Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On Mon, Sep 21, 2020 at 08:11:57PM +0100, Matthew Wilcox wrote: > This is awkward. I'd like it if we had a vfree() variant which called > put_page() instead of __free_pages(). I'd like it even more if we > used release_pages() instead of our own loop that called put_page(). Note that we don't need a new vfree variant, we can do this manually if we want, take a look at kernel/dma/remap.c. But I thought this code intentionally doesn't want to do that to avoid locking in the memory for the pages array. Maybe the i915 maintainers can clarify. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm-intel tree
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/selftests/mock_gem_device.c
between commit:
9f9f4101fc98 ("drm/i915/selftests: Push the fake iommu device from the stack
to data")
from the drm-intel tree and commit:
cd01269d11a3 ("drm/i915/selftests: align more to real device lifetimes")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 397c313a8b69,c207d2239791..
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@@ -118,12 -116,11 +116,11 @@@ static struct dev_pm_domain pm_domain
struct drm_i915_private *mock_gem_device(void)
{
- struct drm_i915_private *i915;
- struct pci_dev *pdev;
#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
- struct dev_iommu iommu;
+ static struct dev_iommu fake_iommu = { .priv = (void *)-1 };
#endif
+ struct drm_i915_private *i915;
+ struct pci_dev *pdev;
- int err;
pdev = kzalloc(sizeof(*pdev), GFP_KERNEL);
if (!pdev)
@@@ -141,11 -132,28 +132,26 @@@
dma_coerce_mask_and_coherent(&pdev->dev, DMA_BIT_MASK(64));
#if IS_ENABLED(CONFIG_IOMMU_API) && defined(CONFIG_INTEL_IOMMU)
- /* HACK HACK HACK to disable iommu for the fake device; force identity
mapping */
- memset(&iommu, 0, sizeof(iommu));
- iommu.priv = (void *)-1;
- pdev->dev.iommu = &iommu;
+ /* HACK to disable iommu for the fake device; force identity mapping */
+ pdev->dev.iommu = &fake_iommu;
#endif
+ if (!devres_open_group(&pdev->dev, NULL, GFP_KERNEL)) {
+ put_device(&pdev->dev);
+ return NULL;
+ }
+
+ i915 = devm_drm_dev_alloc(&pdev->dev, &mock_driver,
+ struct drm_i915_private, drm);
+ if (IS_ERR(i915)) {
+ pr_err("Failed to allocate mock GEM device: err=%ld\n",
PTR_ERR(i915));
+ devres_release_group(&pdev->dev, NULL);
+ put_device(&pdev->dev);
+
+ return NULL;
+ }
pci_set_drvdata(pdev, i915);
+ i915->drm.pdev = pdev;
dev_pm_domain_set(&pdev->dev, &pm_domain);
pm_runtime_enable(&pdev->dev);
pgpwdguEmv59V.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Update to use firmware v49.0.1
On 9/21/2020 5:38 PM, John Harrison wrote:
On 9/21/2020 17:24, Daniele Ceraolo Spurio wrote:
On 9/21/2020 10:54 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the instance in bits [3..6].
NOTE: this patch breaks pointer dereferences in some existing GuC
functions that use the guc_id to dereference arrays but these
functions
are not used for now as we have GuC submission disabled and we will
update these functions in follow up patch which requires new IDs.
* The new GuC requires the additional data structure (ADS) and
associated
'private_data' pointer to be setup. This is basically a scratch area
of memory that the GuC owns. The size is read from the CSS header.
* There is now a physical to logical engine mapping table in the ADS
which needs to be configured in order for the firmware to load. For
now, the table is initialised with a 1 to 1 mapping.
* GUC_CTL_CTXINFO has been removed from the initialization params.
* reg_state_buffer is maintained internally by the GuC as part of
the private data.
* The ADS layout has changed significantly. This patch updates the
shared structure and also adds better documentation of the layout.
* While i915 does not use GuC doorbells, the firmware now requires
that some initialisation is done.
* The number of engine classes and instances supported in the ADS has
been increased.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
Signed-off-by: Michel Thierry
Signed-off-by: Rodrigo Vivi
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 18 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 131
+++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 82 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 5 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 27 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 +-
8 files changed, 182 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1985772152bf..3fb52fac0d5d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -305,8 +305,9 @@ static int intel_engine_setup(struct intel_gt
*gt, enum intel_engine_id id)
engine->i915 = i915;
engine->gt = gt;
engine->uncore = gt->uncore;
- engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
+ engine->hw_id = info->hw_id;
+ engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
engine->class = info->class;
engine->instance = info->instance;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 942c7c187adb..6909da1e1a73 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -213,23 +213,6 @@ static u32 guc_ctl_feature_flags(struct
intel_guc *guc)
return flags;
}
-static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
-{
- u32 flags = 0;
-
- if (intel_guc_submission_is_used(guc)) {
- u32 ctxnum, base;
-
- base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
- ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
-
- base >>= PAGE_SHIFT;
- flags |= (base << GUC_CTL_BASE_ADDR_SHIFT) |
- (ctxnum << GUC_CTL_CTXNUM_IN16_SHIFT);
- }
- return flags;
-}
-
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >>
PAGE_SHIFT;
@@ -291,7 +274,6 @@ static void guc_init_params(struct intel_guc *guc)
BUILD_BUG_ON(sizeof(guc->params) != GUC_CTL_MAX_DWORDS *
sizeof(u32));
- params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);
params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index d44061033f23..7950d28beb8c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -10,11 +10,52 @@
/*
* The Additional Data Struct (ADS) has pointers for different
buffers used by
- * the GuC. One single gem object contains the ADS struct itself
(guc_ads), the
- * scheduling policies (guc_policies), a structure describing a
collection of
- * register sets (guc_mmio_reg_stat
Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Update to use firmware v49.0.1
On 9/21/2020 17:24, Daniele Ceraolo Spurio wrote:
On 9/21/2020 10:54 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the instance in bits [3..6].
NOTE: this patch breaks pointer dereferences in some existing GuC
functions that use the guc_id to dereference arrays but these
functions
are not used for now as we have GuC submission disabled and we will
update these functions in follow up patch which requires new IDs.
* The new GuC requires the additional data structure (ADS) and
associated
'private_data' pointer to be setup. This is basically a scratch area
of memory that the GuC owns. The size is read from the CSS header.
* There is now a physical to logical engine mapping table in the ADS
which needs to be configured in order for the firmware to load. For
now, the table is initialised with a 1 to 1 mapping.
* GUC_CTL_CTXINFO has been removed from the initialization params.
* reg_state_buffer is maintained internally by the GuC as part of
the private data.
* The ADS layout has changed significantly. This patch updates the
shared structure and also adds better documentation of the layout.
* While i915 does not use GuC doorbells, the firmware now requires
that some initialisation is done.
* The number of engine classes and instances supported in the ADS has
been increased.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
Signed-off-by: Michel Thierry
Signed-off-by: Rodrigo Vivi
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 3 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 18 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 131 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 82 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 5 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 27 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 +-
8 files changed, 182 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1985772152bf..3fb52fac0d5d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -305,8 +305,9 @@ static int intel_engine_setup(struct intel_gt
*gt, enum intel_engine_id id)
engine->i915 = i915;
engine->gt = gt;
engine->uncore = gt->uncore;
- engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
+ engine->hw_id = info->hw_id;
+ engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
engine->class = info->class;
engine->instance = info->instance;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 942c7c187adb..6909da1e1a73 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -213,23 +213,6 @@ static u32 guc_ctl_feature_flags(struct
intel_guc *guc)
return flags;
}
-static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
-{
- u32 flags = 0;
-
- if (intel_guc_submission_is_used(guc)) {
- u32 ctxnum, base;
-
- base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
- ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
-
- base >>= PAGE_SHIFT;
- flags |= (base << GUC_CTL_BASE_ADDR_SHIFT) |
- (ctxnum << GUC_CTL_CTXNUM_IN16_SHIFT);
- }
- return flags;
-}
-
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >>
PAGE_SHIFT;
@@ -291,7 +274,6 @@ static void guc_init_params(struct intel_guc *guc)
BUILD_BUG_ON(sizeof(guc->params) != GUC_CTL_MAX_DWORDS *
sizeof(u32));
- params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);
params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index d44061033f23..7950d28beb8c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -10,11 +10,52 @@
/*
* The Additional Data Struct (ADS) has pointers for different
buffers used by
- * the GuC. One single gem object contains the ADS struct itself
(guc_ads), the
- * scheduling policies (guc_policies), a structure describing a
collection of
- * register sets (guc_mmio_reg_state) and some extra pages for the
GuC to save
-
Re: [Intel-gfx] [PATCH 2/4] drm/i915/guc: Improved reporting when GuC fails to load
On 9/21/2020 10:54 AM, john.c.harri...@intel.com wrote:
From: John Harrison
Rather than just saying 'GuC failed to load: -110', actually print out
the GuC status register and break it down into the individual fields.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index d4a87f4c9421..eac84baf34e6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -74,8 +74,9 @@ static inline bool guc_ready(struct intel_uncore *uncore, u32
*status)
((val & GS_MIA_CORE_STATE) && (uk_val ==
GS_UKERNEL_LAPIC_DONE));
}
-static int guc_wait_ucode(struct intel_uncore *uncore)
+static int guc_wait_ucode(struct intel_gt *gt)
No need to pass the GT here, you already have i915 in the uncore
structure and you don't seem to be using the GT for anything else.
{
+ struct intel_uncore *uncore = gt->uncore;
u32 status;
int ret;
@@ -91,16 +92,32 @@ static int guc_wait_ucode(struct intel_uncore *uncore)
DRM_DEBUG_DRIVER("GuC status %#x\n", status);
if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
- DRM_ERROR("GuC firmware signature verification failed\n");
+ drm_err(>->i915->drm, "GuC firmware signature verification
failed\n");
ret = -ENOEXEC;
+ goto out;
}
if ((status & GS_UKERNEL_MASK) == GS_UKERNEL_EXCEPTION) {
- DRM_ERROR("GuC firmware exception. EIP: %#x\n",
- intel_uncore_read(uncore, SOFT_SCRATCH(13)));
+ drm_err(>->i915->drm, "GuC firmware exception. EIP: %#x\n",
+ intel_uncore_read(uncore, SOFT_SCRATCH(13)));
ret = -ENXIO;
+ goto out;
}
+ if (ret) {
+ drm_err(>->i915->drm, "GuC load failed: status: Reset = %d, "
+ "BootROM = 0x%02X, UKernel = 0x%02X, "
+ "MIA = 0x%02X, Auth = 0x%02X\n",
+ (status >> GS_RESET_SHIFT) & 1,
+ (status & GS_BOOTROM_MASK) >> GS_BOOTROM_SHIFT,
Could use the REG_FIELD_GET macro here and below to simplify the code
+ (status & GS_UKERNEL_MASK) >> GS_UKERNEL_SHIFT,
+ (status & GS_MIA_MASK) >> GS_MIA_SHIFT,
+ (status & GS_AUTH_STATUS_MASK) >> GS_AUTH_STATUS_SHIFT);
IMO it'd be worth printing the status breakdown for all failures cases,
even the 2 above, but not a blocker.
With the function parameter flipped back to uncore, this is:
Reviewed-by: Daniele Ceraolo Spurio
Daniele
+ }
+
+out:
+ if (ret)
+ drm_err(>->i915->drm, "GuC load failed: status = 0x%08X\n",
status);
return ret;
}
@@ -139,7 +156,7 @@ int intel_guc_fw_upload(struct intel_guc *guc)
if (ret)
goto out;
- ret = guc_wait_ucode(uncore);
+ ret = guc_wait_ucode(gt);
if (ret)
goto out;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
Hi Logan, On 9/21/20 11:48 PM, Logan Gunthorpe wrote: On 2020-09-20 12:36 a.m., Lu Baolu wrote: Hi Logan, On 2020/9/19 4:47, Logan Gunthorpe wrote: Hi Lu, On 2020-09-11 9:21 p.m., Lu Baolu wrote: Tom Murphy has almost done all the work. His latest patch series was posted here. https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ Thanks a lot! This series is a follow-up with below changes: 1. Add a quirk for the i915 driver issue described in Tom's cover letter. 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use bounce buffers" to make the bounce buffer work for untrusted devices. 3. Several cleanups in iommu/vt-d driver after the conversion. I'm trying to test this on an old Sandy Bridge, but found that I get spammed with warnings on boot. I've put a sample of a few of them below. They all seem to be related to ioat. I had the same issue with Tom's v2 but never saw this on his v1. Have you verified whether this could be reproduced with the lasted upstream kernel (without this patch series)? Yes. I am sorry. Just want to make sure I understand you correctly. :-) When you say "yes", do you mean you could reproduce this with pure upstream kernel (5.9-rc6)? Also, it's hitting a warning in the dma-iommu code which would not be hit without this patch set. Without this series, DMA APIs don't go through dma-iommu. Do you mind posting the warning message? Best regards, baolu ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915/guc: Update to use firmware v49.0.1
On 9/21/2020 10:54 AM, john.c.harri...@intel.com wrote:
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the instance in bits [3..6].
NOTE: this patch breaks pointer dereferences in some existing GuC
functions that use the guc_id to dereference arrays but these functions
are not used for now as we have GuC submission disabled and we will
update these functions in follow up patch which requires new IDs.
* The new GuC requires the additional data structure (ADS) and associated
'private_data' pointer to be setup. This is basically a scratch area
of memory that the GuC owns. The size is read from the CSS header.
* There is now a physical to logical engine mapping table in the ADS
which needs to be configured in order for the firmware to load. For
now, the table is initialised with a 1 to 1 mapping.
* GUC_CTL_CTXINFO has been removed from the initialization params.
* reg_state_buffer is maintained internally by the GuC as part of
the private data.
* The ADS layout has changed significantly. This patch updates the
shared structure and also adds better documentation of the layout.
* While i915 does not use GuC doorbells, the firmware now requires
that some initialisation is done.
* The number of engine classes and instances supported in the ADS has
been increased.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
Signed-off-by: Michel Thierry
Signed-off-by: Rodrigo Vivi
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 18 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 131 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 82 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 5 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 27 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 +-
8 files changed, 182 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1985772152bf..3fb52fac0d5d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -305,8 +305,9 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
engine->i915 = i915;
engine->gt = gt;
engine->uncore = gt->uncore;
- engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
+ engine->hw_id = info->hw_id;
+ engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
engine->class = info->class;
engine->instance = info->instance;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 942c7c187adb..6909da1e1a73 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -213,23 +213,6 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
return flags;
}
-static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
-{
- u32 flags = 0;
-
- if (intel_guc_submission_is_used(guc)) {
- u32 ctxnum, base;
-
- base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
- ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
-
- base >>= PAGE_SHIFT;
- flags |= (base << GUC_CTL_BASE_ADDR_SHIFT) |
- (ctxnum << GUC_CTL_CTXNUM_IN16_SHIFT);
- }
- return flags;
-}
-
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
@@ -291,7 +274,6 @@ static void guc_init_params(struct intel_guc *guc)
BUILD_BUG_ON(sizeof(guc->params) != GUC_CTL_MAX_DWORDS * sizeof(u32));
- params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);
params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index d44061033f23..7950d28beb8c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -10,11 +10,52 @@
/*
* The Additional Data Struct (ADS) has pointers for different buffers used by
- * the GuC. One single gem object contains the ADS struct itself (guc_ads), the
- * scheduling policies (guc_policies), a structure describing a collection of
- * register sets (guc_mmio_reg_state) and some extra pages fo
Re: [Intel-gfx] [PATCH] drm/i915/dp: Tweak initial dpcd backlight.enabled value
So if I understand this correctly, it sounds like that some Pixelbooks boot up
with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
panel actually having DPCD backlight controls enabled?
If I'm understanding that correctly, then this patch looks good to me:
Reviewed-by: Lyude Paul
On Thu, 2020-09-17 at 20:28 -0400, Sean Paul wrote:
> From: Sean Paul
>
> In commit 79946723092b ("drm/i915: Assume 100% brightness when not in
> DPCD control mode"), we fixed the brightness level when DPCD control was
> not active to max brightness. This is as good as we can guess since most
> backlights go on full when uncontrolled.
>
> However in doing so we changed the semantics of the initial
> 'backlight.enabled' value. At least on Pixelbooks, they were relying
> on the brightness level in DP_EDP_BACKLIGHT_BRIGHTNESS_MSB to be 0 on
> boot such that enabled would be false. This causes the device to be
> enabled when the brightness is set. Without this, brightness control
> doesn't work. So by changing brightness to max, we also flipped enabled
> to be true on boot.
>
> To fix this, make enabled a function of brightness and backlight control
> mechanism.
>
> Fixes: 79946723092b ("drm/i915: Assume 100% brightness when not in DPCD
> control mode")
> Cc: Lyude Paul
> Cc: Jani Nikula
> Cc: Juha-Pekka Heikkila
> Cc: "Ville Syrjälä"
> Cc: Rodrigo Vivi
> Cc: Kevin Chowski >
> Signed-off-by: Sean Paul
> ---
> .../drm/i915/display/intel_dp_aux_backlight.c | 31 ---
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> index acbd7eb66cbe..036f504ac7db 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
> @@ -52,17 +52,11 @@ static void set_aux_backlight_enable(struct intel_dp
> *intel_dp, bool enable)
> }
> }
>
> -/*
> - * Read the current backlight value from DPCD register(s) based
> - * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> - */
> -static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> +static bool intel_dp_aux_backlight_dpcd_mode(struct intel_connector
> *connector)
> {
> struct intel_dp *intel_dp = intel_attached_dp(connector);
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> - u8 read_val[2] = { 0x0 };
> u8 mode_reg;
> - u16 level = 0;
>
> if (drm_dp_dpcd_readb(&intel_dp->aux,
> DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> @@ -70,15 +64,29 @@ static u32 intel_dp_aux_get_backlight(struct
> intel_connector *connector)
> drm_dbg_kms(&i915->drm,
> "Failed to read the DPCD register 0x%x\n",
> DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> - return 0;
> + return false;
> }
>
> + return (mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
> +DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
> +}
> +
> +/*
> + * Read the current backlight value from DPCD register(s) based
> + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported
> + */
> +static u32 intel_dp_aux_get_backlight(struct intel_connector *connector)
> +{
> + struct intel_dp *intel_dp = intel_attached_dp(connector);
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + u8 read_val[2] = { 0x0 };
> + u16 level = 0;
> +
> /*
>* If we're not in DPCD control mode yet, the programmed brightness
>* value is meaningless and we should assume max brightness
>*/
> - if ((mode_reg & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) !=
> - DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD)
> + if (!intel_dp_aux_backlight_dpcd_mode(connector))
> return connector->panel.backlight.max;
>
> if (drm_dp_dpcd_read(&intel_dp->aux, DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
> @@ -319,7 +327,8 @@ static int intel_dp_aux_setup_backlight(struct
> intel_connector *connector,
>
> panel->backlight.min = 0;
> panel->backlight.level = intel_dp_aux_get_backlight(connector);
> - panel->backlight.enabled = panel->backlight.level != 0;
> + panel->backlight.enabled = intel_dp_aux_backlight_dpcd_mode(connector)
> &&
> +panel->backlight.level != 0;
>
> return 0;
> }
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
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 drm/i915/guc: Update to GuC v49
On 9/21/2020 13:36, Daniele Ceraolo Spurio wrote: On 9/21/2020 12:22 PM, John Harrison wrote: On 9/16/2020 23:48, Petri Latvala wrote: On Wed, Sep 16, 2020 at 06:22:45PM -0700, John Harrison wrote: Hello, The failures below all appear to be because the new GuC firmware was not found on the test system. My understanding is that all we need to do to get the CI system to update with new firmwares is to push the firmware to a branch on the FDO drm-firmware repo and then send a pull request to this mailing list. That was done yesterday. That pull request used an ssh:// url though. Can you send it again with a git:// url? I suppose that's a plausible reason why I don't see the binaries in CI's deploy dir. Hello, We reset the pull request with a git:// URL as requested. I even gave it a full weekend to propagate through. However, I am still getting missing firmware failures after posting a new patch set. John. You sure you're looking at the correct logs? AFAICS BAT on the new patches passed (https://patchwork.freedesktop.org/series/81906/) and I see the correct GuC being loaded in the logs. e.g. https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-icl-u2/boot0.txt: <6>[ 9.283866] i915 :00:02.0: [drm] GuC firmware i915/icl_guc_49.0.1.bin version 49.0 submission:disabled Daniele Grrr. When I downloaded the dmesg.txt it saved is as dmesg.txt.1. So yes, I was looking at a stale log :(. I guess the other question is are we supposed to be supporting HuC by default on KBL? It is running the gem_huc_copy test but we have only enabled GuC/HuC loading on Gen11+ platforms. John. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v6 10/11] drm/i915: Add intel_update_bigjoiner handling.
On Mon, Sep 14, 2020 at 12:21:26PM -0700, Navare, Manasi wrote:
> On Thu, Sep 03, 2020 at 10:23:35PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:21PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst
> > >
> > > Enabling is done in a special sequence and so should plane updates
> > > be. Ideally the end user never notices the second pipe is used,
> > > so use the vblank evasion to cover both pipes.
> > >
> > > This way ideally everything will be tear free, and updates are
> > > really atomic as userspace expects it.
> > >
> > > This needs to be checked if it still works since lot of refactoring
> > > in skl_commit_modeset_enables
> > >
> > > v2:
> > > * Manual Rebase (Manasi)
> > > * Refactoring on intel_update_crtc and enable_crtc and removing
> > > special trans_port_sync_update (Manasi)
> > >
> > > Signed-off-by: Maarten Lankhorst
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 120 +--
> > > drivers/gpu/drm/i915/display/intel_sprite.c | 25 +++-
> > > drivers/gpu/drm/i915/display/intel_sprite.h | 3 +-
> > > 3 files changed, 129 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index a1011414da6d..00b26863ffc6 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -15656,7 +15656,7 @@ static void intel_update_crtc(struct
> > > intel_atomic_state *state,
> > > else
> > > i9xx_update_planes_on_crtc(state, crtc);
> > >
> > > - intel_pipe_update_end(new_crtc_state);
> > > + intel_pipe_update_end(new_crtc_state, NULL);
> > >
> > > /*
> > >* We usually enable FIFO underrun interrupts as part of the
> > > @@ -15754,6 +15754,52 @@ static void intel_commit_modeset_disables(struct
> > > intel_atomic_state *state)
> > > }
> > > }
> > >
> > > +static void intel_update_bigjoiner(struct intel_crtc *crtc,
> > > +struct intel_atomic_state *state,
> > > +struct intel_crtc_state *old_crtc_state,
> > > +struct intel_crtc_state *new_crtc_state)
> > > +{
> > > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > + bool modeset = needs_modeset(new_crtc_state);
> > > + struct intel_crtc *slave = new_crtc_state->bigjoiner_linked_crtc;
> > > + struct intel_crtc_state *new_slave_crtc_state =
> > > + intel_atomic_get_new_crtc_state(state, slave);
> > > +
> > > + if (modeset) {
> > > + /* Enable slave first */
> > > + intel_crtc_update_active_timings(new_slave_crtc_state);
> > > + dev_priv->display.crtc_enable(state, slave);
> > > +
> > > + /* Then master */
> > > + intel_crtc_update_active_timings(new_crtc_state);
> > > + dev_priv->display.crtc_enable(state, crtc);
> > > +
> > > + /* vblanks work again, re-enable pipe CRC. */
> > > + intel_crtc_enable_pipe_crc(crtc);
> > > +
> > > + } else {
> > > + intel_pre_plane_update(state, crtc);
> > > + intel_pre_plane_update(state, slave);
> > > +
> > > + if (new_crtc_state->update_pipe)
> > > + intel_encoders_update_pipe(state, crtc);
> > > + }
> > > +
> > > + /*
> > > + * Perform vblank evasion around commit operation, and make sure to
> > > + * commit both planes simultaneously for best results.
> > > + */
> > > + intel_pipe_update_start(new_crtc_state);
> > > +
> > > + commit_pipe_config(state, crtc);
> > > + commit_pipe_config(state, slave);
> > > +
> > > + skl_update_planes_on_crtc(state, crtc);
> > > + skl_update_planes_on_crtc(state, slave);
> > > +
> > > + intel_pipe_update_end(new_crtc_state, new_slave_crtc_state);
> > > +}
> >
> > I think this should ideally all go away and just the normal logic
> > in commit_modeset_enables() should deal with it. Just like it does
> > for port sync/mst pipe dependencies.
> >
>
> Yes I think so too. Except for the intel_pipe_update_end where
> now we send the new_slave_crtc_state() so thats still something I need to
> figure
> how it will work in normal code without special bigjoiner handling.
>
> I think the 2p2p transcoder ports sync code initially had a special trans
> port sync handling
> function and thats why this was written this way but with the new code we
> just use
> the regular modeset_enables function with no special handling
>
> Manasi
>
> > > +
> > > static void intel_commit_modeset_enables(struct intel_atomic_state
> > > *state)
> > > {
> > > struct intel_crtc_state *new_crtc_state;
> > > @@ -15772,15 +15818,22 @@ static void intel_commit_modeset_enables(struct
> > > intel_atomic_state *state)
> > > static void skl_commit_modeset_enables(struct intel_atomic_state *state)
> > > {
> > > struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > > - struct intel_crtc *crtc;
Re: [Intel-gfx] [PATCH v6 02/11] drm/i915: Remove hw.mode
On Mon, Sep 14, 2020 at 09:52:57PM +0300, Ville Syrjälä wrote:
> On Mon, Sep 14, 2020 at 11:32:48AM -0700, Navare, Manasi wrote:
> > On Mon, Sep 07, 2020 at 03:35:23PM +0300, Ville Syrjälä wrote:
> > > On Thu, Sep 03, 2020 at 09:40:44PM +0300, Ville Syrjälä wrote:
> > > > On Thu, Sep 03, 2020 at 11:04:33AM -0700, Navare, Manasi wrote:
> > > > > On Thu, Sep 03, 2020 at 08:49:44PM +0300, Ville Syrjälä wrote:
> > > > > > On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> > > > > > > From: Maarten Lankhorst
> > > > > > >
> > > > > > > The members in hw.mode can be used from adjusted_mode as well,
> > > > > > > use that when available.
> > > > > > >
> > > > > > > Some places that use hw.mode can be converted to use adjusted_mode
> > > > > > > as well.
> > > > > > >
> > > > > > > v2:
> > > > > > > * Manual rebase (Manasi)
> > > > > > > * remove the use of pipe_mode defined in patch 3 (Manasi)
> > > > > > >
> > > > > > > v3:
> > > > > > > * Rebase on drm-tip (Manasi)
> > > > > >
> > > > > > Previous review was apparently ignored. Or is there a better version
> > > > > > somewhere? If not, this still looks very wrong.
> > > > >
> > > > > This was the latest rev that Maarten had in his local tree which he
> > > > > said should address all the review comments.
> > > > > What in particular looks wrong or what review comments were
> > > > > unaddressed here?
> > > >
> > > > The dvo/sdvo changes.
> > >
> > > I recommend just dropping this patch entirely. It doesn't seem to have
> > > anything to do with the bigjoiner anyway.
> >
> > So for the dvo/svdo changes, no need to use the adjusted_mode instead keep
> > using hw.mode?
> > How about other cleanups like: intel_crtc_copy_hw_to_uapi_state(crtc_state,
> > &mode); and
> > static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
> > *crtc_state,
> > +struct drm_display_mode *user_mode)
> >
> > You think we dont need mode as an argument there either?
>
> Not in this patch if all the other stuff disappears. No idea if some
> later patch might need something like it.
Hi Ville,
So this patch basically removes the hw.mode and just keeps hw.adjusted_mode
So no need to remove that?
But basically from this patch onwards we say that there is hw.pipe_mode
and hw.adjusted_mode, there is no hw.mode.
Are you suggesting keeping hw.mode as well? Would this be replacing
hw.pipe_mode then?
Manasi
>
> >
> > Manasi
> > >
> > > >
> > > > >
> > > > > @Maarten any feedback on Ville's unaddressed comments?
> > > > >
> > > > > Manasi
> > > > >
> > > > > >
> > > > > > >
> > > > > > > Signed-off-by: Maarten Lankhorst
> > > > > > >
> > > > > > > Signed-off-by: Manasi Navare
> > > > > > > ---
> > > > > > > drivers/gpu/drm/i915/display/intel_display.c | 29
> > > > > > > ++-
> > > > > > > .../drm/i915/display/intel_display_types.h| 2 +-
> > > > > > > drivers/gpu/drm/i915/display/intel_dvo.c | 2 +-
> > > > > > > drivers/gpu/drm/i915/display/intel_sdvo.c | 16 --
> > > > > > > 4 files changed, 23 insertions(+), 26 deletions(-)
> > > > > > >
> > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > index 729ec6e0d43a..8652a7c6bf11 100644
> > > > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > > > @@ -8892,9 +8892,6 @@ static void intel_get_pipe_src_size(struct
> > > > > > > intel_crtc *crtc,
> > > > > > > tmp = intel_de_read(dev_priv, PIPESRC(crtc->pipe));
> > > > > > > pipe_config->pipe_src_h = (tmp & 0x) + 1;
> > > > > > > pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> > > > > > > -
> > > > > > > - pipe_config->hw.mode.vdisplay = pipe_config->pipe_src_h;
> > > > > > > - pipe_config->hw.mode.hdisplay = pipe_config->pipe_src_w;
> > > > > > > }
> > > > > > >
> > > > > > > void intel_mode_from_pipe_config(struct drm_display_mode *mode,
> > > > > > > @@ -13079,7 +13076,7 @@ static void intel_dump_pipe_config(const
> > > > > > > struct intel_crtc_state *pipe_config,
> > > > > > > intel_dump_dp_vsc_sdp(dev_priv,
> > > > > > > &pipe_config->infoframes.vsc);
> > > > > > >
> > > > > > > drm_dbg_kms(&dev_priv->drm, "requested mode:\n");
> > > > > > > - drm_mode_debug_printmodeline(&pipe_config->hw.mode);
> > > > > > > + drm_mode_debug_printmodeline(&pipe_config->uapi.mode);
> > > > > > > drm_dbg_kms(&dev_priv->drm, "adjusted mode:\n");
> > > > > > > drm_mode_debug_printmodeline(&pipe_config->hw.adjusted_mode);
> > > > > > > intel_dump_crtc_timings(dev_priv,
> > > > > > > &pipe_config->hw.adjusted_mode);
> > > > > > > @@ -13221,17 +13218,17 @@ intel_crtc_copy_uapi_to_hw_state(struct
> > > > > > > intel_crtc_state *crtc_state)
> > > > > > > {
> > > > > > > crtc_state->hw.enable = crtc_state->uapi.enable;
> > > > > > > crtc_state->hw.active = crt
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Update to GuC v49
On 9/21/2020 12:22 PM, John Harrison wrote: On 9/16/2020 23:48, Petri Latvala wrote: On Wed, Sep 16, 2020 at 06:22:45PM -0700, John Harrison wrote: Hello, The failures below all appear to be because the new GuC firmware was not found on the test system. My understanding is that all we need to do to get the CI system to update with new firmwares is to push the firmware to a branch on the FDO drm-firmware repo and then send a pull request to this mailing list. That was done yesterday. That pull request used an ssh:// url though. Can you send it again with a git:// url? I suppose that's a plausible reason why I don't see the binaries in CI's deploy dir. Hello, We reset the pull request with a git:// URL as requested. I even gave it a full weekend to propagate through. However, I am still getting missing firmware failures after posting a new patch set. John. You sure you're looking at the correct logs? AFAICS BAT on the new patches passed (https://patchwork.freedesktop.org/series/81906/) and I see the correct GuC being loaded in the logs. e.g. https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-icl-u2/boot0.txt: <6>[ 9.283866] i915 :00:02.0: [drm] GuC firmware i915/icl_guc_49.0.1.bin version 49.0 submission:disabled Daniele ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Update to GuC v49
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/81906/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9027_full -> Patchwork_18542_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_18542_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18542_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_18542_full:
### IGT changes ###
Warnings
* igt@gem_ctx_shared@disjoint-timelines:
- shard-hsw: [SKIP][1] ([fdo#109271]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-hsw4/igt@gem_ctx_sha...@disjoint-timelines.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/shard-hsw4/igt@gem_ctx_sha...@disjoint-timelines.html
- shard-snb: [SKIP][3] ([fdo#109271]) -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-snb1/igt@gem_ctx_sha...@disjoint-timelines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/shard-snb4/igt@gem_ctx_sha...@disjoint-timelines.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@core_hotunplug@hotrebind-lateclose}:
- shard-iclb: [FAIL][5] ([i915#2476]) -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-iclb2/igt@core_hotunp...@hotrebind-lateclose.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/shard-iclb4/igt@core_hotunp...@hotrebind-lateclose.html
### Piglit changes ###
Possible regressions
* spec@glsl-1.50@execution@built-in-functions@gs-clamp-int-int-int (NEW):
- pig-snb-2600: NOTRUN -> [FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/pig-snb-2600/spec@glsl-1.50@execution@built-in-functi...@gs-clamp-int-int-int.html
New tests
-
New tests have been introduced between CI_DRM_9027_full and
Patchwork_18542_full:
### New Piglit tests (1) ###
* spec@glsl-1.50@execution@built-in-functions@gs-clamp-int-int-int:
- Statuses : 1 fail(s)
- Exec time: [0.19] s
Known issues
Here are the changes found in Patchwork_18542_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_param@vm:
- shard-skl: [PASS][8] -> [DMESG-WARN][9] ([i915#1982]) +6 similar
issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl6/igt@gem_ctx_pa...@vm.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/shard-skl4/igt@gem_ctx_pa...@vm.html
* igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd:
- shard-apl: [PASS][10] -> [FAIL][11] ([i915#1635] / [i915#2374])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-apl8/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/shard-apl6/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html
* igt@gem_exec_reloc@basic-many-active@bcs0:
- shard-glk: [PASS][12] -> [FAIL][13] ([i915#2389])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-glk9/igt@gem_exec_reloc@basic-many-act...@bcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/shard-glk3/igt@gem_exec_reloc@basic-many-act...@bcs0.html
* igt@gem_exec_suspend@basic-s3:
- shard-kbl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +4
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-kbl7/igt@gem_exec_susp...@basic-s3.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/shard-kbl6/igt@gem_exec_susp...@basic-s3.html
* igt@i915_pm_rc6_residency@rc6-fence:
- shard-hsw: [PASS][16] -> [WARN][17] ([i915#1519])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-hsw2/igt@i915_pm_rc6_reside...@rc6-fence.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/shard-hsw1/igt@i915_pm_rc6_reside...@rc6-fence.html
* igt@i915_selftest@mock@contexts:
- shard-apl: [PASS][18] -> [INCOMPLETE][19] ([i915#1635] /
[i915#2278])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-apl7/igt@i915_selftest@m...@contexts.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/shard-apl1/igt@i915_selftest@m...@contexts.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- shard-apl: [PASS][20] -> [DMESG-WARN][21] ([i915#1635] /
[i915#1982])
[20]:
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Sat, Sep 19, 2020 at 06:39:06PM +0100, Matthew Wilcox wrote:
> On Sat, Sep 19, 2020 at 10:18:54AM -0700, Linus Torvalds wrote:
> > On Sat, Sep 19, 2020 at 2:50 AM Thomas Gleixner wrote:
> > >
> > > this provides a preemptible variant of kmap_atomic & related
> > > interfaces. This is achieved by:
> >
> > Ack. This looks really nice, even apart from the new capability.
> >
> > The only thing I really reacted to is that the name doesn't make sense
> > to me: "kmap_temporary()" seems a bit odd.
> >
> > Particularly for an interface that really is basically meant as a
> > better replacement of "kmap_atomic()" (but is perhaps also a better
> > replacement for "kmap()").
> >
> > I think I understand how the name came about: I think the "temporary"
> > is there as a distinction from the "longterm" regular kmap(). So I
> > think it makes some sense from an internal implementation angle, but I
> > don't think it makes a lot of sense from an interface name.
> >
> > I don't know what might be a better name, but if we want to emphasize
> > that it's thread-private and a one-off, maybe "local" would be a
> > better naming, and make it distinct from the "global" nature of the
> > old kmap() interface?
> >
> > However, another solution might be to just use this new preemptible
> > "local" kmap(), and remove the old global one entirely. Yes, the old
> > global one caches the page table mapping and that sounds really
> > efficient and nice. But it's actually horribly horribly bad, because
> > it means that we need to use locking for them. Your new "temporary"
> > implementation seems to be fundamentally better locking-wise, and only
> > need preemption disabling as locking (and is equally fast for the
> > non-highmem case).
> >
> > So I wonder if the single-page TLB flush isn't a better model, and
> > whether it wouldn't be a lot simpler to just get rid of the old
> > complex kmap() entirely, and replace it with this?
> >
> > I agree we can't replace the kmap_atomic() version, because maybe
> > people depend on the preemption disabling it also implied. But what
> > about replacing the non-atomic kmap()?
>
> My concern with that is people might use kmap() and then pass the address
> to a different task. So we need to audit the current users of kmap()
> and convert any that do that into using vmap() instead.
>
I've done some of this work.[3] PKS and pmem stray write protection[2] depend
on kmap to enable the correct PKS settings. After working through the
exception handling we realized that some users of kmap() seem to be doing just
this; passing the address to a different task.
>From what I have found ~90% of kmap() callers are 'kmap_thread()' and the other
~10% are kmap().[3] But of those 10% I'm not familiar with the code enough to
know if they really require a 'global' map. What I do know is they save an
address which appears to be used in other threads. But I could be wrong.
For PKS I added a 'global' implementation which could then be called by kmap()
and added a new kmap_thread() call which used the original 'local' version of
the PKS interface. The PKS work is still being reviewed internally for the TIP
core code. But I've pushed it all to git hub for purposes of this
discussion.[1]
> I like kmap_local(). Or kmap_thread().
I chose kmap_thread() so that makes sense to me. I also thought about using
kmap_global() as an alternative interface which would change just ~10% of the
callers and make the series much smaller. But internal discussions lead me to
chose kmap_thread() as the new interface so that we don't change the semantics
of kmap().
Ira
[1] https://github.com/weiny2/linux-kernel/tree/lm-pks-pmem-for-5.10-v3
[2] https://lore.kernel.org/lkml/20200717072056.73134-1-ira.we...@intel.com/
[3]
12:42:06 > git grep ' kmap(' *.c | grep -v '* ' | wc -l
22
12:43:32 > git grep ' kmap_thread(' *.c | grep -v '* ' | wc -l
204
Here are the callers which hand an address to another thread.
12:45:25 > git grep ' kmap(' *.c | grep -v '* '
arch/x86/mm/dump_pagetables.c: [PKMAP_BASE_NR] = { 0UL, "Persistent
kmap() Area" },
drivers/firewire/net.c: ptr = kmap(dev->broadcast_rcv_buffer.pages[u]);
drivers/gpu/drm/i915/gem/i915_gem_pages.c: return
kmap(sg_page(sgt->sgl));
drivers/gpu/drm/i915/selftests/i915_perf.c: scratch =
kmap(ce->vm->scratch[0].base.page);
drivers/gpu/drm/ttm/ttm_bo_util.c: map->virtual = kmap(map->page);
drivers/infiniband/hw/qib/qib_user_sdma.c: mpage = kmap(page);
drivers/misc/vmw_vmci/vmci_host.c: context->notify =
kmap(context->notify_page) + (uva & (PAGE_SIZE - 1));
drivers/misc/xilinx_sdfec.c:addr = kmap(pages[i]);
drivers/mmc/host/usdhi6rol0.c: host->pg.mapped = kmap(host->pg.page);
drivers/mmc/host/usdhi6rol0.c: host->pg.mapped = kmap(host->pg.page);
drivers/mmc/host/usdhi6rol0.c: host->pg.mapped = kmap(host->pg.page);
drivers/nvme/target/tcp.c: iov->iov_base = kmap(sg_page(sg
Re: [Intel-gfx] [PATCH 20/20] drm/i915: Add 10bit gamma mode for gen2/3
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Saturday, July 18, 2020 2:44 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 20/20] drm/i915: Add 10bit gamma mode for gen2/3
>
> From: Ville Syrjälä
>
> Some gen2/gen3 parts have a 10bit gamma mode, on some pipes.
> Expose it.
>
> The format is different to the later i965+ style in that we store a 10bit
> value and
> a 6 bit floating point slope for each entry. Ie. the hardware extrapolates the
> intermediate steps from the current LUT entry, instead of interpolating
> between
> the current and next LUT entries. This also means we don't store the last LUT
> entry in any register as it is defined by the previous LUT entry's
> value+slope.
>
> The slope has limited precision though (2 bit exponent + 4 bit mantissa), so
> we
> have to allow for more error in the state checker for the last entry, and we
> have
> to make sure userspace doesn't pass in something where the slope is simply to
> steep. In theory we should perhaps check the slope for every interval, but we
> don't do that for any other interpolated gamma mode and I suspect they may
> also have some internal limit on the slope. I haven't confirmed that theory
> though. Anyways, only the last entry provides a slight challenge for the state
> checker since all the other entries do have an explicit value stored in a
> register.
Couldn't verify the details from spec. But with the description, was not able
to spot any issue
with the implementation.
Acked-by: Uma Shankar
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 248 -
> drivers/gpu/drm/i915/i915_pci.c| 10 +-
> drivers/gpu/drm/i915/i915_reg.h| 38 +++-
> 3 files changed, 279 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index ca6c6679368c..055a49ed4e3a 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -414,6 +414,79 @@ static void i9xx_lut_8_pack(struct drm_color_lut *entry,
> u32 val)
> entry->blue =
> intel_color_lut_pack(REG_FIELD_GET(LGC_PALETTE_BLUE_MASK, val), 8); }
>
> +/* i8xx/i9xx+ 10bit slope format "even DW" (low 8 bits) */ static u32
> +_i9xx_lut_10_ldw(u16 a) {
> + return drm_color_lut_extract(a, 10) & 0xff; }
> +
> +static u32 i9xx_lut_10_ldw(const struct drm_color_lut *color) {
> + return _i9xx_lut_10_ldw(color[0].red) << 16 |
> + _i9xx_lut_10_ldw(color[0].green) << 8 |
> + _i9xx_lut_10_ldw(color[0].blue);
> +}
> +
> +/* i8xx/i9xx+ 10bit slope format "odd DW" (high 2 bits + slope) */
> +static u32 _i9xx_lut_10_udw(u16 a, u16 b) {
> + unsigned int mantissa, exponent;
> +
> + a = drm_color_lut_extract(a, 10);
> + b = drm_color_lut_extract(b, 10);
> +
> + /* b = a + 8 * m * 2 ^ -e */
> + mantissa = clamp(b - a, 0, 0x7f);
> + exponent = 3;
> + while (mantissa > 0xf) {
> + mantissa >>= 1;
> + exponent--;
> + }
> +
> + return (exponent << 6) |
> + (mantissa << 2) |
> + (a >> 8);
> +}
> +
> +static u32 i9xx_lut_10_udw(const struct drm_color_lut *color) {
> + return _i9xx_lut_10_udw(color[0].red, color[1].red) << 16 |
> + _i9xx_lut_10_udw(color[0].green, color[1].green) << 8 |
> + _i9xx_lut_10_udw(color[0].blue, color[1].blue); }
> +
> +static void i9xx_lut_10_pack(struct drm_color_lut *color,
> + u32 ldw, u32 udw)
> +{
> + u16 red = REG_FIELD_GET(PALETTE_10BIT_RED_LDW_MASK, ldw) |
> + REG_FIELD_GET(PALETTE_10BIT_RED_UDW_MASK, udw) << 8;
> + u16 green = REG_FIELD_GET(PALETTE_10BIT_GREEN_LDW_MASK, ldw) |
> + REG_FIELD_GET(PALETTE_10BIT_GREEN_UDW_MASK, udw) << 8;
> + u16 blue = REG_FIELD_GET(PALETTE_10BIT_BLUE_LDW_MASK, ldw) |
> + REG_FIELD_GET(PALETTE_10BIT_BLUE_UDW_MASK, udw) << 8;
> +
> + color->red = intel_color_lut_pack(red, 10);
> + color->green = intel_color_lut_pack(green, 10);
> + color->blue = intel_color_lut_pack(blue, 10); }
> +
> +static void i9xx_lut_10_pack_slope(struct drm_color_lut *color,
> +u32 ldw, u32 udw)
> +{
> + int r_exp = REG_FIELD_GET(PALETTE_10BIT_RED_EXP_MASK, udw);
> + int r_mant = REG_FIELD_GET(PALETTE_10BIT_RED_MANT_MASK, udw);
> + int g_exp = REG_FIELD_GET(PALETTE_10BIT_GREEN_EXP_MASK, udw);
> + int g_mant = REG_FIELD_GET(PALETTE_10BIT_GREEN_MANT_MASK,
> udw);
> + int b_exp = REG_FIELD_GET(PALETTE_10BIT_BLUE_EXP_MASK, udw);
> + int b_mant = REG_FIELD_GET(PALETTE_10BIT_BLUE_MANT_MASK, udw);
> +
> + i9xx_lut_10_pack(color, ldw, udw);
> +
> + color->red += r_mant << (3 - r_exp);
> + color->green += g_mant << (3 - g_exp);
> + color->blue += b_mant << (3 - b_exp);
> +}
> +
> /* i965+ "10.6" bi
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Mon, Sep 21 2020 at 09:24, Linus Torvalds wrote: > On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote: >> >> If a task is migrated to a different CPU then the mapping address will >> change which will explode in colourful ways. > > Right you are. > > Maybe we really *could* call this new kmap functionality something > like "kmap_percpu()" (or maybe "local" is good enough), and make it > act like your RT code does for spinlocks - not disable preemption, but > only disabling CPU migration. I"m all for it, but the scheduler people have opinions :) > That would probably be good enough for a lot of users that don't want > to expose excessive latencies, but where it's really not a huge deal > to say "stick to this CPU for a short while". > > The crypto code certainly sounds like one such case. I looked at a lot of the kmap_atomic() places and quite some of them only require migration to be disabled to keep the temporary map stable. Quite some code could be simplified significantly especially those places which need to do copy_from/to_user inside these sections. Graphics is the main example here as Daniel pointed out. Alternatively this could of course be solved with per CPU page tables which will come around some day anyway I fear. Thanks, tglx ___ 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 drm/i915/guc: Update to GuC v49
On 9/16/2020 23:48, Petri Latvala wrote: On Wed, Sep 16, 2020 at 06:22:45PM -0700, John Harrison wrote: Hello, The failures below all appear to be because the new GuC firmware was not found on the test system. My understanding is that all we need to do to get the CI system to update with new firmwares is to push the firmware to a branch on the FDO drm-firmware repo and then send a pull request to this mailing list. That was done yesterday. That pull request used an ssh:// url though. Can you send it again with a git:// url? I suppose that's a plausible reason why I don't see the binaries in CI's deploy dir. Hello, We reset the pull request with a git:// URL as requested. I even gave it a full weekend to propagate through. However, I am still getting missing firmware failures after posting a new patch set. John. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: use vmap in shmem_pin_map
On Fri, Sep 18, 2020 at 06:37:21PM +0200, Christoph Hellwig wrote:
> void shmem_unpin_map(struct file *file, void *ptr)
> {
> + long i = shmem_npages(file);
> +
> mapping_clear_unevictable(file->f_mapping);
> - __shmem_unpin_map(file, ptr, shmem_npte(file));
> + vunmap(ptr);
> +
> + for (i = 0; i < shmem_npages(file); i++) {
> + struct page *page;
> +
> + page = shmem_read_mapping_page_gfp(file->f_mapping, i,
> +GFP_KERNEL);
> + if (!WARN_ON(IS_ERR(page))) {
> + put_page(page);
> + put_page(page);
> + }
> + }
> }
This is awkward. I'd like it if we had a vfree() variant which called
put_page() instead of __free_pages(). I'd like it even more if we
used release_pages() instead of our own loop that called put_page().
Perhaps something like this ...
+++ b/mm/vmalloc.c
@@ -2262,7 +2262,7 @@ static void __vunmap(const void *addr, int deallocate_page
s)
vm_remove_mappings(area, deallocate_pages);
- if (deallocate_pages) {
+ if (deallocate_pages == 1) {
int i;
for (i = 0; i < area->nr_pages; i++) {
@@ -2271,8 +2271,12 @@ static void __vunmap(const void *addr, int
deallocate_pages)
BUG_ON(!page);
__free_pages(page, 0);
}
- atomic_long_sub(area->nr_pages, &nr_vmalloc_pages);
+ } else if (deallocate_pages == 2) {
+ release_pages(area->pages, area->nr_pages);
+ }
+ if (deallocate_pages) {
+ atomic_long_sub(area->nr_pages, &nr_vmalloc_pages);
kvfree(area->pages);
}
@@ -2369,6 +2373,14 @@ void vunmap(const void *addr)
}
EXPORT_SYMBOL(vunmap);
+void vunmap_put_pages(const void *addr)
+{
+ BUG_ON(in_interrupt());
+ might_sleep();
+ if (addr)
+ __vunmap(addr, 2);
+}
+
/**
* vmap - map an array of pages into virtually contiguous space
* @pages: array of page pointers
only with kernel-doc and so on. I bet somebody has a better idea for a name.
___
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/guc: Update to GuC v49
== Series Details ==
Series: drm/i915/guc: Update to GuC v49
URL : https://patchwork.freedesktop.org/series/81906/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9027 -> Patchwork_18542
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_18542 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_18542, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_18542:
### IGT changes ###
Warnings
* igt@gem_huc_copy@huc-copy:
- fi-cml-u2: [SKIP][1] ([i915#2190]) -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-cml-u2/igt@gem_huc_c...@huc-copy.html
- fi-cml-s: [SKIP][3] ([i915#2190]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-cml-s/igt@gem_huc_c...@huc-copy.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-cml-s/igt@gem_huc_c...@huc-copy.html
Known issues
Here are the changes found in Patchwork_18542 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92] /
[i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@vgem_basic@unload:
- fi-kbl-x1275: [PASS][7] -> [DMESG-WARN][8] ([i915#62] / [i915#92])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@vgem_ba...@unload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-kbl-x1275/igt@vgem_ba...@unload.html
Possible fixes
* {igt@core_hotunplug@unbind-rebind}:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
* igt@gem_huc_copy@huc-copy:
- {fi-ehl-1}: [SKIP][11] ([i915#2190]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-ehl-1/igt@gem_huc_c...@huc-copy.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-ehl-1/igt@gem_huc_c...@huc-copy.html
- fi-icl-y: [SKIP][13] ([i915#2190]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-icl-y/igt@gem_huc_c...@huc-copy.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-icl-y/igt@gem_huc_c...@huc-copy.html
- fi-icl-u2: [SKIP][15] ([i915#2190]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-icl-u2/igt@gem_huc_c...@huc-copy.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-byt-j1900/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][19] ([i915#1982]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-flip-after-cursor-atomic:
- fi-icl-u2: [DMESG-WARN][21] ([i915#1982]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][23] ([i915#2203]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-skl-guc/igt@vgem_ba...@unload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18542/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@gem_huc_copy@huc-copy:
- fi-skl-6600u: [SKIP][25] ([fdo#109271] / [i915#2190]) -> [SKIP][26]
([f
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/6] zsmalloc: switch from alloc_vm_area to get_vm_area (rev3)
== Series Details == Series: series starting with [1/6] zsmalloc: switch from alloc_vm_area to get_vm_area (rev3) URL : https://patchwork.freedesktop.org/series/81855/ State : failure == Summary == Applying: zsmalloc: switch from alloc_vm_area to get_vm_area error: sha1 information is lacking or useless (mm/memory.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 zsmalloc: switch from alloc_vm_area to get_vm_area When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] zsmalloc: switch from alloc_vm_area to get_vm_area
On Mon, Sep 21, 2020 at 11:42:29AM -0700, Minchan Kim wrote: > It seems zsmalloc is only customer the function so let's have the helper > when we see another customer. > > If we don't have objection, I'd like to ask to Andrew fold this up. Fine with me. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] zsmalloc: switch from alloc_vm_area to get_vm_area
On Mon, Sep 21, 2020 at 08:17:08PM +0200, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 10:42:56AM -0700, Minchan Kim wrote:
> > IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
> > zs_map_object API runs under non-preemtible section.
>
> Make sense.
>
> > > - area->vm = alloc_vm_area(PAGE_SIZE * 2, NULL);
> > > + area->vm = get_vm_area(PAGE_SIZE * 2, 0);
> > > if (!area->vm)
> > > return -ENOMEM;
> > > return 0;
> >
> > I think it shoud work.
> >
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 05789aa4af12..6a1e4d854593 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -2232,7 +2232,7 @@ static int apply_to_pte_range(struct mm_struct *mm,
> > pmd_t *pmd,
> > arch_enter_lazy_mmu_mode();
> >
> > do {
> > - if (create || !pte_none(*pte)) {
> > + if ((create || !pte_none(*pte)) && fn) {
> > err = fn(pte++, addr, data);
> > if (err)
> > break;
> > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > index 3e4fe3259612..9ef7daf3d279 100644
> > --- a/mm/zsmalloc.c
> > +++ b/mm/zsmalloc.c
> > @@ -1116,6 +1116,8 @@ static struct zspage *find_get_zspage(struct
> > size_class *class)
> > #ifdef CONFIG_ZSMALLOC_PGTABLE_MAPPING
> > static inline int __zs_cpu_up(struct mapping_area *area)
> > {
> > + int ret;
> > +
> > /*
> > * Make sure we don't leak memory if a cpu UP notification
> > * and zs_init() race and both call zs_cpu_up() on the same cpu
> > @@ -1125,7 +1127,13 @@ static inline int __zs_cpu_up(struct mapping_area
> > *area)
> > area->vm = get_vm_area(PAGE_SIZE * 2, 0);
> > if (!area->vm)
> > return -ENOMEM;
> > - return 0;
> > +
> > + /*
> > +* Populate ptes in advance to avoid pte allocation with GFP_KERNEL
> > +* in non-preemtible context of zs_map_object.
> > +*/
> > + ret = apply_to_page_range(&init_mm, NULL, PAGE_SIZE * 2, NULL, NULL);
> > + return ret;
>
> I think this needs the addr from the vm area somewhere..
Yeah, let's assign the addres we got get_vm_area.
>
> We probaby want to add a trivial helper to prefault an area instead of
> the open coded variant.
It seems zsmalloc is only customer the function so let's have the helper
when we see another customer.
If we don't have objection, I'd like to ask to Andrew fold this up.
---
mm/memory.c | 2 +-
mm/zsmalloc.c | 8 +++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index 05789aa4af12..6a1e4d854593 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2232,7 +2232,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t
*pmd,
arch_enter_lazy_mmu_mode();
do {
- if (create || !pte_none(*pte)) {
+ if ((create || !pte_none(*pte)) && fn) {
err = fn(pte++, addr, data);
if (err)
break;
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 3e4fe3259612..918c7b019b3d 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1125,7 +1125,13 @@ static inline int __zs_cpu_up(struct mapping_area *area)
area->vm = get_vm_area(PAGE_SIZE * 2, 0);
if (!area->vm)
return -ENOMEM;
- return 0;
+
+ /*
+* Populate ptes in advance to avoid pte allocation with GFP_KERNEL
+* in non-preemtible context of zs_map_object.
+*/
+ return apply_to_page_range(&init_mm, (unsigned long)area->vm->addr,
+ PAGE_SIZE * 2, NULL, NULL);
}
static inline void __zs_cpu_down(struct mapping_area *area)
--
2.28.0.681.g6f77f65b4e-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps
On Mon, 21 Sep 2020, Lyude Paul wrote: > On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote: >> I guess we can try without the change, and fix later if we hit issues. > > I'm fine with the change if it doesn't break things btw - just as long as > we're making sure that we don't zero things out by accident My conclusion was to go without, it's a trivial change to add afterwards as needed. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/guc: Update to GuC v49
== Series Details == Series: drm/i915/guc: Update to GuC v49 URL : https://patchwork.freedesktop.org/series/81906/ State : warning == Summary == $ dim checkpatch origin/drm-tip a2bf36c707f0 drm/i915/guc: Update to use firmware v49.0.1 -:231: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #231: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c:167: + blob->system_info.generic_gt_sysinfo[GUC_GENERIC_GT_SYSINFO_DOORBELL_COUNT_PER_SQIDI] = total: 0 errors, 1 warnings, 0 checks, 447 lines checked 087e6d613cd2 drm/i915/guc: Improved reporting when GuC fails to load d89334936a2a drm/i915/guc: Clear pointers on free ea46ad89cb74 drm/i915/uc: turn on GuC/HuC auto mode by default ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/6] zsmalloc: switch from alloc_vm_area to get_vm_area
On Mon, Sep 21, 2020 at 10:42:56AM -0700, Minchan Kim wrote:
> IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
> zs_map_object API runs under non-preemtible section.
Make sense.
> > - area->vm = alloc_vm_area(PAGE_SIZE * 2, NULL);
> > + area->vm = get_vm_area(PAGE_SIZE * 2, 0);
> > if (!area->vm)
> > return -ENOMEM;
> > return 0;
>
> I think it shoud work.
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 05789aa4af12..6a1e4d854593 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -2232,7 +2232,7 @@ static int apply_to_pte_range(struct mm_struct *mm,
> pmd_t *pmd,
> arch_enter_lazy_mmu_mode();
>
> do {
> - if (create || !pte_none(*pte)) {
> + if ((create || !pte_none(*pte)) && fn) {
> err = fn(pte++, addr, data);
> if (err)
> break;
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index 3e4fe3259612..9ef7daf3d279 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -1116,6 +1116,8 @@ static struct zspage *find_get_zspage(struct size_class
> *class)
> #ifdef CONFIG_ZSMALLOC_PGTABLE_MAPPING
> static inline int __zs_cpu_up(struct mapping_area *area)
> {
> + int ret;
> +
> /*
>* Make sure we don't leak memory if a cpu UP notification
>* and zs_init() race and both call zs_cpu_up() on the same cpu
> @@ -1125,7 +1127,13 @@ static inline int __zs_cpu_up(struct mapping_area
> *area)
> area->vm = get_vm_area(PAGE_SIZE * 2, 0);
> if (!area->vm)
> return -ENOMEM;
> - return 0;
> +
> + /*
> + * Populate ptes in advance to avoid pte allocation with GFP_KERNEL
> + * in non-preemtible context of zs_map_object.
> + */
> + ret = apply_to_page_range(&init_mm, NULL, PAGE_SIZE * 2, NULL, NULL);
> + return ret;
I think this needs the addr from the vm area somewhere..
We probaby want to add a trivial helper to prefault an area instead of
the open coded variant.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps
On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote:
> On Tue, 01 Sep 2020, Lyude Paul wrote:
> > On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
> > > In the future, we'll be needing more of the extended receiver capability
> > > field starting at DPCD address 0x2200. (Specifically, we'll need main
> > > link channel coding cap for DP 2.0.) Start using it now to not miss out
> > > later on.
> > >
> > > Cc: Lyude Paul
> > > Signed-off-by: Jani Nikula
> > >
> > > ---
> > >
> > > I guess this can be merged after the topic branch to drm-misc-next or
> > > so, but I'd prefer to have this fairly early on to catch any potential
> > > issues.
> > > ---
> > > drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 1e7c638873c8..3a3c238452df 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
> > > dpcd[DP_RECEIVER_CAP_SIZE])
> > > static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> > > u8 dpcd[DP_RECEIVER_CAP_SIZE])
> > > {
> > > - u8 dpcd_ext[6];
> > > + u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> >
> > Not 100% sure this is right? It's not clear at first glance of the 2.0
> > spec, but
> > my assumption would be that on < DP2.0 devices that everything but those
> > first 6
> > bytes are zeroed out in the extended DPRX field. Since we memcpy()
> > dpcd_ext
> > using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the
> > DPCD caps
> > that comes after those 6 bytes.
>
> Re-reading stuff... AFAICT everything in 0x2200..0x220F should be
> valid. They should match what's in 0x..0x000F except for 0x,
> 0x0001, and 0x0005, for backwards compatibility.
>
> Apparently there are no such backwards compatibility concerns with the
> other receiver cap fields then.
>
> But it gives me an uneasy feeling that many places in the spec refer to
> 0x2200+ even though they should per spec be the same in 0x+.
>
> I guess we can try without the change, and fix later if we hit issues.
I'm fine with the change if it doesn't break things btw - just as long as
we're making sure that we don't zero things out by accident
>
>
> BR,
> Jani.
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] drm/i915/guc: Update to GuC v49
From: John Harrison Update to the latest GuC firmware and enable by default. Signed-off-by: John Harrison Daniele Ceraolo Spurio (1): drm/i915/uc: turn on GuC/HuC auto mode by default John Harrison (3): drm/i915/guc: Update to use firmware v49.0.1 drm/i915/guc: Improved reporting when GuC fails to load drm/i915/guc: Clear pointers on free drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 +- drivers/gpu/drm/i915/gt/uc/intel_guc.c | 18 --- drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 132 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c| 1 + drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c| 27 +++- drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 82 +++- drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 5 + drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 27 ++-- drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 +- drivers/gpu/drm/i915/i915_params.h | 2 +- 11 files changed, 207 insertions(+), 98 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/i915/guc: Update to use firmware v49.0.1
From: John Harrison
The latest GuC firmware includes a number of interface changes that
require driver updates to match.
* Starting from Gen11, the ID to be provided to GuC needs to contain
the engine class in bits [0..2] and the instance in bits [3..6].
NOTE: this patch breaks pointer dereferences in some existing GuC
functions that use the guc_id to dereference arrays but these functions
are not used for now as we have GuC submission disabled and we will
update these functions in follow up patch which requires new IDs.
* The new GuC requires the additional data structure (ADS) and associated
'private_data' pointer to be setup. This is basically a scratch area
of memory that the GuC owns. The size is read from the CSS header.
* There is now a physical to logical engine mapping table in the ADS
which needs to be configured in order for the firmware to load. For
now, the table is initialised with a 1 to 1 mapping.
* GUC_CTL_CTXINFO has been removed from the initialization params.
* reg_state_buffer is maintained internally by the GuC as part of
the private data.
* The ADS layout has changed significantly. This patch updates the
shared structure and also adds better documentation of the layout.
* While i915 does not use GuC doorbells, the firmware now requires
that some initialisation is done.
* The number of engine classes and instances supported in the ADS has
been increased.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Oscar Mateo
Signed-off-by: Michel Thierry
Signed-off-by: Rodrigo Vivi
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Tomasz Lis
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 +-
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 18 ---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 131 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 82 +++-
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h | 5 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 27 ++--
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h | 2 +
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 6 +-
8 files changed, 182 insertions(+), 92 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1985772152bf..3fb52fac0d5d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -305,8 +305,9 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
engine->i915 = i915;
engine->gt = gt;
engine->uncore = gt->uncore;
- engine->hw_id = engine->guc_id = info->hw_id;
engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
+ engine->hw_id = info->hw_id;
+ engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
engine->class = info->class;
engine->instance = info->instance;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 942c7c187adb..6909da1e1a73 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -213,23 +213,6 @@ static u32 guc_ctl_feature_flags(struct intel_guc *guc)
return flags;
}
-static u32 guc_ctl_ctxinfo_flags(struct intel_guc *guc)
-{
- u32 flags = 0;
-
- if (intel_guc_submission_is_used(guc)) {
- u32 ctxnum, base;
-
- base = intel_guc_ggtt_offset(guc, guc->stage_desc_pool);
- ctxnum = GUC_MAX_STAGE_DESCRIPTORS / 16;
-
- base >>= PAGE_SHIFT;
- flags |= (base << GUC_CTL_BASE_ADDR_SHIFT) |
- (ctxnum << GUC_CTL_CTXNUM_IN16_SHIFT);
- }
- return flags;
-}
-
static u32 guc_ctl_log_params_flags(struct intel_guc *guc)
{
u32 offset = intel_guc_ggtt_offset(guc, guc->log.vma) >> PAGE_SHIFT;
@@ -291,7 +274,6 @@ static void guc_init_params(struct intel_guc *guc)
BUILD_BUG_ON(sizeof(guc->params) != GUC_CTL_MAX_DWORDS * sizeof(u32));
- params[GUC_CTL_CTXINFO] = guc_ctl_ctxinfo_flags(guc);
params[GUC_CTL_LOG_PARAMS] = guc_ctl_log_params_flags(guc);
params[GUC_CTL_FEATURE] = guc_ctl_feature_flags(guc);
params[GUC_CTL_DEBUG] = guc_ctl_debug_flags(guc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index d44061033f23..7950d28beb8c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -10,11 +10,52 @@
/*
* The Additional Data Struct (ADS) has pointers for different buffers used by
- * the GuC. One single gem object contains the ADS struct itself (guc_ads), the
- * scheduling policies (guc_policies), a structure describing a collection of
- * register sets (guc_mmio_reg_state) and some extra pages for the GuC to save
- * its internal state for sleep.
+ * the GuC. One single gem o
[Intel-gfx] [PATCH 2/4] drm/i915/guc: Improved reporting when GuC fails to load
From: John Harrison
Rather than just saying 'GuC failed to load: -110', actually print out
the GuC status register and break it down into the individual fields.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index d4a87f4c9421..eac84baf34e6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -74,8 +74,9 @@ static inline bool guc_ready(struct intel_uncore *uncore, u32
*status)
((val & GS_MIA_CORE_STATE) && (uk_val ==
GS_UKERNEL_LAPIC_DONE));
}
-static int guc_wait_ucode(struct intel_uncore *uncore)
+static int guc_wait_ucode(struct intel_gt *gt)
{
+ struct intel_uncore *uncore = gt->uncore;
u32 status;
int ret;
@@ -91,16 +92,32 @@ static int guc_wait_ucode(struct intel_uncore *uncore)
DRM_DEBUG_DRIVER("GuC status %#x\n", status);
if ((status & GS_BOOTROM_MASK) == GS_BOOTROM_RSA_FAILED) {
- DRM_ERROR("GuC firmware signature verification failed\n");
+ drm_err(>->i915->drm, "GuC firmware signature verification
failed\n");
ret = -ENOEXEC;
+ goto out;
}
if ((status & GS_UKERNEL_MASK) == GS_UKERNEL_EXCEPTION) {
- DRM_ERROR("GuC firmware exception. EIP: %#x\n",
- intel_uncore_read(uncore, SOFT_SCRATCH(13)));
+ drm_err(>->i915->drm, "GuC firmware exception. EIP: %#x\n",
+ intel_uncore_read(uncore, SOFT_SCRATCH(13)));
ret = -ENXIO;
+ goto out;
}
+ if (ret) {
+ drm_err(>->i915->drm, "GuC load failed: status: Reset = %d, "
+ "BootROM = 0x%02X, UKernel = 0x%02X, "
+ "MIA = 0x%02X, Auth = 0x%02X\n",
+ (status >> GS_RESET_SHIFT) & 1,
+ (status & GS_BOOTROM_MASK) >> GS_BOOTROM_SHIFT,
+ (status & GS_UKERNEL_MASK) >> GS_UKERNEL_SHIFT,
+ (status & GS_MIA_MASK) >> GS_MIA_SHIFT,
+ (status & GS_AUTH_STATUS_MASK) >> GS_AUTH_STATUS_SHIFT);
+ }
+
+out:
+ if (ret)
+ drm_err(>->i915->drm, "GuC load failed: status = 0x%08X\n",
status);
return ret;
}
@@ -139,7 +156,7 @@ int intel_guc_fw_upload(struct intel_guc *guc)
if (ret)
goto out;
- ret = guc_wait_ucode(uncore);
+ ret = guc_wait_ucode(gt);
if (ret)
goto out;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915/uc: turn on GuC/HuC auto mode by default
From: Daniele Ceraolo Spurio This will enable HuC loading for Gen11+ by default if the binaries are available on the system. GuC submission still requires explicit enabling by the user. Signed-off-by: Daniele Ceraolo Spurio Cc: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 330c03e2b4f7..7bdbd8f6ed30 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -58,7 +58,7 @@ struct drm_printer; param(int, disable_power_well, -1, 0400) \ param(int, enable_ips, 1, 0600) \ param(int, invert_brightness, 0, 0600) \ - param(int, enable_guc, 0, 0400) \ + param(int, enable_guc, -1, 0400) \ param(int, guc_log_level, -1, 0400) \ param(char *, guc_firmware_path, NULL, 0400) \ param(char *, huc_firmware_path, NULL, 0400) \ -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915/guc: Clear pointers on free
From: John Harrison
Was hitting null pointers and similar issues when running various
module load/unload and inject failure type tests. So clear those
pointers down when the objects have been de-allocated.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 7950d28beb8c..5212ff844292 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -220,6 +220,7 @@ int intel_guc_ads_create(struct intel_guc *guc)
void intel_guc_ads_destroy(struct intel_guc *guc)
{
i915_vma_unpin_and_release(&guc->ads_vma, I915_VMA_RELEASE_MAP);
+ guc->ads_blob = NULL;
}
static void guc_ads_private_data_reset(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 11742fca0e9e..fa9e048cc65f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -210,6 +210,7 @@ void intel_guc_ct_fini(struct intel_guc_ct *ct)
GEM_BUG_ON(ct->enabled);
i915_vma_unpin_and_release(&ct->vma, I915_VMA_RELEASE_MAP);
+ memset(ct, 0, sizeof(*ct));
}
/**
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/6] zsmalloc: switch from alloc_vm_area to get_vm_area (rev2)
== Series Details == Series: series starting with [1/6] zsmalloc: switch from alloc_vm_area to get_vm_area (rev2) URL : https://patchwork.freedesktop.org/series/81855/ State : failure == Summary == Applying: zsmalloc: switch from alloc_vm_area to get_vm_area error: sha1 information is lacking or useless (mm/memory.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 zsmalloc: switch from alloc_vm_area to get_vm_area When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: check i915_vm_alloc_pt_stash for errors
== Series Details == Series: drm/i915: check i915_vm_alloc_pt_stash for errors URL : https://patchwork.freedesktop.org/series/81901/ State : success == Summary == CI Bug Log - changes from CI_DRM_9027_full -> Patchwork_18540_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18540_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_param@vm: - shard-skl: [PASS][1] -> [DMESG-WARN][2] ([i915#1982]) +7 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl6/igt@gem_ctx_pa...@vm.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-skl9/igt@gem_ctx_pa...@vm.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2389]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-glk9/igt@gem_exec_reloc@basic-many-act...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-glk5/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-skl: [PASS][5] -> [TIMEOUT][6] ([i915#1958] / [i915#2424]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl2/igt@gem_userptr_bl...@sync-unmap-cycles.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-skl9/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][7] -> [TIMEOUT][8] ([i915#1958]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl8/igt@gem_userptr_bl...@unsync-unmap-cycles.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-skl5/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gem_workarounds@suspend-resume: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-kbl2/igt@gem_workarou...@suspend-resume.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-kbl6/igt@gem_workarou...@suspend-resume.html * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#1436] / [i915#716]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-kbl7/igt@gen9_exec_pa...@allowed-all.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-kbl3/igt@gen9_exec_pa...@allowed-all.html * igt@i915_suspend@sysfs-reader: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([i915#198]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl4/igt@i915_susp...@sysfs-reader.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-skl10/igt@i915_susp...@sysfs-reader.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#177] / [i915#52] / [i915#54]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl1/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-skl7/igt@kms_draw_...@draw-method-rgb565-pwrite-untiled.html * igt@kms_flip@flip-vs-expired-vblank@a-edp1: - shard-skl: [PASS][17] -> [FAIL][18] ([i915#79]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl6/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-skl3/igt@kms_flip@flip-vs-expired-vbl...@a-edp1.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt: - shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-tglb5/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-tglb5/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#1982]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-kbl4/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-kbl3/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc: - shard-skl: [PASS][23] -> [FAIL][24] ([i915#49]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl1/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/shard-skl7/igt@kms_frontbuffer_track...@psr-1p-primscrn-pri-indfb-draw-mmap-wc.htm
Re: [Intel-gfx] [PATCH 1/6] zsmalloc: switch from alloc_vm_area to get_vm_area
On Fri, Sep 18, 2020 at 06:37:19PM +0200, Christoph Hellwig wrote:
> There is no obvious reason why zsmalloc needs to pre-fault the PTEs
> given that it later uses map_kernel_range to just like vmap().
IIRC, the problem was runtime pte popluating needs GFP_KERNEL but
zs_map_object API runs under non-preemtible section.
>
> Signed-off-by: Christoph Hellwig
> ---
> mm/zsmalloc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> index c36fdff9a37131..3e4fe3259612fd 100644
> --- a/mm/zsmalloc.c
> +++ b/mm/zsmalloc.c
> @@ -1122,7 +1122,7 @@ static inline int __zs_cpu_up(struct mapping_area *area)
>*/
> if (area->vm)
> return 0;
> - area->vm = alloc_vm_area(PAGE_SIZE * 2, NULL);
> + area->vm = get_vm_area(PAGE_SIZE * 2, 0);
> if (!area->vm)
> return -ENOMEM;
> return 0;
I think it shoud work.
diff --git a/mm/memory.c b/mm/memory.c
index 05789aa4af12..6a1e4d854593 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2232,7 +2232,7 @@ static int apply_to_pte_range(struct mm_struct *mm, pmd_t
*pmd,
arch_enter_lazy_mmu_mode();
do {
- if (create || !pte_none(*pte)) {
+ if ((create || !pte_none(*pte)) && fn) {
err = fn(pte++, addr, data);
if (err)
break;
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 3e4fe3259612..9ef7daf3d279 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -1116,6 +1116,8 @@ static struct zspage *find_get_zspage(struct size_class
*class)
#ifdef CONFIG_ZSMALLOC_PGTABLE_MAPPING
static inline int __zs_cpu_up(struct mapping_area *area)
{
+ int ret;
+
/*
* Make sure we don't leak memory if a cpu UP notification
* and zs_init() race and both call zs_cpu_up() on the same cpu
@@ -1125,7 +1127,13 @@ static inline int __zs_cpu_up(struct mapping_area *area)
area->vm = get_vm_area(PAGE_SIZE * 2, 0);
if (!area->vm)
return -ENOMEM;
- return 0;
+
+ /*
+* Populate ptes in advance to avoid pte allocation with GFP_KERNEL
+* in non-preemtible context of zs_map_object.
+*/
+ ret = apply_to_page_range(&init_mm, NULL, PAGE_SIZE * 2, NULL, NULL);
+ return ret;
}
static inline void __zs_cpu_down(struct mapping_area *area)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: check i915_vm_alloc_pt_stash for errors
Quoting Matthew Auld (2020-09-21 17:08:44)
> If we are really unlucky and encounter an error during
> i915_vm_alloc_pt_stash, we end up passing an empty pt/pd stash all the
> way down into the low-level ppgtt alloc code, leading to explosions,
> since it expects at least the required number of pt/pd for the va range.
>
> [ 211.981418] BUG: kernel NULL pointer dereference, address:
> [ 211.981421] #PF: supervisor read access in kernel mode
> [ 211.981422] #PF: error_code(0x) - not-present page
> [ 211.981424] PGD 8008439cb067 P4D 8008439cb067 PUD 84a37f067 PMD 0
> [ 211.981427] Oops: [#1] SMP PTI
> [ 211.981428] CPU: 1 PID: 1301 Comm: i915_selftest Tainted: G UI
> 5.9.0-rc5+ #3
> [ 211.981430] Hardware name: /NUC6i7KYB, BIOS
> KYSKLi70.86A.0050.2017.0831.1924 08/31/2017
> [ 211.981521] RIP: 0010:__gen8_ppgtt_alloc+0x1ed/0x3c0 [i915]
> [ 211.981523] Code: c1 48 c7 c7 5d 5d fe c0 65 ff 0d ee 1d 03 3f e8 d9 91 1f
> e2 8b 55 c4 31 c0 48 8b 75 b8 85 d2 0f 95 c0 48 8b 1c c6 48 89 45 98 <48> 8b
> 03 48 8b 90 58 02 00 00 48 85 d2 0f 84 07 ea 15 00 48 81 fa
> [ 211.981526] RSP: 0018:ba2cc0eb3970 EFLAGS: 00010202
> [ 211.981527] RAX: 0001 RBX: RCX:
> 0004
> [ 211.981529] RDX: 0002 RSI: 9be998bdb8c0 RDI:
> 9be99c844300
> [ 211.981530] RBP: ba2cc0eb39d8 R08: 0640 R09:
> 9be97cdfd000
> [ 211.981531] R10: 9be97cdfd614 R11: R12:
>
> [ 211.981532] R13: 9be98607ba20 R14: 9be995a0b400 R15:
> ba2cc0eb39e8
> [ 211.981534] FS: 7f0f10b31000() GS:9be99fc4()
> knlGS:
> [ 211.981536] CS: 0010 DS: ES: CR0: 80050033
> [ 211.981538] CR2: CR3: 00084d74e006 CR4:
> 003706e0
> [ 211.981539] DR0: DR1: DR2:
>
> [ 211.981541] DR3: DR6: fffe0ff0 DR7:
> 0400
> [ 211.981542] Call Trace:
> [ 211.981609] gen8_ppgtt_alloc+0x79/0x90 [i915]
> [ 211.981678] ppgtt_bind_vma+0x36/0x80 [i915]
> [ 211.981756] __vma_bind+0x39/0x40 [i915]
> [ 211.981818] fence_work+0x21/0x98 [i915]
> [ 211.981879] fence_notify+0x8d/0x128 [i915]
> [ 211.981939] __i915_sw_fence_complete+0x62/0x240 [i915]
> [ 211.982018] i915_vma_pin_ww+0x1ee/0x9c0 [i915]
>
> Fixes: cd0452aa2a0d ("drm/i915: Preallocate stashes for vma page-directories")
> Signed-off-by: Matthew Auld
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_vma.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 495d28f6d160..ffb5287e055a 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -892,9 +892,11 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
> i915_gem_ww_ctx *ww,
>
> /* Allocate enough page directories to used PTE */
> if (vma->vm->allocate_va_range) {
> - i915_vm_alloc_pt_stash(vma->vm,
> - &work->stash,
> - vma->size);
> + err = i915_vm_alloc_pt_stash(vma->vm,
> +&work->stash,
> +vma->size);
> + if (err)
> + goto err_fence;
Whelp, well that was silly of me.
Thanks,
Reviewed-by: Chris Wilson
-Chris
___
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: check i915_vm_alloc_pt_stash for errors
== Series Details ==
Series: drm/i915: check i915_vm_alloc_pt_stash for errors
URL : https://patchwork.freedesktop.org/series/81901/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9027 -> Patchwork_18540
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/index.html
Known issues
Here are the changes found in Patchwork_18540 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2] ([i915#1982])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-byt-j1900/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [PASS][3] -> [DMESG-FAIL][4] ([i915#1748])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-gdg-551/igt@i915_selftest@l...@coherency.html
* igt@kms_busy@basic@flip:
- fi-kbl-x1275: [PASS][5] -> [DMESG-WARN][6] ([i915#62] / [i915#92] /
[i915#95])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-kbl-x1275/igt@kms_busy@ba...@flip.html
* igt@kms_cursor_legacy@basic-flip-before-cursor-atomic:
- fi-icl-u2: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-icl-u2/igt@kms_cursor_leg...@basic-flip-before-cursor-atomic.html
Possible fixes
* {igt@core_hotunplug@unbind-rebind}:
- fi-kbl-x1275: [DMESG-WARN][9] ([i915#62] / [i915#92] / [i915#95])
-> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-kbl-x1275/igt@core_hotunp...@unbind-rebind.html
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][11] ([i915#1982]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-byt-j1900/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bsw-kefka: [DMESG-WARN][13] ([i915#1982]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-bsw-kefka/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][15] ([i915#1982]) -> [PASS][16] +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][17] ([i915#2203]) -> [PASS][18] +1
similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-skl-guc/igt@vgem_ba...@unload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@gem_exec_suspend@basic-s0:
- fi-kbl-x1275: [DMESG-WARN][19] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][20] ([i915#1982] / [i915#62] / [i915#92] / [i915#95])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-kbl-x1275/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload:
- fi-kbl-x1275: [DMESG-WARN][21] ([i915#62] / [i915#92]) ->
[DMESG-WARN][22] ([i915#62] / [i915#92] / [i915#95]) +2 similar issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@i915_module_l...@reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-kbl-x1275/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][23] ([i915#62] / [i915#95]) ->
[DMESG-FAIL][24] ([i915#62])
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18540/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner wrote: > > If a task is migrated to a different CPU then the mapping address will > change which will explode in colourful ways. Heh. Right you are. Maybe we really *could* call this new kmap functionality something like "kmap_percpu()" (or maybe "local" is good enough), and make it act like your RT code does for spinlocks - not disable preemption, but only disabling CPU migration. That would probably be good enough for a lot of users that don't want to expose excessive latencies, but where it's really not a huge deal to say "stick to this CPU for a short while". The crypto code certainly sounds like one such case. Linus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: check i915_vm_alloc_pt_stash for errors
If we are really unlucky and encounter an error during
i915_vm_alloc_pt_stash, we end up passing an empty pt/pd stash all the
way down into the low-level ppgtt alloc code, leading to explosions,
since it expects at least the required number of pt/pd for the va range.
[ 211.981418] BUG: kernel NULL pointer dereference, address:
[ 211.981421] #PF: supervisor read access in kernel mode
[ 211.981422] #PF: error_code(0x) - not-present page
[ 211.981424] PGD 8008439cb067 P4D 8008439cb067 PUD 84a37f067 PMD 0
[ 211.981427] Oops: [#1] SMP PTI
[ 211.981428] CPU: 1 PID: 1301 Comm: i915_selftest Tainted: G UI
5.9.0-rc5+ #3
[ 211.981430] Hardware name: /NUC6i7KYB, BIOS
KYSKLi70.86A.0050.2017.0831.1924 08/31/2017
[ 211.981521] RIP: 0010:__gen8_ppgtt_alloc+0x1ed/0x3c0 [i915]
[ 211.981523] Code: c1 48 c7 c7 5d 5d fe c0 65 ff 0d ee 1d 03 3f e8 d9 91 1f
e2 8b 55 c4 31 c0 48 8b 75 b8 85 d2 0f 95 c0 48 8b 1c c6 48 89 45 98 <48> 8b 03
48 8b 90 58 02 00 00 48 85 d2 0f 84 07 ea 15 00 48 81 fa
[ 211.981526] RSP: 0018:ba2cc0eb3970 EFLAGS: 00010202
[ 211.981527] RAX: 0001 RBX: RCX: 0004
[ 211.981529] RDX: 0002 RSI: 9be998bdb8c0 RDI: 9be99c844300
[ 211.981530] RBP: ba2cc0eb39d8 R08: 0640 R09: 9be97cdfd000
[ 211.981531] R10: 9be97cdfd614 R11: R12:
[ 211.981532] R13: 9be98607ba20 R14: 9be995a0b400 R15: ba2cc0eb39e8
[ 211.981534] FS: 7f0f10b31000() GS:9be99fc4()
knlGS:
[ 211.981536] CS: 0010 DS: ES: CR0: 80050033
[ 211.981538] CR2: CR3: 00084d74e006 CR4: 003706e0
[ 211.981539] DR0: DR1: DR2:
[ 211.981541] DR3: DR6: fffe0ff0 DR7: 0400
[ 211.981542] Call Trace:
[ 211.981609] gen8_ppgtt_alloc+0x79/0x90 [i915]
[ 211.981678] ppgtt_bind_vma+0x36/0x80 [i915]
[ 211.981756] __vma_bind+0x39/0x40 [i915]
[ 211.981818] fence_work+0x21/0x98 [i915]
[ 211.981879] fence_notify+0x8d/0x128 [i915]
[ 211.981939] __i915_sw_fence_complete+0x62/0x240 [i915]
[ 211.982018] i915_vma_pin_ww+0x1ee/0x9c0 [i915]
Fixes: cd0452aa2a0d ("drm/i915: Preallocate stashes for vma page-directories")
Signed-off-by: Matthew Auld
Cc: Chris Wilson
---
drivers/gpu/drm/i915/i915_vma.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 495d28f6d160..ffb5287e055a 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -892,9 +892,11 @@ int i915_vma_pin_ww(struct i915_vma *vma, struct
i915_gem_ww_ctx *ww,
/* Allocate enough page directories to used PTE */
if (vma->vm->allocate_va_range) {
- i915_vm_alloc_pt_stash(vma->vm,
- &work->stash,
- vma->size);
+ err = i915_vm_alloc_pt_stash(vma->vm,
+&work->stash,
+vma->size);
+ if (err)
+ goto err_fence;
err = i915_vm_pin_pt_stash(vma->vm,
&work->stash);
--
2.26.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 0/6] Convert the intel iommu driver to the dma-iommu api
On 2020-09-20 12:36 a.m., Lu Baolu wrote: > Hi Logan, > > On 2020/9/19 4:47, Logan Gunthorpe wrote: >> Hi Lu, >> >> On 2020-09-11 9:21 p.m., Lu Baolu wrote: >>> Tom Murphy has almost done all the work. His latest patch series was >>> posted here. >>> >>> https://lore.kernel.org/linux-iommu/20200903201839.7327-1-murph...@tcd.ie/ >>> >>> Thanks a lot! >>> >>> This series is a follow-up with below changes: >>> >>> 1. Add a quirk for the i915 driver issue described in Tom's cover >>> letter. >>> 2. Fix several bugs in patch "iommu: Allow the dma-iommu api to use >>> bounce buffers" to make the bounce buffer work for untrusted devices. >>> 3. Several cleanups in iommu/vt-d driver after the conversion. >>> >> >> I'm trying to test this on an old Sandy Bridge, but found that I get >> spammed with warnings on boot. I've put a sample of a few of them below. >> They all seem to be related to ioat. >> >> I had the same issue with Tom's v2 but never saw this on his v1. > > Have you verified whether this could be reproduced with the lasted > upstream kernel (without this patch series)? Yes. Also, it's hitting a warning in the dma-iommu code which would not be hit without this patch set. Thanks, Logan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi! Since Daniel wanted a few thing to make it into 5.10, here's a final drm-misc-next PR for this cycle :) Thanks! Maxime drm-misc-next-2020-09-21: drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: Core Changes: - dev: More devm_drm convertions and removal of drm_dev_init Driver Changes: - i915: selftests improvements - panfrost: support for Amlogic SoC - vc4: one fix The following changes since commit 818280d5adf1d80e78f95821815148abe9407e14: Merge v5.9-rc5 into drm-next (2020-09-14 17:19:11 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2020-09-21 for you to fetch changes up to 089d83418914abd4d908db117d9a3eca7f51a68c: drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing (2020-09-21 16:43:11 +0200) drm-misc-next for 5.10: UAPI Changes: Cross-subsystem Changes: Core Changes: - dev: More devm_drm convertions and removal of drm_dev_init Driver Changes: - i915: selftests improvements - panfrost: support for Amlogic SoC - vc4: one fix Alex Dewar (2): video: fbdev: sstfb: replace spurious snprintf() with sprintf() drm/bridge: dw-mipi-dsi: Use kmemdup cf. kmalloc+memcpy Angelo Ribeiro (1): drm/bridge: dw-mipi-dsi.c: Add VPG runtime config through debugfs Antonio Borneo (3): drm/bridge/synopsys: dsi: allow LP commands in video mode drm/bridge/synopsys: dsi: allow sending longer LP commands drm/bridge/synopsys: dsi: add support for non-continuous HS clock Bernard Zhao (1): gpu/drm: cleanup coding style a bit Bilal Wasim (1): docs: fb: Correcting the location of FRAMEBUFFER_CONSOLE option. Christian König (14): drm/ttm: make sure that we always zero init mem.bus v2 drm/nouveau: move io_reserve_lru handling into the driver v5 drm/ttm: remove io_reserve_lru handling v3 drm/qxl: don't touch mem.bus.offset drm/ttm: merge offset and base in ttm_bus_placement drm/vram-helper: stop using TTM placement flags drm/nouveau: stop using TTM placement flags drm/vmwgfx: stop setting multiple domain flags drm/ttm: nuke memory type flags drm/ttm: remove default caching drm/nouveau: explicitly specify caching to use drm/ttm: remove available_caching drm/ttm: some cleanups drm/ttm: remove superflous extern attribute from funcs Colin Ian King (2): video: fbdev: vga16fb: fix setting of pixclock because a pass-by-value error omapfb: fix spelling mistake "propert" -> "property" Dan Carpenter (2): drm/vc4: hdmi: Fix off by ones in vc4_hdmi_read/write() drm/vc4: hdmi: Fix NULL vs IS_ERR() checks in vc5_hdmi_init_resources() Daniel Vetter (11): drm/managed: Cleanup of unused functions and polishing docs drm/armada: Use devm_drm_dev_alloc drm/armada: Don't use drm_device->dev_private drm/aspeed: Use managed drmm_mode_config_cleanup drm/vgem: Use devm_drm_dev_alloc drm/vkms: Use devm_drm_dev_alloc drm/xlnx: Use devm_drm_dev_alloc dma-resv: lockdep-prime address_space->i_mmap_rwsem for dma-resv drm/i915/selftest: Create mock_destroy_device drm/i915/selftests: align more to real device lifetimes drm/dev: Remove drm_dev_init Dave Airlie (30): drm/ttm: remove bdev from ttm_tt drm/ttm: introduce ttm_bo_move_null drm/ttm: add optional bind/unbind via driver. drm/qxl: move bind/unbind/destroy to the driver function table. drm/ttm/agp: export bind/unbind/destroy for drivers to use. drm/radeon/ttm: move to driver binding/destroy functions. (v2) drm/nouveau/ttm: use driver bind/unbind/destroy functions. drm/vmwgfx: move to driver binding functions drm/amdgpu/ttm: move to driver backend binding funcs drm/gem_vram/ttm: move to driver backend destroy function. drm/ttm/agp: drop back end bindings from agp drm/ttm: get rid of agp specific populate/unpopulate paths. drm/ttm/agp: remove bdev from agp helpers drm/ttm: drop the tt backend function paths. drm/ttm/tt: add wrappers to set tt state. drm/ttm: wrap tt destroy. (v2) drm/ttm: tt destroy move null check to outer function. drm/ttm: split populate out from binding. drm/ttm: move ttm binding/unbinding out of ttm_tt paths. drm/ttm: split bound/populated flags. drm/ttm: move populated state into page flags drm/ttm: protect against reentrant bind in the drivers drm/ttm: flip tt destroy ordering. drm/ttm: move unbind into the tt destroy. drm/ttm/drivers: call the bind function directly. drm/ttm: add a simple assign mem to bo wrapper drm/ttm: move ghost object creation to a common function drm/ttm: make common function for wait/free node path. drm/ttm: drop
Re: [Intel-gfx] [Mesa-dev] XDC 2020 feedback and comments
First off, I think you all did a fantastic job. I felt that things ran very smoothly and, as far as the talks themselves go, I think it went almost as smoothly as an in-person XDC. I'm really quite impressed. I do have a couple pieces of more nuanced feedback: 1. I think we were maybe a bit too scared of overloading jitsi. Having more people in the instance for questions might have made that portion go better. As it was, there was only one or two talks that had any live questions. That said, there are a few advantages to having things funneled through IRC, the most obvious of which being that people can ask their question mid-talk and have it handled at the end instead of having to remember it for 20 minutes. 2. I really miss the hallway track. On Thursday, after the conference, Bas, Connor, and I used jitsi to have a chat about ray-tracing. That was really fun and I wish I'd done something like that every day of XDC. Maybe it's my own fault for not setting up said chats but I think it could have been made more accessible (I had no idea how to fork off a jitsi instance) and/or encouraged somehow. --Jason On Mon, Sep 21, 2020 at 3:07 AM Samuel Iglesias Gonsálvez wrote: > > Hi all, > > Huge thanks again to the entire team from Intel, for their great work > organizing XDC 2020, our first virtual conference! > > As usual we're looking for feedback on both XDC itself, and the CFP > process and program selection. Both about what was great and should be > kept for next year's edition, and where there's room for improvement. > > The board does keep some notes, for those interested in what we have > already: > > - XDC notes for prospective organizers: > https://www.x.org/wiki/Events/RFP/ > > - CFP notes: https://www.x.org/wiki/Events/PapersCommittee/ > > If you want to send in your comments in private, please send them to > the X.org Foundation board: bo...@foundation.x.org > > Cheers, > > Sam > ___ > mesa-dev mailing list > mesa-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/mesa-dev ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Asynchronous flip implementation for i915 (rev12)
== Series Details == Series: Asynchronous flip implementation for i915 (rev12) URL : https://patchwork.freedesktop.org/series/74386/ State : success == Summary == CI Bug Log - changes from CI_DRM_9027_full -> Patchwork_18539_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_18539_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_blits@basic: - shard-glk: [PASS][1] -> [DMESG-WARN][2] ([i915#118] / [i915#95]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-glk9/igt@gem_bl...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-glk7/igt@gem_bl...@basic.html * igt@gem_ctx_param@vm: - shard-skl: [PASS][3] -> [DMESG-WARN][4] ([i915#1982]) +6 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl6/igt@gem_ctx_pa...@vm.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-skl10/igt@gem_ctx_pa...@vm.html * igt@gem_ctx_persistence@legacy-engines-mixed-process@bsd: - shard-apl: [PASS][5] -> [FAIL][6] ([i915#1635] / [i915#2374]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-apl8/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-apl8/igt@gem_ctx_persistence@legacy-engines-mixed-proc...@bsd.html * igt@gem_exec_reloc@basic-many-active@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2389]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-glk9/igt@gem_exec_reloc@basic-many-act...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-glk1/igt@gem_exec_reloc@basic-many-act...@rcs0.html * igt@gem_exec_suspend@basic-s4-devices: - shard-hsw: [PASS][9] -> [INCOMPLETE][10] ([i915#1888]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-hsw6/igt@gem_exec_susp...@basic-s4-devices.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-hsw7/igt@gem_exec_susp...@basic-s4-devices.html * igt@gem_mmap_offset@ptrace@uc: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([i915#1635] / [i915#1982]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-apl3/igt@gem_mmap_offset@ptr...@uc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-apl3/igt@gem_mmap_offset@ptr...@uc.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-skl: [PASS][13] -> [TIMEOUT][14] ([i915#1958] / [i915#2424]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl2/igt@gem_userptr_bl...@sync-unmap-cycles.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-skl5/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@gem_userptr_blits@unsync-unmap-cycles: - shard-skl: [PASS][15] -> [TIMEOUT][16] ([i915#1958]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-skl8/igt@gem_userptr_bl...@unsync-unmap-cycles.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-skl1/igt@gem_userptr_bl...@unsync-unmap-cycles.html * igt@gen9_exec_parse@allowed-all: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#1436] / [i915#716]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-kbl7/igt@gen9_exec_pa...@allowed-all.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-kbl2/igt@gen9_exec_pa...@allowed-all.html * igt@i915_selftest@mock@contexts: - shard-apl: [PASS][19] -> [INCOMPLETE][20] ([i915#1635] / [i915#2278]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-apl7/igt@i915_selftest@m...@contexts.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-apl6/igt@i915_selftest@m...@contexts.html * igt@kms_flip@2x-dpms-vs-vblank-race@bc-hdmi-a1-hdmi-a2: - shard-glk: [PASS][21] -> [FAIL][22] ([i915#407]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-glk9/igt@kms_flip@2x-dpms-vs-vblank-r...@bc-hdmi-a1-hdmi-a2.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-glk8/igt@kms_flip@2x-dpms-vs-vblank-r...@bc-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@c-hdmi-a2: - shard-glk: [PASS][23] -> [FAIL][24] ([i915#79]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/shard-glk7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a2.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/shard-glk5/igt@kms_flip@flip-vs-expired-vblank-interrupti...@c-hdmi-a2.html * igt@kms_flip@plain-flip-fb-recreate@b-edp1: - shard-skl: [PASS][25] -> [FAIL][26] ([i915#2122]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_
Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on Nightfury board
On Tue, Sept. 15, 2020, 1:35 p.m. Ville Syrjälä wrote:
>On Tue, Sep 15, 2020 at 01:18:13PM +, Lee, Shawn C wrote:
>> On Fri, Sept. 11, 2020, 2:21 p.m. Ville Syrjälä wrote:
>> >On Thu, Aug 27, 2020 at 01:51:29PM +0800, Lee Shawn C wrote:
>> >> Customer report random display flicker issue on Nightfury board.
>> >> And we found this problem might be caused by VT-d and FBC are both
>> >> enabled. According to sighting report, it recommend to turn
>> >> drm/i915/fbc: disable FBC on Nightfury board
>> >>
>> >> Customer report random display flicker issue on Nightfury board.
>> >> And we found this problem might be caused by VT-d and FBC are both
>> >> enabled. According to sighting report, it recommend to turn FBC
>> >> off to workaround this kind of issue.
>> >>
>> >> This change refer to DMI BOARD_VENDOR and BOARD_NAME information
>> >> to disable FBC.
>> >
>> >What is this "nightfury board" exactly?
>>
>> It is chrome os project on CML platform. The board name is "nightfury".
>
>OK, then someone should definitely test if that missing w/a fixes the
>underruns.
Customer already confirmed display flicker issue disappear after applied this
w/a.
BTW, here is the patch v2 to fix some typo in v1.
https://patchwork.freedesktop.org/series/81087/#rev2
Best regards,
Shawn
>
>>
>> >
>> >I think we're missing at least one fbc vs. vt-d w/a on some kbl/cfl/etc.
>> >era platforms:
>> >git://github.com/vsyrjala/linux.git vtd_wa_1142
>> >
>> >>
>> >> Cc: Ville Syrjälä
>> >> Cc: Rodrigo Vivi
>> >> Cc: Mika Kuoppala
>> >> Cc: Jani Nikula
>> >> Cc: William Tseng
>> >> Cc: Cooper Chiou
>> >> Signed-off-by: Lee Shawn C
>> >> ---
>> >> drivers/gpu/drm/i915/display/intel_fbc.c | 22
>> >> ++
>> >> 1 file changed, 22 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
>> >> b/drivers/gpu/drm/i915/display/intel_fbc.c
>> >> index 327af428d73f..20660fdbab36 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
>> >> @@ -39,6 +39,7 @@
>> >> */
>> >>
>> >> #include
>> >> +#include
>> >>
>> >> #include "i915_drv.h"
>> >> #include "i915_trace.h"
>> >> @@ -1439,6 +1440,24 @@ static int intel_sanitize_fbc_option(struct
>> >> drm_i915_private *dev_priv)
>> >> return 0;
>> >> }
>> >>
>> >> +static int intel_fbc_vtd_callback(const struct dmi_system_id *id) {
>> >> + DRM_DEBUG_KMS("Disabling FBC to prevent screen flicker on %s device\n",
>> >> id->ident);
>> >> + return 1;
>> >> +}
>> >> +
>> >> +static const struct dmi_system_id intel_fbc_vtd_detect[] = {
>> >> + {
>> >> + .callback = intel_fbc_vtd_callback,
>> >> + .ident = "Google Nightfury",
>> >> + .matches = {
>> >> + DMI_MATCH(DMI_BOARD_VENDOR, "Google"),
>> >> + DMI_MATCH(DMI_BOARD_NAME, "Nightfury"),
>> >> + },
>> >> + },
>> >> + { }
>> >> +};
>> >> +
>> >> static bool need_fbc_vtd_wa(struct drm_i915_private *dev_priv) {
>> >> /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */ @@ -1450,6
>> >> +1469,9 @@ static bool need_fbc_vtd_wa(struct drm_i915_private *dev_priv)
>> >> return true;
>> >> }
>> >>
>> >> + if (dmi_check_system(intel_fbc_vtd_detect))
>> >> + return true;
>> >> +
>> >> return false;
>> >> }
>> >>
>> >> --
>> >> 2.17.1
>> >
>> >--
>> >Ville Syrjälä
>> >Intel
>>
>> Best regards,
>> Shawn
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on Nightfury board
On Tue, Sept. 15, 2020, 1:35 p.m. Ville Syrjälä wrote:
>On Tue, Sep 15, 2020 at 01:18:13PM +, Lee, Shawn C wrote:
>> On Fri, Sept. 11, 2020, 2:21 p.m. Ville Syrjälä wrote:
>> >On Thu, Aug 27, 2020 at 01:51:29PM +0800, Lee Shawn C wrote:
>> >> Customer report random display flicker issue on Nightfury board.
>> >> And we found this problem might be caused by VT-d and FBC are both
>> >> enabled. According to sighting report, it recommend to turn
>> >> drm/i915/fbc: disable FBC on Nightfury board
>> >>
>> >> Customer report random display flicker issue on Nightfury board.
>> >> And we found this problem might be caused by VT-d and FBC are both
>> >> enabled. According to sighting report, it recommend to turn FBC off to
>> >> workaround this kind of issue.
>> >>
>> >> This change refer to DMI BOARD_VENDOR and BOARD_NAME information to
>> >> disable FBC.
>> >
>> >What is this "nightfury board" exactly?
>>
>> It is chrome os project on CML platform. The board name is "nightfury".
>
>OK, then someone should definitely test if that missing w/a
>fixes the underruns.
Customer already confirmed display flicker issue disappear after
applied this w/a.
BTW, here is the patch v2 to fix some typo in v1.
https://patchwork.freedesktop.org/series/81087/#rev2
Best regards,
Shawn
>
>>
>> >
>> >I think we're missing at least one fbc vs. vt-d w/a on some kbl/cfl/etc.
>> >era platforms:
>> >git://github.com/vsyrjala/linux.git vtd_wa_1142
>> >
>> >>
>> >> Cc: Ville Syrjälä
>> >> Cc: Rodrigo Vivi
>> >> Cc: Mika Kuoppala
>> >> Cc: Jani Nikula
>> >> Cc: William Tseng
>> >> Cc: Cooper Chiou
>> >> Signed-off-by: Lee Shawn C
>> >> ---
>> >> drivers/gpu/drm/i915/display/intel_fbc.c | 22 ++
>> >> 1 file changed, 22 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
>> >> b/drivers/gpu/drm/i915/display/intel_fbc.c
>> >> index 327af428d73f..20660fdbab36 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
>> >> @@ -39,6 +39,7 @@
>> >> */
>> >>
>> >> #include
>> >> +#include
>> >>
>> >> #include "i915_drv.h"
>> >> #include "i915_trace.h"
>> >> @@ -1439,6 +1440,24 @@ static int intel_sanitize_fbc_option(struct
>> >> drm_i915_private *dev_priv)
>> >> return 0;
>> >> }
>> >>
>> >> +static int intel_fbc_vtd_callback(const struct dmi_system_id *id) {
>> >> + DRM_DEBUG_KMS("Disabling FBC to prevent screen flicker on %s device\n",
>> >> id->ident);
>> >> + return 1;
>> >> +}
>> >> +
>> >> +static const struct dmi_system_id intel_fbc_vtd_detect[] = {
>> >> + {
>> >> + .callback = intel_fbc_vtd_callback,
>> >> + .ident = "Google Nightfury",
>> >> + .matches = {
>> >> + DMI_MATCH(DMI_BOARD_VENDOR, "Google"),
>> >> + DMI_MATCH(DMI_BOARD_NAME, "Nightfury"),
>> >> + },
>> >> + },
>> >> + { }
>> >> +};
>> >> +
>> >> static bool need_fbc_vtd_wa(struct drm_i915_private *dev_priv) {
>> >> /* WaFbcTurnOffFbcWhenHyperVisorIsUsed:skl,bxt */ @@ -1450,6 +1469,9
>> >> @@ static bool need_fbc_vtd_wa(struct drm_i915_private *dev_priv)
>> >> return true;
>> >> }
>> >>
>> >> + if (dmi_check_system(intel_fbc_vtd_detect))
>> >> + return true;
>> >> +
>> >> return false;
>> >> }
>> >>
>> >> --
>> >> 2.17.1
>> >
>> >--
>> >Ville Syrjälä
>> >Intel
>>
>> Best regards,
>> Shawn
___
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: Break up error capture compression loops with cond_resched()
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.8.10, v5.4.66, v4.19.146, v4.14.198,
v4.9.236, v4.4.236.
v5.8.10: Build OK!
v5.4.66: Build OK!
v4.19.146: Build OK!
v4.14.198: Build OK!
v4.9.236: Failed to apply! Possible dependencies:
0a97015d45ee ("drm/i915: Compress GPU objects in error state")
83bc0f5b432f ("drm/i915: Handle incomplete Z_FINISH for compressed error
states")
95374d759ac7 ("drm/i915: Always use the GTT for error capture")
98a2f411671f ("drm/i915: Allow disabling error capture")
9f267eb8d2ea ("drm/i915: Stop the machine whilst capturing the GPU crash
dump")
d636951ec01b ("drm/i915: Cleanup instdone collection")
fc4c79c37e82 ("drm/i915: Consolidate error object printing")
v4.4.236: Failed to apply! Possible dependencies:
0a97015d45ee ("drm/i915: Compress GPU objects in error state")
0bc40be85f33 ("drm/i915: Rename intel_engine_cs function parameters")
688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request herd")
755412e29c77 ("drm/i915: Add an optional selection from i915 of
CONFIG_MMU_NOTIFIER")
98a2f411671f ("drm/i915: Allow disabling error capture")
ca82580c9cea ("drm/i915: Do not call API requiring struct_mutex where it is
not available")
cbdc12a9fc9d ("drm/i915: make A0 wa's applied to A1")
e87a005d90c3 ("drm/i915: add helpers for platform specific revision id
range checks")
ef712bb4b700 ("drm/i915: remove parens around revision ids")
fffda3f4fb49 ("drm/i915/bxt: add revision id for A1 stepping and use it")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] XDC 2020 feedback and comments
Hi all, Huge thanks again to the entire team from Intel, for their great work organizing XDC 2020, our first virtual conference! As usual we're looking for feedback on both XDC itself, and the CFP process and program selection. Both about what was great and should be kept for next year's edition, and where there's room for improvement. The board does keep some notes, for those interested in what we have already: - XDC notes for prospective organizers: https://www.x.org/wiki/Events/RFP/ - CFP notes: https://www.x.org/wiki/Events/PapersCommittee/ If you want to send in your comments in private, please send them to the X.org Foundation board: bo...@foundation.x.org Cheers, Sam signature.asc Description: This is a digitally signed message part ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 02/15] highmem: Provide generic variant of kmap_atomic*
> +# ifndef ARCH_NEEDS_KMAP_HIGH_GET
> +static inline void *arch_kmap_temporary_high_get(struct page *page)
> +{
> + return NULL;
> +}
> +# endif
Turn this into a macro and use #ifndef on the symbol name?
> +static inline void __kunmap_atomic(void *addr)
> +{
> + kumap_atomic_indexed(addr);
> +}
> +
> +
> +#endif /* CONFIG_KMAP_ATOMIC_GENERIC */
Stange double empty line above the endif.
> -#define kunmap_atomic(addr) \
> -do {\
> - BUILD_BUG_ON(__same_type((addr), struct page *)); \
> - kunmap_atomic_high(addr); \
> - pagefault_enable(); \
> - preempt_enable(); \
> -} while (0)
> -
> +#define kunmap_atomic(addr) \
> + do {\
> + BUILD_BUG_ON(__same_type((addr), struct page *)); \
> + __kunmap_atomic(addr); \
> + preempt_enable(); \
> + } while (0)
Why the strange re-indent to a form that is much less common and less
readable?
> +void *kmap_atomic_pfn_prot(unsigned long pfn, pgprot_t prot)
> +{
> + pagefault_disable();
> + return __kmap_atomic_pfn_prot(pfn, prot);
> +}
> +EXPORT_SYMBOL(kmap_atomic_pfn_prot);
The existing kmap_atomic_pfn & co implementation is EXPORT_SYMBOL_GPL,
and this stuff should preferably stay that way.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 01/15] mm/highmem: Un-EXPORT __kmap_atomic_idx()
On Sat, Sep 19, 2020 at 11:17:52AM +0200, Thomas Gleixner wrote: > Nothing in modules can use that. > > Signed-off-by: Thomas Gleixner Looks good, Reviewed-by: Christoph Hellwig ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Asynchronous flip implementation for i915 (rev12)
== Series Details ==
Series: Asynchronous flip implementation for i915 (rev12)
URL : https://patchwork.freedesktop.org/series/74386/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9027 -> Patchwork_18539
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/index.html
Known issues
Here are the changes found in Patchwork_18539 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@coherency:
- fi-gdg-551: [PASS][1] -> [DMESG-FAIL][2] ([i915#1748])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-gdg-551/igt@i915_selftest@l...@coherency.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/fi-gdg-551/igt@i915_selftest@l...@coherency.html
Possible fixes
* igt@i915_module_load@reload:
- fi-byt-j1900: [DMESG-WARN][3] ([i915#1982]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-byt-j1900/igt@i915_module_l...@reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/fi-byt-j1900/igt@i915_module_l...@reload.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-bsw-n3050: [DMESG-WARN][5] ([i915#1982]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/fi-bsw-n3050/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- fi-icl-u2: [DMESG-WARN][7] ([i915#1982]) -> [PASS][8] +1 similar
issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@vgem_basic@unload:
- fi-skl-guc: [DMESG-WARN][9] ([i915#2203]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-skl-guc/igt@vgem_ba...@unload.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/fi-skl-guc/igt@vgem_ba...@unload.html
Warnings
* igt@i915_module_load@reload:
- fi-kbl-x1275: [DMESG-WARN][11] ([i915#62] / [i915#92]) ->
[DMESG-WARN][12] ([i915#62] / [i915#92] / [i915#95])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/fi-kbl-x1275/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- fi-kbl-x1275: [DMESG-FAIL][13] ([i915#62] / [i915#95]) ->
[DMESG-FAIL][14] ([i915#62])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/fi-kbl-x1275/igt@i915_pm_...@module-reload.html
- fi-kbl-guc: [SKIP][15] ([fdo#109271]) -> [DMESG-WARN][16]
([i915#2203])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-guc/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/fi-kbl-guc/igt@i915_pm_...@module-reload.html
* igt@prime_vgem@basic-fence-flip:
- fi-kbl-x1275: [DMESG-WARN][17] ([i915#62] / [i915#92] / [i915#95])
-> [DMESG-WARN][18] ([i915#62] / [i915#92]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_9027/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18539/fi-kbl-x1275/igt@prime_v...@basic-fence-flip.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1748]: https://gitlab.freedesktop.org/drm/intel/issues/1748
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
[i915#62]: https://gitlab.freedesktop.org/drm/intel/issues/62
[i915#92]: https://gitlab.freedesktop.org/drm/intel/issues/92
[i915#95]: https://gitlab.freedesktop.org/drm/intel/issues/95
Participating hosts (44 -> 38)
--
Missing(6): fi-ilk-m540 fi-tgl-dsi fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-bdw-samus
Build changes
-
* Linux: CI_DRM_9027 -> Patchwork_18539
CI-20190529: 20190529
CI_DRM_9027: a3a0834d3d2112e8ca11332fdef4e9334868a834 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5787: 0ec962017c8131de14e0cb038f7f76b1f17ed637 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
P
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Asynchronous flip implementation for i915 (rev12)
== Series Details == Series: Asynchronous flip implementation for i915 (rev12) URL : https://patchwork.freedesktop.org/series/74386/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/gt/intel_reset.c:1311:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gvt/mmio.c:290:23: warning: memcpy with byte count of 279040 +drivers/gpu/drm/i915/i915_perf.c:1440:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1494:15: warning: memset with byte count of 16777216 +./include/linux/seqlock.h:752:24: warning: trying to copy expression type 31 +./include/linux/seqlock.h:778:16: warning: trying to copy expression type 31 +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen8_write8' - different lock contexts for basic block ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 5/8] drm/i915: Add dedicated plane hook for async flip case
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
-Add a vfunc for skl_program_async_surface_address
and call it from intel_update_plane. (Ville)
v8: -Rebased.
v9: -Use if-else instead of return in intel_update_plane(). (Ville)
-Rename 'program_async_surface_address' to 'async_flip'. (Ville)
v10: -Check if async_flip hook is present before calling it.
Otherwise it will OOPS during legacy cursor updates. (Ville)
v11: -Rename skl_program_async_surface_address(). (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 6 -
.../drm/i915/display/intel_display_types.h| 3 +++
drivers/gpu/drm/i915/display/intel_sprite.c | 24 +++
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 79032701873a..6bd8e6cdd477 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -408,7 +408,11 @@ void intel_update_plane(struct intel_plane *plane,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
trace_intel_update_plane(&plane->base, crtc);
- plane->update_plane(plane, crtc_state, plane_state);
+
+ if (crtc_state->uapi.async_flip && plane->async_flip)
+ plane->async_flip(plane, crtc_state, plane_state);
+ else
+ plane->update_plane(plane, crtc_state, plane_state);
}
void intel_disable_plane(struct intel_plane *plane,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3d4bf9b6a0a2..e3339e41ddf7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1183,6 +1183,9 @@ struct intel_plane {
struct intel_plane_state *plane_state);
int (*min_cdclk)(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state);
+ void (*async_flip)(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state);
};
struct intel_watermark_params {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 76a3d9bfe0de..d4b8ba7e8015 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -609,6 +609,29 @@ icl_program_input_csc(struct intel_plane *plane,
PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
}
+static void
+skl_plane_async_flip(struct intel_plane *plane,
+const struct intel_crtc_state *crtc_state,
+const struct intel_plane_state *plane_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ unsigned long irqflags;
+ enum plane_id plane_id = plane->id;
+ enum pipe pipe = plane->pipe;
+ u32 surf_addr = plane_state->color_plane[0].offset;
+ u32 plane_ctl = plane_state->ctl;
+
+ plane_ctl |= skl_plane_ctl_crtc(crtc_state);
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+
+ intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
+ intel_plane_ggtt_offset(plane_state) + surf_addr);
+
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+}
+
static void
skl_program_plane(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
@@ -3095,6 +3118,7 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
plane->get_hw_state = skl_plane_get_hw_state;
plane->check_plane = skl_plane_check;
plane->min_cdclk = skl_plane_min_cdclk;
+ plane->async_flip = skl_plane_async_flip;
if (INTEL_GEN(dev_priv) >= 11)
formats = icl_get_plane_formats(dev_priv, pipe,
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 8/8] drm/i915: Enable async flips in i915
Enable asynchronous flips in i915 for gen9+ platforms. v2: -Async flip enablement should be a stand alone patch (Paulo) v3: -Move the patch to the end of the series (Paulo) v4: -Rebased. v5: -Rebased. v6: -Rebased. v7: -Rebased. v8: -Rebased. v9: -Rebased. v10: -Rebased. Signed-off-by: Karthik B S Signed-off-by: Vandita Kulkarni Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index c0e0c8992982..5bb029cfd440 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -18004,6 +18004,9 @@ static void intel_mode_config_init(struct drm_i915_private *i915) mode_config->funcs = &intel_mode_funcs; + if (INTEL_GEN(i915) >= 9) + mode_config->async_page_flip = true; + /* * Maximum framebuffer dimensions, chosen to match * the maximum render engine surface size on gen4+. -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 6/8] drm/i915: WA for platforms with double buffered address update enable bit
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated before continuing
with the normal commit for sync flip.
v9: -Rename skl_toggle_async_sync() to skl_disable_async_flip_wa(). (Ville)
-Place the declarations appropriately as per need. (Ville)
-Take the lock before the reg read. (Ville)
-Fix comment and formatting. (Ville)
-Use IS_GEN_RANGE() for gen check. (Ville)
-Move skl_disable_async_flip_wa() to intel_pre_plane_update(). (Ville)
v10: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 46
1 file changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b3ec08f17c65..dda32ab389b7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6562,6 +6562,43 @@ static void intel_post_plane_update(struct
intel_atomic_state *state,
icl_wa_scalerclkgating(dev_priv, pipe, false);
}
+static void skl_disable_async_flip_wa(struct intel_atomic_state *state,
+ struct intel_crtc *crtc,
+ const struct intel_crtc_state
*new_crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_plane *plane;
+ struct intel_plane_state *new_plane_state;
+ int i;
+
+ for_each_new_intel_plane_in_state(state, plane, new_plane_state, i) {
+ u32 update_mask = new_crtc_state->update_planes;
+ u32 plane_ctl, surf_addr;
+ enum plane_id plane_id;
+ unsigned long irqflags;
+ enum pipe pipe;
+
+ if (crtc->pipe != plane->pipe ||
+ !(update_mask & BIT(plane->id)))
+ continue;
+
+ plane_id = plane->id;
+ pipe = plane->pipe;
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+ plane_ctl = intel_de_read_fw(dev_priv, PLANE_CTL(pipe,
plane_id));
+ surf_addr = intel_de_read_fw(dev_priv, PLANE_SURF(pipe,
plane_id));
+
+ plane_ctl &= ~PLANE_CTL_ASYNC_FLIP;
+
+ intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id),
plane_ctl);
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
surf_addr);
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+ }
+
+ intel_wait_for_vblank(dev_priv, crtc->pipe);
+}
+
static void intel_pre_plane_update(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
@@ -6647,6 +6684,15 @@ static void intel_pre_plane_update(struct
intel_atomic_state *state,
*/
if (IS_GEN(dev_priv, 2) && planes_disabling(old_crtc_state,
new_crtc_state))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
+
+ /*
+* WA for platforms where async address update enable bit
+* is double buffered and only latched at start of vblank.
+*/
+ if (old_crtc_state->uapi.async_flip &&
+ !new_crtc_state->uapi.async_flip &&
+ IS_GEN_RANGE(dev_priv, 9, 10))
+ skl_disable_async_flip_wa(state, crtc, new_crtc_state);
}
static void intel_crtc_disable_planes(struct intel_atomic_state *state,
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 4/8] drm/i915: Do not call drm_crtc_arm_vblank_event in async flips
Since the flip done event will be sent in the flip_done_handler, no need to add the event to the list and delay it for later. v2: -Moved the async check above vblank_get as it was causing issues for PSR. v3: -No need to wait for vblank to pass, as this wait was causing a 16ms delay once every few flips. v4: -Rebased. v5: -Rebased. v6: -Rebased. v7: -No need of irq disable if we are not doing vblank evade. (Ville) v8: -Rebased. v9: -Move the return in intel_pipe_update_end before tracepoint. (Ville) v10: Rebased. Signed-off-by: Karthik B S Signed-off-by: Vandita Kulkarni Reviewed-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c index 63040cb0d4e1..76a3d9bfe0de 100644 --- a/drivers/gpu/drm/i915/display/intel_sprite.c +++ b/drivers/gpu/drm/i915/display/intel_sprite.c @@ -93,6 +93,9 @@ void intel_pipe_update_start(const struct intel_crtc_state *new_crtc_state) DEFINE_WAIT(wait); u32 psr_status; + if (new_crtc_state->uapi.async_flip) + return; + vblank_start = adjusted_mode->crtc_vblank_start; if (adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) vblank_start = DIV_ROUND_UP(vblank_start, 2); @@ -200,6 +203,9 @@ void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state) ktime_t end_vbl_time = ktime_get(); struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); + if (new_crtc_state->uapi.async_flip) + return; + trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end); /* We're still in the vblank-evade critical section, this can't race. -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v11 3/8] drm/i915: Add checks specific to async flips
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
v3: -Removed TODO as benchmarking tests have been run now.
v4: -Added more state checks for async flip (Ville)
-Moved intel_atomic_check_async to the end of intel_atomic_check
as the plane checks needs to pass before this. (Ville)
-Removed crtc_state->enable_fbc check. (Ville)
-Set the I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag for async
flip case as scanline counter is not reliable here.
v5: -Fix typo and other check patch errors seen in CI
in 'intel_atomic_check_async' function.
v6: -Don't call intel_atomic_check_async multiple times. (Ville)
-Remove the check for n_planes in intel_atomic_check_async
-Added documentation for async flips. (Paulo)
v7: -Replace 'intel_plane' with 'plane'. (Ville)
-Replace all uapi.foo as hw.foo. (Ville)
-Do not use intel_wm_need_update function. (Ville)
-Add destination coordinate check. (Ville)
-Do not allow async flip with linear buffer
on older hw as it has issues with this. (Ville)
-Remove break after intel_atomic_check_async. (Ville)
v8: -Rebased.
v9: -Replace DRM_DEBUG_KMS with drm_dbg_kms(). (Ville)
-Fix comment formatting. (Ville)
-Remove gen specific checks. (Ville)
-Remove irrelevant FB size check. (Ville)
-Add missing stride check. (Ville)
-Use drm_rect_equals() instead of individual checks. (Ville)
-Call intel_atomic_check_async before state dump. (Ville)
v10: -Fix the checkpatch errors seen on CI.
v11: -Use const for all plane/crtc states. (Ville)
-Use 'switch' instead of 'if' for modifier check. (Ville)
-Move documentation changes to a single patch. (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 121 +++
1 file changed, 121 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 30e8908ee263..b3ec08f17c65 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14877,6 +14877,121 @@ static bool intel_cpu_transcoders_need_modeset(struct
intel_atomic_state *state,
return false;
}
+static int intel_atomic_check_async(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
+ const struct intel_crtc_state *old_crtc_state, *new_crtc_state;
+ const struct intel_plane_state *new_plane_state, *old_plane_state;
+ struct intel_crtc *crtc;
+ struct intel_plane *plane;
+ int i;
+
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ if (needs_modeset(new_crtc_state)) {
+ drm_dbg_kms(&i915->drm, "Modeset Required. Async flip
not supported\n");
+ return -EINVAL;
+ }
+
+ if (!new_crtc_state->hw.active) {
+ drm_dbg_kms(&i915->drm, "CRTC inactive\n");
+ return -EINVAL;
+ }
+ if (old_crtc_state->active_planes !=
new_crtc_state->active_planes) {
+ drm_dbg_kms(&i915->drm,
+ "Active planes cannot be changed during
async flip\n");
+ return -EINVAL;
+ }
+ }
+
+ for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
+new_plane_state, i) {
+ /*
+* TODO: Async flip is only supported through the page flip
IOCTL
+* as of now. So support currently added for primary plane only.
+* Support for other planes on platforms on which supports
+* this(vlv/chv and icl+) should be added when async flip is
+* enabled in the atomic IOCTL path.
+*/
+ if (plane->id != PLANE_PRIMARY)
+ return -EINVAL;
+
+ /*
+* FIXME: This check is kept generic for all platforms.
+* Need to verify this for all gen9 and gen10 platforms to
enable
+* this selectively if required.
+*/
+ switch (new_plane_state->hw.fb->modifier) {
+ case I915_FORMAT_MOD_X_TILED:
+ case I915_FORMAT_MOD_Y_TILED:
+ case I915_FORMAT_MOD_Yf_TILED:
+ break;
+ default:
+ drm_dbg_kms(&i915->drm,
+ "Linear memory/CCS does not support async
flips\n");
+
[Intel-gfx] [PATCH v10 7/8] Documentation/gpu: Add asynchronous flip documentation for i915
Add the details of the implementation of asynchronous flips for i915.
v7: -Rebased.
v8: -Rebased.
v9: -Rebased.
v10: Move all documentation changes to this patch. (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
---
Documentation/gpu/i915.rst | 6 ++
drivers/gpu/drm/i915/display/intel_display.c | 18 ++
2 files changed, 24 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 33cc6ddf8f64..84ead508f7ad 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -118,6 +118,12 @@ Atomic Plane Helpers
.. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c
:internal:
+Asynchronous Page Flip
+--
+
+.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c
+ :doc: asynchronous flip implementation
+
Output Probing
--
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dda32ab389b7..c0e0c8992982 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14923,6 +14923,24 @@ static bool intel_cpu_transcoders_need_modeset(struct
intel_atomic_state *state,
return false;
}
+/**
+ * DOC: asynchronous flip implementation
+ *
+ * Asynchronous page flip is the implementation for the
DRM_MODE_PAGE_FLIP_ASYNC
+ * flag. Currently async flip is only supported via the drmModePageFlip IOCTL.
+ * Correspondingly, support is currently added for primary plane only.
+ *
+ * Async flip can only change the plane surface address, so anything else
+ * changing is rejected from the intel_atomic_check_async() function.
+ * Once this check is cleared, flip done interrupt is enabled using
+ * the skl_enable_flip_done() function.
+ *
+ * As soon as the surface address register is written, flip done interrupt is
+ * generated and the requested events are sent to the usersapce in the
interrupt
+ * handler itself. The timestamp and sequence sent during the flip done event
+ * correspond to the last vblank and have no relation to the actual time when
+ * the flip done event was sent.
+ */
static int intel_atomic_check_async(struct intel_atomic_state *state)
{
struct drm_i915_private *i915 = to_i915(state->base.dev);
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 1/8] drm/i915: Add enable/disable flip done and flip done handler
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called before writing the
surface address register as the write to this register triggers
the flip done interrupt
Flip done handler is used to send the page flip event as soon as the
surface address is written as per the requirement of async flips.
The interrupt is disabled after the event is sent.
v2: -Change function name from icl_* to skl_* (Paulo)
-Move flip handler to this patch (Paulo)
-Remove vblank_put() (Paulo)
-Enable flip done interrupt for gen9+ only (Paulo)
-Enable flip done interrupt in power_well_post_enable hook (Paulo)
-Removed the event check in flip done handler to handle async
flips without pageflip events.
v3: -Move skl_disable_flip_done out of interrupt handler (Paulo)
-Make the pending vblank event NULL in the beginning of
flip_done_handler to remove sporadic WARN_ON that is seen.
v4: -Calculate timestamps using flip done time stamp and current
timestamp for async flips (Ville)
v5: -Fix the sparse warning by making the function 'g4x_get_flip_counter'
static.(Reported-by: kernel test robot )
-Fix the typo in commit message.
v6: -Revert back to old time stamping code.
-Remove the break while calling skl_enable_flip_done. (Paulo)
v7: -Rebased.
v8: -Rebased.
v9: -Use struct drm_i915_private *i915 in new code. (Ville)
-Use intel_crtc instead of drm_crtc. (Ville)
-Do not mix the flip done and vblank hooks. (Ville)
v10: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 8 +++
drivers/gpu/drm/i915/i915_irq.c | 52
drivers/gpu/drm/i915/i915_irq.h | 3 ++
3 files changed, 63 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5a9d933e425a..171d293a0d88 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -15607,6 +15607,11 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
intel_dbuf_pre_plane_update(state);
+ for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip)
+ skl_enable_flip_done(crtc);
+ }
+
/* Now enable the clocks, plane, pipe, and connectors that we set up. */
dev_priv->display.commit_modeset_enables(state);
@@ -15628,6 +15633,9 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
drm_atomic_helper_wait_for_flip_done(dev, &state->base);
for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
+ if (new_crtc_state->uapi.async_flip)
+ skl_disable_flip_done(crtc);
+
if (new_crtc_state->hw.active &&
!needs_modeset(new_crtc_state) &&
!new_crtc_state->preload_luts &&
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 759f523c6a6b..9b8796c1a256 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1245,6 +1245,23 @@ display_pipe_crc_irq_handler(struct drm_i915_private
*dev_priv,
u32 crc4) {}
#endif
+static void flip_done_handler(struct drm_i915_private *i915,
+ enum pipe pipe)
+{
+ struct intel_crtc *crtc = intel_get_crtc_for_pipe(i915, pipe);
+ struct drm_crtc_state *crtc_state = crtc->base.state;
+ struct drm_pending_vblank_event *e = crtc_state->event;
+ struct drm_device *dev = &i915->drm;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&dev->event_lock, irqflags);
+
+ crtc_state->event = NULL;
+
+ drm_crtc_send_vblank_event(&crtc->base, e);
+
+ spin_unlock_irqrestore(&dev->event_lock, irqflags);
+}
static void hsw_pipe_crc_irq_handler(struct drm_i915_private *dev_priv,
enum pipe pipe)
@@ -2329,6 +2346,9 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv,
u32 master_ctl)
if (iir & GEN8_PIPE_VBLANK)
intel_handle_vblank(dev_priv, pipe);
+ if (iir & GEN9_PIPE_PLANE1_FLIP_DONE)
+ flip_done_handler(dev_priv, pipe);
+
if (iir & GEN8_PIPE_CDCLK_CRC_DONE)
hsw_pipe_crc_irq_handler(dev_priv, pipe);
@@ -2650,6 +2670,19 @@ int bdw_enable_vblank(struct drm_crtc *crtc)
return 0;
}
+void skl_enable_flip_done(struct intel_crtc *crtc)
+{
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&i915->irq_lock, irqflags);
+
+
[Intel-gfx] [PATCH v10 2/8] drm/i915: Add support for async flips in I915
Set the Async Address Update Enable bit in plane ctl
when async flip is requested.
v2: -Move the Async flip enablement to individual patch (Paulo)
v3: -Rebased.
v4: -Add separate plane hook for async flip case (Ville)
v5: -Rebased.
v6: -Move the plane hook to separate patch. (Paulo)
-Remove the early return in skl_plane_ctl. (Paulo)
v7: -Move async address update enable to skl_plane_ctl_crtc() (Ville)
v8: -Rebased.
v9: -Rebased.
v10: -Rebased.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 3 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 171d293a0d88..30e8908ee263 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4785,6 +4785,9 @@ u32 skl_plane_ctl_crtc(const struct intel_crtc_state
*crtc_state)
struct drm_i915_private *dev_priv = to_i915(crtc_state->uapi.crtc->dev);
u32 plane_ctl = 0;
+ if (crtc_state->uapi.async_flip)
+ plane_ctl |= PLANE_CTL_ASYNC_FLIP;
+
if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
return plane_ctl;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d805d4da6181..e94ca1f8f6b2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6923,6 +6923,7 @@ enum {
#define PLANE_CTL_TILED_X(1 << 10)
#define PLANE_CTL_TILED_Y(4 << 10)
#define PLANE_CTL_TILED_YF (5 << 10)
+#define PLANE_CTL_ASYNC_FLIP (1 << 9)
#define PLANE_CTL_FLIP_HORIZONTAL(1 << 8)
#define PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE (1 << 4) /* TGL+ */
#define PLANE_CTL_ALPHA_MASK (0x3 << 4) /* Pre-GLK */
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 0/8] Asynchronous flip implementation for i915
Without async flip support in the kernel, fullscreen apps where game resolution is equal to the screen resolution, must perform an extra blit per frame prior to flipping. Asynchronous page flips will also boost the FPS of Mesa benchmarks. v2: -Few patches have been squashed and patches have been shuffled as per the reviews on the previous version. v3: -Few patches have been squashed and patches have been shuffled as per the reviews on the previous version. v4: -Made changes to fix the sequence and time stamp issue as per the comments received on the previous version. -Timestamps are calculated using the flip done time stamp and current timestamp. Here I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag is used for timestamp calculations. -Event is sent from the interrupt handler immediately using this updated timestamps and sequence. -Added more state checks as async flip should only allow change in plane surface address and nothing else should be allowed to change. -Added a separate plane hook for async flip. -Need to find a way to reject fbc enabling if it comes as part of this flip as bspec states that changes to FBC are not allowed. v5: -Fixed the Checkpatch and sparse warnings. v6: -Reverted back to the old timestamping code as per the feedback received. -Added documentation. v7: -Changes in intel_atomic_check_async() -Add vfunc for skl_program_async_surface_address() v8: -Add WA for older platforms with double buffered async address update enable bit. v9: -Changes as per feedback received on previous version. v10: -Changes as per feedback received on previous version. Karthik B S (8): drm/i915: Add enable/disable flip done and flip done handler drm/i915: Add support for async flips in I915 drm/i915: Add checks specific to async flips drm/i915: Do not call drm_crtc_arm_vblank_event in async flips drm/i915: Add dedicated plane hook for async flip case drm/i915: WA for platforms with double buffered address update enable bit Documentation/gpu: Add asynchronous flip documentation for i915 drm/i915: Enable async flips in i915 Documentation/gpu/i915.rst| 6 + .../gpu/drm/i915/display/intel_atomic_plane.c | 6 +- drivers/gpu/drm/i915/display/intel_display.c | 199 ++ .../drm/i915/display/intel_display_types.h| 3 + drivers/gpu/drm/i915/display/intel_sprite.c | 30 +++ drivers/gpu/drm/i915/i915_irq.c | 52 + drivers/gpu/drm/i915/i915_irq.h | 3 + drivers/gpu/drm/i915/i915_reg.h | 1 + 8 files changed, 299 insertions(+), 1 deletion(-) -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 8/8] drm/i915: Enable async flips in i915
On 9/18/2020 5:33 PM, Ville Syrjälä wrote: On Wed, Sep 16, 2020 at 08:38:24PM +0530, Karthik B S wrote: Enable asynchronous flips in i915 for gen9+ platforms. v2: -Async flip enablement should be a stand alone patch (Paulo) v3: -Move the patch to the end of the series (Paulo) v4: -Rebased. v5: -Rebased. v6: -Rebased. v7: -Rebased. v8: -Rebased. v9: -Rebased. Signed-off-by: Karthik B S Signed-off-by: Vandita Kulkarni --- drivers/gpu/drm/i915/display/intel_display.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 6f6edc581e14..e31abf5f1a9d 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -18021,6 +18021,9 @@ static void intel_mode_config_init(struct drm_i915_private *i915) mode_config->funcs = &intel_mode_funcs; + if (INTEL_GEN(i915) >= 9) + mode_config->async_page_flip = true; + Should have all we need for those platforms I think. Reviewed-by: Ville Syrjälä Thanks for the RB. The followup to enable it for ilk+ would require a slight change to bump X-tiled surface alignment to 256KiB. Apart from the actual regiser smashing part that should be all we need really. Oh, and the double buffer bit w/a will also be needed on bdw. I've now tested snb/ivb/hsw/bdw and only bdw needs it. I guess that's not entirely unsurpising since bdw did introduce one other fail for the flip done interrupt (the interupt fires immediately when the plane was disabled, so can't use flip done to determine when the plane has actually become visible). Fortunately that other fail should have no impact on using it for async flip completion. Sure I'll make the mentioned changes in the followup patches to enable async flip for ilk+ platforms. Thanks, Karthik.B.S /* * Maximum framebuffer dimensions, chosen to match * the maximum render engine surface size on gen4+. -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 7/8] Documentation/gpu: Add asynchronous flip documentation for i915
On 9/18/2020 5:28 PM, Ville Syrjälä wrote: On Wed, Sep 16, 2020 at 08:38:23PM +0530, Karthik B S wrote: Add the details of the implementation of asynchronous flips for i915. v7: -Rebased. v8: -Rebased. v9: -Rebased. Signed-off-by: Karthik B S Signed-off-by: Vandita Kulkarni --- Documentation/gpu/i915.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 33cc6ddf8f64..84ead508f7ad 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -118,6 +118,12 @@ Atomic Plane Helpers .. kernel-doc:: drivers/gpu/drm/i915/display/intel_atomic_plane.c :internal: +Asynchronous Page Flip +-- + +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_display.c + :doc: asynchronous flip implementation A bit weird having this in one patch but the actual docs in the other. I guess just squash them together, or extract the docs from the other patch into this one? Thanks for the review. Sure, I'll move all the doc changes to this patch. Either way Reviewed-by: Ville Syrjälä Thanks, Karthik.B.S + Output Probing -- -- 2.22.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 6/8] drm/i915: WA for platforms with double buffered address update enable bit
On 9/18/2020 5:24 PM, Ville Syrjälä wrote:
On Wed, Sep 16, 2020 at 08:38:22PM +0530, Karthik B S wrote:
In Gen 9 and Gen 10 platforms, async address update enable bit is
double buffered. Due to this, during the transition from async flip
to sync flip we have to wait until this bit is updated before continuing
with the normal commit for sync flip.
v9: -Rename skl_toggle_async_sync() to skl_disable_async_flip_wa(). (Ville)
-Place the declarations appropriately as per need. (Ville)
-Take the lock before the reg read. (Ville)
-Fix comment and formatting. (Ville)
-Use IS_GEN_RANGE() for gen check. (Ville)
-Move skl_disable_async_flip_wa() to intel_pre_plane_update(). (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
Reviewed-by: Ville Syrjälä
Thanks for the RB.
Thanks,
Karthik.B.S
---
drivers/gpu/drm/i915/display/intel_display.c | 46
1 file changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0f0bcbb00c7f..6f6edc581e14 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6562,6 +6562,43 @@ static void intel_post_plane_update(struct
intel_atomic_state *state,
icl_wa_scalerclkgating(dev_priv, pipe, false);
}
+static void skl_disable_async_flip_wa(struct intel_atomic_state *state,
+ struct intel_crtc *crtc,
+ const struct intel_crtc_state
*new_crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ struct intel_plane *plane;
+ struct intel_plane_state *new_plane_state;
+ int i;
+
+ for_each_new_intel_plane_in_state(state, plane, new_plane_state, i) {
+ u32 update_mask = new_crtc_state->update_planes;
+ u32 plane_ctl, surf_addr;
+ enum plane_id plane_id;
+ unsigned long irqflags;
+ enum pipe pipe;
+
+ if (crtc->pipe != plane->pipe ||
+ !(update_mask & BIT(plane->id)))
+ continue;
+
+ plane_id = plane->id;
+ pipe = plane->pipe;
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+ plane_ctl = intel_de_read_fw(dev_priv, PLANE_CTL(pipe,
plane_id));
+ surf_addr = intel_de_read_fw(dev_priv, PLANE_SURF(pipe,
plane_id));
+
+ plane_ctl &= ~PLANE_CTL_ASYNC_FLIP;
+
+ intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id),
plane_ctl);
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
surf_addr);
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+ }
+
+ intel_wait_for_vblank(dev_priv, crtc->pipe);
+}
+
static void intel_pre_plane_update(struct intel_atomic_state *state,
struct intel_crtc *crtc)
{
@@ -6647,6 +6684,15 @@ static void intel_pre_plane_update(struct
intel_atomic_state *state,
*/
if (IS_GEN(dev_priv, 2) && planes_disabling(old_crtc_state,
new_crtc_state))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
+
+ /*
+* WA for platforms where async address update enable bit
+* is double buffered and only latched at start of vblank.
+*/
+ if (old_crtc_state->uapi.async_flip &&
+ !new_crtc_state->uapi.async_flip &&
+ IS_GEN_RANGE(dev_priv, 9, 10))
+ skl_disable_async_flip_wa(state, crtc, new_crtc_state);
}
static void intel_crtc_disable_planes(struct intel_atomic_state *state,
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 5/8] drm/i915: Add dedicated plane hook for async flip case
On 9/18/2020 5:23 PM, Ville Syrjälä wrote:
On Fri, Sep 18, 2020 at 12:30:45PM +0530, Karthik B S wrote:
This hook is added to avoid writing other plane registers in case of
async flips, so that we do not write the double buffered registers
during async surface address update.
v7: -Plane ctl needs bits from skl_plane_ctl_crtc as well. (Ville)
-Add a vfunc for skl_program_async_surface_address
and call it from intel_update_plane. (Ville)
v8: -Rebased.
v9: -Use if-else instead of return in intel_update_plane(). (Ville)
-Rename 'program_async_surface_address' to 'async_flip'. (Ville)
v10: -Check if async_flip hook is present before calling it.
Otherwise it will OOPS during legacy cursor updates. (Ville)
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 6 -
.../drm/i915/display/intel_display_types.h| 3 +++
drivers/gpu/drm/i915/display/intel_sprite.c | 24 +++
3 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 79032701873a..6bd8e6cdd477 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -408,7 +408,11 @@ void intel_update_plane(struct intel_plane *plane,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
trace_intel_update_plane(&plane->base, crtc);
- plane->update_plane(plane, crtc_state, plane_state);
+
+ if (crtc_state->uapi.async_flip && plane->async_flip)
+ plane->async_flip(plane, crtc_state, plane_state);
+ else
+ plane->update_plane(plane, crtc_state, plane_state);
}
void intel_disable_plane(struct intel_plane *plane,
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 3d4bf9b6a0a2..e3339e41ddf7 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1183,6 +1183,9 @@ struct intel_plane {
struct intel_plane_state *plane_state);
int (*min_cdclk)(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state);
+ void (*async_flip)(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state);
};
struct intel_watermark_params {
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 76a3d9bfe0de..3634e98b04c1 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -609,6 +609,29 @@ icl_program_input_csc(struct intel_plane *plane,
PLANE_INPUT_CSC_POSTOFF(pipe, plane_id, 2), 0x0);
}
+static void
+skl_program_async_surface_address(struct intel_plane *plane,
+ const struct intel_crtc_state *crtc_state,
+ const struct intel_plane_state *plane_state)
Pls rename this to skl_plane_async_flip() as well.
Thanks for the review.
Sure, I'll update this.
With that
Reviewed-by: Ville Syrjälä
Thanks,
Karthik.B.S
+{
+ struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
+ unsigned long irqflags;
+ enum plane_id plane_id = plane->id;
+ enum pipe pipe = plane->pipe;
+ u32 surf_addr = plane_state->color_plane[0].offset;
+ u32 plane_ctl = plane_state->ctl;
+
+ plane_ctl |= skl_plane_ctl_crtc(crtc_state);
+
+ spin_lock_irqsave(&dev_priv->uncore.lock, irqflags);
+
+ intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), plane_ctl);
+ intel_de_write_fw(dev_priv, PLANE_SURF(pipe, plane_id),
+ intel_plane_ggtt_offset(plane_state) + surf_addr);
+
+ spin_unlock_irqrestore(&dev_priv->uncore.lock, irqflags);
+}
+
static void
skl_program_plane(struct intel_plane *plane,
const struct intel_crtc_state *crtc_state,
@@ -3095,6 +3118,7 @@ skl_universal_plane_create(struct drm_i915_private
*dev_priv,
plane->get_hw_state = skl_plane_get_hw_state;
plane->check_plane = skl_plane_check;
plane->min_cdclk = skl_plane_min_cdclk;
+ plane->async_flip = skl_program_async_surface_address;
if (INTEL_GEN(dev_priv) >= 11)
formats = icl_get_plane_formats(dev_priv, pipe,
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v10 3/8] drm/i915: Add checks specific to async flips
On 9/18/2020 5:21 PM, Ville Syrjälä wrote:
On Fri, Sep 18, 2020 at 02:32:34PM +0530, Karthik B S wrote:
If flip is requested on any other plane, reject it.
Make sure there is no change in fbc, offset and framebuffer modifiers
when async flip is requested.
If any of these are modified, reject async flip.
v2: -Replace DRM_ERROR (Paulo)
-Add check for changes in OFFSET, FBC, RC(Paulo)
v3: -Removed TODO as benchmarking tests have been run now.
v4: -Added more state checks for async flip (Ville)
-Moved intel_atomic_check_async to the end of intel_atomic_check
as the plane checks needs to pass before this. (Ville)
-Removed crtc_state->enable_fbc check. (Ville)
-Set the I915_MODE_FLAG_GET_SCANLINE_FROM_TIMESTAMP flag for async
flip case as scanline counter is not reliable here.
v5: -Fix typo and other check patch errors seen in CI
in 'intel_atomic_check_async' function.
v6: -Don't call intel_atomic_check_async multiple times. (Ville)
-Remove the check for n_planes in intel_atomic_check_async
-Added documentation for async flips. (Paulo)
v7: -Replace 'intel_plane' with 'plane'. (Ville)
-Replace all uapi.foo as hw.foo. (Ville)
-Do not use intel_wm_need_update function. (Ville)
-Add destination coordinate check. (Ville)
-Do not allow async flip with linear buffer
on older hw as it has issues with this. (Ville)
-Remove break after intel_atomic_check_async. (Ville)
v8: -Rebased.
v9: -Replace DRM_DEBUG_KMS with drm_dbg_kms(). (Ville)
-Fix comment formatting. (Ville)
-Remove gen specific checks. (Ville)
-Remove irrelevant FB size check. (Ville)
-Add missing stride check. (Ville)
-Use drm_rect_equals() instead of individual checks. (Ville)
-Call intel_atomic_check_async before state dump. (Ville)
v10: -Fix the checkpatch errors seen on CI.
Signed-off-by: Karthik B S
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_display.c | 137 +++
1 file changed, 137 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 30e8908ee263..7327ed4a04f8 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -14877,6 +14877,137 @@ static bool intel_cpu_transcoders_need_modeset(struct
intel_atomic_state *state,
return false;
}
+/**
+ * DOC: asynchronous flip implementation
+ *
+ * Asynchronous page flip is the implementation for the
DRM_MODE_PAGE_FLIP_ASYNC
+ * flag. Currently async flip is only supported via the drmModePageFlip IOCTL.
+ * Correspondingly, support is currently added for primary plane only.
+ *
+ * Async flip can only change the plane surface address, so anything else
+ * changing is rejected from the intel_atomic_check_async() function.
+ * Once this check is cleared, flip done interrupt is enabled using
+ * the skl_enable_flip_done() function.
+ *
+ * As soon as the surface address register is written, flip done interrupt is
+ * generated and the requested events are sent to the usersapce in the
interrupt
+ * handler itself. The timestamp and sequence sent during the flip done event
+ * correspond to the last vblank and have no relation to the actual time when
+ * the flip done event was sent.
+ */
+
+static int intel_atomic_check_async(struct intel_atomic_state *state)
+{
+ struct drm_i915_private *i915 = to_i915(state->base.dev);
+ struct intel_crtc_state *old_crtc_state, *new_crtc_state;
+ struct intel_plane_state *new_plane_state, *old_plane_state;a
All plane/crtc states can be const I believe.
Thanks for the review.
Sure, I'll update this.
+ struct intel_crtc *crtc;
+ struct intel_plane *plane;
+ int i;
+
+ for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
+ new_crtc_state, i) {
+ if (needs_modeset(new_crtc_state)) {
+ drm_dbg_kms(&i915->drm, "Modeset Required. Async flip not
supported\n");
+ return -EINVAL;
+ }
+
+ if (!new_crtc_state->hw.active) {
+ drm_dbg_kms(&i915->drm, "CRTC inactive\n");
+ return -EINVAL;
+ }
+ if (old_crtc_state->active_planes !=
new_crtc_state->active_planes) {
+ drm_dbg_kms(&i915->drm,
+ "Active planes cannot be changed during async
flip\n");
+ return -EINVAL;
+ }
+ }
+
+ for_each_oldnew_intel_plane_in_state(state, plane, old_plane_state,
+new_plane_state, i) {
+ /*
+* TODO: Async flip is only supported through the page flip
IOCTL
+* as of now. So support currently added for primary plane only.
+* Support for other
Re: [Intel-gfx] [PATCH] drm/i915: Fix uninitialised variable in intel_context_create_request.
Op 18-09-2020 om 19:19 schreef Rodrigo Vivi:
> On Fri, Sep 18, 2020 at 01:12:08PM +0200, Maarten Lankhorst wrote:
>> In case backoff fails with an error, we return an undefined rq,
>> assign err to rq correctly.
>>
>> Fixes: 8a929c9eb1c2 ("drm/i915: Use ww pinning for
>> intel_context_create_request()")
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/gt/intel_context.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
>> b/drivers/gpu/drm/i915/gt/intel_context.c
>> index d301dda1b261..92a3f25c4006 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_context.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_context.c
>> @@ -472,6 +472,7 @@ struct i915_request *intel_context_create_request(struct
>> intel_context *ce)
>> err = i915_gem_ww_ctx_backoff(&ww);
>> if (!err)
>> goto retry;
>> +rq = ERR_PTR(err);
> The mix with "err" and rq handling both request and err is a bit confusing
> ihmo and prone to misses like this.
>
> I wonder if we also need this before the goto retry as well...
> but anyway it looks better than before with no rq assigment on this block...
>
>
> Reviewed-by: Rodrigo Vivi
>
>
>
>> } else {
>> rq = ERR_PTR(err);
>> }
>>
>> base-commit: 5887fa2d8b9b7f6a278f9a1bc8642cb9d5d0279a
>> --
>> 2.28.0
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Thanks, pushed. :)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] managed drm_device, absolute final leftover bits
On Fri, Sep 18, 2020 at 01:12:21PM -0400, Rodrigo Vivi wrote: > On Fri, Sep 18, 2020 at 11:03:12AM -0400, Alex Deucher wrote: > > On Fri, Sep 18, 2020 at 9:25 AM Daniel Vetter > > wrote: > > > > > > Hi all, > > > > > > These are the leftovers of the leftovers of my initial drmm series to > > > manage drm_device. > > > > > > Changes: > > > - bugfixed i915 selftests > > > - patch from Luben to finalize the admgpu conversion > > > > > > Alex & i915 maintainers, pls ack for merging this all through > > > drm-misc-next since otherwise the final patch (and the resulting confusion > > > with outdated docs) is held up another round. > > > > Acked-by: Alex Deucher > > > Acked-by: Rodrigo Vivi Entire series merged into drm-misc-next. -Daniel > > > > > > > > > Cheers, Daniel > > > > > > Daniel Vetter (3): > > > drm/i915/selftest: Create mock_destroy_device > > > drm/i915/selftests: align more to real device lifetimes > > > drm/dev: Remove drm_dev_init > > > > > > Luben Tuikov (1): > > > drm/amdgpu: Convert to using devm_drm_dev_alloc() (v2) > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16 ++ > > > drivers/gpu/drm/drm_drv.c | 41 ++-- > > > drivers/gpu/drm/drm_internal.h| 1 + > > > drivers/gpu/drm/drm_managed.c | 13 - > > > .../gpu/drm/i915/gem/selftests/huge_pages.c | 2 +- > > > .../drm/i915/gem/selftests/i915_gem_context.c | 2 +- > > > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 2 +- > > > .../drm/i915/gem/selftests/i915_gem_object.c | 2 +- > > > .../drm/i915/gem/selftests/i915_gem_phys.c| 2 +- > > > drivers/gpu/drm/i915/gt/selftest_timeline.c | 2 +- > > > .../gpu/drm/i915/selftests/i915_gem_evict.c | 2 +- > > > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +- > > > drivers/gpu/drm/i915/selftests/i915_request.c | 2 +- > > > drivers/gpu/drm/i915/selftests/i915_vma.c | 2 +- > > > .../drm/i915/selftests/intel_memory_region.c | 2 +- > > > .../gpu/drm/i915/selftests/mock_gem_device.c | 49 --- > > > .../gpu/drm/i915/selftests/mock_gem_device.h | 2 + > > > include/drm/drm_drv.h | 4 -- > > > 18 files changed, 51 insertions(+), 97 deletions(-) > > > > > > -- > > > 2.28.0 > > > > > > ___ > > > amd-gfx mailing list > > > amd-...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/amd-gfx > > ___ > > Intel-gfx mailing list > > Intel-gfx@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler
Quoting Zbigniew Kempczyński (2020-09-21 04:50:17) > On !llc platforms when buffer is mapped with WB using GEM_MMAP_OFFSET > pagefault handler clears its dirty flag. This has consequences > buffer is not flushed on exec before moving to render domain. > So make sure we keep dirty flag for buffers mapped to write until > it leaves cpu domain. So the faulthandler is only tangentially associated with cache domains. In that a fresh fault is likely to indicate utilisation of the cpu domain, but it is not definitive; there may either be no fault between domain changes or the fault does not incur any. So we do not touch the domain during the fault, that is required to be tracked by set-domain around the access. This ensures the fault has no implicit domain changes, waits or locks. In particular, the path of interest here is relatively new, using the old mmap ioctl, we do not see the fault at all. The bug you are looking for is in set_domain_ioctl. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
On Sun, Sep 20 2020 at 10:42, Linus Torvalds wrote: > On Sun, Sep 20, 2020 at 10:40 AM Thomas Gleixner wrote: >> >> I think the more obvious solution is to split the whole exercise: >> >> schedule() >> prepare_switch() >> unmap() >> >> switch_to() >> >> finish_switch() >> map() > > Yeah, that looks much easier to explain. Ack. So far so good, but Peter Z. just pointed out to me that I completely missed the fact that this cannot work. If a task is migrated to a different CPU then the mapping address will change which will explode in colourful ways. On RT kernels this works because we ping the task to the CPU via migrate_disable(). On a !RT kernel migrate_disable() maps to preempt_disable() which brings us back to square one. /me goes back to the drawing board. Thanks, tglx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault handler (rev2)
On Mon, Sep 21, 2020 at 06:55:36AM +, Patchwork wrote: >Patch Details > >Series: drm/i915: Ensure bo is dirty when WB-mapped on !llc in pagefault > > handler (rev2) > >URL: https://patchwork.freedesktop.org/series/81881/ > >State: failure > >Details: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18538/index.html > >CI Bug Log - changes from CI_DRM_9025_full -> Patchwork_18538_full > > Summary > >FAILURE > >Serious unknown changes coming with Patchwork_18538_full absolutely need >to be >verified manually. > >If you think the reported changes have nothing to do with the changes >introduced in Patchwork_18538_full, please notify your bug team to allow >them >to document this new failure mode, which will reduce false positives in >CI. > > Possible new issues > >Here are the unknown changes that may have been introduced in >Patchwork_18538_full: > > IGT changes > > Possible regressions > > * igt@kms_flip@2x-nonexisting-fb-interruptible@ac-vga1-hdmi-a1: > * shard-hsw: NOTRUN -> INCOMPLETE +1 similar issue Unrelated. See below. > > Known issues > >Here are the changes found in Patchwork_18538_full that come from known >issues: > > IGT changes > > Issues hit > > * igt@gem_ctx_persistence@engines-mixed-process@bcs0: > > * shard-skl: PASS -> FAIL (i915#2374) > * igt@gem_ctx_persistence@legacy-engines-mixed@vebox: > > * shard-kbl: PASS -> DMESG-WARN (i915#1982) > * igt@gem_exec_reloc@basic-many-active@rcs0: > > * shard-glk: PASS -> FAIL (i915#2389) +3 similar issues > * igt@gem_huc_copy@huc-copy: > > * shard-tglb: PASS -> SKIP (i915#2190) > * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: > > * shard-hsw: PASS -> FAIL (i915#96) > * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: > > * shard-skl: PASS -> DMESG-WARN (i915#1982) +5 similar issues > * igt@kms_cursor_legacy@pipe-b-torture-bo: > > * shard-iclb: PASS -> DMESG-WARN (i915#128) > * igt@kms_draw_crc@draw-method-rgb565-pwrite-untiled: > > * shard-skl: PASS -> FAIL (i915#177 / i915#52 / i915#54) > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-fullscreen: > > * shard-tglb: PASS -> DMESG-WARN (i915#1982) +2 similar issues > * igt@kms_frontbuffer_tracking@psr-1p-primscrn-pri-indfb-draw-mmap-wc: > > * shard-skl: PASS -> FAIL (i915#49) +1 similar issue > * igt@kms_hdr@bpc-switch-suspend: > > * shard-skl: PASS -> FAIL (i915#1188) +1 similar issue > * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-a-planes: > > * shard-iclb: PASS -> INCOMPLETE (i915#1185 / i915#250) > * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: > > * shard-skl: PASS -> FAIL (fdo#108145 / i915#265) +1 similar issue > * igt@kms_psr@psr2_cursor_render: > > * shard-iclb: PASS -> SKIP (fdo#109441) +1 similar issue > > Possible fixes > > * igt@gem_eio@suspend: > > * shard-iclb: INCOMPLETE (i915#2483) -> PASS > * igt@gem_mmap_offset@blt-coherency: > > * shard-glk: FAIL (i915#2328) -> PASS Change was related to fix above coherency issue. -- Zbigniew > * igt@gem_userptr_blits@sync-unmap-cycles: > > * shard-skl: TIMEOUT (i915#1958 / i915#2424) -> PASS > * igt@i915_selftest@mock@contexts: > > * shard-apl: INCOMPLETE (i915#1635 / i915#2278) -> PASS > * igt@kms_cursor_legacy@2x-cursor-vs-flip-atomic: > > * shard-hsw: INCOMPLETE (CI#80) -> PASS > * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy: > > * shard-glk: FAIL (i915#72) -> PASS > * igt@kms_flip@2x-dpms-vs-vblank-race@ab-vga1-hdmi-a1: > > * shard-hsw: DMESG-WARN (i915#1982) -> PASS > * igt@kms_flip@2x-flip-vs-suspend-interruptible@bc-vga1-hdmi-a1: > > * shard-hsw: INCOMPLETE (i915#2055) -> PASS > * igt@kms_flip@flip-vs-suspend@c-dp1: > > * shard-kbl: DMESG-WARN (i915#180) -> PASS +3 similar issues > * igt@kms_flip@plain-flip-ts-check-interruptible@c-edp1: > > * shard-skl: FAIL (i915#2122) -> PASS +1 similar issue > * igt@kms_frontbuffer_tracking@fbcpsr-1p-pri-indfb-multidraw: > > * shard-iclb: DMESG-WARN (i915#1982) -> PASS > * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-fullscreen: > > * shard-tglb: DMESG-WARN (i915#1982) -> PASS > * igt@kms_hdr@bpc-switch-dpms: > > * shard-skl: FAIL (i915#1188) -> PASS > * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: > > * shard-skl: DMESG-WARN (i915#1982) -> PASS +5 similar issues > * igt@kms_psr@psr2_spr
