[PATCH v2] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME
From: Guangming Cao
If dma-buf don't want userspace users to touch the dmabuf buffer,
it seems we should add this restriction into dma_buf_ops.mmap,
not in this IOCTL:DMA_BUF_SET_NAME.
With this restriction, we can only know the kernel users of the dmabuf
by attachments.
However, for many userspace users, such as userpsace users of dma_heap,
they also need to mark the usage of dma-buf, and they don't care about
who attached to this dmabuf, and seems it's no meaning to be waiting for
IOCTL:DMA_BUF_SET_NAME rather than mmap.
Signed-off-by: Guangming Cao
---
drivers/dma-buf/dma-buf.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 511fe0d217a0..db2f4efdec32 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
/**
* dma_buf_set_name - Set a name to a specific dma_buf to track the usage.
- * The name of the dma-buf buffer can only be set when the dma-buf is not
- * attached to any devices. It could theoritically support changing the
- * name of the dma-buf if the same piece of memory is used for multiple
- * purpose between different devices.
+ * It could theoretically support changing the name of the dma-buf if the same
+ * piece of memory is used for multiple purpose between different devices.
*
* @dmabuf: [in] dmabuf buffer that will be renamed.
* @buf:[in] A piece of userspace memory that contains the name of
@@ -346,19 +344,11 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
const char __user *buf)
if (IS_ERR(name))
return PTR_ERR(name);
- dma_resv_lock(dmabuf->resv, NULL);
- if (!list_empty(>attachments)) {
- ret = -EBUSY;
- kfree(name);
- goto out_unlock;
- }
spin_lock(>name_lock);
kfree(dmabuf->name);
dmabuf->name = name;
spin_unlock(>name_lock);
-out_unlock:
- dma_resv_unlock(dmabuf->resv);
return ret;
}
--
2.17.1
Re: [PATCH 1/6] lib/scatterlist: Add contiguous DMA chunks helpers
On Thu, Sep 16, 2021 at 11:43:59AM +0200, Thierry Reding wrote: > From: Thierry Reding > > Add a few helpers to count the number of contiguous DMA chunks found in > an SG table. This is useful to determine whether or not a mapping can be > used by drivers whose devices need contiguous memory. [...] Is the counting of all blocks necessary if all to be checked is whether there is more than one continuous block? Best Regards Michał Mirosław
Re: [PATCH] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME
On 10/8/21 7:47 PM, guangming@mediatek.com wrote:
From: Guangming Cao
If dma-buf don't want userspace users to touch the dmabuf buffer,
it seems we should add this restriction into dma_buf_ops.mmap,
not in this IOCTL:DMA_BUF_SET_NAME.
With this restriction, we can only know the kernel users of the dmabuf
by attachments.
However, for many userspace users, such as userpsace users of dma_heap,
they also need to mark the usage of dma-buf, and they don't care about
who attached to this dmabuf, and seems it's no meaning to waitting for
to be waiting for
IOCTL:DMA_BUF_SET_NAME rather than mmap.
Signed-off-by: Guangming Cao
---
drivers/dma-buf/dma-buf.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 511fe0d217a0..afbd0a226639 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
/**
* dma_buf_set_name - Set a name to a specific dma_buf to track the usage.
- * The name of the dma-buf buffer can only be set when the dma-buf is not
- * attached to any devices. It could theoritically support changing the
- * name of the dma-buf if the same piece of memory is used for multiple
- * purpose between different devices.
+ * It could theoritically support changing the name of the dma-buf if the same
theoretically
(yes, it was incorrect before this change.)
+ * piece of memory is used for multiple purpose between different devices.
*
* @dmabuf: [in] dmabuf buffer that will be renamed.
* @buf:[in] A piece of userspace memory that contains the name of
@@ -346,19 +344,11 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
const char __user *buf)
if (IS_ERR(name))
return PTR_ERR(name);
- dma_resv_lock(dmabuf->resv, NULL);
- if (!list_empty(>attachments)) {
- ret = -EBUSY;
- kfree(name);
- goto out_unlock;
- }
spin_lock(>name_lock);
kfree(dmabuf->name);
dmabuf->name = name;
spin_unlock(>name_lock);
-out_unlock:
- dma_resv_unlock(dmabuf->resv);
return ret;
}
--
~Randy
[PATCH v4] drm/i915/gt: move remaining debugfs interfaces into gt
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
\-- reset
For backwards compatibility with existing igt (and the slight
semantic difference between operating on the i915 abi entry
points and the deep gt info):
dri/0
|
+-- i915_wedged
|
\-- i915_forcewake_user
remain at the top level.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
Changelog:
--
v3 -> v4: https://patchwork.freedesktop.org/patch/458225/
* remove the unnecessary interrupt_info_show() information. They
were already removed here by Chris:
cf977e18610e6 ("drm/i915/gem: Spring clean debugfs")
v2 -> v3: https://patchwork.freedesktop.org/patch/458108/
* keep the original interfaces as they were (thanks Chris) but
implement the functionality inside the gt. The upper level
files will call the gt functions (thanks Lucas).
v1 -> v2: https://patchwork.freedesktop.org/patch/456652/
* keep the original interfaces intact (thanks Chris).
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 42 ++
drivers/gpu/drm/i915/gt/intel_gt_debugfs.h| 4 ++
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 41 ++
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h | 4 ++
drivers/gpu/drm/i915/i915_debugfs.c | 43 +++
5 files changed, 98 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index 1fe19ccd27942..f712670993b68 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -13,6 +13,46 @@
#include "pxp/intel_pxp_debugfs.h"
#include "uc/intel_uc_debugfs.h"
+int reset_show(void *data, u64 *val)
+{
+ struct intel_gt *gt = data;
+ int ret = intel_gt_terminally_wedged(gt);
+
+ switch (ret) {
+ case -EIO:
+ *val = 1;
+ return 0;
+ case 0:
+ *val = 0;
+ return 0;
+ default:
+ return ret;
+ }
+}
+
+int reset_store(void *data, u64 val)
+{
+ struct intel_gt *gt = data;
+
+ /* Flush any previous reset before applying for a new one */
+ wait_event(gt->reset.queue,
+ !test_bit(I915_RESET_BACKOFF, >reset.flags));
+
+ intel_gt_handle_error(gt, val, I915_ERROR_CAPTURE,
+ "Manually reset engine mask to %llx", val);
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(reset_fops, reset_show, reset_store, "%llu\n");
+
+static void gt_debugfs_register(struct intel_gt *gt, struct dentry *root)
+{
+ static const struct intel_gt_debugfs_file files[] = {
+ { "reset", _fops, NULL },
+ };
+
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
+}
+
void intel_gt_debugfs_register(struct intel_gt *gt)
{
struct dentry *root;
@@ -24,6 +64,8 @@ void intel_gt_debugfs_register(struct intel_gt *gt)
if (IS_ERR(root))
return;
+ gt_debugfs_register(gt, root);
+
intel_gt_engines_debugfs_register(gt, root);
intel_gt_pm_debugfs_register(gt, root);
intel_sseu_debugfs_register(gt, root);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
index 8b6fca09897ce..6bc4f044c23f3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
@@ -35,4 +35,8 @@ void intel_gt_debugfs_register_files(struct dentry *root,
const struct intel_gt_debugfs_file *files,
unsigned long count, void *data);
+/* functions that need to be accessed by the upper level non-gt interfaces */
+int reset_show(void *data, u64 *val);
+int reset_store(void *data, u64 val);
+
#endif /* INTEL_GT_DEBUGFS_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 5f84ad6026423..712c91d588eb3 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -19,6 +19,46 @@
#include "intel_sideband.h"
#include "intel_uncore.h"
+int __forcewake_user_open(struct intel_gt *gt)
+{
+ atomic_inc(>user_wakeref);
+ intel_gt_pm_get(gt);
+ if (GRAPHICS_VER(gt->i915) >= 6)
+ intel_uncore_forcewake_user_get(gt->uncore);
+
+ return 0;
+}
+
+int __forcewake_user_release(struct intel_gt *gt)
+{
+ if (GRAPHICS_VER(gt->i915) >= 6)
+ intel_uncore_forcewake_user_put(gt->uncore);
+ intel_gt_pm_put(gt);
+ atomic_dec(>user_wakeref);
+
+ return 0;
+}
+
+static int forcewake_user_open(struct inode *inode, struct file *file)
+{
+ struct intel_gt *gt = inode->i_private;
+
+ return
[PATCH] dma-buf: remove restriction of IOCTL:DMA_BUF_SET_NAME
From: Guangming Cao
If dma-buf don't want userspace users to touch the dmabuf buffer,
it seems we should add this restriction into dma_buf_ops.mmap,
not in this IOCTL:DMA_BUF_SET_NAME.
With this restriction, we can only know the kernel users of the dmabuf
by attachments.
However, for many userspace users, such as userpsace users of dma_heap,
they also need to mark the usage of dma-buf, and they don't care about
who attached to this dmabuf, and seems it's no meaning to waitting for
IOCTL:DMA_BUF_SET_NAME rather than mmap.
Signed-off-by: Guangming Cao
---
drivers/dma-buf/dma-buf.c | 14 ++
1 file changed, 2 insertions(+), 12 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 511fe0d217a0..afbd0a226639 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -325,10 +325,8 @@ static __poll_t dma_buf_poll(struct file *file, poll_table
*poll)
/**
* dma_buf_set_name - Set a name to a specific dma_buf to track the usage.
- * The name of the dma-buf buffer can only be set when the dma-buf is not
- * attached to any devices. It could theoritically support changing the
- * name of the dma-buf if the same piece of memory is used for multiple
- * purpose between different devices.
+ * It could theoritically support changing the name of the dma-buf if the same
+ * piece of memory is used for multiple purpose between different devices.
*
* @dmabuf: [in] dmabuf buffer that will be renamed.
* @buf:[in] A piece of userspace memory that contains the name of
@@ -346,19 +344,11 @@ static long dma_buf_set_name(struct dma_buf *dmabuf,
const char __user *buf)
if (IS_ERR(name))
return PTR_ERR(name);
- dma_resv_lock(dmabuf->resv, NULL);
- if (!list_empty(>attachments)) {
- ret = -EBUSY;
- kfree(name);
- goto out_unlock;
- }
spin_lock(>name_lock);
kfree(dmabuf->name);
dmabuf->name = name;
spin_unlock(>name_lock);
-out_unlock:
- dma_resv_unlock(dmabuf->resv);
return ret;
}
--
2.17.1
Re: [Intel-gfx] [PATCH v3] drm/i915/gt: move remaining debugfs interfaces into gt
Hi Ville,
> > + if (IS_CHERRYVIEW(i915)) {
> > + seq_printf(m, "Master Interrupt Control:\t%08x\n",
> > + intel_uncore_read(uncore, GEN8_MASTER_IRQ));
> > +
> > + for (i = 0; i < 4; i++) {
> > + seq_printf(m, "GT Interrupt IMR %d:\t%08x\n",
> > + i, intel_uncore_read(uncore,
> > + GEN8_GT_IMR(i)));
> > + seq_printf(m, "GT Interrupt IIR %d:\t%08x\n",
> > + i, intel_uncore_read(uncore,
> > + GEN8_GT_IIR(i)));
> > + seq_printf(m, "GT Interrupt IER %d:\t%08x\n",
> > + i, intel_uncore_read(uncore,
> > + GEN8_GT_IER(i)));
> > + }
> > +
>
> Why does chv get its own block? Looks identical to the bdw block.
[...]
> > + } else if (!HAS_PCH_SPLIT(i915)) {
>
> HAS_PCH_SPLIT in gt code looks a bit out of place.
>
> > + seq_printf(m, "Interrupt enable:%08x\n",
> > + intel_uncore_read(uncore, GEN2_IER));
> > + seq_printf(m, "Interrupt identity: %08x\n",
> > + intel_uncore_read(uncore, GEN2_IIR));
> > + seq_printf(m, "Interrupt mask: %08x\n",
> > + intel_uncore_read(uncore, GEN2_IMR));
>
> Technically on gen2 these are 16 bits, on gen3+ 32 bits. I don't
> quite remember now what happens when you read them as 32bit on gen2.
> Might be the msbs just come out all zeroes.
>
> > + } else {
> > + seq_printf(m, "Graphics Interrupt enable: %08x\n",
> > + intel_uncore_read(uncore, GTIER));
> > + seq_printf(m, "Graphics Interrupt identity: %08x\n",
> > + intel_uncore_read(uncore, GTIIR));
> > + seq_printf(m, "Graphics Interrupt mask: %08x\n",
> > + intel_uncore_read(uncore, GTIMR));
>
> Probably this should be before the previous block to keep things in
> order. Also missing GEN6_PM stuff for snb+, and the master interrupt
> stuff for ilk+.
[...]
thanks for your input. Actually I'm not even sure this part of
the patch is required anymore. It was originally a copy paste of
the parts of the 'i915_interrupt_info' functions in the
'i915_gem_interrupt' debugfs file.
This file was removed here by Chris:
cf977e18610e6 ("drm/i915/gem: Spring clean debugfs")
I have reproposed it in this patch seeking for comments because I
wanted to understand after all this time it might be needed or
not. If not I was going to remove it in my last version.
I haven't received any comments and therefore I am going to
remove it in v4.
Thank you,
Andi
Re: [PATCH v2] drm/i915/gt: move remaining debugfs interfaces into gt
On Fri, Oct 8, 2021 at 3:14 AM Andi Shyti wrote:
>
> Hi Lucas,
>
> > > I am reproposing this patch exactly as it was proposed initially
> > > where the original interfaces are kept where they have been
> > > originally placed. It might generate some duplicated code but,
> > > well, it's debugfs and I don't see any issue. In the future we
> > > can transform the upper interfaces to act upon all the GTs and
> > > provide information from all the GTs. This is, for example, how
> > > the sysfs interfaces will act.
> >
> > NACK. We've made this mistake in the past for other debugfs files.
> > We don't want to do it again just to maintain 2 separate places for
> > one year and then finally realize we want to merge them.
>
> In my opinion it's all about what mistake you like the most
> because until we will have multi-gt support in upstream all the
> patches come with the "promise" of a follow-up and maintenance
> cost.
no. If you put the implementation in a single place, later you only have the
decision on what to do with the per-device entrypoint:
- should we remove it once igt is converted?
- should we make it iterate all gts?
- should we make it mean root tile?
Then you take the action that is needed and decide it per interface.
Here you are leaving behind a lot of code that we will need to maintain
until there is support for such a thing.
It already happened once: we needed to maintain that duplicated code
for over a year with multiple patches changing them (or failing to do so).
>
> > > The reason I removed them in V1 is because igt as only user is
> > > not a strong reason to keep duplicated code, but as Chris
> > > suggested offline:
> > >
> > > "It's debugfs, igt is the primary consumer. CI has to be bridged over
> > > changes to the interfaces it is using in any case, as you want
> > > comparable results before/after the patches land.
> >
> > That doesn't mean you have to copy and paste it. It may mean you
> > do the implementation in one of them and the other calls that
> > implementation.
> > See how I did the deduplication in commit d0c560316d6f ("drm/i915:
> > deduplicate frequency dump on debugfs")
>
> In this case, from a user perspective, which gt is the interface
> affecting? is it affecting all the system? or gt 0, 1...? Does
> the user know? The maintenance cost is that later you will need
> to use for_each_gt and make all those interfaces multitile, and
> this would be your "promise".
multi-gt is irrelevant here. This patch without any "promise" should do
what the commit message says: *move*. The only reason to keep
the old entrypoint around is because it's missing the igt conversion. If
you are going to support a per-device entrypoint and do for_each_gt(),
or do a symlink to the root tile, or whatever, it isn't very relevant
to this patch.
Right now we have just a single directory, gt.
Lucas De Marchi
Re: [PATCH 07/11] drm/i915/xehp: Determine which tile raised an interrupt
On Fri, Oct 08, 2021 at 02:56:31PM -0700, Matt Roper wrote:
> From: Paulo Zanoni
>
> The first step of interrupt handling is to read a tile0 register that
> tells us in which tile the interrupt happened; we can then we read the
> usual interrupt registers from the appropriate tile.
>
> Note that this is just the first step of handling interrupts properly on
> multi-tile platforms. Subsequent patches will convert other parts of
> the interrupt handling flow.
>
> Cc: Stuart Summers
> Signed-off-by: Paulo Zanoni
> Signed-off-by: Tvrtko Ursulin
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_irq.c | 31 ---
> 1 file changed, 16 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 038a9ec563c1..9f99ad56cde6 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2772,37 +2772,38 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
> {
> struct drm_i915_private * const i915 = arg;
> struct intel_gt *gt = >gt;
> - void __iomem * const regs = gt->uncore->regs;
> + void __iomem * const t0_regs = gt->uncore->regs;
> u32 master_tile_ctl, master_ctl;
> - u32 gu_misc_iir;
> + u32 gu_misc_iir = 0;
> + unsigned int i;
>
> if (!intel_irqs_enabled(i915))
> return IRQ_NONE;
>
> - master_tile_ctl = dg1_master_intr_disable(regs);
> + master_tile_ctl = dg1_master_intr_disable(t0_regs);
> if (!master_tile_ctl) {
> - dg1_master_intr_enable(regs);
> + dg1_master_intr_enable(t0_regs);
> return IRQ_NONE;
> }
>
> - /* FIXME: we only support tile 0 for now. */
> - if (master_tile_ctl & DG1_MSTR_TILE(0)) {
> + for_each_gt(i915, i, gt) {
> + void __iomem *const regs = gt->uncore->regs;
> +
> + if ((master_tile_ctl & DG1_MSTR_TILE(i)) == 0)
> + continue;
> +
> master_ctl = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ);
> raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, master_ctl);
> - } else {
> - DRM_ERROR("Tile not supported: 0x%08x\n", master_tile_ctl);
> - dg1_master_intr_enable(regs);
> - return IRQ_NONE;
> - }
>
> - gen11_gt_irq_handler(gt, master_ctl);
> + gen11_gt_irq_handler(gt, master_ctl);
> +
> + gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
Hmm, I missed it before sending the series, but this doesn't look right.
We ack every tile's gu_misc_irq separately, but...
> + }
>
> if (master_ctl & GEN11_DISPLAY_IRQ)
> gen11_display_irq_handler(i915);
>
> - gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
> -
> - dg1_master_intr_enable(regs);
> + dg1_master_intr_enable(t0_regs);
>
> gen11_gu_misc_irq_handler(gt, gu_misc_iir);
...only handle the value from the final tile? Looks like this was
intended to move inside the loop as well.
Matt
>
> --
> 2.33.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
[PATCH v2 11/11] drm/i915/xehpsdv: Initialize multi-tiles
From: Tvrtko Ursulin
Check how many extra GT tiles are available on the system and setup
register access for all of them. We can detect how may GT tiles are
available by reading a register on the root tile. The same register
returns the tile ID on all tiles.
v2:
- Include some additional refactor that didn't get squashed in properly
on v1.
Bspec: 33407
Original-author: Abdiel Janulgue
Signed-off-by: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Cc: Joonas Lahtinen
Cc: Paulo Zanoni
Cc: Andi Shyti
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 83 +--
drivers/gpu/drm/i915/gt/intel_gt.h| 4 +-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +
drivers/gpu/drm/i915/i915_drv.h | 7 +-
drivers/gpu/drm/i915/i915_pci.c | 40 +--
drivers/gpu/drm/i915/i915_reg.h | 4 ++
drivers/gpu/drm/i915/intel_device_info.h | 15
8 files changed, 145 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 2ae57e4656a3..1d9fcf9572ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -525,7 +525,7 @@ static intel_engine_mask_t init_engine_mask(struct intel_gt
*gt)
u16 vdbox_mask;
u16 vebox_mask;
- info->engine_mask = INTEL_INFO(i915)->platform_engine_mask;
+ GEM_BUG_ON(!info->engine_mask);
if (GRAPHICS_VER(i915) < 11)
return info->engine_mask;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 6528d21e68eb..0879e30ace7c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -912,14 +912,17 @@ u32 intel_gt_read_register_fw(struct intel_gt *gt,
i915_reg_t reg)
return intel_uncore_read_fw(gt->uncore, reg);
}
-static int
-tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t phys_addr)
+int intel_tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t
phys_addr)
{
struct drm_i915_private *i915 = gt->i915;
struct intel_uncore *uncore;
struct intel_uncore_mmio_debug *mmio_debug;
int ret;
+ /* For Modern GENs size of GTTMMADR is 16MB (for each tile) */
+ if (GEM_WARN_ON(pci_resource_len(to_pci_dev(i915->drm.dev), 0) < (id +
1) * SZ_16M))
+ return -EINVAL;
+
if (id) {
uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
if (!uncore)
@@ -943,6 +946,16 @@ tile_setup(struct intel_gt *gt, unsigned int id,
phys_addr_t phys_addr)
if (ret)
return ret;
+ /* Which tile am I? default to zero on single tile systems */
+ if (HAS_REMOTE_TILES(i915)) {
+ u32 instance =
+ __raw_uncore_read32(gt->uncore, XEHPSDV_MTCFG_ADDR) &
+ TILE_NUMBER;
+
+ if (GEM_WARN_ON(instance != id))
+ return -ENXIO;
+ }
+
gt->phys_addr = phys_addr;
return 0;
@@ -958,25 +971,87 @@ static void tile_cleanup(struct intel_gt *gt)
}
}
+static unsigned int tile_count(struct drm_i915_private *i915)
+{
+ u32 mtcfg;
+
+ /*
+* We use raw MMIO reads at this point since the
+* MMIO vfuncs are not setup yet
+*/
+ mtcfg = __raw_uncore_read32(>uncore, XEHPSDV_MTCFG_ADDR);
+ return REG_FIELD_GET(TILE_COUNT, mtcfg) + 1;
+}
+
int intel_probe_gts(struct drm_i915_private *i915)
{
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+ const struct intel_gt_definition *gtdef;
+ struct intel_gt *gt;
phys_addr_t phys_addr;
unsigned int mmio_bar;
+ unsigned int i, tiles;
int ret;
mmio_bar = GRAPHICS_VER(i915) == 2 ? 1 : 0;
phys_addr = pci_resource_start(pdev, mmio_bar);
/* We always have at least one primary GT on any device */
- ret = tile_setup(>gt, 0, phys_addr);
+ gt = >gt;
+ gt->name = "Primary GT";
+ gt->info.engine_mask = INTEL_INFO(i915)->platform_engine_mask;
+
+ drm_dbg(>drm, "Setting up %s %u\n", gt->name, gt->info.id);
+ ret = intel_tile_setup(gt, 0, phys_addr);
if (ret)
return ret;
i915->gts[0] = >gt;
- /* TODO: add more tiles */
+ tiles = tile_count(i915);
+ drm_dbg(>drm, "Tile count: %u\n", tiles);
+
+ for (gtdef = INTEL_INFO(i915)->extra_gts, i = 1;
+gtdef && i < tiles;
+gtdef++, i++) {
+ if (GEM_WARN_ON(i >= I915_MAX_GTS)) {
+ ret = -EINVAL;
+ goto err;
+ }
+
+ gt = kzalloc(sizeof(*gt), GFP_KERNEL);
+ if (!gt) {
+ ret =
[PATCH] drm/rockchip: vop: Add timeout for DSP hold
If hardware is malfunctioning (e.g., misconfigured clocks?), we can get stuck here forever, holding various DRM locks and eventually locking up the entire system. It's better to complain loudly and move on, than to lock up the system. In local tests, this operation takes less than 20ms. Signed-off-by: Brian Norris --- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c index ba9e14da41b4..b28ea5d6a3e2 100644 --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c @@ -726,7 +726,9 @@ static void vop_crtc_atomic_disable(struct drm_crtc *crtc, spin_unlock(>reg_lock); - wait_for_completion(>dsp_hold_completion); + if (!wait_for_completion_timeout(>dsp_hold_completion, +msecs_to_jiffies(200))) + WARN(1, "%s: timed out waiting for DSP hold", crtc->name); vop_dsp_hold_valid_irq_disable(vop); -- 2.33.0.882.g93a45727a2-goog
[PATCH 10/11] drm/i915: Release per-gt resources allocated
From: Venkata Sandeep Dhanalakota
Iterate for_each_gt during release to support multi-tile
devices.
Cc: Tvrtko Ursulin
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 36b6e6f2cebf..da574f422084 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -381,10 +381,14 @@ static int i915_driver_early_probe(struct
drm_i915_private *dev_priv)
*/
static void i915_driver_late_release(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int id;
+
intel_irq_fini(dev_priv);
intel_power_domains_cleanup(dev_priv);
i915_gem_cleanup_early(dev_priv);
- intel_gt_driver_late_release(_priv->gt);
+ for_each_gt(dev_priv, id, gt)
+ intel_gt_driver_late_release(gt);
intel_region_ttm_device_fini(dev_priv);
vlv_suspend_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
--
2.33.0
[PATCH 11/11] drm/i915/xehpsdv: Initialize multi-tiles
From: Tvrtko Ursulin
Check how many extra GT tiles are available on the system and setup
register access for all of them. We can detect how may GT tiles are
available by reading a register on the root tile. The same register
returns the tile ID on all tiles.
Bspec: 33407
Original-author: Abdiel Janulgue
Signed-off-by: Tvrtko Ursulin
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Cc: Joonas Lahtinen
Cc: Paulo Zanoni
Signed-off-by: Paulo Zanoni
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/intel_gt.c | 66 +++-
drivers/gpu/drm/i915/i915_drv.h | 3 ++
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 4 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
5 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 6528d21e68eb..d7efaef9ade7 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -943,6 +943,17 @@ tile_setup(struct intel_gt *gt, unsigned int id,
phys_addr_t phys_addr)
if (ret)
return ret;
+ /* Which tile am I? default to zero on single tile systems */
+ if (HAS_REMOTE_TILES(i915)) {
+ u32 instance =
+ __raw_uncore_read32(gt->uncore, XEHPSDV_MTCFG_ADDR) &
+ TILE_NUMBER;
+
+ if (GEM_WARN_ON(instance != id))
+ return -ENXIO;
+ }
+
+ gt->info.id = id;
gt->phys_addr = phys_addr;
return 0;
@@ -958,11 +969,25 @@ static void tile_cleanup(struct intel_gt *gt)
}
}
+static unsigned int tile_count(struct drm_i915_private *i915)
+{
+ u32 mtcfg;
+
+ /*
+* We use raw MMIO reads at this point since the
+* MMIO vfuncs are not setup yet
+*/
+ mtcfg = __raw_uncore_read32(>uncore, XEHPSDV_MTCFG_ADDR);
+ return REG_FIELD_GET(TILE_COUNT, mtcfg) + 1;
+}
+
int intel_probe_gts(struct drm_i915_private *i915)
{
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+ struct intel_gt *gt;
phys_addr_t phys_addr;
unsigned int mmio_bar;
+ unsigned int i, tiles;
int ret;
mmio_bar = GRAPHICS_VER(i915) == 2 ? 1 : 0;
@@ -975,8 +1000,47 @@ int intel_probe_gts(struct drm_i915_private *i915)
i915->gts[0] = >gt;
- /* TODO: add more tiles */
+ if (!HAS_REMOTE_TILES(i915))
+ return 0;
+
+ /* Setup other tiles */
+ tiles = tile_count(i915);
+ drm_dbg(>drm, "Tile count: %u\n", tiles);
+
+ if (GEM_WARN_ON(tiles > I915_MAX_TILES))
+ return -EINVAL;
+
+ /* For multi-tile platforms, size of GTTMMADR is 16MB per tile */
+ if (GEM_WARN_ON(pci_resource_len(pdev, 0) / tiles != SZ_16M))
+ return -EINVAL;
+
+ for (i = 1; i < tiles; i++) {
+ gt = kzalloc(sizeof(*gt), GFP_KERNEL);
+ if (!gt) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ ret = tile_setup(gt, i, phys_addr + SZ_16M * i);
+ if (ret)
+ goto err;
+
+ i915->gts[i] = gt;
+ }
+
+ i915->remote_tiles = tiles - 1;
+
return 0;
+
+err:
+ drm_err(>drm, "Failed to initialize tile %u! (%d)\n", i, ret);
+
+ for_each_gt(i915, i, gt) {
+ tile_cleanup(gt);
+ i915->gts[i] = NULL;
+ }
+
+ return ret;
}
int intel_gt_tiles_init(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3a26a21ffb3a..342c42e5aa96 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -865,6 +865,8 @@ struct drm_i915_private {
*/
resource_size_t stolen_usable_size; /* Total size minus reserved
ranges */
+ unsigned int remote_tiles;
+
struct intel_uncore uncore;
struct intel_uncore_mmio_debug mmio_debug;
@@ -1724,6 +1726,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_REGION(i915, i) (INTEL_INFO(i915)->memory_regions & (i))
#define HAS_LMEM(i915) HAS_REGION(i915, REGION_LMEM)
+#define HAS_REMOTE_TILES(dev_priv) (INTEL_INFO(dev_priv)->has_remote_tiles)
#define HAS_GT_UC(dev_priv)(INTEL_INFO(dev_priv)->has_gt_uc)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 169837de395d..95870c2e366e 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1015,6 +1015,7 @@ static const struct intel_device_info xehpsdv_info = {
DGFX_FEATURES,
PLATFORM(INTEL_XEHPSDV),
.display = { },
+ .has_remote_tiles = 1,
.pipe_mask = 0,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
diff --git
[PATCH 06/11] drm/i915: Initial support for per-tile uncore
From: Daniele Ceraolo Spurio
Initialization and suspend/resume is replicated per-tile.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/i915_debugfs.c | 5 ++-
drivers/gpu/drm/i915/i915_drv.c | 61 ++---
3 files changed, 51 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 736725411f51..6528d21e68eb 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1008,6 +1008,7 @@ void intel_gts_release(struct drm_i915_private *i915)
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p)
{
+ drm_printf(p, "GT %u info:\n", info->id);
drm_printf(p, "available engines: %x\n", info->engine_mask);
intel_sseu_dump(>sseu, p);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fdbd46ff59e0..34fefdfb6661 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -60,12 +60,15 @@ static int i915_capabilities(struct seq_file *m, void *data)
{
struct drm_i915_private *i915 = node_to_i915(m->private);
struct drm_printer p = drm_seq_file_printer(m);
+ struct intel_gt *gt;
+ unsigned int id;
seq_printf(m, "pch: %d\n", INTEL_PCH_TYPE(i915));
intel_device_info_print_static(INTEL_INFO(i915), );
intel_device_info_print_runtime(RUNTIME_INFO(i915), );
- intel_gt_info_print(>gt.info, );
+ for_each_gt(i915, id, gt)
+ intel_gt_info_print(>info, );
intel_driver_caps_print(>caps, );
kernel_param_lock(THIS_MODULE);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 44ccf0078ac4..36b6e6f2cebf 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -406,6 +406,8 @@ static void i915_driver_late_release(struct
drm_i915_private *dev_priv)
*/
static int i915_driver_mmio_probe(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int i, j;
int ret;
if (i915_inject_probe_failure(dev_priv))
@@ -415,26 +417,35 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
if (ret < 0)
return ret;
- ret = intel_uncore_init_mmio(_priv->uncore);
- if (ret)
- return ret;
+ for_each_gt(dev_priv, i, gt) {
+ ret = intel_uncore_init_mmio(gt->uncore);
+ if (ret)
+ goto err_uncore;
+ }
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
intel_device_info_runtime_init(dev_priv);
- ret = intel_gt_init_mmio(_priv->gt);
- if (ret)
- goto err_uncore;
+ for_each_gt(dev_priv, j, gt) {
+ ret = intel_gt_init_mmio(gt);
+ if (ret)
+ goto err_mchbar;
+ }
/* As early as possible, scrub existing GPU state before clobbering */
sanitize_gpu(dev_priv);
return 0;
-err_uncore:
+err_mchbar:
intel_teardown_mchbar(dev_priv);
- intel_uncore_fini_mmio(_priv->uncore);
+err_uncore:
+ for_each_gt(dev_priv, j, gt) {
+ if (j >= i)
+ break;
+ intel_uncore_fini_mmio(gt->uncore);
+ }
pci_dev_put(dev_priv->bridge_dev);
return ret;
@@ -446,8 +457,12 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
*/
static void i915_driver_mmio_release(struct drm_i915_private *dev_priv)
{
+ struct intel_gt *gt;
+ unsigned int i;
+
intel_teardown_mchbar(dev_priv);
- intel_uncore_fini_mmio(_priv->uncore);
+ for_each_gt(dev_priv, i, gt)
+ intel_uncore_fini_mmio(gt->uncore);
pci_dev_put(dev_priv->bridge_dev);
}
@@ -734,6 +749,8 @@ static void i915_welcome_messages(struct drm_i915_private
*dev_priv)
{
if (drm_debug_enabled(DRM_UT_DRIVER)) {
struct drm_printer p = drm_debug_printer("i915 device info:");
+ struct intel_gt *gt;
+ unsigned int id;
drm_printf(, "pciid=0x%04x rev=0x%02x platform=%s
(subplatform=0x%x) gen=%i\n",
INTEL_DEVID(dev_priv),
@@ -745,7 +762,8 @@ static void i915_welcome_messages(struct drm_i915_private
*dev_priv)
intel_device_info_print_static(INTEL_INFO(dev_priv), );
intel_device_info_print_runtime(RUNTIME_INFO(dev_priv), );
- intel_gt_info_print(_priv->gt.info, );
+ for_each_gt(dev_priv, id, gt)
+ intel_gt_info_print(>info, );
}
if (IS_ENABLED(CONFIG_DRM_I915_DEBUG))
@@ -1167,13 +1185,16 @@
[PATCH 05/11] drm/i915: Prepare for multiple gts
From: Tvrtko Ursulin
Add some basic plumbing to support more than one dynamically allocated
struct intel_gt. Up to four gts are supported in i915->gts[], with slot
zero shadowing the existing i915->gt to enable source compatibility with
legacy driver paths. A for_each_gt macro is added to iterate over the
GTs and will be used by upcoming patches that convert various parts of
the driver to be multi-gt aware.
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 74 --
drivers/gpu/drm/i915/gt/intel_gt.h | 8 ++-
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
drivers/gpu/drm/i915/i915_drv.c| 2 +-
drivers/gpu/drm/i915/i915_drv.h| 6 ++
drivers/gpu/drm/i915/intel_memory_region.h | 3 +
6 files changed, 86 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 863039d56cba..736725411f51 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -23,10 +23,13 @@
#include "shmem_utils.h"
#include "pxp/intel_pxp.h"
-void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+static void
+__intel_gt_init_early(struct intel_gt *gt,
+ struct intel_uncore *uncore,
+ struct drm_i915_private *i915)
{
gt->i915 = i915;
- gt->uncore = >uncore;
+ gt->uncore = uncore;
spin_lock_init(>irq_lock);
@@ -46,13 +49,18 @@ void intel_gt_init_early(struct intel_gt *gt, struct
drm_i915_private *i915)
intel_rps_init_early(>rps);
}
-int intel_gt_probe_lmem(struct intel_gt *gt)
+static int intel_gt_probe_lmem(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
+ unsigned int instance = gt->info.id;
struct intel_memory_region *mem;
int id;
int err;
+ id = INTEL_REGION_LMEM + instance;
+ if (drm_WARN_ON(>drm, id >= INTEL_REGION_STOLEN_SMEM))
+ return -ENODEV;
+
mem = intel_gt_setup_lmem(gt);
if (mem == ERR_PTR(-ENODEV))
mem = intel_gt_setup_fake_lmem(gt);
@@ -67,9 +75,8 @@ int intel_gt_probe_lmem(struct intel_gt *gt)
return err;
}
- id = INTEL_REGION_LMEM;
-
mem->id = id;
+ mem->instance = instance;
intel_memory_region_set_name(mem, "local%u", mem->instance);
@@ -80,6 +87,11 @@ int intel_gt_probe_lmem(struct intel_gt *gt)
return 0;
}
+void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915)
+{
+ __intel_gt_init_early(gt, >uncore, i915);
+}
+
void intel_gt_init_hw_early(struct intel_gt *gt, struct i915_ggtt *ggtt)
{
gt->ggtt = ggtt;
@@ -903,9 +915,29 @@ u32 intel_gt_read_register_fw(struct intel_gt *gt,
i915_reg_t reg)
static int
tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t phys_addr)
{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_uncore *uncore;
+ struct intel_uncore_mmio_debug *mmio_debug;
int ret;
- intel_uncore_init_early(gt->uncore, gt);
+ if (id) {
+ uncore = kzalloc(sizeof(*uncore), GFP_KERNEL);
+ if (!uncore)
+ return -ENOMEM;
+
+ mmio_debug = kzalloc(sizeof(*mmio_debug), GFP_KERNEL);
+ if (!mmio_debug) {
+ kfree(uncore);
+ return -ENOMEM;
+ }
+
+ __intel_gt_init_early(gt, uncore, i915);
+ } else {
+ uncore = >uncore;
+ mmio_debug = >mmio_debug;
+ }
+
+ intel_uncore_init_early(uncore, gt);
ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
if (ret)
@@ -919,6 +951,11 @@ tile_setup(struct intel_gt *gt, unsigned int id,
phys_addr_t phys_addr)
static void tile_cleanup(struct intel_gt *gt)
{
intel_uncore_cleanup_mmio(gt->uncore);
+
+ if (gt->info.id) {
+ kfree(gt->uncore);
+ kfree(gt);
+ }
}
int intel_probe_gts(struct drm_i915_private *i915)
@@ -936,13 +973,36 @@ int intel_probe_gts(struct drm_i915_private *i915)
if (ret)
return ret;
+ i915->gts[0] = >gt;
+
/* TODO: add more tiles */
return 0;
}
+int intel_gt_tiles_init(struct drm_i915_private *i915)
+{
+ struct intel_gt *gt;
+ unsigned int id;
+ int ret;
+
+ for_each_gt(i915, id, gt) {
+ ret = intel_gt_probe_lmem(gt);
+ if (ret)
+ return ret;
+ }
+
+ return 0;
+}
+
void intel_gts_release(struct drm_i915_private *i915)
{
- tile_cleanup(>gt);
+ struct intel_gt *gt;
+ unsigned int id;
+
+ for_each_gt(i915, id, gt) {
+ tile_cleanup(gt);
+ i915->gts[id] = NULL;
+ }
}
void intel_gt_info_print(const struct intel_gt_info
[PATCH 08/11] drm/i915/xehp: Make IRQ reset and postinstall multi-tile aware
From: Paulo Zanoni
Loop through all the tiles when initializing and resetting interrupts.
Signed-off-by: Paulo Zanoni
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_irq.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9f99ad56cde6..e788e283d4a8 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3190,14 +3190,19 @@ static void dg1_irq_reset(struct drm_i915_private
*dev_priv)
{
struct intel_gt *gt = _priv->gt;
struct intel_uncore *uncore = gt->uncore;
+ unsigned int i;
dg1_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(gt);
- gen11_display_irq_reset(dev_priv);
+ for_each_gt(dev_priv, i, gt) {
+ gen11_gt_irq_reset(gt);
- GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
- GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ uncore = gt->uncore;
+ GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
+ GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ }
+
+ gen11_display_irq_reset(dev_priv);
}
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
@@ -3890,13 +3895,16 @@ static void gen11_irq_postinstall(struct
drm_i915_private *dev_priv)
static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
{
- struct intel_gt *gt = _priv->gt;
- struct intel_uncore *uncore = gt->uncore;
+ struct intel_gt *gt;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+ unsigned int i;
- gen11_gt_irq_postinstall(gt);
+ for_each_gt(dev_priv, i, gt) {
+ gen11_gt_irq_postinstall(gt);
- GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
+ GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_, ~gu_misc_masked,
+ gu_misc_masked);
+ }
if (HAS_DISPLAY(dev_priv)) {
icp_irq_postinstall(dev_priv);
@@ -3905,8 +3913,8 @@ static void dg1_irq_postinstall(struct drm_i915_private
*dev_priv)
GEN11_DISPLAY_IRQ_ENABLE);
}
- dg1_master_intr_enable(uncore->regs);
- intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
+ dg1_master_intr_enable(dev_priv->gt.uncore->regs);
+ intel_uncore_posting_read(dev_priv->gt.uncore, DG1_MSTR_TILE_INTR);
}
static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
--
2.33.0
[PATCH 02/11] drm/i915: split general MMIO setup from per-GT uncore init
From: Daniele Ceraolo Spurio
In coming patches we'll be doing the actual tile initialization between
these two uncore init phases.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.c | 9 -
drivers/gpu/drm/i915/intel_uncore.c | 17 +++--
drivers/gpu/drm/i915/intel_uncore.h | 2 ++
3 files changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c65c3742887a..7f96d26c012a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -415,10 +415,14 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
if (ret < 0)
return ret;
- ret = intel_uncore_init_mmio(_priv->uncore);
+ ret = intel_uncore_setup_mmio(_priv->uncore);
if (ret < 0)
goto err_bridge;
+ ret = intel_uncore_init_mmio(_priv->uncore);
+ if (ret)
+ goto err_mmio;
+
/* Try to make sure MCHBAR is enabled before poking at it */
intel_setup_mchbar(dev_priv);
intel_device_info_runtime_init(dev_priv);
@@ -435,6 +439,8 @@ static int i915_driver_mmio_probe(struct drm_i915_private
*dev_priv)
err_uncore:
intel_teardown_mchbar(dev_priv);
intel_uncore_fini_mmio(_priv->uncore);
+err_mmio:
+ intel_uncore_cleanup_mmio(_priv->uncore);
err_bridge:
pci_dev_put(dev_priv->bridge_dev);
@@ -449,6 +455,7 @@ static void i915_driver_mmio_release(struct
drm_i915_private *dev_priv)
{
intel_teardown_mchbar(dev_priv);
intel_uncore_fini_mmio(_priv->uncore);
+ intel_uncore_cleanup_mmio(_priv->uncore);
pci_dev_put(dev_priv->bridge_dev);
}
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index e072054adac5..a308e86c9d9f 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2020,7 +2020,7 @@ static int i915_pmic_bus_access_notifier(struct
notifier_block *nb,
return NOTIFY_OK;
}
-static int uncore_mmio_setup(struct intel_uncore *uncore)
+int intel_uncore_setup_mmio(struct intel_uncore *uncore)
{
struct drm_i915_private *i915 = uncore->i915;
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
@@ -2053,7 +2053,7 @@ static int uncore_mmio_setup(struct intel_uncore *uncore)
return 0;
}
-static void uncore_mmio_cleanup(struct intel_uncore *uncore)
+void intel_uncore_cleanup_mmio(struct intel_uncore *uncore)
{
struct pci_dev *pdev = to_pci_dev(uncore->i915->drm.dev);
@@ -2146,10 +2146,6 @@ int intel_uncore_init_mmio(struct intel_uncore *uncore)
struct drm_i915_private *i915 = uncore->i915;
int ret;
- ret = uncore_mmio_setup(uncore);
- if (ret)
- return ret;
-
/*
* The boot firmware initializes local memory and assesses its health.
* If memory training fails, the punit will have been instructed to
@@ -2170,7 +2166,7 @@ int intel_uncore_init_mmio(struct intel_uncore *uncore)
} else {
ret = uncore_forcewake_init(uncore);
if (ret)
- goto out_mmio_cleanup;
+ return ret;
}
/* make sure fw funcs are set if and only if we have fw*/
@@ -2192,11 +2188,6 @@ int intel_uncore_init_mmio(struct intel_uncore *uncore)
drm_dbg(>drm, "unclaimed mmio detected on uncore init,
clearing\n");
return 0;
-
-out_mmio_cleanup:
- uncore_mmio_cleanup(uncore);
-
- return ret;
}
/*
@@ -2261,8 +2252,6 @@ void intel_uncore_fini_mmio(struct intel_uncore *uncore)
intel_uncore_fw_domains_fini(uncore);
iosf_mbi_punit_release();
}
-
- uncore_mmio_cleanup(uncore);
}
static const struct reg_whitelist {
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index 3248e4e2c540..d1d17b04e29f 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -218,11 +218,13 @@ void
intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug);
void intel_uncore_init_early(struct intel_uncore *uncore,
struct drm_i915_private *i915);
+int intel_uncore_setup_mmio(struct intel_uncore *uncore);
int intel_uncore_init_mmio(struct intel_uncore *uncore);
void intel_uncore_prune_engine_fw_domains(struct intel_uncore *uncore,
struct intel_gt *gt);
bool intel_uncore_unclaimed_mmio(struct intel_uncore *uncore);
bool intel_uncore_arm_unclaimed_mmio_detection(struct intel_uncore *uncore);
+void intel_uncore_cleanup_mmio(struct intel_uncore *uncore);
void intel_uncore_fini_mmio(struct intel_uncore *uncore);
void intel_uncore_suspend(struct intel_uncore *uncore);
void intel_uncore_resume_early(struct intel_uncore *uncore);
--
2.33.0
[PATCH 07/11] drm/i915/xehp: Determine which tile raised an interrupt
From: Paulo Zanoni
The first step of interrupt handling is to read a tile0 register that
tells us in which tile the interrupt happened; we can then we read the
usual interrupt registers from the appropriate tile.
Note that this is just the first step of handling interrupts properly on
multi-tile platforms. Subsequent patches will convert other parts of
the interrupt handling flow.
Cc: Stuart Summers
Signed-off-by: Paulo Zanoni
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_irq.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 038a9ec563c1..9f99ad56cde6 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2772,37 +2772,38 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
{
struct drm_i915_private * const i915 = arg;
struct intel_gt *gt = >gt;
- void __iomem * const regs = gt->uncore->regs;
+ void __iomem * const t0_regs = gt->uncore->regs;
u32 master_tile_ctl, master_ctl;
- u32 gu_misc_iir;
+ u32 gu_misc_iir = 0;
+ unsigned int i;
if (!intel_irqs_enabled(i915))
return IRQ_NONE;
- master_tile_ctl = dg1_master_intr_disable(regs);
+ master_tile_ctl = dg1_master_intr_disable(t0_regs);
if (!master_tile_ctl) {
- dg1_master_intr_enable(regs);
+ dg1_master_intr_enable(t0_regs);
return IRQ_NONE;
}
- /* FIXME: we only support tile 0 for now. */
- if (master_tile_ctl & DG1_MSTR_TILE(0)) {
+ for_each_gt(i915, i, gt) {
+ void __iomem *const regs = gt->uncore->regs;
+
+ if ((master_tile_ctl & DG1_MSTR_TILE(i)) == 0)
+ continue;
+
master_ctl = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ);
raw_reg_write(regs, GEN11_GFX_MSTR_IRQ, master_ctl);
- } else {
- DRM_ERROR("Tile not supported: 0x%08x\n", master_tile_ctl);
- dg1_master_intr_enable(regs);
- return IRQ_NONE;
- }
- gen11_gt_irq_handler(gt, master_ctl);
+ gen11_gt_irq_handler(gt, master_ctl);
+
+ gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
+ }
if (master_ctl & GEN11_DISPLAY_IRQ)
gen11_display_irq_handler(i915);
- gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
-
- dg1_master_intr_enable(regs);
+ dg1_master_intr_enable(t0_regs);
gen11_gu_misc_irq_handler(gt, gu_misc_iir);
--
2.33.0
[PATCH 09/11] drm/i915/guc: Update CT debug macro for multi-tile
From: Michal Wajdeczko
Update CT debug macros by including tile ID in all messages.
Cc: Michał Winiarski
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
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 0a3504bc0b61..013ad85cc7f6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -33,15 +33,15 @@ static inline struct drm_device *ct_to_drm(struct
intel_guc_ct *ct)
}
#define CT_ERROR(_ct, _fmt, ...) \
- drm_err(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+ drm_err(ct_to_drm(_ct), "CT%u: " _fmt, ct_to_gt(_ct)->info.id,
##__VA_ARGS__)
#ifdef CONFIG_DRM_I915_DEBUG_GUC
#define CT_DEBUG(_ct, _fmt, ...) \
- drm_dbg(ct_to_drm(_ct), "CT: " _fmt, ##__VA_ARGS__)
+ drm_dbg(ct_to_drm(_ct), "CT%u: " _fmt, ct_to_gt(_ct)->info.id,
##__VA_ARGS__)
#else
#define CT_DEBUG(...) do { } while (0)
#endif
#define CT_PROBE_ERROR(_ct, _fmt, ...) \
- i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
+ i915_probe_error(ct_to_i915(ct), "CT%u: " _fmt, ct_to_gt(_ct)->info.id,
##__VA_ARGS__)
/**
* DOC: CTB Blob
--
2.33.0
[PATCH 01/11] drm/i915: rework some irq functions to take intel_gt as argument
From: Paulo Zanoni
We'll be adding multi-tile support soon; on multi-tile platforms
interrupts are per-tile and every tile has the full set of
interrupt registers.
In this commit we start passing intel_gt instead of dev_priv for the
functions that are related to Xe_HP irq handling. Right now we're still
passing tile 0 everywhere, but in later patches we'll start actually
passing the correct tile.
Signed-off-by: Paulo Zanoni
Co-authored-by: Tvrtko Ursulin
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_irq.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 77680bca46ee..038a9ec563c1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2772,7 +2772,7 @@ static irqreturn_t dg1_irq_handler(int irq, void *arg)
{
struct drm_i915_private * const i915 = arg;
struct intel_gt *gt = >gt;
- void __iomem * const regs = i915->uncore.regs;
+ void __iomem * const regs = gt->uncore->regs;
u32 master_tile_ctl, master_ctl;
u32 gu_misc_iir;
@@ -3173,11 +3173,12 @@ static void gen11_display_irq_reset(struct
drm_i915_private *dev_priv)
static void gen11_irq_reset(struct drm_i915_private *dev_priv)
{
- struct intel_uncore *uncore = _priv->uncore;
+ struct intel_gt *gt = _priv->gt;
+ struct intel_uncore *uncore = gt->uncore;
gen11_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(_priv->gt);
+ gen11_gt_irq_reset(gt);
gen11_display_irq_reset(dev_priv);
GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
@@ -3186,11 +3187,12 @@ static void gen11_irq_reset(struct drm_i915_private
*dev_priv)
static void dg1_irq_reset(struct drm_i915_private *dev_priv)
{
- struct intel_uncore *uncore = _priv->uncore;
+ struct intel_gt *gt = _priv->gt;
+ struct intel_uncore *uncore = gt->uncore;
dg1_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(_priv->gt);
+ gen11_gt_irq_reset(gt);
gen11_display_irq_reset(dev_priv);
GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
@@ -3869,13 +3871,14 @@ static void gen11_de_irq_postinstall(struct
drm_i915_private *dev_priv)
static void gen11_irq_postinstall(struct drm_i915_private *dev_priv)
{
- struct intel_uncore *uncore = _priv->uncore;
+ struct intel_gt *gt = _priv->gt;
+ struct intel_uncore *uncore = gt->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
if (INTEL_PCH_TYPE(dev_priv) >= PCH_ICP)
icp_irq_postinstall(dev_priv);
- gen11_gt_irq_postinstall(_priv->gt);
+ gen11_gt_irq_postinstall(gt);
gen11_de_irq_postinstall(dev_priv);
GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
@@ -3886,10 +3889,11 @@ static void gen11_irq_postinstall(struct
drm_i915_private *dev_priv)
static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
{
- struct intel_uncore *uncore = _priv->uncore;
+ struct intel_gt *gt = _priv->gt;
+ struct intel_uncore *uncore = gt->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
- gen11_gt_irq_postinstall(_priv->gt);
+ gen11_gt_irq_postinstall(gt);
GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
@@ -3900,8 +3904,8 @@ static void dg1_irq_postinstall(struct drm_i915_private
*dev_priv)
GEN11_DISPLAY_IRQ_ENABLE);
}
- dg1_master_intr_enable(dev_priv->uncore.regs);
- intel_uncore_posting_read(_priv->uncore, DG1_MSTR_TILE_INTR);
+ dg1_master_intr_enable(uncore->regs);
+ intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
}
static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
--
2.33.0
[PATCH 03/11] drm/i915: Restructure probe to handle multi-tile platforms
On a multi-tile platform, each tile has its own registers + GGTT space,
and BAR 0 is extended to cover all of them. Upcoming patches will start
exposing the tiles as multiple GTs within a single PCI device. In
preparation for supporting such setups, restructure the driver's probe
code a bit.
Only the primary/root tile is initialized for now; the other tiles will
be detected and plugged in by future patches once the necessary
infrastructure is in place to handle them.
Original-author: Abdiel Janulgue
Cc: Daniele Ceraolo Spurio
Cc: Matthew Auld
Cc: Joonas Lahtinen
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 45
drivers/gpu/drm/i915/gt/intel_gt.h | 3 ++
drivers/gpu/drm/i915/gt/intel_gt_pm.c| 9 -
drivers/gpu/drm/i915/gt/intel_gt_types.h | 5 +++
drivers/gpu/drm/i915/i915_drv.c | 20 +--
drivers/gpu/drm/i915/intel_uncore.c | 12 +++
drivers/gpu/drm/i915/intel_uncore.h | 3 +-
7 files changed, 76 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 1cb1948ac959..f4bea1f1de77 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -900,6 +900,51 @@ u32 intel_gt_read_register_fw(struct intel_gt *gt,
i915_reg_t reg)
return intel_uncore_read_fw(gt->uncore, reg);
}
+static int
+tile_setup(struct intel_gt *gt, unsigned int id, phys_addr_t phys_addr)
+{
+ int ret;
+
+ intel_uncore_init_early(gt->uncore, gt->i915);
+
+ ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
+ if (ret)
+ return ret;
+
+ gt->phys_addr = phys_addr;
+
+ return 0;
+}
+
+static void tile_cleanup(struct intel_gt *gt)
+{
+ intel_uncore_cleanup_mmio(gt->uncore);
+}
+
+int intel_probe_gts(struct drm_i915_private *i915)
+{
+ struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
+ phys_addr_t phys_addr;
+ unsigned int mmio_bar;
+ int ret;
+
+ mmio_bar = GRAPHICS_VER(i915) == 2 ? 1 : 0;
+ phys_addr = pci_resource_start(pdev, mmio_bar);
+
+ /* We always have at least one primary GT on any device */
+ ret = tile_setup(>gt, 0, phys_addr);
+ if (ret)
+ return ret;
+
+ /* TODO: add more tiles */
+ return 0;
+}
+
+void intel_gts_release(struct drm_i915_private *i915)
+{
+ tile_cleanup(>gt);
+}
+
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 74e771871a9b..f4f35a70cbe4 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -85,6 +85,9 @@ static inline bool intel_gt_needs_read_steering(struct
intel_gt *gt,
u32 intel_gt_read_register_fw(struct intel_gt *gt, i915_reg_t reg);
+int intel_probe_gts(struct drm_i915_private *i915);
+void intel_gts_release(struct drm_i915_private *i915);
+
void intel_gt_info_print(const struct intel_gt_info *info,
struct drm_printer *p);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 524eaf678790..76f498edb0d5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -126,7 +126,14 @@ static const struct intel_wakeref_ops wf_ops = {
void intel_gt_pm_init_early(struct intel_gt *gt)
{
- intel_wakeref_init(>wakeref, gt->uncore->rpm, _ops);
+ /*
+* We access the runtime_pm structure via gt->i915 here rather than
+* gt->uncore as we do elsewhere in the file because gt->uncore is not
+* yet initialized for all tiles at this point in the driver startup.
+* runtime_pm is per-device rather than per-tile, so this is still the
+* correct structure.
+*/
+ intel_wakeref_init(>wakeref, >i915->runtime_pm, _ops);
seqcount_mutex_init(>stats.lock, >wakeref.mutex);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 14216cc471b1..66143316d92e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -180,6 +180,11 @@ struct intel_gt {
const struct intel_mmio_range *steering_table[NUM_STEERING_TYPES];
+ /*
+* Base of per-tile GTTMMADR where we can derive the MMIO and the GGTT.
+*/
+ phys_addr_t phys_addr;
+
struct intel_gt_info {
intel_engine_mask_t engine_mask;
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7f96d26c012a..51234fd1349b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -312,8 +312,8 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
[PATCH 04/11] drm/i915: Store backpointer to GT in uncore
From: Michał Winiarski
We now support a per-gt uncore, yet we're not able to infer which GT
we're operating upon. Let's store a backpointer for now.
Signed-off-by: Michał Winiarski
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 9 +
drivers/gpu/drm/i915/intel_uncore.h | 3 ++-
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 +--
drivers/gpu/drm/i915/selftests/mock_uncore.c | 2 +-
5 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f4bea1f1de77..863039d56cba 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -905,7 +905,7 @@ tile_setup(struct intel_gt *gt, unsigned int id,
phys_addr_t phys_addr)
{
int ret;
- intel_uncore_init_early(gt->uncore, gt->i915);
+ intel_uncore_init_early(gt->uncore, gt);
ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
if (ret)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 8a0a0676d67a..2c449836f537 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2057,12 +2057,13 @@ void intel_uncore_cleanup_mmio(struct intel_uncore
*uncore)
}
void intel_uncore_init_early(struct intel_uncore *uncore,
-struct drm_i915_private *i915)
+struct intel_gt *gt)
{
spin_lock_init(>lock);
- uncore->i915 = i915;
- uncore->rpm = >runtime_pm;
- uncore->debug = >mmio_debug;
+ uncore->i915 = gt->i915;
+ uncore->gt = gt;
+ uncore->rpm = >i915->runtime_pm;
+ uncore->debug = >i915->mmio_debug;
}
static void uncore_raw_init(struct intel_uncore *uncore)
diff --git a/drivers/gpu/drm/i915/intel_uncore.h
b/drivers/gpu/drm/i915/intel_uncore.h
index 83a455aa8374..2989032b580b 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -130,6 +130,7 @@ struct intel_uncore {
void __iomem *regs;
struct drm_i915_private *i915;
+ struct intel_gt *gt;
struct intel_runtime_pm *rpm;
spinlock_t lock; /** lock is also taken in irq contexts. */
@@ -218,7 +219,7 @@ u32 intel_uncore_read_with_mcr_steering(struct intel_uncore
*uncore,
void
intel_uncore_mmio_debug_init_early(struct intel_uncore_mmio_debug *mmio_debug);
void intel_uncore_init_early(struct intel_uncore *uncore,
-struct drm_i915_private *i915);
+struct intel_gt *gt);
int intel_uncore_setup_mmio(struct intel_uncore *uncore, phys_addr_t
phys_addr);
int intel_uncore_init_mmio(struct intel_uncore *uncore);
void intel_uncore_prune_engine_fw_domains(struct intel_uncore *uncore,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 4f8180146888..bd21bb7d104e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -175,10 +175,9 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->memory_regions = REGION_SMEM;
intel_memory_regions_hw_probe(i915);
- mock_uncore_init(>uncore, i915);
-
i915_gem_init__mm(i915);
intel_gt_init_early(>gt, i915);
+ mock_uncore_init(>uncore, i915);
atomic_inc(>gt.wakeref.count); /* disable; no hw support */
i915->gt.awake = -ENODEV;
diff --git a/drivers/gpu/drm/i915/selftests/mock_uncore.c
b/drivers/gpu/drm/i915/selftests/mock_uncore.c
index ca57e4008701..b3790ef137e4 100644
--- a/drivers/gpu/drm/i915/selftests/mock_uncore.c
+++ b/drivers/gpu/drm/i915/selftests/mock_uncore.c
@@ -42,7 +42,7 @@ __nop_read(64)
void mock_uncore_init(struct intel_uncore *uncore,
struct drm_i915_private *i915)
{
- intel_uncore_init_early(uncore, i915);
+ intel_uncore_init_early(uncore, >gt);
ASSIGN_RAW_WRITE_MMIO_VFUNCS(uncore, nop);
ASSIGN_RAW_READ_MMIO_VFUNCS(uncore, nop);
--
2.33.0
[PATCH 00/11] i915: Initial multi-tile support
Some of our upcoming platforms, including the Xe_HP SDV, support a "multi-tile" design. A multi-tile platform is effectively a platform with multiple GT instances and local memory regions, all behind a single PCI device. From an i915 perspective, this translates to multiple intel_gt structures per drm_i915_private. This series provides the initial refactoring to support multiple independent GTs per card, but further work (especially related to local memory) will be required to fully enable a multi-tile platform. Note that the presence of multiple GTs is largely transparent to userspace. A multi-tile platform will advertise a larger list of engines to userspace, but the concept of "tile" is not something userspace has to worry about directly. There will be some uapi implications later due to the devices having multiple local memory regions, but that aspect of multi-tile is not covered by this patch series and will show up in future work. Daniele Ceraolo Spurio (2): drm/i915: split general MMIO setup from per-GT uncore init drm/i915: Initial support for per-tile uncore Matt Roper (1): drm/i915: Restructure probe to handle multi-tile platforms Michal Wajdeczko (1): drm/i915/guc: Update CT debug macro for multi-tile Michał Winiarski (1): drm/i915: Store backpointer to GT in uncore Paulo Zanoni (3): drm/i915: rework some irq functions to take intel_gt as argument drm/i915/xehp: Determine which tile raised an interrupt drm/i915/xehp: Make IRQ reset and postinstall multi-tile aware Tvrtko Ursulin (2): drm/i915: Prepare for multiple gts drm/i915/xehpsdv: Initialize multi-tiles Venkata Sandeep Dhanalakota (1): drm/i915: Release per-gt resources allocated drivers/gpu/drm/i915/gt/intel_gt.c| 180 +- drivers/gpu/drm/i915/gt/intel_gt.h| 11 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 9 +- drivers/gpu/drm/i915/gt/intel_gt_types.h | 7 + drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 6 +- drivers/gpu/drm/i915/i915_debugfs.c | 5 +- drivers/gpu/drm/i915/i915_drv.c | 80 ++-- drivers/gpu/drm/i915/i915_drv.h | 9 + drivers/gpu/drm/i915/i915_irq.c | 71 --- drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_reg.h | 4 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/intel_memory_region.h| 3 + drivers/gpu/drm/i915/intel_uncore.c | 36 ++-- drivers/gpu/drm/i915/intel_uncore.h | 6 +- .../gpu/drm/i915/selftests/mock_gem_device.c | 3 +- drivers/gpu/drm/i915/selftests/mock_uncore.c | 2 +- 17 files changed, 345 insertions(+), 89 deletions(-) -- 2.33.0
Re: [PATCH 0/5] drm/vmwgfx: Support module unload and hotunplug
On Fri, 2021-10-08 at 20:40 +, Zack Rusin wrote: > On Fri, 2021-10-08 at 22:28 +0200, Thomas Hellström wrote: > > On Fri, 2021-10-08 at 13:31 -0400, Zack Rusin wrote: > > > This is a largely trivial set that makes vmwgfx support module > > > reload > > > and PCI hot-unplug. It also makes IGT's core_hotunplug pass > > > instead > > > of kernel oops'ing. > > > > > > The one "ugly" change is the "Introduce a new placement for MOB > > > page > > > tables". It seems vmwgfx has been violating a TTM assumption that > > > TTM_PL_SYSTEM buffers are never fenced for a while. Apart from a > > > kernel > > > oops on module unload it didn't seem to wreak too much havoc, but > > > we > > > shouldn't be abusing TTM. So to solve it we're introducing a new > > > placement, which is basically system, but can deal with fenced > > > bo's. > > > > > > Cc: Christian König > > > Cc: Thomas Hellström > > > > Hi, Zack, > > > > What part of TTM doesn't allow fenced system memory currently? It > > was > > certainly designed to allow that and vmwgfx has been relying on > > that > > since the introduction of MOBs IIRC. Also i915 is currently relying > > on > > that. > > It's the shutdown. BO's allocated through the ttm system manager > might > be busy during ttm_bo_put which results in them being scheduled for a > delayed deletion. The ttm system manager is disabled before the final > delayed deletion is ran in ttm_device_fini. This results in crashes > during freeing of the BO resources because they're trying to remove > themselves from a no longer existent ttm_resource_manager (e.g. in > IGT's core_hotunplug on vmwgfx) > > During review of the trivial patch that was fixing it in ttm > Christian > said that system domain buffers must be idle or otherwise a number of > assumptions in ttm breaks: > https://lists.freedesktop.org/archives/dri-devel/2021-September/324027.html > And later clarified that in fact system domain buffers being fenced > is > illegal from a design point of view: > https://lists.freedesktop.org/archives/dri-devel/2021-September/324697.html Hmm, this looks very odd, because I remember reminding Christian as late as this spring that both vmwgfx and i915 sets up GPU bindings to system buffers, as part of the review of a patch series pushing a couple of changes to the swapout path that apparently had missed this. This more sounds like there have been changes to TTM happening not taking into account or knowing that TTM was designed for system buffers bound to GPU and that there were drivers actually doing that. And there is still older code around clearly implying system buffers can be fenced, like ttm_bo_swapout(), and that there is dma fences signaling completion on work that has never touched the GPU, not to mention async eviction where a bo may be evicted to system but has tons of outstanding fenced work in the pipe. So if there has been a design change WRT this I believe it should have been brought up on dri-devel to have it properly discussed so affected drivers could agree on the different options. Perhaps Christian can enlighten us here. Christian? /Thomas > > z
Re: [PATCH v3] drm/dp: Add Additional DP2 Headers
On 2021-10-08 04:36, Tvrtko Ursulin wrote: > > Hi, > > Is it my checkout only or this causes a lot of build warnings for everyone? > > ./include/drm/drm_dp_helper.h:1120: warning: > "DP_TEST_264BIT_CUSTOM_PATTERN_7_0" redefined > 1120 | #define DP_TEST_264BIT_CUSTOM_PATTERN_7_0 0x2230 > | > In file included from > ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_types.h:35, > from > ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:30, > from > ./drivers/gpu/drm/amd/amdgpu/../include/dm_pp_interface.h:26, > from drivers/gpu/drm/amd/amdgpu/amdgpu.h:66, > from drivers/gpu/drm/amd/amdgpu/amdgpu_fence.c:40: > ./drivers/gpu/drm/amd/amdgpu/../display/dc/dc_dp_types.h:871: note: this is > the location of the previous definition > > Etc.. > Fixed by https://patchwork.freedesktop.org/patch/456190/?series=95166=2 but looks like it's not in drm-misc-next. Siqueira, do you have bandwidth to pull that patch into drm-misc-next? Harry > Regards, > > Tvrtko > > > On 30/09/2021 22:21, Rodrigo Siqueira wrote: >> Applied to drm-misc-next. >> >> Thanks >> >> On 09/28, Harry Wentland wrote: >>> On 2021-09-27 15:23, Fangzhi Zuo wrote: Include FEC, DSC, Link Training related headers. Change since v2 - Align with the spec for DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT Signed-off-by: Fangzhi Zuo >>> >>> Reviewed-by: Harry Wentland >>> >>> Harry >>> --- This patch is based on top of the other DP2.0 work in "drm/dp: add LTTPR DP 2.0 DPCD addresses" --- include/drm/drm_dp_helper.h | 20 1 file changed, 20 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 1d5b3dbb6e56..a1df35aa6e68 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -453,6 +453,7 @@ struct drm_panel; # define DP_FEC_UNCORR_BLK_ERROR_COUNT_CAP (1 << 1) # define DP_FEC_CORR_BLK_ERROR_COUNT_CAP (1 << 2) # define DP_FEC_BIT_ERROR_COUNT_CAP (1 << 3) +#define DP_FEC_CAPABILITY_1 0x091 /* 2.0 */ /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */ #define DP_PCON_DSC_ENCODER_CAP_SIZE 0xC /* 0x9E - 0x92 */ @@ -537,6 +538,9 @@ struct drm_panel; #define DP_DSC_BRANCH_OVERALL_THROUGHPUT_1 0x0a1 #define DP_DSC_BRANCH_MAX_LINE_WIDTH 0x0a2 +/* DFP Capability Extension */ +#define DP_DFP_CAPABILITY_EXTENSION_SUPPORT 0x0a3 /* 2.0 */ + /* Link Configuration */ #define DP_LINK_BW_SET 0x100 # define DP_LINK_RATE_TABLE 0x00 /* eDP 1.4 */ @@ -688,6 +692,7 @@ struct drm_panel; #define DP_DSC_ENABLE 0x160 /* DP 1.4 */ # define DP_DECOMPRESSION_EN (1 << 0) +#define DP_DSC_CONFIGURATION 0x161 /* DP 2.0 */ #define DP_PSR_EN_CFG 0x170 /* XXX 1.2? */ # define DP_PSR_ENABLE BIT(0) @@ -743,6 +748,7 @@ struct drm_panel; # define DP_RECEIVE_PORT_0_STATUS (1 << 0) # define DP_RECEIVE_PORT_1_STATUS (1 << 1) # define DP_STREAM_REGENERATION_STATUS (1 << 2) /* 2.0 */ +# define DP_INTRA_HOP_AUX_REPLY_INDICATION (1 << 3) /* 2.0 */ #define DP_ADJUST_REQUEST_LANE0_1 0x206 #define DP_ADJUST_REQUEST_LANE2_3 0x207 @@ -865,6 +871,8 @@ struct drm_panel; # define DP_PHY_TEST_PATTERN_80BIT_CUSTOM 0x4 # define DP_PHY_TEST_PATTERN_CP2520 0x5 +#define DP_PHY_SQUARE_PATTERN 0x249 + #define DP_TEST_HBR2_SCRAMBLER_RESET 0x24A #define DP_TEST_80BIT_CUSTOM_PATTERN_7_0 0x250 #define DP_TEST_80BIT_CUSTOM_PATTERN_15_8 0x251 @@ -1109,6 +1117,18 @@ struct drm_panel; #define DP_128B132B_TRAINING_AUX_RD_INTERVAL 0x2216 /* 2.0 */ # define DP_128B132B_TRAINING_AUX_RD_INTERVAL_MASK 0x7f +#define DP_TEST_264BIT_CUSTOM_PATTERN_7_0 0x2230 +#define DP_TEST_264BIT_CUSTOM_PATTERN_263_256 0x2250 + +/* DSC Extended Capability Branch Total DSC Resources */ +#define DP_DSC_SUPPORT_AND_DSC_DECODER_COUNT 0x2260 /* 2.0 */ +# define DP_DSC_DECODER_COUNT_MASK (0b111 << 5) +# define DP_DSC_DECODER_COUNT_SHIFT 5 +#define DP_DSC_MAX_SLICE_COUNT_AND_AGGREGATION_0 0x2270 /* 2.0 */ +# define DP_DSC_DECODER_0_MAXIMUM_SLICE_COUNT_MASK (1 << 0) +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_MASK (0b111 << 1) +# define DP_DSC_DECODER_0_AGGREGATION_SUPPORT_SHIFT 1 + /* Protocol Converter Extension */ /* HDMI CEC tunneling over AUX DP 1.3 section 5.3.3.3.1 DPCD 1.4+ */ #define DP_CEC_TUNNELING_CAPABILITY 0x3000 >>> >>
Re: [PATCH v3 20/20] drm: cleanup: remove acquire_ctx from drm_mode_config
On 21/10/07 09:37PM, Fernando Ramos wrote: > --- > include/drm/drm_mode_config.h | 10 -- > 1 file changed, 10 deletions(-) > > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h > index 48b7de80daf5..b214b07157f2 100644 > This patch was missing the commit description and signed-off-by line. I'll fix that for the next revision (v4) together with the rest of issues that might come up.
Re: [PATCH 0/5] drm/vmwgfx: Support module unload and hotunplug
On Fri, 2021-10-08 at 22:28 +0200, Thomas Hellström wrote: > On Fri, 2021-10-08 at 13:31 -0400, Zack Rusin wrote: > > This is a largely trivial set that makes vmwgfx support module reload > > and PCI hot-unplug. It also makes IGT's core_hotunplug pass instead > > of kernel oops'ing. > > > > The one "ugly" change is the "Introduce a new placement for MOB page > > tables". It seems vmwgfx has been violating a TTM assumption that > > TTM_PL_SYSTEM buffers are never fenced for a while. Apart from a > > kernel > > oops on module unload it didn't seem to wreak too much havoc, but we > > shouldn't be abusing TTM. So to solve it we're introducing a new > > placement, which is basically system, but can deal with fenced bo's. > > > > Cc: Christian König > > Cc: Thomas Hellström > > Hi, Zack, > > What part of TTM doesn't allow fenced system memory currently? It was > certainly designed to allow that and vmwgfx has been relying on that > since the introduction of MOBs IIRC. Also i915 is currently relying on > that. It's the shutdown. BO's allocated through the ttm system manager might be busy during ttm_bo_put which results in them being scheduled for a delayed deletion. The ttm system manager is disabled before the final delayed deletion is ran in ttm_device_fini. This results in crashes during freeing of the BO resources because they're trying to remove themselves from a no longer existent ttm_resource_manager (e.g. in IGT's core_hotunplug on vmwgfx) During review of the trivial patch that was fixing it in ttm Christian said that system domain buffers must be idle or otherwise a number of assumptions in ttm breaks: https://lists.freedesktop.org/archives/dri-devel/2021-September/324027.html And later clarified that in fact system domain buffers being fenced is illegal from a design point of view: https://lists.freedesktop.org/archives/dri-devel/2021-September/324697.html z
Re: [PATCH 0/5] drm/vmwgfx: Support module unload and hotunplug
On Fri, 2021-10-08 at 13:31 -0400, Zack Rusin wrote: > This is a largely trivial set that makes vmwgfx support module reload > and PCI hot-unplug. It also makes IGT's core_hotunplug pass instead > of kernel oops'ing. > > The one "ugly" change is the "Introduce a new placement for MOB page > tables". It seems vmwgfx has been violating a TTM assumption that > TTM_PL_SYSTEM buffers are never fenced for a while. Apart from a > kernel > oops on module unload it didn't seem to wreak too much havoc, but we > shouldn't be abusing TTM. So to solve it we're introducing a new > placement, which is basically system, but can deal with fenced bo's. > > Cc: Christian König > Cc: Thomas Hellström Hi, Zack, What part of TTM doesn't allow fenced system memory currently? It was certainly designed to allow that and vmwgfx has been relying on that since the introduction of MOBs IIRC. Also i915 is currently relying on that. /Thomas
[GIT PULL] drm/tegra: Changes for v5.16-rc1
Hi Dave, Daniel, The following changes since commit c3dbfb9c49eef7d07904e5fd5e158dd6688bbab3: gpu: host1x: Plug potential memory leak (2021-09-16 18:06:52 +0200) are available in the Git repository at: ssh://git.freedesktop.org/git/tegra/linux.git tags/drm/tegra/for-5.16-rc1 for you to fetch changes up to 5dccbc9de8f0071eb731b4de81d0638ea6c06a53: drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra30+ (2021-10-08 21:17:38 +0200) This is based on the drm/tegra/for-5.15-rc3 tag that you pulled a couple of weeks ago. As mentioned last time already, the userspace for the new NVDEC driver can be found here: https://github.com/cyndis/vaapi-tegra-driver I'm sending this a week earlier than usual because I'm out of office next week. Thanks, Thierry drm/tegra: Changes for v5.16-rc1 This contains a fairly large rework that makes the buffer objects behave more according to what the DMA-BUF infrastructure expects. A buffer object cache is implemented on top of that to make certain operations such as page-flipping more efficient by avoiding needless map/unmap operations. This in turn is useful to implement asynchronous commits to support legacy cursor updates. Another fairly big addition is the NVDEC driver. This uses the updated UABI introduced in v5.15-rc1 to provide access to the video decode engines found on Tegra210 and later. The remainder of these changes is an assortment of cleanups and minor fixes. Arnd Bergmann (1): gpu: host1x: select CONFIG_DMA_SHARED_BUFFER Dmitry Osipenko (2): drm/tegra: dc: rgb: Move PCLK shifter programming to CRTC drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra30+ Mikko Perttunen (3): drm/tegra: Add NVDEC driver drm/tegra: Bump VIC/NVDEC clock rates to Fmax drm/tegra: vic: Use autosuspend Randy Dunlap (1): gpu: host1x: Drop excess kernel-doc entry @key Thierry Reding (6): drm/tegra: Implement correct DMA-BUF semantics drm/tegra: Implement buffer object cache drm/tegra: Do not reference tegra_plane_funcs directly drm/tegra: Propagate errors from drm_gem_plane_helper_prepare_fb() drm/tegra: Support asynchronous commits for cursor drm/tegra: gr2d: Explicitly control module reset Wan Jiabing (1): drm/tegra: Remove duplicate struct declaration drivers/gpu/drm/tegra/Makefile | 3 +- drivers/gpu/drm/tegra/dc.c | 117 -- drivers/gpu/drm/tegra/dc.h | 1 + drivers/gpu/drm/tegra/drm.c| 4 + drivers/gpu/drm/tegra/drm.h| 1 + drivers/gpu/drm/tegra/gem.c| 171 +-- drivers/gpu/drm/tegra/gr2d.c | 33 ++- drivers/gpu/drm/tegra/hub.h| 1 - drivers/gpu/drm/tegra/nvdec.c | 470 + drivers/gpu/drm/tegra/plane.c | 65 ++ drivers/gpu/drm/tegra/plane.h | 2 +- drivers/gpu/drm/tegra/rgb.c| 53 - drivers/gpu/drm/tegra/submit.c | 63 -- drivers/gpu/drm/tegra/uapi.c | 68 +++--- drivers/gpu/drm/tegra/uapi.h | 5 +- drivers/gpu/drm/tegra/vic.c| 8 + drivers/gpu/host1x/Kconfig | 1 + drivers/gpu/host1x/bus.c | 79 ++- drivers/gpu/host1x/dev.c | 20 ++ drivers/gpu/host1x/dev.h | 2 + drivers/gpu/host1x/job.c | 160 +- drivers/gpu/host1x/job.h | 6 +- include/linux/host1x.h | 75 +-- 23 files changed, 1087 insertions(+), 321 deletions(-) create mode 100644 drivers/gpu/drm/tegra/nvdec.c
[pull] amdgpu, amdkfd drm-next-5.16
Hi Dave, Daniel, More new stuff for 5.16. MCE change has an ack from Boris to merge through the amdgpu tree. The following changes since commit 1e3944578b749449bd7fa6bf0bae4c3d3f5f1733: Merge tag 'amd-drm-next-5.16-2021-09-27' of https://gitlab.freedesktop.org/agd5f/linux into drm-next (2021-09-28 17:08:26 +1000) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-next-5.16-2021-10-08 for you to fetch changes up to 40348baedfbc6500e7a090c7da1d55b6c94c334f: drm/amd/display: fix duplicated inclusion (2021-10-08 13:22:52 -0400) amd-drm-next-5.16-2021-10-08: amdgpu: - gart BO pin count fix - RAS fixes - Misc display fixes - Misc code cleanups - Validate IP discovery table - IOMMU handling fixes for hotplug - Cyan Skillfish display support - DP 2.0 fixes - Covert vega and navi to IP discovery based asic enumeration - JPEG fixes - More FP cleanup for display - DCC fixes for DCN3.x - Initial USB4 DP tunnelling support - Aldebaran MCE support amdkfd: - Misc bug fixes - Misc code cleanups - RAS fixes x86/MCE: - Export symbol for use by GPU driver Alex Deucher (69): drm/amdgpu: move headless sku check into harvest function drm/amdgpu: add debugfs access to the IP discovery table drm/amdgpu: store HW IP versions in the driver structure drm/amdgpu: fill in IP versions from IP discovery table drm/amdgpu: add XGMI HWIP drm/amdgpu/nv: export common IP functions drm/amdgpu: add initial IP enumeration via IP discovery table drm/amdgpu/sdma5.0: convert to IP version checking drm/amdgpu/sdma5.2: convert to IP version checking drm/amdgpu/gfx10: convert to IP version checking drm/amdgpu: filter out radeon PCI device IDs drm/amdgpu: bind to any 0x1002 PCI diplay class device drm/amdgpu/gmc10.0: convert to IP version checking drm/amdgpu: Use IP discovery to drive setting IP blocks by default drm/amdgpu: drive nav10 from the IP discovery table drm/amdgpu/gfxhub2.1: convert to IP version checking drm/amdgpu/mmhub2.0: convert to IP version checking drm/amdgpu/mmhub2.1: convert to IP version checking drm/amdgpu/vcn3.0: convert to IP version checking drm/amdgpu/athub2.0: convert to IP version checking drm/amdgpu/athub2.1: convert to IP version checking drm/amdgpu/navi10_ih: convert to IP version checking drm/amdgpu/amdgpu_smu: convert to IP version checking drm/amdgpu/smu11.0: convert to IP version checking drm/amdgpu/navi10_ppt: convert to IP version checking drm/amdgpu/sienna_cichlid_ppt: convert to IP version checking drm/amdgpu/nv: convert to IP version checking drm/amdgpu: drive all navi asics from the IP discovery table drm/amdgpu/display/dm: convert to IP version checking drm/amdgpu: add DCI HWIP drm/amdgpu/soc15: export common IP functions drm/amdgpu: add initial IP discovery support for vega based parts drm/amdgpu/soc15: get rev_id in soc15_common_early_init drm/amdgpu: drive all vega asics from the IP discovery table drm/amdgpu: default to true in amdgpu_device_asic_has_dc_support drm/amdgpu/display/dm: convert RAVEN to IP version checking drm/amdgpu/sdma4.0: convert to IP version checking drm/amdgpu/hdp4.0: convert to IP version checking drm/amdgpu/gfx9.0: convert to IP version checking drm/amdgpu/amdgpu_psp: convert to IP version checking drm/amdgpu/psp_v11.0: convert to IP version checking drm/amdgpu/psp_v13.0: convert to IP version checking drm/amdgpu/pm/smu_v11.0: update IP version checking drm/amdgpu/pm/smu_v13.0: convert IP version checking drm/amdgpu/pm/amdgpu_smu: convert more IP version checking drm/amdgpu/amdgpu_vcn: convert to IP version checking drm/amdgpu/vcn2.5: convert to IP version checking drm/amdgpu/soc15: convert to IP version checking drm/amdgpu: add VCN1 hardware IP drm/amdgpu: get VCN and SDMA instances from IP discovery table drm/amdgpu/sdma: remove manual instance setting drm/amdgpu/vcn: remove manual instance setting drm/amdgpu: get VCN harvest information from IP discovery table drm/amdgpu/ucode: add default behavior drm/amdgpu: add new asic_type for IP discovery drm/amdgpu: set CHIP_IP_DISCOVERY as the asic type by default drm/amdgpu: convert IP version array to include instances drm/amdgpu: clean up set IP function drm/amdgpu: add support for SRIOV in IP discovery path drm/amdkfd: clean up parameters in kgd2kfd_probe drm/amdkfd: convert kfd_device.c to use GC IP version drm/amdgpu: add an option to override IP discovery table from a file drm/amdgpu: consolidate case statements Documentation/gpu: remove spurious "+" in
Re: [PATCH v1 2/2] drm/tegra: dc: rgb: Allow changing PLLD rate on Tegra30+
On Thu, Sep 30, 2021 at 01:28:05AM +0300, Dmitry Osipenko wrote: > Asus Transformer TF700T is a Tegra30 tablet device which uses RGB->DSI > bridge that requires a precise clock rate in order to operate properly. > Tegra30 has a dedicated PLL for each display controller, hence the PLL > rate can be changed freely. Allow PLL rate changes on Tegra30+ for RGB > output. Configure the clock rate before display controller is enabled > since DC itself may be running off this PLL and it's not okay to change > the rate of the active PLL that doesn't support dynamic frequency > switching since hardware will hang. > > Tested-by: Maxim Schwalm #TF700T > Signed-off-by: Dmitry Osipenko > --- > drivers/gpu/drm/tegra/dc.c | 27 > drivers/gpu/drm/tegra/dc.h | 1 + > drivers/gpu/drm/tegra/rgb.c | 49 +++-- > 3 files changed, 65 insertions(+), 12 deletions(-) Applied, thanks. Thierry signature.asc Description: PGP signature
Re: [PATCH 07/26] drm/i915/guc: Introduce context parent-child relationship
On Thu, Oct 07, 2021 at 12:35:08PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > Introduce context parent-child relationship. Once this relationship is
> > created all pinning / unpinning operations are directed to the parent
> > context. The parent context is responsible for pinning all of its'
> No need for an apostrophe.
>
Fixed.
> > children and itself.
> >
> > This is a precursor to the full GuC multi-lrc implementation but aligns
> > to how GuC mutli-lrc interface is defined - a single H2G is used
> > register / deregister all of the contexts simultaneously.
> >
> > Subsequent patches in the series will implement the pinning / unpinning
> > operations for parent / child contexts.
> >
> > v2:
> > (Daniel Vetter)
> >- Add kernel doc, add wrapper to access parent to ensure safety
> > v3:
> > (John Harrison)
> >- Fix comment explaing GEM_BUG_ON in to_parent()
> >- Make variable names generic (non-GuC specific)
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 29 +
> > drivers/gpu/drm/i915/gt/intel_context.h | 41 +++
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 21 ++
> > 3 files changed, 91 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index f601323b939f..c5bb7ccfb3f8 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -403,6 +403,8 @@ intel_context_init(struct intel_context *ce, struct
> > intel_engine_cs *engine)
> > INIT_LIST_HEAD(>destroyed_link);
> > + INIT_LIST_HEAD(>parallel.child_list);
> > +
> > /*
> > * Initialize fence to be complete as this is expected to be complete
> > * unless there is a pending schedule disable outstanding.
> > @@ -417,10 +419,17 @@ intel_context_init(struct intel_context *ce, struct
> > intel_engine_cs *engine)
> > void intel_context_fini(struct intel_context *ce)
> > {
> > + struct intel_context *child, *next;
> > +
> > if (ce->timeline)
> > intel_timeline_put(ce->timeline);
> > i915_vm_put(ce->vm);
> > + /* Need to put the creation ref for the children */
> > + if (intel_context_is_parent(ce))
> > + for_each_child_safe(ce, child, next)
> > + intel_context_put(child);
> > +
> > mutex_destroy(>pin_mutex);
> > i915_active_fini(>active);
> > i915_sw_fence_fini(>guc_state.blocked);
> > @@ -537,6 +546,26 @@ struct i915_request
> > *intel_context_find_active_request(struct intel_context *ce)
> > return active;
> > }
> > +void intel_context_bind_parent_child(struct intel_context *parent,
> > +struct intel_context *child)
> > +{
> > + /*
> > +* Callers responsibility to validate that this function is used
> > +* correctly but we use GEM_BUG_ON here ensure that they do.
> > +*/
> > + GEM_BUG_ON(!intel_engine_uses_guc(parent->engine));
> > + GEM_BUG_ON(intel_context_is_pinned(parent));
> > + GEM_BUG_ON(intel_context_is_child(parent));
> > + GEM_BUG_ON(intel_context_is_pinned(child));
> > + GEM_BUG_ON(intel_context_is_child(child));
> > + GEM_BUG_ON(intel_context_is_parent(child));
> > +
> > + parent->parallel.number_children++;
> > + list_add_tail(>parallel.child_link,
> > + >parallel.child_list);
> > + child->parallel.parent = parent;
> > +}
> > +
> > #if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> > #include "selftest_context.c"
> > #endif
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
> > b/drivers/gpu/drm/i915/gt/intel_context.h
> > index c41098950746..b63c10a144af 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.h
> > @@ -44,6 +44,47 @@ void intel_context_free(struct intel_context *ce);
> > int intel_context_reconfigure_sseu(struct intel_context *ce,
> >const struct intel_sseu sseu);
> > +static inline bool intel_context_is_child(struct intel_context *ce)
> > +{
> > + return !!ce->parallel.parent;
> > +}
> > +
> > +static inline bool intel_context_is_parent(struct intel_context *ce)
> > +{
> > + return !!ce->parallel.number_children;
> > +}
> > +
> > +static inline bool intel_context_is_pinned(struct intel_context *ce);
> > +
> > +static inline struct intel_context *
> > +intel_context_to_parent(struct intel_context *ce)
> > +{
> > + if (intel_context_is_child(ce)) {
> > + /*
> > +* The parent holds ref count to the child so it is always safe
> > +* for the parent to access the child, but the child has a
> > +* pointer to the parent without a ref. To ensure this is safe
> > +* the child should only access the parent pointer while the
> > +* parent is pinned.
> > +*/
> > +
Re: [PATCH 02/26] drm/i915/guc: Take GT PM ref when deregistering context
On Wed, Oct 06, 2021 at 08:37:03PM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > Taking a PM reference to prevent intel_gt_wait_for_idle from short
> > circuiting while a deregister context H2G is in flight. To do this must
> > issue the deregister H2G from a worker as context can be destroyed from
> > an atomic context and taking GT PM ref blows up. Previously we took a
> > runtime PM from this atomic context which worked but will stop working
> > once runtime pm autosuspend in enabled.
> >
> > So this patch is two fold, stop intel_gt_wait_for_idle from short
> > circuting and fix runtime pm autosuspend.
> >
> > v2:
> > (John Harrison)
> >- Split structure changes out in different patch
> > (Tvrtko)
> >- Don't drop lock in deregister_destroyed_contexts
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 2 +
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +
> > drivers/gpu/drm/i915/gt/intel_engine_pm.h | 5 +
> > drivers/gpu/drm/i915/gt/intel_gt_pm.h | 4 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 11 ++
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 146 +++---
> > 6 files changed, 121 insertions(+), 54 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index e9a0cad5c34d..1076066f41e0 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -399,6 +399,8 @@ intel_context_init(struct intel_context *ce, struct
> > intel_engine_cs *engine)
> > ce->guc_id.id = GUC_INVALID_LRC_ID;
> > INIT_LIST_HEAD(>guc_id.link);
> > + INIT_LIST_HEAD(>destroyed_link);
> > +
> > /*
> > * Initialize fence to be complete as this is expected to be complete
> > * unless there is a pending schedule disable outstanding.
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index e7e3984aab78..4613d027cbc3 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -213,6 +213,13 @@ struct intel_context {
> > struct list_head link;
> > } guc_id;
> > + /**
> > +* @destroyed_link: link in guc->submission_state.destroyed_contexts, in
> > +* list when context is pending to be destroyed (deregistered with the
> > +* GuC), protected by guc->submission_state.lock
> > +*/
> > + struct list_head destroyed_link;
> > +
> > #ifdef CONFIG_DRM_I915_SELFTEST
> > /**
> > * @drop_schedule_enable: Force drop of schedule enable G2H for selftest
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
> > index 8520c595f5e1..6fdeae668e6e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.h
> > @@ -16,6 +16,11 @@ intel_engine_pm_is_awake(const struct intel_engine_cs
> > *engine)
> > return intel_wakeref_is_active(>wakeref);
> > }
> > +static inline void __intel_engine_pm_get(struct intel_engine_cs *engine)
> > +{
> > + __intel_wakeref_get(>wakeref);
> > +}
> > +
> > static inline void intel_engine_pm_get(struct intel_engine_cs *engine)
> > {
> > intel_wakeref_get(>wakeref);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > index d0588d8aaa44..05de6c1af25b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
> > @@ -41,6 +41,10 @@ static inline void intel_gt_pm_put_async(struct intel_gt
> > *gt)
> > intel_wakeref_put_async(>wakeref);
> > }
> > +#define with_intel_gt_pm(gt, tmp) \
> > + for (tmp = 1, intel_gt_pm_get(gt); tmp; \
> > +intel_gt_pm_put(gt), tmp = 0)
> > +
> > static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
> > {
> > return intel_wakeref_wait_for_idle(>wakeref);
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 65b5e8eeef96..25a598e2b6e8 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -84,6 +84,17 @@ struct intel_guc {
> > * refs
> > */
> > struct list_head guc_id_list;
> > + /**
> > +* @destroyed_contexts: list of contexts waiting to be destroyed
> > +* (deregistered with the GuC)
> > +*/
> > + struct list_head destroyed_contexts;
> > + /**
> > +* @destroyed_worker: worker to deregister contexts, need as we
> > +* need to take a GT PM reference and can't from destroy
> > +* function as it might be in an atomic context (no sleeping)
> > +*/
> > + struct work_struct destroyed_worker;
> > } submission_state;
>
Re: [PATCH v2 1/7] drm/sysfs: introduce drm_sysfs_connector_hotplug_event
Ping
Re: [PATCH 14/26] drm/i915/guc: Implement multi-lrc reset
On Fri, Oct 08, 2021 at 10:39:35AM -0700, John Harrison wrote:
> On 10/4/2021 15:06, Matthew Brost wrote:
> > Update context and full GPU reset to work with multi-lrc. The idea is
> > parent context tracks all the active requests inflight for itself and
> > its' children. The parent context owns the reset replaying / canceling
> Still its' should be its.
>
Yea. Will fix.
> > requests as needed.
> >
> > v2:
> > (John Harrison)
> >- Simply loop in find active request
> >- Add comments to find ative request / reset loop
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_context.c | 15 +++-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 69 ++-
> > 2 files changed, 63 insertions(+), 21 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > b/drivers/gpu/drm/i915/gt/intel_context.c
> > index c5bb7ccfb3f8..3b340eb59ada 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > @@ -528,20 +528,29 @@ struct i915_request
> > *intel_context_create_request(struct intel_context *ce)
> > struct i915_request *intel_context_find_active_request(struct
> > intel_context *ce)
> > {
> > + struct intel_context *parent = intel_context_to_parent(ce);
> > struct i915_request *rq, *active = NULL;
> > unsigned long flags;
> > GEM_BUG_ON(!intel_engine_uses_guc(ce->engine));
> > - spin_lock_irqsave(>guc_state.lock, flags);
> > - list_for_each_entry_reverse(rq, >guc_state.requests,
> > + /*
> > +* We search the parent list to find an active request on the submitted
> > +* context. The parent list contains the requests for all the contexts
> > +* in the relationship so we have to do a compare of each request's
> > +* context must be done.
> "have to do ... must be done" - no need for both.
>
Right, will fix.
> > +*/
> > + spin_lock_irqsave(>guc_state.lock, flags);
> > + list_for_each_entry_reverse(rq, >guc_state.requests,
> > sched.link) {
> > + if (rq->context != ce)
> > + continue;
> > if (i915_request_completed(rq))
> > break;
> > active = rq;
> > }
> > - spin_unlock_irqrestore(>guc_state.lock, flags);
> > + spin_unlock_irqrestore(>guc_state.lock, flags);
> > return active;
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 6be7adf89e4f..d661a69ef4f7 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -681,6 +681,11 @@ static inline int rq_prio(const struct i915_request
> > *rq)
> > return rq->sched.attr.priority;
> > }
> > +static inline bool is_multi_lrc(struct intel_context *ce)
> > +{
> > + return intel_context_is_parallel(ce);
> > +}
> > +
> > static bool is_multi_lrc_rq(struct i915_request *rq)
> > {
> > return intel_context_is_parallel(rq->context);
> > @@ -1214,10 +1219,15 @@ __unwind_incomplete_requests(struct intel_context
> > *ce)
> > static void __guc_reset_context(struct intel_context *ce, bool stalled)
> > {
> > + bool local_stalled;
> > struct i915_request *rq;
> > unsigned long flags;
> > u32 head;
> > + int i, number_children = ce->parallel.number_children;
> > bool skip = false;
> > + struct intel_context *parent = ce;
> > +
> > + GEM_BUG_ON(intel_context_is_child(ce));
> > intel_context_get(ce);
> > @@ -1243,25 +1253,38 @@ static void __guc_reset_context(struct
> > intel_context *ce, bool stalled)
> > if (unlikely(skip))
> > goto out_put;
> > - rq = intel_context_find_active_request(ce);
> > - if (!rq) {
> > - head = ce->ring->tail;
> > - stalled = false;
> > - goto out_replay;
> > - }
> > + /*
> > +* For each context in the relationship find the hanging request
> > +* resetting each context / request as needed
> > +*/
> > + for (i = 0; i < number_children + 1; ++i) {
> > + if (!intel_context_is_pinned(ce))
> > + goto next_context;
> > +
> > + local_stalled = false;
> > + rq = intel_context_find_active_request(ce);
> > + if (!rq) {
> > + head = ce->ring->tail;
> > + goto out_replay;
> > + }
> > - if (!i915_request_started(rq))
> > - stalled = false;
> > + GEM_BUG_ON(i915_active_is_idle(>active));
> > + head = intel_ring_wrap(ce->ring, rq->head);
> > - GEM_BUG_ON(i915_active_is_idle(>active));
> > - head = intel_ring_wrap(ce->ring, rq->head);
> > - __i915_request_reset(rq, stalled);
> > + if (i915_request_started(rq))
> I didn't see an answer as to why the started test and the wrap call need to
> be reversed?
>
Sorry, they don't have to be. Can flip this back
Re: [PATCH 16/26] drm/i915: Fix bug in user proto-context creation that leaked contexts
On 10/4/2021 15:06, Matthew Brost wrote:
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly. Also check return of
alloc_engines for NULL.
v2:
(Tvrtko)
- Send as stand alone patch
(John Harrison)
- Check for alloc_engines returning NULL
v3:
(Checkpatch / Tvrtko)
- Remove braces around single line if statement
Cc: Jason Ekstrand
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create
parameters (v5)")
Reviewed-by: Tvrtko Ursulin
Signed-off-by: Matthew Brost
Cc:
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 8208fd5b72c3..8c7ea6e56262 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -898,6 +898,10 @@ static struct i915_gem_engines *user_engines(struct
i915_gem_context *ctx,
unsigned int n;
e = alloc_engines(num_engines);
+ if (!e)
+ return ERR_PTR(-ENOMEM);
+ e->num_engines = num_engines;
+
for (n = 0; n < num_engines; n++) {
struct intel_context *ce;
int ret;
@@ -931,7 +935,6 @@ static struct i915_gem_engines *user_engines(struct
i915_gem_context *ctx,
goto free_engines;
}
}
- e->num_engines = num_engines;
return e;
Re: [PATCH 15/26] drm/i915/guc: Update debugfs for GuC multi-lrc
On 10/4/2021 15:06, Matthew Brost wrote:
Display the workqueue status in debugfs for GuC contexts that are in
parent-child relationship.
v2:
(John Harrison)
- Output number children in debugfs
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 53 ++-
1 file changed, 39 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index d661a69ef4f7..f69e984683aa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3704,6 +3704,26 @@ static inline void guc_log_context_priority(struct
drm_printer *p,
drm_printf(p, "\n");
}
+
+static inline void guc_log_context(struct drm_printer *p,
+ struct intel_context *ce)
+{
+ drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id.id);
+ drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
+ drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
+ ce->ring->head,
+ ce->lrc_reg_state[CTX_RING_HEAD]);
+ drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
+ ce->ring->tail,
+ ce->lrc_reg_state[CTX_RING_TAIL]);
+ drm_printf(p, "\t\tContext Pin Count: %u\n",
+ atomic_read(>pin_count));
+ drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
+ atomic_read(>guc_id.ref));
+ drm_printf(p, "\t\tSchedule State: 0x%x\n\n",
+ ce->guc_state.sched_state);
+}
+
void intel_guc_submission_print_context_info(struct intel_guc *guc,
struct drm_printer *p)
{
@@ -3713,22 +3733,27 @@ void intel_guc_submission_print_context_info(struct
intel_guc *guc,
xa_lock_irqsave(>context_lookup, flags);
xa_for_each(>context_lookup, index, ce) {
- drm_printf(p, "GuC lrc descriptor %u:\n", ce->guc_id.id);
- drm_printf(p, "\tHW Context Desc: 0x%08x\n", ce->lrc.lrca);
- drm_printf(p, "\t\tLRC Head: Internal %u, Memory %u\n",
- ce->ring->head,
- ce->lrc_reg_state[CTX_RING_HEAD]);
- drm_printf(p, "\t\tLRC Tail: Internal %u, Memory %u\n",
- ce->ring->tail,
- ce->lrc_reg_state[CTX_RING_TAIL]);
- drm_printf(p, "\t\tContext Pin Count: %u\n",
- atomic_read(>pin_count));
- drm_printf(p, "\t\tGuC ID Ref Count: %u\n",
- atomic_read(>guc_id.ref));
- drm_printf(p, "\t\tSchedule State: 0x%x\n\n",
- ce->guc_state.sched_state);
+ GEM_BUG_ON(intel_context_is_child(ce));
+ guc_log_context(p, ce);
guc_log_context_priority(p, ce);
+
+ if (intel_context_is_parent(ce)) {
+ struct guc_process_desc *desc = __get_process_desc(ce);
+ struct intel_context *child;
+
+ drm_printf(p, "\t\tNumber children: %u\n",
+ ce->parallel.number_children);
+ drm_printf(p, "\t\tWQI Head: %u\n",
+ READ_ONCE(desc->head));
+ drm_printf(p, "\t\tWQI Tail: %u\n",
+ READ_ONCE(desc->tail));
+ drm_printf(p, "\t\tWQI Status: %u\n\n",
+ READ_ONCE(desc->wq_status));
+
+ for_each_child(ce, child)
+ guc_log_context(p, child);
+ }
}
xa_unlock_irqrestore(>context_lookup, flags);
}
Re: [PATCH 14/26] drm/i915/guc: Implement multi-lrc reset
On 10/4/2021 15:06, Matthew Brost wrote:
Update context and full GPU reset to work with multi-lrc. The idea is
parent context tracks all the active requests inflight for itself and
its' children. The parent context owns the reset replaying / canceling
Still its' should be its.
requests as needed.
v2:
(John Harrison)
- Simply loop in find active request
- Add comments to find ative request / reset loop
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 15 +++-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 69 ++-
2 files changed, 63 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index c5bb7ccfb3f8..3b340eb59ada 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -528,20 +528,29 @@ struct i915_request *intel_context_create_request(struct
intel_context *ce)
struct i915_request *intel_context_find_active_request(struct intel_context *ce)
{
+ struct intel_context *parent = intel_context_to_parent(ce);
struct i915_request *rq, *active = NULL;
unsigned long flags;
GEM_BUG_ON(!intel_engine_uses_guc(ce->engine));
- spin_lock_irqsave(>guc_state.lock, flags);
- list_for_each_entry_reverse(rq, >guc_state.requests,
+ /*
+* We search the parent list to find an active request on the submitted
+* context. The parent list contains the requests for all the contexts
+* in the relationship so we have to do a compare of each request's
+* context must be done.
"have to do ... must be done" - no need for both.
+*/
+ spin_lock_irqsave(>guc_state.lock, flags);
+ list_for_each_entry_reverse(rq, >guc_state.requests,
sched.link) {
+ if (rq->context != ce)
+ continue;
if (i915_request_completed(rq))
break;
active = rq;
}
- spin_unlock_irqrestore(>guc_state.lock, flags);
+ spin_unlock_irqrestore(>guc_state.lock, flags);
return active;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 6be7adf89e4f..d661a69ef4f7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -681,6 +681,11 @@ static inline int rq_prio(const struct i915_request *rq)
return rq->sched.attr.priority;
}
+static inline bool is_multi_lrc(struct intel_context *ce)
+{
+ return intel_context_is_parallel(ce);
+}
+
static bool is_multi_lrc_rq(struct i915_request *rq)
{
return intel_context_is_parallel(rq->context);
@@ -1214,10 +1219,15 @@ __unwind_incomplete_requests(struct intel_context *ce)
static void __guc_reset_context(struct intel_context *ce, bool stalled)
{
+ bool local_stalled;
struct i915_request *rq;
unsigned long flags;
u32 head;
+ int i, number_children = ce->parallel.number_children;
bool skip = false;
+ struct intel_context *parent = ce;
+
+ GEM_BUG_ON(intel_context_is_child(ce));
intel_context_get(ce);
@@ -1243,25 +1253,38 @@ static void __guc_reset_context(struct intel_context *ce, bool stalled)
if (unlikely(skip))
goto out_put;
- rq = intel_context_find_active_request(ce);
- if (!rq) {
- head = ce->ring->tail;
- stalled = false;
- goto out_replay;
- }
+ /*
+* For each context in the relationship find the hanging request
+* resetting each context / request as needed
+*/
+ for (i = 0; i < number_children + 1; ++i) {
+ if (!intel_context_is_pinned(ce))
+ goto next_context;
+
+ local_stalled = false;
+ rq = intel_context_find_active_request(ce);
+ if (!rq) {
+ head = ce->ring->tail;
+ goto out_replay;
+ }
- if (!i915_request_started(rq))
- stalled = false;
+ GEM_BUG_ON(i915_active_is_idle(>active));
+ head = intel_ring_wrap(ce->ring, rq->head);
- GEM_BUG_ON(i915_active_is_idle(>active));
- head = intel_ring_wrap(ce->ring, rq->head);
- __i915_request_reset(rq, stalled);
+ if (i915_request_started(rq))
I didn't see an answer as to why the started test and the wrap call need
to be reversed?
John.
+ local_stalled = true;
+ __i915_request_reset(rq, local_stalled && stalled);
out_replay:
- guc_reset_state(ce, head, stalled);
- __unwind_incomplete_requests(ce);
+ guc_reset_state(ce, head, local_stalled && stalled);
+next_context:
+ if (i != number_children)
+
Re: [Intel-gfx] [PATCH 08/26] drm/i915/guc: Add multi-lrc context registration
On Fri, Oct 08, 2021 at 10:20:16AM -0700, John Harrison wrote:
> On 10/7/2021 12:50, John Harrison wrote:
> > On 10/4/2021 15:06, Matthew Brost wrote:
> > > Add multi-lrc context registration H2G. In addition a workqueue and
> > > process descriptor are setup during multi-lrc context registration as
> > > these data structures are needed for multi-lrc submission.
> > >
> > > v2:
> > > (John Harrison)
> > > - Move GuC specific fields into sub-struct
> > > - Clean up WQ defines
> > > - Add comment explaining math to derive WQ / PD address
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_context_types.h | 12 ++
> > > drivers/gpu/drm/i915/gt/intel_lrc.c | 5 +
> > > .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
> > > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 -
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 114 +-
> > > 5 files changed, 131 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > index 76dfca57cb45..48decb5ee954 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > @@ -239,6 +239,18 @@ struct intel_context {
> > > struct intel_context *parent;
> > > /** @number_children: number of children if parent */
> > > u8 number_children;
> > > + /** @guc: GuC specific members for parallel submission */
> > > + struct {
> > > + /** @wqi_head: head pointer in work queue */
> > > + u16 wqi_head;
> > > + /** @wqi_tail: tail pointer in work queue */
> > > + u16 wqi_tail;
> PS: As per comments on previous rev, something somewhere needs to explicitly
> state what WQI means. One suggestion was to do that here, ideally with maybe
> a brief description of what the queue is, how it is used, etc. Although
> probably it would be better kept in a GuC specific file. E.g. added to
> guc_fwif.h in patch #12.
>
I think this should just be in the main GuC kernel doc. I can include an
update to the kernel DoC in a patch at the end of the next rev of the
series. That patch doesn't necessarily have to included in the initial
merge of parallel submission if it takes a bit more time to review.
Matt
> John.
>
> > > + /**
> > > + * @parent_page: page in context state (ce->state) used
> > > + * by parent for work queue, process descriptor
> > > + */
> > > + u8 parent_page;
> > > + } guc;
> > > } parallel;
> > > #ifdef CONFIG_DRM_I915_SELFTEST
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > > index 3ef9eaf8c50e..57339d5c1fc8 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > > @@ -942,6 +942,11 @@ __lrc_alloc_state(struct intel_context *ce,
> > > struct intel_engine_cs *engine)
> > > context_size += PAGE_SIZE;
> > > }
> > > + if (intel_context_is_parent(ce) &&
> > > intel_engine_uses_guc(engine)) {
> > > + ce->parallel.guc.parent_page = context_size / PAGE_SIZE;
> > > + context_size += PAGE_SIZE;
> > > + }
> > > +
> > > obj = i915_gem_object_create_lmem(engine->i915, context_size,
> > > I915_BO_ALLOC_PM_VOLATILE);
> > > if (IS_ERR(obj))
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > > b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > > index 8ff58aff..ba10bd374cee 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > > @@ -142,6 +142,7 @@ enum intel_guc_action {
> > > INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
> > > INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
> > > INTEL_GUC_ACTION_DEREGISTER_CONTEXT_DONE = 0x4600,
> > > + INTEL_GUC_ACTION_REGISTER_CONTEXT_MULTI_LRC = 0x4601,
> > > INTEL_GUC_ACTION_RESET_CLIENT = 0x5507,
> > > INTEL_GUC_ACTION_LIMIT
> > > };
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > > index fa4be13c8854..0eeb2a9feeed 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > > @@ -52,8 +52,6 @@
> > > #define GUC_DOORBELL_INVALID 256
> > > -#define GUC_WQ_SIZE (PAGE_SIZE * 2)
> > > -
> > > /* Work queue item header definitions */
> > > #define WQ_STATUS_ACTIVE 1
> > > #define WQ_STATUS_SUSPENDED 2
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > > index 451d9ae861a6..ab6d7fc1b0b1 100644
> > > ---
Re: Questions over DSI within DRM.
On Thu, 7 Oct 2021 at 21:19, Andrzej Hajda wrote: > > On 07.10.2021 13:07, Dave Stevenson wrote: > > On Tue, 5 Oct 2021 at 22:03, Andrzej Hajda wrote: > >> > >> On 05.10.2021 17:32, Dave Stevenson wrote: > >>> Hi Andrzej > >>> > >>> Thanks for joining in the discussion. > >>> > >>> On Tue, 5 Oct 2021 at 16:08, Andrzej Hajda > >>> wrote: > > On 05.10.2021 13:23, Dave Stevenson wrote: > > Hi Laurent > > > > On Sun, 3 Oct 2021 at 15:16, Laurent Pinchart > > wrote: > >> > >> Hello, > >> > >> Reviving a bit of an old thread. > > > > I'd been looking at reviving this conversation too as I've moved > > further on with DSI on the Pi, and converting from an encoder to a > > bridge > > > >> On Thu, Jul 15, 2021 at 11:50:22AM +0200, Maxime Ripard wrote: > >>> On Tue, Jul 06, 2021 at 05:44:58PM +0100, Dave Stevenson wrote: > On Tue, 6 Jul 2021 at 16:13, Maxime Ripard wrote: > On a similar theme, some devices want the clock lane in HS mode > early > so they can use it in place of an external oscillator, but the > data > lanes still in LP-11. There appears to be no way for the > display/bridge to signal this requirement or it be achieved. > >>> > >>> You're right. A lng time ago, the omapdrm driver had an > >>> internal > >>> infrastructure that didn't use drm_bridge or drm_panel and instead > >>> required omapdrm-specific drivers for those components. It used > >>> to model > >>> the display pipeline in a different way than drm_bridge, with the > >>> sync > >>> explicitly setting the source state. A DSI sink could thus > >>> control its > >>> enable sequence, interleaving programming of the sink with > >>> control of > >>> the source. > >>> > >>> Migrating omapdrm to the drm_bridge model took a really large > >>> effort, > >>> which makes me believe that transitioning the whole subsystem to > >>> sink-controlled sources would be close to impossible. We could add > >>> DSI-specific operations, or add another enable bridge operation > >>> (post_pre_enable ? :-D). Neither would scale, but it may be > >>> enough. > >> > >> I haven't thought it through for all generic cases, but I suspect > >> it's > >> more a pre_pre_enable that is needed to initialise the PHY etc, > >> probably from source to sink. > >> > >> I believe it could be implemented as a pre-pre-enable indeed. It feels > >> like a bit of a hack, as the next time we need more fine-grained > >> control > >> over the startup sequence, we'll have to add a pre-pre-pre-enable. > >> Given > >> that the startup sequence requirements come from the sink device, it > >> would make sense to let it explicitly control the initialization, > >> instead of driving it from the source. I don't think we'll be able to > >> rework the bridge API in that direction though, so I'm fine with a > >> hack. > > > > There are pros and cons to both approaches. > > You're in a much better place to make that sort of call than I am, so > > I'll take your advice. > > > > Implementing a DSI host op function may mean an update to a number of > > existing DSI host drivers, > > Why? You just add new op to mipi_dsi_host_ops and create appropriate > helper, which in case of NULL will perform default action, either: > - return -ENOSYS, > - try to emulate by calling > mipi_dsi_device_transfer(MIPI_DSI_NULL_PACKET) > > The latter is just wild guess, but I suspect it could work (even now) as > an alternate way of entering into stop state. > >>> > >>> If we're looking at fixing bridges to use the new DSI state call and > >>> then initialise in "pre_enable" (ie before video is started), then > >>> making that change to the bridge will require support for the DSI > >>> state call or risk regressions. > >> > >> I think there is misunderstanding somewhere, I do not know where, yet :) > >> My idea is as follow: > >> 1. Add dsi_host.set_state() op to dsi host accompanied with helper, lets > >> call it mipi_dsi_host_set_state for now. > >> 2. Implement dsi_host.set_state in DSI host you are working with. > >> 3. In body of your bridge pre_enable you call mipi_dsi_host_set_state in > >> proper place. > >> > >> 1 and 2 do not introduce any regression. > >> 3 can introduce regression only if your bridge is used with another dsi > >> host but only on such platforms. > >> > >> Why do you think we need to 'fix' it everywhere? > > > > I'm looking at sn65dsi83 which is already working against other > > platforms (I don't know which). If it is fixed to request the DSI > > state and initialise in pre_enable, then those platforms
[PATCH 5/5] drm/vmwgfx: Switch the internal BO's to ttm_bo_type_kernel
There's never a need to access our internal kernel bo's from user-space. Those objects are used exclusively for internal support to guest backed surfaces (in otable setup and mob page tables) and there's no need to have them be of device type, i.e. mmappable from user-space. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev --- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c index fd007f1c1776..c97a3d5e90ce 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_bo.c @@ -494,7 +494,7 @@ int vmw_bo_create_kernel(struct vmw_private *dev_priv, unsigned long size, drm_vma_node_reset(>base.vma_node); ret = ttm_bo_init_reserved(_priv->bdev, bo, size, - ttm_bo_type_device, placement, 0, + ttm_bo_type_kernel, placement, 0, , NULL, NULL, NULL); if (unlikely(ret)) goto error_account; -- 2.30.2
[PATCH 4/5] drm/vmwgfx: Introduce a new placement for MOB page tables
For larger (bigger than a page) and noncontiguous mobs we have
to create page tables that allow the host to find the memory.
Those page tables just used regular system memory. Unfortunately
in TTM those BO's are not allowed to be busy thus can't be
fenced and we have to fence those bo's because we don't want
to destroy the page tables while the host is still executing
the command buffers which might be accessing them.
To solve it we introduce a new placement VMW_PL_SYSTEM which
is very similar to TTM_PL_SYSTEM except that it allows
fencing. This fixes kernel oops'es during unloading of the driver
(and pci hot remove/add) which were caused by busy BO's in
TTM_PL_SYSTEM being present in the delayed deletion list in
TTM (TTM_PL_SYSTEM manager is destroyed before the delayed
deletions are executed)
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
Cc: Christian König
Cc: Thomas Hellström
---
drivers/gpu/drm/vmwgfx/Makefile | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 14 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 12 ++-
.../gpu/drm/vmwgfx/vmwgfx_system_manager.c| 90 +++
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 58 ++--
5 files changed, 138 insertions(+), 38 deletions(-)
create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_system_manager.c
diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index bc323f7d4032..0188a312c38c 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -9,7 +9,7 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o
vmwgfx_drv.o \
vmwgfx_cotable.o vmwgfx_so.o vmwgfx_binding.o vmwgfx_msg.o \
vmwgfx_simple_resource.o vmwgfx_va.o vmwgfx_blit.o \
vmwgfx_validation.o vmwgfx_page_dirty.o vmwgfx_streamoutput.o \
-vmwgfx_devcaps.o ttm_object.o ttm_memory.o
+ vmwgfx_devcaps.o ttm_object.o ttm_memory.o vmwgfx_system_manager.o
vmwgfx-$(CONFIG_DRM_FBDEV_EMULATION) += vmwgfx_fb.o
vmwgfx-$(CONFIG_TRANSPARENT_HUGEPAGE) += vmwgfx_thp.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 8d0b083ba267..daf65615308a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1071,6 +1071,12 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
u32 pci_id)
"3D will be disabled.\n");
dev_priv->has_mob = false;
}
+ if (vmw_sys_man_init(dev_priv) != 0) {
+ drm_info(_priv->drm,
+"No MOB page table memory available. "
+"3D will be disabled.\n");
+ dev_priv->has_mob = false;
+ }
}
if (dev_priv->has_mob && (dev_priv->capabilities & SVGA_CAP_DX)) {
@@ -1121,8 +1127,10 @@ static int vmw_driver_load(struct vmw_private *dev_priv,
u32 pci_id)
vmw_overlay_close(dev_priv);
vmw_kms_close(dev_priv);
out_no_kms:
- if (dev_priv->has_mob)
+ if (dev_priv->has_mob) {
vmw_gmrid_man_fini(dev_priv, VMW_PL_MOB);
+ vmw_sys_man_fini(dev_priv);
+ }
if (dev_priv->has_gmr)
vmw_gmrid_man_fini(dev_priv, VMW_PL_GMR);
vmw_devcaps_destroy(dev_priv);
@@ -1172,8 +1180,10 @@ static void vmw_driver_unload(struct drm_device *dev)
vmw_gmrid_man_fini(dev_priv, VMW_PL_GMR);
vmw_release_device_early(dev_priv);
- if (dev_priv->has_mob)
+ if (dev_priv->has_mob) {
vmw_gmrid_man_fini(dev_priv, VMW_PL_MOB);
+ vmw_sys_man_fini(dev_priv);
+ }
vmw_devcaps_destroy(dev_priv);
vmw_vram_manager_fini(dev_priv);
ttm_device_fini(_priv->bdev);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index a833751099b5..df19dfb3ce18 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -82,8 +82,9 @@
VMWGFX_NUM_GB_SURFACE +\
VMWGFX_NUM_GB_SCREEN_TARGET)
-#define VMW_PL_GMR (TTM_PL_PRIV + 0)
-#define VMW_PL_MOB (TTM_PL_PRIV + 1)
+#define VMW_PL_GMR (TTM_PL_PRIV + 0)
+#define VMW_PL_MOB (TTM_PL_PRIV + 1)
+#define VMW_PL_SYSTEM (TTM_PL_PRIV + 2)
#define VMW_RES_CONTEXT ttm_driver_type0
#define VMW_RES_SURFACE ttm_driver_type1
@@ -1039,7 +1040,6 @@ extern struct ttm_placement vmw_vram_placement;
extern struct ttm_placement vmw_vram_sys_placement;
extern struct ttm_placement vmw_vram_gmr_placement;
extern struct ttm_placement vmw_sys_placement;
-extern struct ttm_placement vmw_evictable_placement;
extern struct ttm_placement vmw_srf_placement;
extern struct ttm_placement vmw_mob_placement;
extern struct ttm_placement vmw_nonfixed_placement;
@@ -1251,6 +1251,12 @@ int vmw_overlay_num_free_overlays(struct vmw_private
*dev_priv);
[PATCH 3/5] drm/vmwgfx: Fail to initialize on broken configs
Some of our hosts have a bug where rescaning a pci bus results in stale
fifo memory being mapped on the host. This makes any fifo communication
impossible resulting in various kernel crashes.
Instead of unexpectedly crashing, predictably fail to load the driver
which will preserve the system.
Fixes: fb1d9738ca05 ("drm/vmwgfx: Add DRM driver for VMware Virtual GPU")
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
index 67db472d3493..a3bfbb6c3e14 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c
@@ -145,6 +145,13 @@ struct vmw_fifo_state *vmw_fifo_create(struct vmw_private
*dev_priv)
(unsigned int) max,
(unsigned int) min,
(unsigned int) fifo->capabilities);
+
+ if (unlikely(min >= max)) {
+ drm_warn(_priv->drm,
+"FIFO memory is not usable. Driver failed to
initialize.");
+ return ERR_PTR(-ENXIO);
+ }
+
return fifo;
}
--
2.30.2
[PATCH 2/5] drm/vmwgfx: Release ttm memory if probe fails
The ttm mem global state was leaking if the vmwgfx driver load failed.
In case of a driver load failure we have to make sure we also release
the ttm mem global state.
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 26 --
1 file changed, 16 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index ab9a1750e1df..8d0b083ba267 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1617,34 +1617,40 @@ static int vmw_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, );
if (ret)
- return ret;
+ goto out_error;
ret = pcim_enable_device(pdev);
if (ret)
- return ret;
+ goto out_error;
vmw = devm_drm_dev_alloc(>dev, ,
struct vmw_private, drm);
- if (IS_ERR(vmw))
- return PTR_ERR(vmw);
+ if (IS_ERR(vmw)) {
+ ret = PTR_ERR(vmw);
+ goto out_error;
+ }
pci_set_drvdata(pdev, >drm);
ret = ttm_mem_global_init(_mem_glob, >dev);
if (ret)
- return ret;
+ goto out_error;
ret = vmw_driver_load(vmw, ent->device);
if (ret)
- return ret;
+ goto out_release;
ret = drm_dev_register(>drm, 0);
- if (ret) {
- vmw_driver_unload(>drm);
- return ret;
- }
+ if (ret)
+ goto out_unload;
return 0;
+out_unload:
+ vmw_driver_unload(>drm);
+out_release:
+ ttm_mem_global_release(_mem_glob);
+out_error:
+ return ret;
}
static int __init vmwgfx_init(void)
--
2.30.2
[PATCH 1/5] drm/vmwgfx: Remove the deprecated lower mem limit
TTM during the transition to the new page allocator lost the ability
to constrain the allocations via the lower_mem_limit. The code has
been unused since the change:
256dd44bd897 ("drm/ttm: nuke old page allocator")
and there's no reason to keep it.
Fixes: 256dd44bd897 ("drm/ttm: nuke old page allocator")
Signed-off-by: Zack Rusin
Reviewed-by: Martin Krastev
---
drivers/gpu/drm/vmwgfx/ttm_memory.c | 99 +
drivers/gpu/drm/vmwgfx/ttm_memory.h | 6 +-
2 files changed, 2 insertions(+), 103 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/ttm_memory.c
b/drivers/gpu/drm/vmwgfx/ttm_memory.c
index edd17c30d5a5..2ced4c06ca45 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_memory.c
+++ b/drivers/gpu/drm/vmwgfx/ttm_memory.c
@@ -34,7 +34,6 @@
#include
#include
#include
-#include
#include
#include
@@ -173,69 +172,7 @@ static struct kobj_type ttm_mem_zone_kobj_type = {
.sysfs_ops = _mem_zone_ops,
.default_attrs = ttm_mem_zone_attrs,
};
-
-static struct attribute ttm_mem_global_lower_mem_limit = {
- .name = "lower_mem_limit",
- .mode = S_IRUGO | S_IWUSR
-};
-
-static ssize_t ttm_mem_global_show(struct kobject *kobj,
-struct attribute *attr,
-char *buffer)
-{
- struct ttm_mem_global *glob =
- container_of(kobj, struct ttm_mem_global, kobj);
- uint64_t val = 0;
-
- spin_lock(>lock);
- val = glob->lower_mem_limit;
- spin_unlock(>lock);
- /* convert from number of pages to KB */
- val <<= (PAGE_SHIFT - 10);
- return snprintf(buffer, PAGE_SIZE, "%llu\n",
- (unsigned long long) val);
-}
-
-static ssize_t ttm_mem_global_store(struct kobject *kobj,
- struct attribute *attr,
- const char *buffer,
- size_t size)
-{
- int chars;
- uint64_t val64;
- unsigned long val;
- struct ttm_mem_global *glob =
- container_of(kobj, struct ttm_mem_global, kobj);
-
- chars = sscanf(buffer, "%lu", );
- if (chars == 0)
- return size;
-
- val64 = val;
- /* convert from KB to number of pages */
- val64 >>= (PAGE_SHIFT - 10);
-
- spin_lock(>lock);
- glob->lower_mem_limit = val64;
- spin_unlock(>lock);
-
- return size;
-}
-
-static struct attribute *ttm_mem_global_attrs[] = {
- _mem_global_lower_mem_limit,
- NULL
-};
-
-static const struct sysfs_ops ttm_mem_global_ops = {
- .show = _mem_global_show,
- .store = _mem_global_store,
-};
-
-static struct kobj_type ttm_mem_glob_kobj_type = {
- .sysfs_ops = _mem_global_ops,
- .default_attrs = ttm_mem_global_attrs,
-};
+static struct kobj_type ttm_mem_glob_kobj_type = {0};
static bool ttm_zones_above_swap_target(struct ttm_mem_global *glob,
bool from_wq, uint64_t extra)
@@ -435,11 +372,6 @@ int ttm_mem_global_init(struct ttm_mem_global *glob,
struct device *dev)
si_meminfo();
- spin_lock(>lock);
- /* set it as 0 by default to keep original behavior of OOM */
- glob->lower_mem_limit = 0;
- spin_unlock(>lock);
-
ret = ttm_mem_init_kernel_zone(glob, );
if (unlikely(ret != 0))
goto out_no_zone;
@@ -527,35 +459,6 @@ void ttm_mem_global_free(struct ttm_mem_global *glob,
}
EXPORT_SYMBOL(ttm_mem_global_free);
-/*
- * check if the available mem is under lower memory limit
- *
- * a. if no swap disk at all or free swap space is under swap_mem_limit
- * but available system mem is bigger than sys_mem_limit, allow TTM
- * allocation;
- *
- * b. if the available system mem is less than sys_mem_limit but free
- * swap disk is bigger than swap_mem_limit, allow TTM allocation.
- */
-bool
-ttm_check_under_lowerlimit(struct ttm_mem_global *glob,
- uint64_t num_pages,
- struct ttm_operation_ctx *ctx)
-{
- int64_t available;
-
- /* We allow over commit during suspend */
- if (ctx->force_alloc)
- return false;
-
- available = get_nr_swap_pages() + si_mem_available();
- available -= num_pages;
- if (available < glob->lower_mem_limit)
- return true;
-
- return false;
-}
-
static int ttm_mem_global_reserve(struct ttm_mem_global *glob,
struct ttm_mem_zone *single_zone,
uint64_t amount, bool reserve)
diff --git a/drivers/gpu/drm/vmwgfx/ttm_memory.h
b/drivers/gpu/drm/vmwgfx/ttm_memory.h
index c50dba774485..7b0d617ebcb1 100644
--- a/drivers/gpu/drm/vmwgfx/ttm_memory.h
+++ b/drivers/gpu/drm/vmwgfx/ttm_memory.h
@@ -50,8 +50,6 @@
* @work: The workqueue callback for the shrink queue.
* @lock: Lock to protect the @shrink - and the memory accounting members,
* that is, essentially the whole
[PATCH 0/5] drm/vmwgfx: Support module unload and hotunplug
This is a largely trivial set that makes vmwgfx support module reload and PCI hot-unplug. It also makes IGT's core_hotunplug pass instead of kernel oops'ing. The one "ugly" change is the "Introduce a new placement for MOB page tables". It seems vmwgfx has been violating a TTM assumption that TTM_PL_SYSTEM buffers are never fenced for a while. Apart from a kernel oops on module unload it didn't seem to wreak too much havoc, but we shouldn't be abusing TTM. So to solve it we're introducing a new placement, which is basically system, but can deal with fenced bo's. Cc: Christian König Cc: Thomas Hellström Zack Rusin (5): drm/vmwgfx: Remove the deprecated lower mem limit drm/vmwgfx: Release ttm memory if probe fails drm/vmwgfx: Fail to initialize on broken configs drm/vmwgfx: Introduce a new placement for MOB page tables drm/vmwgfx: Switch the internal BO's to ttm_bo_type_kernel drivers/gpu/drm/vmwgfx/Makefile | 2 +- drivers/gpu/drm/vmwgfx/ttm_memory.c | 99 +-- drivers/gpu/drm/vmwgfx/ttm_memory.h | 6 +- drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_cmd.c | 7 ++ drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 40 +--- drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 12 ++- .../gpu/drm/vmwgfx/vmwgfx_system_manager.c| 90 + drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 58 +-- 9 files changed, 164 insertions(+), 152 deletions(-) create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_system_manager.c -- 2.30.2
Re: [PATCH 12/26] drm/i915/guc: Implement multi-lrc submission
On 10/4/2021 15:06, Matthew Brost wrote:
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of all the contexts in the multi-lrc submission, and updates
these values simultaneously. As such, the tasklet and bypass path have
been updated to coalesce requests into a single submission.
v2:
(John Harrison)
- s/wqe/wqi
- Use FIELD_PREP macros
- Add GEM_BUG_ONs ensures length fits within field
- Add comment / white space to intel_guc_write_barrier
(Kernel test robot)
- Make need_tasklet a static function
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c| 26 ++
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 23 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 319 --
drivers/gpu/drm/i915/i915_request.h | 8 +
6 files changed, 335 insertions(+), 73 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 8f8182bf7c11..7191e8439290 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -756,3 +756,29 @@ void intel_guc_load_status(struct intel_guc *guc, struct
drm_printer *p)
}
}
}
+
+void intel_guc_write_barrier(struct intel_guc *guc)
+{
+ struct intel_gt *gt = guc_to_gt(guc);
+
+ if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
+ /*
+* Ensure intel_uncore_write_fw can be used rather than
+* intel_uncore_write.
+*/
+ GEM_BUG_ON(guc->send_regs.fw_domains);
+
+ /*
+* This register is used by the i915 and GuC for MMIO based
+* communication. Once we are in this code CTBs are the only
+* method the i915 uses to communicate with the GuC so it is
+* safe to write to this register (a value of 0 is NOP for MMIO
+* communication). If we ever start mixing CTBs and MMIOs a new
+* register will have to be chosen.
+*/
Hmm, missed it before but this comment is very CTB centric and the
barrier function is now being used for parallel submission work queues.
Seems like an extra comment should be added to cover that case. Just
something simple about WQ usage is also guaranteed to be post CTB switch
over.
+ intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
+ } else {
+ /* wmb() sufficient for a barrier if in smem */
+ wmb();
+ }
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index a9f4ec972bfb..147f39cc0f2f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -46,6 +46,12 @@ struct intel_guc {
* submitted until the stalled request is processed.
*/
struct i915_request *stalled_request;
+ enum {
+ STALL_NONE,
+ STALL_REGISTER_CONTEXT,
+ STALL_MOVE_LRC_TAIL,
+ STALL_ADD_REQUEST,
+ } submission_stall_reason;
/* intel_guc_recv interrupt related state */
/** @irq_lock: protects GuC irq state */
@@ -361,4 +367,6 @@ void intel_guc_submission_cancel_requests(struct intel_guc
*guc);
void intel_guc_load_status(struct intel_guc *guc, struct drm_printer *p);
+void intel_guc_write_barrier(struct intel_guc *guc);
+
#endif
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 20c710a74498..10d1878d2826 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -377,28 +377,6 @@ static u32 ct_get_next_fence(struct intel_guc_ct *ct)
return ++ct->requests.last_fence;
}
-static void write_barrier(struct intel_guc_ct *ct)
-{
- struct intel_guc *guc = ct_to_guc(ct);
- struct intel_gt *gt = guc_to_gt(guc);
-
- if (i915_gem_object_is_lmem(guc->ct.vma->obj)) {
- GEM_BUG_ON(guc->send_regs.fw_domains);
- /*
-* This register is used by the i915 and GuC for MMIO based
-* communication. Once we are in this code CTBs are the only
-* method the i915 uses to communicate with the GuC so it is
-* safe to write to this register (a value of 0 is NOP for MMIO
-* communication). If we ever start mixing CTBs and MMIOs a new
-* register will have to be chosen.
-*/
- intel_uncore_write_fw(gt->uncore, GEN11_SOFT_SCRATCH(0), 0);
- } else {
- /* wmb() sufficient for a barrier if in smem */
- wmb();
- }
-}
-
static int ct_write(struct
Re: [Intel-gfx] [PATCH 08/26] drm/i915/guc: Add multi-lrc context registration
On 10/7/2021 12:50, John Harrison wrote:
On 10/4/2021 15:06, Matthew Brost wrote:
Add multi-lrc context registration H2G. In addition a workqueue and
process descriptor are setup during multi-lrc context registration as
these data structures are needed for multi-lrc submission.
v2:
(John Harrison)
- Move GuC specific fields into sub-struct
- Clean up WQ defines
- Add comment explaining math to derive WQ / PD address
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 12 ++
drivers/gpu/drm/i915/gt/intel_lrc.c | 5 +
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 2 -
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 114 +-
5 files changed, 131 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 76dfca57cb45..48decb5ee954 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -239,6 +239,18 @@ struct intel_context {
struct intel_context *parent;
/** @number_children: number of children if parent */
u8 number_children;
+ /** @guc: GuC specific members for parallel submission */
+ struct {
+ /** @wqi_head: head pointer in work queue */
+ u16 wqi_head;
+ /** @wqi_tail: tail pointer in work queue */
+ u16 wqi_tail;
PS: As per comments on previous rev, something somewhere needs to
explicitly state what WQI means. One suggestion was to do that here,
ideally with maybe a brief description of what the queue is, how it is
used, etc. Although probably it would be better kept in a GuC specific
file. E.g. added to guc_fwif.h in patch #12.
John.
+ /**
+ * @parent_page: page in context state (ce->state) used
+ * by parent for work queue, process descriptor
+ */
+ u8 parent_page;
+ } guc;
} parallel;
#ifdef CONFIG_DRM_I915_SELFTEST
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 3ef9eaf8c50e..57339d5c1fc8 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -942,6 +942,11 @@ __lrc_alloc_state(struct intel_context *ce,
struct intel_engine_cs *engine)
context_size += PAGE_SIZE;
}
+ if (intel_context_is_parent(ce) &&
intel_engine_uses_guc(engine)) {
+ ce->parallel.guc.parent_page = context_size / PAGE_SIZE;
+ context_size += PAGE_SIZE;
+ }
+
obj = i915_gem_object_create_lmem(engine->i915, context_size,
I915_BO_ALLOC_PM_VOLATILE);
if (IS_ERR(obj))
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 8ff58aff..ba10bd374cee 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -142,6 +142,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
INTEL_GUC_ACTION_DEREGISTER_CONTEXT_DONE = 0x4600,
+ INTEL_GUC_ACTION_REGISTER_CONTEXT_MULTI_LRC = 0x4601,
INTEL_GUC_ACTION_RESET_CLIENT = 0x5507,
INTEL_GUC_ACTION_LIMIT
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index fa4be13c8854..0eeb2a9feeed 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -52,8 +52,6 @@
#define GUC_DOORBELL_INVALID 256
-#define GUC_WQ_SIZE (PAGE_SIZE * 2)
-
/* Work queue item header definitions */
#define WQ_STATUS_ACTIVE 1
#define WQ_STATUS_SUSPENDED 2
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 451d9ae861a6..ab6d7fc1b0b1 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -344,6 +344,45 @@ static inline struct i915_priolist
*to_priolist(struct rb_node *rb)
return rb_entry(rb, struct i915_priolist, node);
}
+/*
+ * When using multi-lrc submission an extra page in the context
state is
+ * reserved for the process descriptor and work queue.
+ *
+ * The layout of this page is below:
+ * 0 guc_process_desc
+ * ... unused
+ * PAGE_SIZE / 2 work queue start
+ * ... work queue
+ * PAGE_SIZE - 1 work queue end
+ */
+#define WQ_SIZE (PAGE_SIZE / 2)
+#define WQ_OFFSET (PAGE_SIZE - WQ_SIZE)
I thought you were going with '#define PARENT_SCRATCH SIZE PAGE_SIZE'
and then using that everywhere else? Unless there is a fundamental
reason why the above must
Re: [git pull] drm fixes for 5.15-rc5
The pull request you sent on Fri, 8 Oct 2021 13:42:41 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2021-10-08 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/0068dc8c96688b72cc99470530b384429129950c Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
Re: [PATCH] drm/msm/dp: Shorten SETUP timeout
On Fri 08 Oct 09:07 PDT 2021, khs...@codeaurora.org wrote: > On 2021-10-07 15:34, Stephen Boyd wrote: > > Quoting khs...@codeaurora.org (2021-10-07 13:28:12) > > > On 2021-10-07 13:06, Bjorn Andersson wrote: > > > > On Thu 07 Oct 12:51 PDT 2021, khs...@codeaurora.org wrote: > > > > > > > >> On 2021-10-06 10:31, Bjorn Andersson wrote: > > > >> > On Wed 06 Oct 08:37 PDT 2021, khs...@codeaurora.org wrote: > > > >> > > > > >> > > On 2021-10-05 19:10, Bjorn Andersson wrote: > > > >> > > > On Tue 05 Oct 16:04 PDT 2021, khs...@codeaurora.org wrote: > > > >> > > > > > > >> > > > > On 2021-10-05 15:36, Stephen Boyd wrote: > > > >> > > > > > Quoting Bjorn Andersson (2021-10-05 14:40:38) > > > >> > > > > > > On Tue 05 Oct 11:45 PDT 2021, Stephen Boyd wrote: > > > >> > > > > > > > > > >> > > > > > > > Quoting Bjorn Andersson (2021-10-04 19:37:50) > > > >> > > > > > > > > Found in the middle of a patch from Sankeerth was the > > > >> > > > > > > > > reduction of the > > > >> > > > > > > > > INIT_SETUP timeout from 10s to 100ms. Upon INIT_SETUP > > > >> > > > > > > > > timeout the host > > > >> > > > > > > > > is initalized and HPD interrupt start to be serviced, > > > >> > > > > > > > > so in the case of > > > >> > > > > > > > > eDP this reduction improves the user experience > > > >> > > > > > > > > dramatically - i.e. > > > >> > > > > > > > > removes 9.9s of bland screen time at boot. > > > >> > > > > > > > > > > > >> > > > > > > > > Suggested-by: Sankeerth Billakanti > > > >> > > > > > > > > > > > >> > > > > > > > > Signed-off-by: Bjorn Andersson > > > >> > > > > > > > > > > > >> > > > > > > > > --- > > > >> > > > > > > > > > > >> > > > > > > > Any Fixes tag? BTW, the delay design is pretty > > > >> > > > > > > > convoluted. I had to go > > > >> > > > > > > > re-read the code a couple times to understand that it's > > > >> > > > > > > > waiting 100ms > > > >> > > > > > > > times the 'delay' number. What? > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > I assume you're happy with the current 10s delay on the > > > >> > > > > > > current > > > >> > > > > > > devices, so I don't think we should push for this to be > > > >> > > > > > > backported. > > > >> > > > > > > I have no need for it to be backported on my side at least. > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > Sure. Fixes tag != backported to stable trees but it is > > > >> > > > > > close. > > > >> > > > > > > > > >> > > > > > > > Reviewed-by: Stephen Boyd > > > >> > > > > > > > > > >> > > > > dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 1); <== to 100ms > > > >> > > > > > > > >> > > > > This patch will prevent usb3 from working due to dp driver > > > >> > > > > initialize phy > > > >> > > > > earlier than usb3 which cause timeout error at power up usb3 > > > >> > > > > phy > > > >> > > > > when both > > > >> > > > > edp and dp are enabled. > > > >> > > > > > > >> > > > Can you please help me understand what you mean here, I use this > > > >> > > > on my > > > >> > > > sc8180x with both eDP and USB-C/DP right now. What is it that > > > >> > > > doesn't > > > >> > > > work? Or am I just lucky in some race condition? > > > >> > > > > > > >> > > > Thanks, > > > >> > > > Bjorn > > > >> > > > > > > >> > > The problem is seen at sc7280. > > > >> > > Apple dongle have both hdmi and usb port. > > > >> > > plug Apple dongle into type-c, then plug DP into apple's hdmi port > > > >> > > and usb > > > >> > > mouse into apple's usb port. > > > >> > > If edp enabled at this time, then usb mouse will not work due to > > > >> > > timeout at > > > >> > > phy power up. > > > >> > > > > > >> > > > > >> > Okay, so you're saying that if the DP driver invokes phy_power_on() > > > >> > before the USB driver does, USB initialization fails (or at least USB > > > >> > doesn't work)? > > > >> > > > >> if dp driver call qcom_qmp_phy_init() before usb3 call > > > >> qcom_qmp_phy_init(), > > > >> usb3 driver will timeout at readl_poll_timeout(status, val, (val & > > > >> mask) == > > > >> ready, 10, PHY_INIT_COMPLETE_TIMEOUT) of qcom_qmp_phy_power_on(). > > > > > > > > Thanks, I will try to reproduce this on my side. So the 10 seconds here > > > > is strictly to give good enough time for the dwc3 driver to probe... > > > > > > > > Any idea why you're saying that this is specific to sc7280, what > > > > changed > > > > from sc7180? > > > > > > I did not have sc7180 with edp before so that i am not sure it will > > > happen on sc7180 or not. > > > The usb3 does not work when both edp and dp enabled I just seen at > > > sc7280. > > > Current at sc7280 EC is not boot up correctly when system power up. > > > I have to manual reboot EC from linux kernel shell before DP/usb3 can > > > work. > > > I am not sure this contribute to this problem or not. > > > > > > > Can you make the usb driver into a module and only load that module > > later in boot after the DP driver calls qcom_qmp_phy_init()? That would > > be an easy way to move usb probe
Re: [Intel-gfx] [PATCH v3] drm/i915/gt: move remaining debugfs interfaces into gt
On Fri, Oct 08, 2021 at 01:27:33PM +0200, Andi Shyti wrote:
> +
> + if (IS_CHERRYVIEW(i915)) {
> + seq_printf(m, "Master Interrupt Control:\t%08x\n",
> +intel_uncore_read(uncore, GEN8_MASTER_IRQ));
> +
> + for (i = 0; i < 4; i++) {
> + seq_printf(m, "GT Interrupt IMR %d:\t%08x\n",
> +i, intel_uncore_read(uncore,
> + GEN8_GT_IMR(i)));
> + seq_printf(m, "GT Interrupt IIR %d:\t%08x\n",
> +i, intel_uncore_read(uncore,
> + GEN8_GT_IIR(i)));
> + seq_printf(m, "GT Interrupt IER %d:\t%08x\n",
> +i, intel_uncore_read(uncore,
> + GEN8_GT_IER(i)));
> + }
> +
Why does chv get its own block? Looks identical to the bdw block.
> + } else if (GRAPHICS_VER(i915) >= 11) {
> + seq_printf(m, "Master Interrupt Control: %08x\n",
> +intel_uncore_read(uncore, GEN11_GFX_MSTR_IRQ));
> +
> + seq_printf(m, "Render/Copy Intr Enable: %08x\n",
> +intel_uncore_read(uncore,
> + GEN11_RENDER_COPY_INTR_ENABLE));
> + seq_printf(m, "VCS/VECS Intr Enable: %08x\n",
> +intel_uncore_read(uncore,
> + GEN11_VCS_VECS_INTR_ENABLE));
> + seq_printf(m, "GUC/SG Intr Enable:\t %08x\n",
> +intel_uncore_read(uncore,
> + GEN11_GUC_SG_INTR_ENABLE));
> + seq_printf(m, "GPM/WGBOXPERF Intr Enable: %08x\n",
> +intel_uncore_read(uncore,
> + GEN11_GPM_WGBOXPERF_INTR_ENABLE));
> + seq_printf(m, "Crypto Intr Enable:\t %08x\n",
> +intel_uncore_read(uncore,
> + GEN11_CRYPTO_RSVD_INTR_ENABLE));
> + seq_printf(m, "GUnit/CSME Intr Enable:\t %08x\n",
> +intel_uncore_read(uncore,
> + GEN11_GUNIT_CSME_INTR_ENABLE));
> +
> + } else if (GRAPHICS_VER(i915) >= 8) {
> + seq_printf(m, "Master Interrupt Control:\t%08x\n",
> +intel_uncore_read(uncore, GEN8_MASTER_IRQ));
> +
> + for (i = 0; i < 4; i++) {
> + seq_printf(m, "GT Interrupt IMR %d:\t%08x\n",
> +i, intel_uncore_read(uncore,
> + GEN8_GT_IMR(i)));
> + seq_printf(m, "GT Interrupt IIR %d:\t%08x\n",
> +i, intel_uncore_read(uncore,
> + GEN8_GT_IIR(i)));
> + seq_printf(m, "GT Interrupt IER %d:\t%08x\n",
> +i, intel_uncore_read(uncore,
> + GEN8_GT_IER(i)));
> + }
> +
> + } else if (IS_VALLEYVIEW(i915)) {
> + seq_printf(m, "Master IER:\t%08x\n",
> +intel_uncore_read(uncore, VLV_MASTER_IER));
> +
> + seq_printf(m, "Render IER:\t%08x\n",
> +intel_uncore_read(uncore, GTIER));
> + seq_printf(m, "Render IIR:\t%08x\n",
> +intel_uncore_read(uncore, GTIIR));
> + seq_printf(m, "Render IMR:\t%08x\n",
> +intel_uncore_read(uncore, GTIMR));
> +
> + seq_printf(m, "PM IER:\t\t%08x\n",
> +intel_uncore_read(uncore, GEN6_PMIER));
> + seq_printf(m, "PM IIR:\t\t%08x\n",
> +intel_uncore_read(uncore, GEN6_PMIIR));
> + seq_printf(m, "PM IMR:\t\t%08x\n",
> +intel_uncore_read(uncore, GEN6_PMIMR));
> +
> + } else if (!HAS_PCH_SPLIT(i915)) {
HAS_PCH_SPLIT in gt code looks a bit out of place.
> + seq_printf(m, "Interrupt enable:%08x\n",
> +intel_uncore_read(uncore, GEN2_IER));
> + seq_printf(m, "Interrupt identity: %08x\n",
> +intel_uncore_read(uncore, GEN2_IIR));
> + seq_printf(m, "Interrupt mask: %08x\n",
> +intel_uncore_read(uncore, GEN2_IMR));
Technically on gen2 these are 16 bits, on gen3+ 32 bits. I don't
quite remember now what happens when you read them as 32bit on gen2.
Might be the msbs just come out all zeroes.
> + } else {
> + seq_printf(m, "Graphics Interrupt enable: %08x\n",
> +intel_uncore_read(uncore, GTIER));
> + seq_printf(m, "Graphics Interrupt identity:
Re: [PATCH 10/26] drm/i915/guc: Assign contexts in parent-child relationship consecutive guc_ids
On 10/7/2021 18:21, Matthew Brost wrote:
On Thu, Oct 07, 2021 at 03:03:04PM -0700, John Harrison wrote:
On 10/4/2021 15:06, Matthew Brost wrote:
Assign contexts in parent-child relationship consecutive guc_ids. This
is accomplished by partitioning guc_id space between ones that need to
be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
available guc_ids). The consecutive search is implemented via the bitmap
API.
This is a precursor to the full GuC multi-lrc implementation but aligns
to how GuC mutli-lrc interface is defined - guc_ids must be consecutive
when using the GuC multi-lrc interface.
v2:
(Daniel Vetter)
- Explicitly state why we assign consecutive guc_ids
v3:
(John Harrison)
- Bring back in spin lock
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 6 +-
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 104 ++
2 files changed, 86 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 25a598e2b6e8..a9f4ec972bfb 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -76,9 +76,13 @@ struct intel_guc {
*/
spinlock_t lock;
/**
-* @guc_ids: used to allocate new guc_ids
+* @guc_ids: used to allocate new guc_ids, single-lrc
*/
struct ida guc_ids;
+ /**
+* @guc_ids_bitmap: used to allocate new guc_ids, multi-lrc
+*/
+ unsigned long *guc_ids_bitmap;
/**
* @guc_id_list: list of intel_context with valid guc_ids but no
* refs
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 1f2809187513..79e7732e83b2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -128,6 +128,16 @@ guc_create_virtual(struct intel_engine_cs **siblings,
unsigned int count);
#define GUC_REQUEST_SIZE 64 /* bytes */
+/*
+ * We reserve 1/16 of the guc_ids for multi-lrc as these need to be contiguous
+ * per the GuC submission interface. A different allocation algorithm is used
+ * (bitmap vs. ida) between multi-lrc and single-lrc hence the reason to
+ * partition the guc_id space. We believe the number of multi-lrc contexts in
+ * use should be low and 1/16 should be sufficient. Minimum of 32 guc_ids for
+ * multi-lrc.
+ */
+#define NUMBER_MULTI_LRC_GUC_ID(GUC_MAX_LRC_DESCRIPTORS / 16)
+
/*
* Below is a set of functions which control the GuC scheduling state which
* require a lock.
@@ -1206,6 +1216,11 @@ int intel_guc_submission_init(struct intel_guc *guc)
INIT_WORK(>submission_state.destroyed_worker,
destroyed_worker_func);
+ guc->submission_state.guc_ids_bitmap =
+ bitmap_zalloc(NUMBER_MULTI_LRC_GUC_ID, GFP_KERNEL);
+ if (!guc->submission_state.guc_ids_bitmap)
+ return -ENOMEM;
+
return 0;
}
@@ -1217,6 +1232,7 @@ void intel_guc_submission_fini(struct intel_guc *guc)
guc_lrc_desc_pool_destroy(guc);
guc_flush_destroyed_contexts(guc);
i915_sched_engine_put(guc->sched_engine);
+ bitmap_free(guc->submission_state.guc_ids_bitmap);
}
static inline void queue_request(struct i915_sched_engine *sched_engine,
@@ -1268,18 +1284,43 @@ static void guc_submit_request(struct i915_request *rq)
spin_unlock_irqrestore(_engine->lock, flags);
}
-static int new_guc_id(struct intel_guc *guc)
+static int new_guc_id(struct intel_guc *guc, struct intel_context *ce)
{
- return ida_simple_get(>submission_state.guc_ids, 0,
- GUC_MAX_LRC_DESCRIPTORS, GFP_KERNEL |
- __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
+ int ret;
+
+ GEM_BUG_ON(intel_context_is_child(ce));
+
+ if (intel_context_is_parent(ce))
+ ret =
bitmap_find_free_region(guc->submission_state.guc_ids_bitmap,
+ NUMBER_MULTI_LRC_GUC_ID,
+
order_base_2(ce->parallel.number_children
+ + 1));
+ else
+ ret = ida_simple_get(>submission_state.guc_ids,
+NUMBER_MULTI_LRC_GUC_ID,
+GUC_MAX_LRC_DESCRIPTORS,
+GFP_KERNEL | __GFP_RETRY_MAYFAIL |
+__GFP_NOWARN);
+ if (unlikely(ret < 0))
+ return ret;
+
+ ce->guc_id.id = ret;
+ return 0;
}
static void __release_guc_id(struct intel_guc *guc, struct intel_context *ce)
{
+ GEM_BUG_ON(intel_context_is_child(ce));
+
[PATCH v2] drm/i915/gt: move remaining debugfs interfaces into gt
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
+-- interrupt_info
|
\-- reset
For backwards compatibility with existing igt (and the slight
semantic difference between operating on the i915 abi entry
points and the deep gt info):
dri/0
|
+-- i915_wedged
|
\-- i915_forcewake_user
remain at the top level.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
Hi,
I am reproposing this patch exactly as it was proposed initially
where the original interfaces are kept where they have been
originally placed. It might generate some duplicated code but,
well, it's debugfs and I don't see any issue. In the future we
can transform the upper interfaces to act upon all the GTs and
provide information from all the GTs. This is, for example, how
the sysfs interfaces will act.
The reason I removed them in V1 is because igt as only user is
not a strong reason to keep duplicated code, but as Chris
suggested offline:
"It's debugfs, igt is the primary consumer. CI has to be bridged over
changes to the interfaces it is using in any case, as you want
comparable results before/after the patches land.
For i915_forcewake_user, it's not just igt testing, but part of the
tools/ packaged up by distro. That makes it a very strong candidate to be
moved out of debugfs into sysfs/gt."
I, therefore, repropose this patch with the idea of improving the
behavior of the upper level interfaces as described above.
Thanks,
Andi
Changelog:
--
v1 -> v2:
* keep the original interfaces intact (thanks Chris).
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 47 -
.../gpu/drm/i915/gt/intel_gt_irq_debugfs.c| 178 ++
.../gpu/drm/i915/gt/intel_gt_irq_debugfs.h| 15 ++
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++
5 files changed, 271 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index cdc244bbbfc1..e92984954ba8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -98,6 +98,7 @@ gt-y += \
gt/intel_gt_debugfs.o \
gt/intel_gt_engines_debugfs.o \
gt/intel_gt_irq.o \
+ gt/intel_gt_irq_debugfs.o \
gt/intel_gt_pm.o \
gt/intel_gt_pm_debugfs.o \
gt/intel_gt_pm_irq.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index 1fe19ccd2794..d3075c138585 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -8,11 +8,54 @@
#include "i915_drv.h"
#include "intel_gt_debugfs.h"
#include "intel_gt_engines_debugfs.h"
+#include "intel_gt_irq_debugfs.h"
+#include "intel_gt_pm.h"
#include "intel_gt_pm_debugfs.h"
+#include "intel_gt_requests.h"
#include "intel_sseu_debugfs.h"
#include "pxp/intel_pxp_debugfs.h"
#include "uc/intel_uc_debugfs.h"
+static int reset_show(void *data, u64 *val)
+{
+ struct intel_gt *gt = data;
+ int ret = intel_gt_terminally_wedged(gt);
+
+ switch (ret) {
+ case -EIO:
+ *val = 1;
+ return 0;
+ case 0:
+ *val = 0;
+ return 0;
+ default:
+ return ret;
+ }
+}
+
+static int reset_store(void *data, u64 val)
+{
+ struct intel_gt *gt = data;
+
+ /* Flush any previous reset before applying for a new one */
+ wait_event(gt->reset.queue,
+ !test_bit(I915_RESET_BACKOFF, >reset.flags));
+
+ intel_gt_handle_error(gt, val, I915_ERROR_CAPTURE,
+ "Manually reset engine mask to %llx", val);
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(reset_fops, reset_show, reset_store, "%llu\n");
+
+static void gt_debugfs_register(struct intel_gt *gt, struct dentry *root)
+{
+ static const struct intel_gt_debugfs_file files[] = {
+ { "reset", _fops, NULL },
+ };
+
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
+}
+
void intel_gt_debugfs_register(struct intel_gt *gt)
{
struct dentry *root;
@@ -24,10 +67,12 @@ void intel_gt_debugfs_register(struct intel_gt *gt)
if (IS_ERR(root))
return;
+ gt_debugfs_register(gt, root);
+
intel_gt_engines_debugfs_register(gt, root);
intel_gt_pm_debugfs_register(gt, root);
+ intel_gt_irq_debugfs_register(gt, root);
intel_sseu_debugfs_register(gt, root);
-
intel_uc_debugfs_register(>uc, root);
intel_pxp_debugfs_register(>pxp, root);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.c
Re: [PATCH] drm/msm/dp: Shorten SETUP timeout
On 2021-10-07 15:34, Stephen Boyd wrote: Quoting khs...@codeaurora.org (2021-10-07 13:28:12) On 2021-10-07 13:06, Bjorn Andersson wrote: > On Thu 07 Oct 12:51 PDT 2021, khs...@codeaurora.org wrote: > >> On 2021-10-06 10:31, Bjorn Andersson wrote: >> > On Wed 06 Oct 08:37 PDT 2021, khs...@codeaurora.org wrote: >> > >> > > On 2021-10-05 19:10, Bjorn Andersson wrote: >> > > > On Tue 05 Oct 16:04 PDT 2021, khs...@codeaurora.org wrote: >> > > > >> > > > > On 2021-10-05 15:36, Stephen Boyd wrote: >> > > > > > Quoting Bjorn Andersson (2021-10-05 14:40:38) >> > > > > > > On Tue 05 Oct 11:45 PDT 2021, Stephen Boyd wrote: >> > > > > > > >> > > > > > > > Quoting Bjorn Andersson (2021-10-04 19:37:50) >> > > > > > > > > Found in the middle of a patch from Sankeerth was the reduction of the >> > > > > > > > > INIT_SETUP timeout from 10s to 100ms. Upon INIT_SETUP timeout the host >> > > > > > > > > is initalized and HPD interrupt start to be serviced, so in the case of >> > > > > > > > > eDP this reduction improves the user experience dramatically - i.e. >> > > > > > > > > removes 9.9s of bland screen time at boot. >> > > > > > > > > >> > > > > > > > > Suggested-by: Sankeerth Billakanti >> > > > > > > > > Signed-off-by: Bjorn Andersson >> > > > > > > > > --- >> > > > > > > > >> > > > > > > > Any Fixes tag? BTW, the delay design is pretty convoluted. I had to go >> > > > > > > > re-read the code a couple times to understand that it's waiting 100ms >> > > > > > > > times the 'delay' number. What? >> > > > > > > > >> > > > > > > >> > > > > > > I assume you're happy with the current 10s delay on the current >> > > > > > > devices, so I don't think we should push for this to be backported. >> > > > > > > I have no need for it to be backported on my side at least. >> > > > > > > >> > > > > > >> > > > > > Sure. Fixes tag != backported to stable trees but it is close. >> > > > > > >> > > > > > > > Reviewed-by: Stephen Boyd >> > > > > > > >> > > > > dp_add_event(dp, EV_HPD_INIT_SETUP, 0, 1); <== to 100ms >> > > > > >> > > > > This patch will prevent usb3 from working due to dp driver >> > > > > initialize phy >> > > > > earlier than usb3 which cause timeout error at power up usb3 phy >> > > > > when both >> > > > > edp and dp are enabled. >> > > > >> > > > Can you please help me understand what you mean here, I use this on my >> > > > sc8180x with both eDP and USB-C/DP right now. What is it that doesn't >> > > > work? Or am I just lucky in some race condition? >> > > > >> > > > Thanks, >> > > > Bjorn >> > > > >> > > The problem is seen at sc7280. >> > > Apple dongle have both hdmi and usb port. >> > > plug Apple dongle into type-c, then plug DP into apple's hdmi port >> > > and usb >> > > mouse into apple's usb port. >> > > If edp enabled at this time, then usb mouse will not work due to >> > > timeout at >> > > phy power up. >> > > >> > >> > Okay, so you're saying that if the DP driver invokes phy_power_on() >> > before the USB driver does, USB initialization fails (or at least USB >> > doesn't work)? >> >> if dp driver call qcom_qmp_phy_init() before usb3 call >> qcom_qmp_phy_init(), >> usb3 driver will timeout at readl_poll_timeout(status, val, (val & >> mask) == >> ready, 10, PHY_INIT_COMPLETE_TIMEOUT) of qcom_qmp_phy_power_on(). > > Thanks, I will try to reproduce this on my side. So the 10 seconds here > is strictly to give good enough time for the dwc3 driver to probe... > > Any idea why you're saying that this is specific to sc7280, what > changed > from sc7180? I did not have sc7180 with edp before so that i am not sure it will happen on sc7180 or not. The usb3 does not work when both edp and dp enabled I just seen at sc7280. Current at sc7280 EC is not boot up correctly when system power up. I have to manual reboot EC from linux kernel shell before DP/usb3 can work. I am not sure this contribute to this problem or not. Can you make the usb driver into a module and only load that module later in boot after the DP driver calls qcom_qmp_phy_init()? That would be an easy way to move usb probe after DP probe and expose this problem. we need usb calls qcom_qmp_phy_init() before dp.
[PATCH v3] drm/i915/gt: move remaining debugfs interfaces into gt
From: Andi Shyti
The following interfaces:
i915_wedged
i915_forcewake_user
i915_gem_interrupt
are dependent on gt values. Put them inside gt/ and drop the
"i915_" prefix name. This would be the new structure:
dri/0/gt
|
+-- forcewake_user
|
+-- interrupt_info
|
\-- reset
For backwards compatibility with existing igt (and the slight
semantic difference between operating on the i915 abi entry
points and the deep gt info):
dri/0
|
+-- i915_wedged
|
\-- i915_forcewake_user
remain at the top level.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
Hi Lucas and Chris,
this third version tries to remove duplicated code, but roughly
the amount of code removed is equal to the amount of code added.
In my opinion it doesn't improve much the code. Amongst the three
versions I still prefer the v2.
Changelog:
--
v2 -> v3: https://patchwork.freedesktop.org/patch/458108/
* keep the original interfaces as they were (thanks Chris) but
implement the functionality inside the gt. The upper level
files will call the gt functions (thanks Lucas).
v1 -> v2: https://patchwork.freedesktop.org/patch/456652/
* keep the original interfaces intact (thanks Chris).
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 47 -
drivers/gpu/drm/i915/gt/intel_gt_debugfs.h| 4 +
.../gpu/drm/i915/gt/intel_gt_irq_debugfs.c| 178 ++
.../gpu/drm/i915/gt/intel_gt_irq_debugfs.h| 15 ++
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 41
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.h | 4 +
drivers/gpu/drm/i915/i915_debugfs.c | 43 +
8 files changed, 296 insertions(+), 37 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index cdc244bbbfc1..e92984954ba8 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -98,6 +98,7 @@ gt-y += \
gt/intel_gt_debugfs.o \
gt/intel_gt_engines_debugfs.o \
gt/intel_gt_irq.o \
+ gt/intel_gt_irq_debugfs.o \
gt/intel_gt_pm.o \
gt/intel_gt_pm_debugfs.o \
gt/intel_gt_pm_irq.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
index 1fe19ccd2794..0d651c33110d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
@@ -8,11 +8,54 @@
#include "i915_drv.h"
#include "intel_gt_debugfs.h"
#include "intel_gt_engines_debugfs.h"
+#include "intel_gt_irq_debugfs.h"
+#include "intel_gt_pm.h"
#include "intel_gt_pm_debugfs.h"
+#include "intel_gt_requests.h"
#include "intel_sseu_debugfs.h"
#include "pxp/intel_pxp_debugfs.h"
#include "uc/intel_uc_debugfs.h"
+int reset_show(void *data, u64 *val)
+{
+ struct intel_gt *gt = data;
+ int ret = intel_gt_terminally_wedged(gt);
+
+ switch (ret) {
+ case -EIO:
+ *val = 1;
+ return 0;
+ case 0:
+ *val = 0;
+ return 0;
+ default:
+ return ret;
+ }
+}
+
+int reset_store(void *data, u64 val)
+{
+ struct intel_gt *gt = data;
+
+ /* Flush any previous reset before applying for a new one */
+ wait_event(gt->reset.queue,
+ !test_bit(I915_RESET_BACKOFF, >reset.flags));
+
+ intel_gt_handle_error(gt, val, I915_ERROR_CAPTURE,
+ "Manually reset engine mask to %llx", val);
+ return 0;
+}
+DEFINE_SIMPLE_ATTRIBUTE(reset_fops, reset_show, reset_store, "%llu\n");
+
+static void gt_debugfs_register(struct intel_gt *gt, struct dentry *root)
+{
+ static const struct intel_gt_debugfs_file files[] = {
+ { "reset", _fops, NULL },
+ };
+
+ intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
+}
+
void intel_gt_debugfs_register(struct intel_gt *gt)
{
struct dentry *root;
@@ -24,10 +67,12 @@ void intel_gt_debugfs_register(struct intel_gt *gt)
if (IS_ERR(root))
return;
+ gt_debugfs_register(gt, root);
+
intel_gt_engines_debugfs_register(gt, root);
intel_gt_pm_debugfs_register(gt, root);
+ intel_gt_irq_debugfs_register(gt, root);
intel_sseu_debugfs_register(gt, root);
-
intel_uc_debugfs_register(>uc, root);
intel_pxp_debugfs_register(>pxp, root);
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
index 8b6fca09897c..6bc4f044c23f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.h
@@ -35,4 +35,8 @@ void intel_gt_debugfs_register_files(struct dentry *root,
const struct intel_gt_debugfs_file *files,
Re: DSI Bridge switching
On Fri, 8 Oct 2021 at 14:37, Laurent Pinchart wrote: > > Hello, > > On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote: > > Hi, > > > > Removed my invalid email (I will update files next week). > > > > On 08.10.2021 13:14, Jagan Teki wrote: > > > Hi, > > > > > > I think this seems to be a known use case for industrial these days with > > > i.mx8m. > > > > > > The host DSI would configure with two bridges one for DSI to LVDS > > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we > > > can use only one bridge at a time as host DSI support single out port. > > > So we can have two separate device tree files for LVDS and HDMI and > > > load them static. > > > > > > But, one of the use cases is to support both of them in single dts, and > > > - Turn On LVDS (default) > > > - Turn Off LVDS then Turn On HDMI when cable plug-in > > > > Are you sure it will work from hardware PoV? Do you have some demuxer? > > isolation of pins? > > It may be in the category of "you shouldn't do this, but it actually > works". I've seen the same being done with two CSI-2 camera sensors > connected to the same receiver, with one of them being held in reset at > all times. Surely the correct way to do this would be with a D-PHY mux chip such as OnSemi FSA642 [1] or those from Diodes Incorporated [2]. How you'd integrate such a mux into DRM is a totally different question. With V4L2 and CSI2 it'd be relatively simple via Media Controller. Just wiring them together isn't going to work very well for DSI reverse direction communication, but neither of the chips Jagan lists support this. Dave [1] https://www.onsemi.com/products/interfaces/analog-switches/fsa642 [2] https://www.diodes.com/products/connectivity-and-timing/switches-mux/protocol-switches/mipi-switches/ > > > The HDMI event can be detected via some HDMI-INT GPIO on-board design. > > > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on > > > port 2 in the DSI host node, and trying to attach the respective > > > bridge based on HDMI-INT like repeating the bridge attachment cycle > > > based on the HDMI-INT. > > > > I think more appropriate would be to share the same port, but provide > > two endpoints inside this port - we have two hardware sharing the same > > physical port. > > That sounds like the correct DT description to me. > > > > Can it be possible to do bridge attachment at runtime? something like > > > a bridge hotplug event? or any other possible solutions? > > > > > > Any suggestions? > > > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi + > > some toshiba bridge - panel and bridge are dynamically 'plugged' and > > 'unplugged' from exynos_drm, but they do not use bridge chain for this > > and some other reasons. (un|re|)plugging should be performed of course > > when pipeline is off (connector disconnected). I am not sure about > > bridges added to bridge chain - you need to inspect all opses to ensure > > it can be done safely. > > > > And the main issue: Daniel does not like it :) > > Neither do I :-) Could it be handled with two DRM connectors that are > mutually exclusive ? > > -- > Regards, > > Laurent Pinchart
Re: [PATCH v9] drm/bridge: add it6505 driver
Hey Allen, I was running the pre-merge checks, and hit some build issues. This was built against todays drm-misc-next branch, which I would like you to rebase your patch against. drivers/gpu/drm/bridge/ite-it6505.c: In function ‘it6505_bridge_atomic_enable’: drivers/gpu/drm/bridge/ite-it6505.c:2919:15: error: implicit declaration of function ‘drm_bridge_new_crtc_state’; did you mean ‘drm_atomic_get_new_crtc_state’? [-Werror=implicit-function-declaration] 2919 | crtc_state = drm_bridge_new_crtc_state(bridge, old_state); | ^ | drm_atomic_get_new_crtc_state drivers/gpu/drm/bridge/ite-it6505.c:2919:13: warning: assignment to ‘const struct drm_crtc_state *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 2919 | crtc_state = drm_bridge_new_crtc_state(bridge, old_state); | ^
Re: [PATCH v2] drm/i915/gt: move remaining debugfs interfaces into gt
Hi,
please ignore! I run the command from the history and forgot that
I had to update the patch file. :)
V3 of this patch is coming soon.
Andi
On Fri, Oct 08, 2021 at 01:22:48PM +0200, Andi Shyti wrote:
> From: Andi Shyti
>
> The following interfaces:
>
> i915_wedged
> i915_forcewake_user
> i915_gem_interrupt
>
> are dependent on gt values. Put them inside gt/ and drop the
> "i915_" prefix name. This would be the new structure:
>
> dri/0/gt
> |
> +-- forcewake_user
> |
> +-- interrupt_info
> |
> \-- reset
>
> For backwards compatibility with existing igt (and the slight
> semantic difference between operating on the i915 abi entry
> points and the deep gt info):
>
> dri/0
> |
> +-- i915_wedged
> |
> \-- i915_forcewake_user
>
> remain at the top level.
>
> Signed-off-by: Andi Shyti
> Cc: Tvrtko Ursulin
> Cc: Chris Wilson
> ---
> Hi,
>
> I am reproposing this patch exactly as it was proposed initially
> where the original interfaces are kept where they have been
> originally placed. It might generate some duplicated code but,
> well, it's debugfs and I don't see any issue. In the future we
> can transform the upper interfaces to act upon all the GTs and
> provide information from all the GTs. This is, for example, how
> the sysfs interfaces will act.
>
> The reason I removed them in V1 is because igt as only user is
> not a strong reason to keep duplicated code, but as Chris
> suggested offline:
>
> "It's debugfs, igt is the primary consumer. CI has to be bridged over
> changes to the interfaces it is using in any case, as you want
> comparable results before/after the patches land.
>
> For i915_forcewake_user, it's not just igt testing, but part of the
> tools/ packaged up by distro. That makes it a very strong candidate to be
> moved out of debugfs into sysfs/gt."
>
> I, therefore, repropose this patch with the idea of improving the
> behavior of the upper level interfaces as described above.
>
> Thanks,
> Andi
>
> Changelog:
> --
> v1 -> v2:
> * keep the original interfaces intact (thanks Chris).
>
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/gt/intel_gt_debugfs.c| 47 -
> .../gpu/drm/i915/gt/intel_gt_irq_debugfs.c| 178 ++
> .../gpu/drm/i915/gt/intel_gt_irq_debugfs.h| 15 ++
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 31 +++
> 5 files changed, 271 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.c
> create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_irq_debugfs.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index cdc244bbbfc1..e92984954ba8 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -98,6 +98,7 @@ gt-y += \
> gt/intel_gt_debugfs.o \
> gt/intel_gt_engines_debugfs.o \
> gt/intel_gt_irq.o \
> + gt/intel_gt_irq_debugfs.o \
> gt/intel_gt_pm.o \
> gt/intel_gt_pm_debugfs.o \
> gt/intel_gt_pm_irq.o \
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> index 1fe19ccd2794..d3075c138585 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_debugfs.c
> @@ -8,11 +8,54 @@
> #include "i915_drv.h"
> #include "intel_gt_debugfs.h"
> #include "intel_gt_engines_debugfs.h"
> +#include "intel_gt_irq_debugfs.h"
> +#include "intel_gt_pm.h"
> #include "intel_gt_pm_debugfs.h"
> +#include "intel_gt_requests.h"
> #include "intel_sseu_debugfs.h"
> #include "pxp/intel_pxp_debugfs.h"
> #include "uc/intel_uc_debugfs.h"
>
> +static int reset_show(void *data, u64 *val)
> +{
> + struct intel_gt *gt = data;
> + int ret = intel_gt_terminally_wedged(gt);
> +
> + switch (ret) {
> + case -EIO:
> + *val = 1;
> + return 0;
> + case 0:
> + *val = 0;
> + return 0;
> + default:
> + return ret;
> + }
> +}
> +
> +static int reset_store(void *data, u64 val)
> +{
> + struct intel_gt *gt = data;
> +
> + /* Flush any previous reset before applying for a new one */
> + wait_event(gt->reset.queue,
> +!test_bit(I915_RESET_BACKOFF, >reset.flags));
> +
> + intel_gt_handle_error(gt, val, I915_ERROR_CAPTURE,
> + "Manually reset engine mask to %llx", val);
> + return 0;
> +}
> +DEFINE_SIMPLE_ATTRIBUTE(reset_fops, reset_show, reset_store, "%llu\n");
> +
> +static void gt_debugfs_register(struct intel_gt *gt, struct dentry *root)
> +{
> + static const struct intel_gt_debugfs_file files[] = {
> + { "reset", _fops, NULL },
> + };
> +
> + intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
> +}
> +
> void intel_gt_debugfs_register(struct intel_gt *gt)
> {
> struct dentry *root;
> @@ -24,10 +67,12 @@ void intel_gt_debugfs_register(struct intel_gt *gt)
>
Re: [PATCH v6 3/3] drm/bridge: ti-sn65dsi86: Implement the pwm_chip
On Thu, 7 Oct 2021 at 05:51, Bjorn Andersson wrote: > > On Wed 29 Sep 20:05 PDT 2021, Bjorn Andersson wrote: > > > The SN65DSI86 provides the ability to supply a PWM signal on GPIO 4, > > with the primary purpose of controlling the backlight of the attached > > panel. Add an implementation that exposes this using the standard PWM > > framework, to allow e.g. pwm-backlight to expose this to the user. > > > > Signed-off-by: Bjorn Andersson > > Any feedback on this? I think this series looks good, and passes all of the normal sanity checks. So I'd like to merge it. Uwe: Can I have your ack on patch 1? Rob.
Re: DSI Bridge switching
Hello, On Fri, Oct 08, 2021 at 03:27:43PM +0200, Andrzej Hajda wrote: > Hi, > > Removed my invalid email (I will update files next week). > > On 08.10.2021 13:14, Jagan Teki wrote: > > Hi, > > > > I think this seems to be a known use case for industrial these days with > > i.mx8m. > > > > The host DSI would configure with two bridges one for DSI to LVDS > > (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we > > can use only one bridge at a time as host DSI support single out port. > > So we can have two separate device tree files for LVDS and HDMI and > > load them static. > > > > But, one of the use cases is to support both of them in single dts, and > > - Turn On LVDS (default) > > - Turn Off LVDS then Turn On HDMI when cable plug-in > > Are you sure it will work from hardware PoV? Do you have some demuxer? > isolation of pins? It may be in the category of "you shouldn't do this, but it actually works". I've seen the same being done with two CSI-2 camera sensors connected to the same receiver, with one of them being held in reset at all times. > > The HDMI event can be detected via some HDMI-INT GPIO on-board design. > > > > The possible solution, I'm thinking of adding LVDS on port 1, HDMI on > > port 2 in the DSI host node, and trying to attach the respective > > bridge based on HDMI-INT like repeating the bridge attachment cycle > > based on the HDMI-INT. > > I think more appropriate would be to share the same port, but provide > two endpoints inside this port - we have two hardware sharing the same > physical port. That sounds like the correct DT description to me. > > Can it be possible to do bridge attachment at runtime? something like > > a bridge hotplug event? or any other possible solutions? > > > > Any suggestions? > > Practically it is possible, see exynos_dsi + panels, or exynos_dsi + > some toshiba bridge - panel and bridge are dynamically 'plugged' and > 'unplugged' from exynos_drm, but they do not use bridge chain for this > and some other reasons. (un|re|)plugging should be performed of course > when pipeline is off (connector disconnected). I am not sure about > bridges added to bridge chain - you need to inspect all opses to ensure > it can be done safely. > > And the main issue: Daniel does not like it :) Neither do I :-) Could it be handled with two DRM connectors that are mutually exclusive ? -- Regards, Laurent Pinchart
[PATCH 6/6] drm/i915: Use irq work for coalescing-only dma-fence-work
We are using a timeline-attached struct dma_fence_work to coalesce
dma-fences on eviction. In this mode we will not have a work callback
attached.
Similar to how the dma-fence-chain and dma-fence-array containers do this,
use irq work to signal to reduce latency.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_sw_fence_work.c | 36 ++-
drivers/gpu/drm/i915/i915_sw_fence_work.h | 2 ++
2 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index 87cdb3158042..4573f537ada4 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -32,16 +32,17 @@ void dma_fence_work_timeline_attach(struct
dma_fence_work_timeline *tl,
{
struct dma_fence *await;
+ might_sleep();
if (tl->ops->get)
tl->ops->get(tl);
- spin_lock(>lock);
+ spin_lock_irq(>lock);
await = tl->last_fence;
tl->last_fence = dma_fence_get(>dma);
f->dma.seqno = tl->seqno++;
f->dma.context = tl->context;
f->tl = tl;
- spin_unlock(>lock);
+ spin_unlock_irq(>lock);
if (await) {
__i915_sw_fence_await_dma_fence(>chain, await, tl_cb);
@@ -53,13 +54,14 @@ static void dma_fence_work_timeline_detach(struct
dma_fence_work *f)
{
struct dma_fence_work_timeline *tl = f->tl;
bool put = false;
+ unsigned long irq_flags;
- spin_lock(>lock);
+ spin_lock_irqsave(>lock, irq_flags);
if (tl->last_fence == >dma) {
put = true;
tl->last_fence = NULL;
}
- spin_unlock(>lock);
+ spin_unlock_irqrestore(>lock, irq_flags);
if (tl->ops->put)
tl->ops->put(tl);
if (put)
@@ -68,8 +70,6 @@ static void dma_fence_work_timeline_detach(struct
dma_fence_work *f)
static void dma_fence_work_complete(struct dma_fence_work *f)
{
- dma_fence_signal(>dma);
-
if (f->ops->release)
f->ops->release(f);
@@ -79,13 +79,32 @@ static void dma_fence_work_complete(struct dma_fence_work
*f)
dma_fence_put(>dma);
}
+static void dma_fence_work_irq_work(struct irq_work *irq_work)
+{
+ struct dma_fence_work *f = container_of(irq_work, typeof(*f), irq_work);
+
+ dma_fence_signal(>dma);
+ if (f->ops->release)
+ /* Note we take the signaled path in dma_fence_work_work() */
+ queue_work(system_unbound_wq, >work);
+ else
+ dma_fence_work_complete(f);
+}
+
static void dma_fence_work_work(struct work_struct *work)
{
struct dma_fence_work *f = container_of(work, typeof(*f), work);
+ if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >dma.flags)) {
+ dma_fence_work_complete(f);
+ return;
+ }
+
if (f->ops->work)
f->ops->work(f);
+ dma_fence_signal(>dma);
+
dma_fence_work_complete(f);
}
@@ -102,8 +121,10 @@ fence_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
dma_fence_get(>dma);
if (test_bit(DMA_FENCE_WORK_IMM, >dma.flags))
dma_fence_work_work(>work);
- else
+ else if (f->ops->work)
queue_work(system_unbound_wq, >work);
+ else
+ irq_work_queue(>irq_work);
break;
case FENCE_FREE:
@@ -155,6 +176,7 @@ void dma_fence_work_init(struct dma_fence_work *f,
dma_fence_init(>dma, _ops, >lock, 0, 0);
i915_sw_fence_init(>chain, fence_notify);
INIT_WORK(>work, dma_fence_work_work);
+ init_irq_work(>irq_work, dma_fence_work_irq_work);
}
int dma_fence_work_chain(struct dma_fence_work *f, struct dma_fence *signal)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.h
b/drivers/gpu/drm/i915/i915_sw_fence_work.h
index 6f41ee360133..c412bb4cb288 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.h
@@ -8,6 +8,7 @@
#define I915_SW_FENCE_WORK_H
#include
+#include
#include
#include
@@ -77,6 +78,7 @@ struct dma_fence_work {
struct i915_sw_dma_fence_cb cb;
struct work_struct work;
+ struct irq_work irq_work;
struct dma_fence_work_timeline *tl;
--
2.31.1
[PATCH 5/6] drm/i915/ttm: Attach the migration fence to a region timeline on eviction
On eviction, TTM requires that migration fences from the same region are
ordered using dma_fence_is_later(). For request-based fences we therefore
need to use the same context for the migration, but now that we use a
dma_fence_work for error recovery, and, in addition, might need to coalesce
the migration fence with async unbind fences, Create a coalesce fence for
this.
Chain the coalesce fence on the migration fence and attach it to a region
timeline.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 84 ++
drivers/gpu/drm/i915/intel_memory_region.c | 43 +++
drivers/gpu/drm/i915/intel_memory_region.h | 7 ++
3 files changed, 119 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 79d4d50aa4e5..625ce52e8662 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -672,9 +672,10 @@ static void __i915_ttm_move_fallback(struct
ttm_buffer_object *bo, bool clear,
}
}
-static int __i915_ttm_move(struct ttm_buffer_object *bo, bool clear,
- struct ttm_resource *dst_mem, struct ttm_tt *dst_ttm,
- struct i915_refct_sgt *dst_rsgt, bool allow_accel)
+static struct dma_fence *
+__i915_ttm_move(struct ttm_buffer_object *bo, bool clear,
+ struct ttm_resource *dst_mem, struct ttm_tt *dst_ttm,
+ struct i915_refct_sgt *dst_rsgt, bool allow_accel)
{
struct i915_ttm_memcpy_work *copy_work;
struct dma_fence *fence;
@@ -689,7 +690,7 @@ static int __i915_ttm_move(struct ttm_buffer_object *bo,
bool clear,
/* Don't fail with -ENOMEM. Move sync instead. */
__i915_ttm_move_fallback(bo, clear, dst_mem, dst_ttm, dst_rsgt,
allow_accel);
- return 0;
+ return NULL;
}
dma_fence_work_init(_work->base, _ttm_memcpy_ops);
@@ -714,14 +715,45 @@ static int __i915_ttm_move(struct ttm_buffer_object *bo,
bool clear,
fence = dma_fence_get(_work->base.dma);
dma_fence_work_commit_imm(_work->base);
- /*
-* We're synchronizing here for now. For async moves, return the
-* fence.
-*/
- dma_fence_wait(fence, false);
- dma_fence_put(fence);
+ return fence;
+}
- return ret;
+/**
+ * struct i915_coalesce_fence - A dma-fence used to coalesce multiple fences
+ * similar to struct dm_fence_array, and at the same time being timeline-
+ * attached.
+ * @base: struct dma_fence_work base.
+ * @cb: Callback for timeline attachment.
+ */
+struct i915_coalesce_fence {
+ struct dma_fence_work base;
+ struct i915_sw_dma_fence_cb cb;
+};
+
+/* No .work or .release callback. Just coalescing. */
+static const struct dma_fence_work_ops i915_coalesce_fence_ops = {
+ .name = "Coalesce fence",
+};
+
+static struct dma_fence *
+i915_ttm_coalesce_fence(struct dma_fence *fence, struct intel_memory_region
*mr)
+{
+ struct i915_coalesce_fence *coalesce =
+ kmalloc(sizeof(*coalesce), GFP_KERNEL);
+
+ if (!coalesce) {
+ dma_fence_wait(fence, false);
+ dma_fence_put(fence);
+ return NULL;
+ }
+
+ dma_fence_work_init(>base, _coalesce_fence_ops);
+ dma_fence_work_chain(>base, fence);
+ dma_fence_work_timeline_attach(>tl, >base, >cb);
+ dma_fence_get(>base.dma);
+ dma_fence_work_commit_imm(>base);
+ dma_fence_put(fence);
+ return >base.dma;
}
static int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
@@ -734,6 +766,7 @@ static int i915_ttm_move(struct ttm_buffer_object *bo, bool
evict,
ttm_manager_type(bo->bdev, dst_mem->mem_type);
struct ttm_tt *ttm = bo->ttm;
struct i915_refct_sgt *dst_rsgt;
+ struct dma_fence *fence = NULL;
bool clear;
int ret;
@@ -765,7 +798,23 @@ static int i915_ttm_move(struct ttm_buffer_object *bo,
bool evict,
clear = !cpu_maps_iomem(bo->resource) && (!ttm ||
!ttm_tt_is_populated(ttm));
if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)))
- __i915_ttm_move(bo, clear, dst_mem, bo->ttm, dst_rsgt, true);
+ fence = __i915_ttm_move(bo, clear, dst_mem, bo->ttm, dst_rsgt,
true);
+ if (fence && evict) {
+ struct intel_memory_region *mr =
+ i915_ttm_region(bo->bdev, bo->resource->mem_type);
+
+ /*
+* Attach to the region timeline and for future async unbind,
+* which requires a timeline. Also future async unbind fences
+* can be attached here.
+*/
+ fence = i915_ttm_coalesce_fence(fence, mr);
+ }
+
+ if (fence) {
+ dma_fence_wait(fence, false);
+
[PATCH 4/6] drm/i915: Add a struct dma_fence_work timeline
The TTM managers and, possibly, the gtt address space managers will
need to be able to order fences for async operation.
Using dma_fence_is_later() for this will require that the fences we hand
them are from a single fence context and ordered.
Introduce a struct dma_fence_work_timeline, and a function to attach
struct dma_fence_work to such a timeline in a way that all previous
fences attached to the timeline will be signaled when the latest
attached struct dma_fence_work signals.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/i915_sw_fence_work.c | 89 ++-
drivers/gpu/drm/i915/i915_sw_fence_work.h | 58 +++
2 files changed, 145 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index 5b55cddafc9b..87cdb3158042 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -5,6 +5,66 @@
*/
#include "i915_sw_fence_work.h"
+#include "i915_utils.h"
+
+/**
+ * dma_fence_work_timeline_attach - Attach a struct dma_fence_work to a
+ * timeline.
+ * @tl: The timeline to attach to.
+ * @f: The struct dma_fence_work.
+ * @tl_cb: The i915_sw_dma_fence_cb needed to attach to the
+ * timeline. This is typically embedded into the structure that also
+ * embeds the struct dma_fence_work.
+ *
+ * This function takes a timeline reference and associates it with the
+ * struct dma_fence_work. That reference is given up when the fence
+ * signals. Furthermore it assigns a fence context and a seqno to the
+ * dma-fence, and then chains upon the previous fence of the timeline
+ * if any, to make sure that the fence signals after that fence. The
+ * @tl_cb callback structure is needed for that chaining. Finally
+ * the registered last fence of the timeline is replaced by this fence, and
+ * the timeline takes a reference on the fence, which is released when
+ * the fence signals.
+ */
+void dma_fence_work_timeline_attach(struct dma_fence_work_timeline *tl,
+ struct dma_fence_work *f,
+ struct i915_sw_dma_fence_cb *tl_cb)
+{
+ struct dma_fence *await;
+
+ if (tl->ops->get)
+ tl->ops->get(tl);
+
+ spin_lock(>lock);
+ await = tl->last_fence;
+ tl->last_fence = dma_fence_get(>dma);
+ f->dma.seqno = tl->seqno++;
+ f->dma.context = tl->context;
+ f->tl = tl;
+ spin_unlock(>lock);
+
+ if (await) {
+ __i915_sw_fence_await_dma_fence(>chain, await, tl_cb);
+ dma_fence_put(await);
+ }
+}
+
+static void dma_fence_work_timeline_detach(struct dma_fence_work *f)
+{
+ struct dma_fence_work_timeline *tl = f->tl;
+ bool put = false;
+
+ spin_lock(>lock);
+ if (tl->last_fence == >dma) {
+ put = true;
+ tl->last_fence = NULL;
+ }
+ spin_unlock(>lock);
+ if (tl->ops->put)
+ tl->ops->put(tl);
+ if (put)
+ dma_fence_put(>dma);
+}
static void dma_fence_work_complete(struct dma_fence_work *f)
{
@@ -13,6 +73,9 @@ static void dma_fence_work_complete(struct dma_fence_work *f)
if (f->ops->release)
f->ops->release(f);
+ if (f->tl)
+ dma_fence_work_timeline_detach(f);
+
dma_fence_put(>dma);
}
@@ -53,14 +116,17 @@ fence_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
static const char *get_driver_name(struct dma_fence *fence)
{
- return "dma-fence";
+ struct dma_fence_work *f = container_of(fence, typeof(*f), dma);
+
+ return (f->tl && f->tl->ops->name) ? f->tl->ops->name : "dma-fence";
}
static const char *get_timeline_name(struct dma_fence *fence)
{
struct dma_fence_work *f = container_of(fence, typeof(*f), dma);
- return f->ops->name ?: "work";
+ return (f->tl && f->tl->name) ? f->tl->name :
+ f->ops->name ?: "work";
}
static void fence_release(struct dma_fence *fence)
@@ -84,6 +150,7 @@ void dma_fence_work_init(struct dma_fence_work *f,
{
f->ops = ops;
f->error = 0;
+ f->tl = NULL;
spin_lock_init(>lock);
dma_fence_init(>dma, _ops, >lock, 0, 0);
i915_sw_fence_init(>chain, fence_notify);
@@ -97,3 +164,21 @@ int dma_fence_work_chain(struct dma_fence_work *f, struct
dma_fence *signal)
return __i915_sw_fence_await_dma_fence(>chain, signal, >cb);
}
+
+/**
+ * dma_fence_work_timeline_init - Initialize a dma_fence_work timeline
+ * @tl: The timeline to initialize,
+ * @name: The name of the timeline,
+ * @ops: The timeline operations.
+ */
+void dma_fence_work_timeline_init(struct dma_fence_work_timeline *tl,
+ const char *name,
+ const struct dma_fence_work_timeline_ops *ops)
+{
+ tl->name = name;
+ spin_lock_init(>lock);
+
[PATCH 3/6] drm/i915/ttm: Failsafe migration blits
If the initial fill blit or copy blit of an object fails, the old
content of the data might be exposed and read as soon as either CPU- or
GPU PTEs are set up to point at the pages.
Intercept the blit fence with an async dma_fence_work that checks the
blit fence for errors and if there are errors performs an async cpu blit
instead. If there is a failure to allocate the async dma_fence_work,
allocate it on the stack and sync wait for the blit to complete.
Add selftests that simulate gpu blit failures and failure to allocate
the async dma_fence_work.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 268 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 4 +
.../drm/i915/gem/selftests/i915_gem_migrate.c | 24 +-
3 files changed, 240 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4b4d7457bef9..79d4d50aa4e5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -7,6 +7,7 @@
#include
#include "i915_drv.h"
+#include "i915_sw_fence_work.h"
#include "intel_memory_region.h"
#include "intel_region_ttm.h"
@@ -25,6 +26,18 @@
#define I915_TTM_PRIO_NO_PAGES 1
#define I915_TTM_PRIO_HAS_PAGES 2
+I915_SELFTEST_DECLARE(static bool fail_gpu_migration;)
+I915_SELFTEST_DECLARE(static bool fail_work_allocation;)
+
+#ifdef CONFIG_DRM_I915_SELFTEST
+void i915_ttm_migrate_set_failure_modes(bool gpu_migration,
+ bool work_allocation)
+{
+ fail_gpu_migration = gpu_migration;
+ fail_work_allocation = work_allocation;
+}
+#endif
+
/*
* Size of struct ttm_place vector in on-stack struct ttm_placement allocs
*/
@@ -466,11 +479,11 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
return intel_region_ttm_resource_to_rsgt(obj->mm.region, res);
}
-static int i915_ttm_accel_move(struct ttm_buffer_object *bo,
- bool clear,
- struct ttm_resource *dst_mem,
- struct ttm_tt *dst_ttm,
- struct sg_table *dst_st)
+static struct dma_fence *i915_ttm_accel_move(struct ttm_buffer_object *bo,
+bool clear,
+struct ttm_resource *dst_mem,
+struct ttm_tt *dst_ttm,
+struct sg_table *dst_st)
{
struct drm_i915_private *i915 = container_of(bo->bdev, typeof(*i915),
bdev);
@@ -481,30 +494,29 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
*bo,
int ret;
if (!i915->gt.migrate.context || intel_gt_is_wedged(>gt))
- return -EINVAL;
+ return ERR_PTR(-EINVAL);
+
+ /* With fail_gpu_migration, we always perform a GPU clear. */
+ if (I915_SELFTEST_ONLY(fail_gpu_migration))
+ clear = true;
dst_level = i915_ttm_cache_level(i915, dst_mem, dst_ttm);
if (clear) {
- if (bo->type == ttm_bo_type_kernel)
- return -EINVAL;
+ if (bo->type == ttm_bo_type_kernel &&
+ !I915_SELFTEST_ONLY(fail_gpu_migration))
+ return ERR_PTR(-EINVAL);
intel_engine_pm_get(i915->gt.migrate.context->engine);
ret = intel_context_migrate_clear(i915->gt.migrate.context,
NULL,
dst_st->sgl, dst_level,
gpu_binds_iomem(dst_mem),
0, );
-
- if (!ret && rq) {
- i915_request_wait(rq, 0, MAX_SCHEDULE_TIMEOUT);
- i915_request_put(rq);
- }
- intel_engine_pm_put(i915->gt.migrate.context->engine);
} else {
struct i915_refct_sgt *src_rsgt =
i915_ttm_resource_get_st(obj, bo->resource);
if (IS_ERR(src_rsgt))
- return PTR_ERR(src_rsgt);
+ return ERR_CAST(src_rsgt);
src_level = i915_ttm_cache_level(i915, bo->resource, src_ttm);
intel_engine_pm_get(i915->gt.migrate.context->engine);
@@ -515,55 +527,201 @@ static int i915_ttm_accel_move(struct ttm_buffer_object
*bo,
dst_st->sgl, dst_level,
gpu_binds_iomem(dst_mem),
);
+
i915_refct_sgt_put(src_rsgt);
- if (!ret && rq) {
- i915_request_wait(rq, 0, MAX_SCHEDULE_TIMEOUT);
- i915_request_put(rq);
- }
-
[PATCH 2/6] drm/i915: Introduce refcounted sg-tables
As we start to introduce asynchronous failsafe object migration,
where we update the object state and then submit asynchronous
commands we need to record what memory resources are actually used
by various part of the command stream. Initially for three purposes:
1) Error capture.
2) Asynchronous migration error recovery.
3) Asynchronous vma bind.
At the time where these happens, the object state may have been updated
to be several migrations ahead and object sg-tables discarded.
In order to make it possible to keep sg-tables with memory resource
information for these operations, introduce refcounted sg-tables that
aren't freed until the last user is done with them.
The alternative would be to reference information sitting on the
corresponding ttm_resources which typically have the same lifetime as
these refcountes sg_tables, but that leads to other awkward constructs:
Due to the design direction chosen for ttm resource managers that would
lead to diamond-style inheritance, the LMEM resources may sometimes be
prematurely freed, and finally the subclassed struct ttm_resource would
have to bleed into the asynchronous vma bind code.
Signed-off-by: Thomas Hellström
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 159 +++---
drivers/gpu/drm/i915/i915_scatterlist.c | 62 +--
drivers/gpu/drm/i915/i915_scatterlist.h | 76 -
drivers/gpu/drm/i915/intel_region_ttm.c | 15 +-
drivers/gpu/drm/i915/intel_region_ttm.h | 5 +-
drivers/gpu/drm/i915/selftests/mock_region.c | 12 +-
7 files changed, 238 insertions(+), 94 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 7c3da4e3e737..d600cf7ceb35 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -485,6 +485,7 @@ struct drm_i915_gem_object {
*/
struct list_head region_link;
+ struct i915_refct_sgt *rsgt;
struct sg_table *pages;
void *mapping;
@@ -538,7 +539,7 @@ struct drm_i915_gem_object {
} mm;
struct {
- struct sg_table *cached_io_st;
+ struct i915_refct_sgt *cached_io_rsgt;
struct i915_gem_object_page_iter get_io_page;
struct drm_i915_gem_object *backup;
bool created:1;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 74a1ffd0d7dd..4b4d7457bef9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -34,7 +34,7 @@
* struct i915_ttm_tt - TTM page vector with additional private information
* @ttm: The base TTM page vector.
* @dev: The struct device used for dma mapping and unmapping.
- * @cached_st: The cached scatter-gather table.
+ * @cached_rsgt: The cached scatter-gather table.
*
* Note that DMA may be going on right up to the point where the page-
* vector is unpopulated in delayed destroy. Hence keep the
@@ -45,7 +45,7 @@
struct i915_ttm_tt {
struct ttm_tt ttm;
struct device *dev;
- struct sg_table *cached_st;
+ struct i915_refct_sgt cached_rsgt;
};
static const struct ttm_place sys_placement_flags = {
@@ -179,6 +179,21 @@ i915_ttm_placement_from_obj(const struct
drm_i915_gem_object *obj,
placement->busy_placement = busy;
}
+static void i915_ttm_tt_release(struct kref *ref)
+{
+ struct i915_ttm_tt *i915_tt =
+ container_of(ref, typeof(*i915_tt), cached_rsgt.kref);
+ struct sg_table *st = _tt->cached_rsgt.table;
+
+ GEM_WARN_ON(st->sgl);
+
+ kfree(i915_tt);
+}
+
+static const struct i915_refct_sgt_ops tt_rsgt_ops = {
+ .release = i915_ttm_tt_release
+};
+
static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
uint32_t page_flags)
{
@@ -203,6 +218,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
return NULL;
}
+ i915_refct_sgt_init_ops(_tt->cached_rsgt, bo->base.size,
+ _rsgt_ops);
i915_tt->dev = obj->base.dev->dev;
return _tt->ttm;
@@ -211,13 +228,13 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
static void i915_ttm_tt_unpopulate(struct ttm_device *bdev, struct ttm_tt *ttm)
{
struct i915_ttm_tt *i915_tt = container_of(ttm, typeof(*i915_tt), ttm);
+ struct sg_table *st = _tt->cached_rsgt.table;
+
+ GEM_WARN_ON(kref_read(_tt->cached_rsgt.kref) != 1);
- if (i915_tt->cached_st) {
- dma_unmap_sgtable(i915_tt->dev, i915_tt->cached_st,
- DMA_BIDIRECTIONAL, 0);
- sg_free_table(i915_tt->cached_st);
- kfree(i915_tt->cached_st);
-
[PATCH 0/6] drm/i915: Failsafe migration blits
This patch series introduces failsafe migration blits. The reason for this seemingly strange concept is that if the initial clearing or readback of LMEM fails for some reason, and we then set up either GPU- or CPU ptes to the allocated LMEM, we can expose old contents from other clients. So after each migration blit we attach a struct dma-fence-work that checks the error value and if it's an error, perform a memcpy blit, instead. This comes with some needed infrastructure updates: Patch 1, updates dma_fence_work to do the work even if there is an error. The work callback needs to check for error and take action accordingly. Patch 2, Introduces refcounted sg-tables. The sg-tables are needed async for the memcpy. Patch 3, Introduces the failsafe migration blits and selftests. Patch 4, Adds the possibility to attach the struct dma_fence_work to a timeline. Patch 5, Attached the migration fence to a timeline since TTM requires that for upcoming async eviction. Patch 6 Adds an optimization for coalescing-only struct dma_fence_work. Worth to consider during review: Patch 4-6 are probably better done in the context of struct dma_fence_array. Both since we perhaps shouldn't add irq work to yet another fence data structure and also because the i915 command submission can individualize struct dma_fence_arrays. Also the memcpy solution here isn't a final one as it only works if the aperture covers all of lmem. We probably need to work on a solution where we intercept move_fence errors and refuse GPU- and CPU mappings. Thomas Hellström (6): drm/i915: Update dma_fence_work drm/i915: Introduce refcounted sg-tables drm/i915/ttm: Failsafe migration blits drm/i915: Add a struct dma_fence_work timeline drm/i915/ttm: Attach the migration fence to a region timeline on eviction drm/i915: Use irq work for coalescing-only dma-fence-work drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 5 + .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 467 ++ drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 4 + .../drm/i915/gem/selftests/i915_gem_migrate.c | 24 +- drivers/gpu/drm/i915/i915_scatterlist.c | 62 ++- drivers/gpu/drm/i915/i915_scatterlist.h | 76 ++- drivers/gpu/drm/i915/i915_sw_fence_work.c | 145 +- drivers/gpu/drm/i915/i915_sw_fence_work.h | 61 +++ drivers/gpu/drm/i915/i915_vma.c | 12 +- drivers/gpu/drm/i915/intel_memory_region.c| 43 ++ drivers/gpu/drm/i915/intel_memory_region.h| 7 + drivers/gpu/drm/i915/intel_region_ttm.c | 15 +- drivers/gpu/drm/i915/intel_region_ttm.h | 5 +- drivers/gpu/drm/i915/selftests/mock_region.c | 12 +- 15 files changed, 776 insertions(+), 165 deletions(-) -- 2.31.1
[PATCH 1/6] drm/i915: Update dma_fence_work
Move the release callback to after fence signaling to align with
what's done for upcoming VM_BIND user-fence signaling.
Finally call the work callback regardless of whether we have a fence
error or not and update the existing callbacks accordingly. We will
need this to intercept the error for failsafe migration.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_clflush.c | 5 +++
drivers/gpu/drm/i915/i915_sw_fence_work.c | 36 ++---
drivers/gpu/drm/i915/i915_sw_fence_work.h | 1 +
drivers/gpu/drm/i915/i915_vma.c | 12 +--
4 files changed, 33 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
index f0435c6feb68..2143ebaf5b6f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_clflush.c
@@ -28,6 +28,11 @@ static void clflush_work(struct dma_fence_work *base)
{
struct clflush *clflush = container_of(base, typeof(*clflush), base);
+ if (base->error) {
+ dma_fence_set_error(>dma, base->error);
+ return;
+ }
+
__do_clflush(clflush->obj);
}
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.c
b/drivers/gpu/drm/i915/i915_sw_fence_work.c
index 5b33ef23d54c..5b55cddafc9b 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.c
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.c
@@ -6,21 +6,24 @@
#include "i915_sw_fence_work.h"
-static void fence_complete(struct dma_fence_work *f)
+static void dma_fence_work_complete(struct dma_fence_work *f)
{
+ dma_fence_signal(>dma);
+
if (f->ops->release)
f->ops->release(f);
- dma_fence_signal(>dma);
+
+ dma_fence_put(>dma);
}
-static void fence_work(struct work_struct *work)
+static void dma_fence_work_work(struct work_struct *work)
{
struct dma_fence_work *f = container_of(work, typeof(*f), work);
- f->ops->work(f);
+ if (f->ops->work)
+ f->ops->work(f);
- fence_complete(f);
- dma_fence_put(>dma);
+ dma_fence_work_complete(f);
}
static int __i915_sw_fence_call
@@ -31,17 +34,13 @@ fence_notify(struct i915_sw_fence *fence, enum
i915_sw_fence_notify state)
switch (state) {
case FENCE_COMPLETE:
if (fence->error)
- dma_fence_set_error(>dma, fence->error);
-
- if (!f->dma.error) {
- dma_fence_get(>dma);
- if (test_bit(DMA_FENCE_WORK_IMM, >dma.flags))
- fence_work(>work);
- else
- queue_work(system_unbound_wq, >work);
- } else {
- fence_complete(f);
- }
+ cmpxchg(>error, 0, fence->error);
+
+ dma_fence_get(>dma);
+ if (test_bit(DMA_FENCE_WORK_IMM, >dma.flags))
+ dma_fence_work_work(>work);
+ else
+ queue_work(system_unbound_wq, >work);
break;
case FENCE_FREE:
@@ -84,10 +83,11 @@ void dma_fence_work_init(struct dma_fence_work *f,
const struct dma_fence_work_ops *ops)
{
f->ops = ops;
+ f->error = 0;
spin_lock_init(>lock);
dma_fence_init(>dma, _ops, >lock, 0, 0);
i915_sw_fence_init(>chain, fence_notify);
- INIT_WORK(>work, fence_work);
+ INIT_WORK(>work, dma_fence_work_work);
}
int dma_fence_work_chain(struct dma_fence_work *f, struct dma_fence *signal)
diff --git a/drivers/gpu/drm/i915/i915_sw_fence_work.h
b/drivers/gpu/drm/i915/i915_sw_fence_work.h
index d56806918d13..caa59fb5252b 100644
--- a/drivers/gpu/drm/i915/i915_sw_fence_work.h
+++ b/drivers/gpu/drm/i915/i915_sw_fence_work.h
@@ -24,6 +24,7 @@ struct dma_fence_work_ops {
struct dma_fence_work {
struct dma_fence dma;
spinlock_t lock;
+ int error;
struct i915_sw_fence chain;
struct i915_sw_dma_fence_cb cb;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 4b7fc4647e46..5123ac28ad9a 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -301,6 +301,11 @@ static void __vma_bind(struct dma_fence_work *work)
struct i915_vma_work *vw = container_of(work, typeof(*vw), base);
struct i915_vma *vma = vw->vma;
+ if (work->error) {
+ dma_fence_set_error(>dma, work->error);
+ return;
+ }
+
vma->ops->bind_vma(vw->vm, >stash,
vma, vw->cache_level, vw->flags);
}
@@ -333,7 +338,7 @@ struct i915_vma_work *i915_vma_work(void)
return NULL;
dma_fence_work_init(>base, _ops);
- vw->base.dma.error = -EAGAIN; /* disable the worker by default */
+ vw->base.error = -EAGAIN; /* disable the worker by default */
Re: [PATCH 0/5] Revert series "CMDQ refinement of Mediatek DRM driver"
Hi Chun-Kuang,
Thank you to take time to send this, for full series
Tested-by: Enric Balletbo i Serra
Display is now working again.
Thanks,
Enric
Missatge de Chun-Kuang Hu del dia dv., 8
d’oct. 2021 a les 1:53:
>
> Commit c1ec54b7b5af
> ("drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb")
> would cause numerous mtk cmdq mailbox driver warning:
>
> WARNING: CPU: 0 PID: 0 at drivers/mailbox/mtk-cmdq-mailbox.c:198
> cmdq_task_exec_done+0xb8/0xe0
>
> So revert that patch and all the patches depend on that patch.
>
> Chun-Kuang Hu (5):
> Revert "drm/mediatek: Clear pending flag when cmdq packet is done"
> Revert "drm/mediatek: Add cmdq_handle in mtk_crtc"
> Revert "drm/mediatek: Detect CMDQ execution timeout"
> Revert "drm/mediatek: Remove struct cmdq_client"
> Revert "drm/mediatek: Use mailbox rx_callback instead of cmdq_task_cb"
>
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 157
> 1 file changed, 24 insertions(+), 133 deletions(-)
>
> --
> 2.25.1
>
Re: [PATCH v1 4/4] drm/mediatek: add mt8195 hdmi TX support
Quoting Guillaume Ranquet (2021-09-30 17:30:16) > Hi Chun-Kuang. > > Thank you for your input. > I have tried to find commonalities between the two drivers but I didn't > find enough shared code to warrant that architecture. > I'll have another look, especially now that I'm more familiar with the > driver. > > Regarding 2, I have removed as much functionalities as I could from the > original vendor tree (like hdcp, hdr, cec...) to keep only HDMI audio and > video TX. > > There might be some more things to remove, but I'm no expert in the domain > and I'm working without access to mediatek datasheets and documentation. > > Though, at this stage I could split the patch in two with video first and > then audio. > > I will try to work something out for a V2. > > Thx, > Guillaume. > > Quoting Chun-Kuang Hu (2021-09-30 15:36:42) > > Hi, Guillaume: > > > > This is a big patch, and I'm not familiar with this driver, so the > > review process would be long. So I tell you about how I review this > > patch, and if you could process according to my way, the process would > > be more short. > > > > 1. Find the common part of all hdmi driver. > > Even though mt8195 hdmi has many difference with other mediatek soc > > hdmi driver, I would like to find the common part and have just one > > copy of the common part. I expect there would three file finally: > > > > mtk_hdmi.c (the common part) > > mtk_hdmi_mt8173.c (each soc special part) > > mtk_hdmi_mt8195.c (each soc special part) > > > > But this would be difficult in this stage, so you could temporarily > > have these three file: > > > > mtk_hdmi_common.c (the common part) > > mtk_hdmi.c (each soc special part) > > mtk_hdmi_mt8195.c (each soc special part) > > > > When review is almost done, then change the file name as I wish. > > > > 2. The first patch has only basic function, separate advance function > > to another patch. > > When comparing mt8195 hdmi driver with other hdmi driver, if mt8195 > > hdmi driver has some function that other hdmi does not have, I would > > think that function is advance function and should be separate to > > another patch. > > > > If you follow this way, I think the review process would be short. > > Because this patch is big, I would just review partial part each time. > > > > Regards, > > Chun-Kuang. > > > > > > Guillaume Ranquet ��� 2021���9���29��� �� > > ��5:47� > > > > > > Add basic hdmi TX support for the mediatek mt8195 SoCs > > > > > > Signed-off-by: Guillaume Ranquet > > > --- > > > drivers/gpu/drm/mediatek/Kconfig | 10 + > > > drivers/gpu/drm/mediatek/Makefile |4 +- > > > drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.c| 2293 + > > > drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.h| 128 + > > > .../gpu/drm/mediatek/mtk_mt8195_hdmi_ddc.c| 530 > > > .../gpu/drm/mediatek/mtk_mt8195_hdmi_ddc.h| 20 + > > > .../gpu/drm/mediatek/mtk_mt8195_hdmi_regs.h | 329 +++ > > > 7 files changed, 3313 insertions(+), 1 deletion(-) > > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.c > > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi.h > > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi_ddc.c > > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi_ddc.h > > > create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8195_hdmi_regs.h > > > > > > diff --git a/drivers/gpu/drm/mediatek/Kconfig > > > b/drivers/gpu/drm/mediatek/Kconfig > > > index 2976d21e9a34a..517d065f0511b 100644 > > > --- a/drivers/gpu/drm/mediatek/Kconfig > > > +++ b/drivers/gpu/drm/mediatek/Kconfig > > > @@ -28,3 +28,13 @@ config DRM_MEDIATEK_HDMI > > > select PHY_MTK_HDMI > > > help > > > DRM/KMS HDMI driver for Mediatek SoCs > > > + > > > +config DRM_MEDIATEK_HDMI_MT8195_SUSPEND_LOW_POWER > > > + tristate "DRM HDMI SUSPEND LOW POWER Support for Mediatek mt8195 > > > SoCs" > > > + depends on DRM_MEDIATEK_HDMI > > > + help > > > + DRM/KMS HDMI SUSPEND_LOW_POWER for Mediatek SoCs. > > > + Choose this option if you want to disable/enable > > > + clock and power domain when platform enter suspend, > > > + and this config depends on DRM_MEDIATEK_HDMI. > > > + > > > diff --git a/drivers/gpu/drm/mediatek/Makefile > > > b/drivers/gpu/drm/mediatek/Makefile > > > index 29098d7c8307c..736f0816083d0 100644 > > > --- a/drivers/gpu/drm/mediatek/Makefile > > > +++ b/drivers/gpu/drm/mediatek/Makefile > > > @@ -18,6 +18,8 @@ obj-$(CONFIG_DRM_MEDIATEK) += mediatek-drm.o > > > > > > mediatek-drm-hdmi-objs := mtk_cec.o \ > > > mtk_hdmi.o \ > > > - mtk_hdmi_ddc.o > > > + mtk_hdmi_ddc.o \ > > > + mtk_mt8195_hdmi.o \ > > > + mtk_mt8195_hdmi_ddc.o \ > > > > > > obj-$(CONFIG_DRM_MEDIATEK_HDMI) += mediatek-drm-hdmi.o > > > diff --git
Re: DSI Bridge switching
Hi, Removed my invalid email (I will update files next week). On 08.10.2021 13:14, Jagan Teki wrote: Hi, I think this seems to be a known use case for industrial these days with i.mx8m. The host DSI would configure with two bridges one for DSI to LVDS (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we can use only one bridge at a time as host DSI support single out port. So we can have two separate device tree files for LVDS and HDMI and load them static. But, one of the use cases is to support both of them in single dts, and - Turn On LVDS (default) - Turn Off LVDS then Turn On HDMI when cable plug-in Are you sure it will work from hardware PoV? Do you have some demuxer? isolation of pins? The HDMI event can be detected via some HDMI-INT GPIO on-board design. The possible solution, I'm thinking of adding LVDS on port 1, HDMI on port 2 in the DSI host node, and trying to attach the respective bridge based on HDMI-INT like repeating the bridge attachment cycle based on the HDMI-INT. I think more appropriate would be to share the same port, but provide two endpoints inside this port - we have two hardware sharing the same physical port. Can it be possible to do bridge attachment at runtime? something like a bridge hotplug event? or any other possible solutions? Any suggestions? Practically it is possible, see exynos_dsi + panels, or exynos_dsi + some toshiba bridge - panel and bridge are dynamically 'plugged' and 'unplugged' from exynos_drm, but they do not use bridge chain for this and some other reasons. (un|re|)plugging should be performed of course when pipeline is off (connector disconnected). I am not sure about bridges added to bridge chain - you need to inspect all opses to ensure it can be done safely. And the main issue: Daniel does not like it :) Regards Andrzej Thanks, Jagan.
Re: [PATCH v4 0/7] Add support to the mmsys driver to be a reset controller
On 30/09/2021 10:31, Enric Balletbo i Serra wrote:
Dear all,
The following patchset is a reimplementation of the patch sent by Jitao
Shi [1] some time ago. As suggested by Chun-Kuang Hu, this time the
reset is done using the reset API, where the mmsys driver is the reset
controller and the mtk_dsi driver is the reset consumer.
Note that the first patch is kind of unrelated change, it's just a
cleanup but is needed if you want to apply all the following patches
cleanly.
This patchset is important in order to have the DSI panel working on some
kukui MT8183 Chromebooks (i.e Lenovo IdeaPad Duet). Without it, you just
get a black screen.
Patch 1-5 pushed to v5.15-next/dts64
Patch 6-7 pushed to v5.15-next/soc
Thanks!
Matthias
Best regards,
Enric
[1]
https://lore.kernel.org/linux-arm-kernel/20210420132614.150242-4-jitao@mediatek.com/
Changes in v4:
- Remove unnused variable as pointed by Hsin-Yi
Changes in v3:
- Based on top of the patch that converts mmsys to schema
- Fix typo in the commit description
Changes in v2:
- Fix build test ERROR Reported-by: kernel test robot
- Added a new patch to describe the dsi reset optional property.
Enric Balletbo i Serra (7):
arm64: dts: mediatek: Move reset controller constants into common
location
dt-bindings: mediatek: Add #reset-cells to mmsys system controller
dt-bindings: display: mediatek: add dsi reset optional property
arm64: dts: mt8173: Add the mmsys reset bit to reset the dsi0
arm64: dts: mt8183: Add the mmsys reset bit to reset the dsi0
soc: mediatek: mmsys: Add reset controller support
drm/mediatek: mtk_dsi: Reset the dsi0 hardware
.../bindings/arm/mediatek/mediatek,mmsys.yaml | 4 ++
.../display/mediatek/mediatek,dsi.txt | 6 ++
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 2 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 5 +-
drivers/gpu/drm/mediatek/mtk_dsi.c| 5 +-
drivers/soc/mediatek/mtk-mmsys.c | 68 +++
drivers/soc/mediatek/mtk-mmsys.h | 2 +
drivers/watchdog/mtk_wdt.c| 6 +-
.../mt2712-resets.h | 0
include/dt-bindings/reset/mt8173-resets.h | 2 +
.../mt8183-resets.h | 3 +
.../mt8192-resets.h | 0
12 files changed, 97 insertions(+), 6 deletions(-)
rename include/dt-bindings/{reset-controller => reset}/mt2712-resets.h (100%)
rename include/dt-bindings/{reset-controller => reset}/mt8183-resets.h (98%)
rename include/dt-bindings/{reset-controller => reset}/mt8192-resets.h (100%)
Fw: [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling
[AMD Official Use Only] Trying with Christian's Gmail, as he still didn't receive previous emails. From: Das, Nirmoy Sent: Friday, October 8, 2021 2:17 PM To: Koenig, Christian Cc: dri-devel@lists.freedesktop.org ; intel-...@lists.freedesktop.org ; Maarten Lankhorst ; Maxime Ripard ; Thomas Zimmermann ; David Airlie ; Daniel Vetter ; Greg KH ; Jani Nikula Subject: Re: [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling Adding Christian as he didn't receive the full thread yet. On 10/8/2021 1:07 PM, Greg KH wrote: > On Fri, Oct 08, 2021 at 12:40:47PM +0300, Jani Nikula wrote: >> On Fri, 08 Oct 2021, Nirmoy Das wrote: >>> Debugfs API returns encoded error instead of NULL. >>> This patch cleanups drm debugfs error handling to >>> properly set dri and its minor's root dentry to NULL. >>> >>> Also do not error out if dri/minor debugfs directory >>> creation fails as a debugfs error is not a fatal error. >> Cc: Greg >> >> I thought this is the opposite of what Greg's been telling everyone to >> do with debugfs. > Yes, that is not good. > > You should never care about the result of a debugfs_create* call. Just > take the result, and if it is a directory, save it off to use it for > creating a file, no need to check anything. > > And then throw it away, later, when you want to remove the directory, > look it up with a call to debugfs_lookup() and pass that to > debugfs_remove() (which does so recursively). > > There should never be a need to save, or check, the result of any > debugfs call. If so, odds are it is being used incorrectly. > > thanks, > > greg k-h
Re: [RFC] drm/msm/dp: Allow attaching a drm_panel
Hi,
On Thu, Oct 07, 2021 at 09:15:12AM -0700, Bjorn Andersson wrote:
> The one thing that I still don't understand though is, if the typec_mux
> is used by the typec controller to inform _the_ mux about the function
> to be used, what's up with the complexity in typec_mux_match()? This is
> what lead me to believe that typec_mux was enabling/disabling individual
> altmodes, rather just flipping the physical switch at the bottom.
Ah, typec_mux_match() is a mess. I'm sorry about that. I think most of
the code in that function is not used by anybody. If I remember
correctly, all that complexity is attempting to solve some
hypothetical corner case(s). Probable a case where we have multiple
muxes per port to deal with.
I think it would probable be best to clean the function to the bare
minimum by keeping only the parts that are actually used today
(attached).
thanks,
--
heikki
diff --git a/drivers/usb/typec/mux.c b/drivers/usb/typec/mux.c
index c8340de0ed495..44f168c9bd9bf 100644
--- a/drivers/usb/typec/mux.c
+++ b/drivers/usb/typec/mux.c
@@ -193,56 +193,15 @@ static int mux_fwnode_match(struct device *dev, const
void *fwnode)
static void *typec_mux_match(struct fwnode_handle *fwnode, const char *id,
void *data)
{
- const struct typec_altmode_desc *desc = data;
struct device *dev;
- bool match;
- int nval;
- u16 *val;
- int ret;
- int i;
/*
-* Check has the identifier already been "consumed". If it
-* has, no need to do any extra connection identification.
+* The connection identifier will be needed with device graph (OF
graph).
+* Device graph is not supported by this code yet, so bailing out.
*/
- match = !id;
- if (match)
- goto find_mux;
-
- /* Accessory Mode muxes */
- if (!desc) {
- match = fwnode_property_present(fwnode, "accessory");
- if (match)
- goto find_mux;
- return NULL;
- }
-
- /* Alternate Mode muxes */
- nval = fwnode_property_count_u16(fwnode, "svid");
- if (nval <= 0)
- return NULL;
-
- val = kcalloc(nval, sizeof(*val), GFP_KERNEL);
- if (!val)
- return ERR_PTR(-ENOMEM);
-
- ret = fwnode_property_read_u16_array(fwnode, "svid", val, nval);
- if (ret < 0) {
- kfree(val);
- return ERR_PTR(ret);
- }
-
- for (i = 0; i < nval; i++) {
- match = val[i] == desc->svid;
- if (match) {
- kfree(val);
- goto find_mux;
- }
- }
- kfree(val);
- return NULL;
+ if (id)
+ return ERR_PTR(-ENOTSUPP);
-find_mux:
dev = class_find_device(_mux_class, NULL, fwnode,
mux_fwnode_match);
Re: [PATCH] dma-resv: Fix dma_resv_get_fences and dma_resv_copy_fences after conversion
Am 08.10.21 um 12:49 schrieb Tvrtko Ursulin:
On 08/10/2021 11:21, Christian König wrote:
Am 08.10.21 um 11:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Cache the count of shared fences in the iterator to avoid dereferencing
the dma_resv_object outside the RCU protection. Otherwise iterator
and its
users can observe an incosistent state which makes it impossible to use
safely.
Ah, of course! I've been staring at the code the whole morning and
couldn't see it.
Going to write a testcase to cover that.
Such as:
<6> [187.517041] [IGT] gem_sync: executing
<7> [187.536343] i915 :00:02.0:
[drm:i915_gem_context_create_ioctl [i915]] HW context 1 created
<7> [187.536793] i915 :00:02.0:
[drm:i915_gem_context_create_ioctl [i915]] HW context 1 created
<6> [187.551235] [IGT] gem_sync: starting subtest basic-many-each
<1> [188.935462] BUG: kernel NULL pointer dereference, address:
0010
<1> [188.935485] #PF: supervisor write access in kernel mode
<1> [188.935495] #PF: error_code(0x0002) - not-present page
<6> [188.935504] PGD 0 P4D 0
<4> [188.935512] Oops: 0002 [#1] PREEMPT SMP NOPTI
<4> [188.935521] CPU: 2 PID: 1467 Comm: gem_sync Not tainted
5.15.0-rc4-CI-Patchwork_21264+ #1
<4> [188.935535] Hardware name: /NUC6CAYB, BIOS
AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018
<4> [188.935546] RIP: 0010:dma_resv_get_fences+0x116/0x2d0
<4> [188.935560] Code: 10 85 c0 7f c9 be 03 00 00 00 e8 15 8b df ff
eb bd e8 8e c6 ff ff eb b6 41 8b 04 24 49 8b 55 00 48 89 e7 8d 48 01
41 89 0c 24 <4c> 89 34 c2 e8 41 f2 ff ff 49 89 c6 48 85 c0 75 8c 48
8b 44 24 10
<4> [188.935583] RSP: 0018:c900011dbcc8 EFLAGS: 00010202
<4> [188.935593] RAX: RBX: RCX:
0001
<4> [188.935603] RDX: 0010 RSI: 822e343c RDI:
c900011dbcc8
<4> [188.935613] RBP: c900011dbd48 R08: 88812d255bb8 R09:
fffe
<4> [188.935623] R10: 0001 R11: R12:
c900011dbd44
<4> [188.935633] R13: c900011dbd50 R14: 888113d29cc0 R15:
<4> [188.935643] FS: 7f68d17e9700()
GS:88827790() knlGS:
<4> [188.935655] CS: 0010 DS: ES: CR0: 80050033
<4> [188.935665] CR2: 0010 CR3: 00012d0a4000 CR4:
003506e0
<4> [188.935676] Call Trace:
<4> [188.935685] i915_gem_object_wait+0x1ff/0x410 [i915]
<4> [188.935988] i915_gem_wait_ioctl+0xf2/0x2a0 [i915]
<4> [188.936272] ? i915_gem_object_wait+0x410/0x410 [i915]
<4> [188.936533] drm_ioctl_kernel+0xae/0x140
<4> [188.936546] drm_ioctl+0x201/0x3d0
<4> [188.936555] ? i915_gem_object_wait+0x410/0x410 [i915]
<4> [188.936820] ? __fget_files+0xc2/0x1c0
<4> [188.936830] ? __fget_files+0xda/0x1c0
<4> [188.936839] __x64_sys_ioctl+0x6d/0xa0
<4> [188.936848] do_syscall_64+0x3a/0xb0
<4> [188.936859] entry_SYSCALL_64_after_hwframe+0x44/0xae
If the shared object has changed during the RCU unlocked period
callers will correctly handle the restart on the next iteration.
Signed-off-by: Tvrtko Ursulin
Fixes: 96601e8a4755 ("dma-buf: use new iterator in
dma_resv_copy_fences")
Fixes: d3c80698c9f5 ("dma-buf: use new iterator in
dma_resv_get_fences v3")
Closes:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Fintel%2F-%2Fissues%2F4274data=04%7C01%7Cchristian.koenig%40amd.com%7Cc22feea06a3f4285cdac08d98a495984%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692870805160909%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=6oPR30sWnJe04I4GlhhvJWX3QvwKFIOMW1uOIyWZFOE%3Dreserved=0
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Maybe we should remove cursor->fences altogether, but either way the
patch is Reviewed-by: Christian König
Please push to drm-misc-next ASAP.
Not sure I can or if my push permissions are limited to Intel
branches. I can try once CI gives a green light.
If it doesn't work just ping me and I will push it.
Thanks,
Christian.
Regards,
Tvrtko
Thanks,
Christian.
---
drivers/dma-buf/dma-resv.c | 18 ++
include/linux/dma-resv.h | 5 -
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index a480af9581bd..7b6d881c8904 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -333,10 +333,14 @@ static void
dma_resv_iter_restart_unlocked(struct dma_resv_iter *cursor)
{
cursor->seq = read_seqcount_begin(>obj->seq);
cursor->index = -1;
- if (cursor->all_fences)
+ cursor->shared_count = 0;
+ if (cursor->all_fences) {
cursor->fences = dma_resv_shared_list(cursor->obj);
- else
+ if (cursor->fences)
+ cursor->shared_count = cursor->fences->shared_count;
+ } else {
Re: [PATCH] dma-buf: Update obsoluted comments on dma_buf_vmap/vunmap()
Am 08.10.21 um 13:20 schrieb Shunsuke Mie: A comment for the dma_buf_vmap/vunmap() is not catching up a corresponding implementation. Signed-off-by: Shunsuke Mie Reviewed-by: Christian König --- drivers/dma-buf/dma-buf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index beb504a92d60..7b619998f03a 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1052,8 +1052,8 @@ EXPORT_SYMBOL_GPL(dma_buf_move_notify); * * Interfaces:: * - * void \*dma_buf_vmap(struct dma_buf \*dmabuf) - * void dma_buf_vunmap(struct dma_buf \*dmabuf, void \*vaddr) + * void \*dma_buf_vmap(struct dma_buf \*dmabuf, struct dma_buf_map \*map) + * void dma_buf_vunmap(struct dma_buf \*dmabuf, struct dma_buf_map \*map) * * The vmap call can fail if there is no vmap support in the exporter, or if * it runs out of vmalloc space. Note that the dma-buf layer keeps a reference
Re: [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling
[AMD Official Use Only] Thanks, Greg and Jani. So I have to do the exact opposite. We do have some NULL dentry check in the drm code. I will remove those instead. Regards, Nirmoy From: Greg KH Sent: Friday, October 8, 2021 1:07 PM To: Jani Nikula Cc: Das, Nirmoy ; dri-devel@lists.freedesktop.org ; intel-...@lists.freedesktop.org ; Maarten Lankhorst ; Maxime Ripard ; Thomas Zimmermann ; David Airlie ; Daniel Vetter Subject: Re: [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling On Fri, Oct 08, 2021 at 12:40:47PM +0300, Jani Nikula wrote: > On Fri, 08 Oct 2021, Nirmoy Das wrote: > > Debugfs API returns encoded error instead of NULL. > > This patch cleanups drm debugfs error handling to > > properly set dri and its minor's root dentry to NULL. > > > > Also do not error out if dri/minor debugfs directory > > creation fails as a debugfs error is not a fatal error. > > Cc: Greg > > I thought this is the opposite of what Greg's been telling everyone to > do with debugfs. Yes, that is not good. You should never care about the result of a debugfs_create* call. Just take the result, and if it is a directory, save it off to use it for creating a file, no need to check anything. And then throw it away, later, when you want to remove the directory, look it up with a call to debugfs_lookup() and pass that to debugfs_remove() (which does so recursively). There should never be a need to save, or check, the result of any debugfs call. If so, odds are it is being used incorrectly. thanks, greg k-h
Re: [PATCH v11, 0/2] soc: mediatek: mmsys: add mt8192 mmsys support
On 08/10/2021 04:05, Yongqiang Niu wrote: base v5.15 Yongqiang Niu (2): soc: mediatek: mmsys: add comp OVL_2L2/POSTMASK/RDMA4 soc: mediatek: mmsys: Add mt8192 mmsys routing table I'm a bit puzzled that you keep on sending this series while I accepted an older one long time ago: https://lore.kernel.org/lkml/e4afa712-9936-15fc-ad43-576948758...@gmail.com/ As you don't provide a changelog I'm not able to find out what has changed. I also asked you to double check if the fixup I did was correct, but you never answered. If there are anything to fix for this series that's not in my tree yet, please send a follow-up patch. Regards, Matthias drivers/soc/mediatek/mt8192-mmsys.h| 77 ++ drivers/soc/mediatek/mtk-mmsys.c | 11 include/linux/soc/mediatek/mtk-mmsys.h | 3 + 3 files changed, 91 insertions(+) create mode 100644 drivers/soc/mediatek/mt8192-mmsys.h
Re: [PATCH v10, 2/5] drm/mediatek: add component POSTMASK
On 08/10/2021 04:09, yongqiang.niu wrote:
On Fri, 2021-10-01 at 13:00 +0200, Dafna Hirschfeld wrote:
On 30.09.21 17:52, Yongqiang Niu wrote:
This patch add component POSTMASK.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
---
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c | 102 ++-
-
drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.h | 1 +
2 files changed, 73 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
index 4a2abcf3e5f9..89170ad825fd 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_ddp_comp.c
@@ -62,6 +62,12 @@
#define DITHER_ADD_LSHIFT_G(x) (((x) & 0x7) <<
4)
#define DITHER_ADD_RSHIFT_G(x) (((x) & 0x7) <<
0)
+#define DISP_POSTMASK_EN 0x
+#define POSTMASK_ENBIT(0)
+#define DISP_POSTMASK_CFG 0x0020
+#define POSTMASK_RELAY_MODEBIT(0)
+#define DISP_POSTMASK_SIZE 0x0030
+
struct mtk_ddp_comp_dev {
struct clk *clk;
void __iomem *regs;
@@ -214,6 +220,32 @@ static void mtk_dither_stop(struct device
*dev)
writel_relaxed(0x0, priv->regs + DISP_DITHER_EN);
}
+static void mtk_postmask_config(struct device *dev, unsigned int
w,
+ unsigned int h, unsigned int vrefresh,
+ unsigned int bpc, struct cmdq_pkt
*cmdq_pkt)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ mtk_ddp_write(cmdq_pkt, w << 16 | h, >cmdq_reg, priv-
regs,
+ DISP_POSTMASK_SIZE);
+ mtk_ddp_write(cmdq_pkt, POSTMASK_RELAY_MODE, >cmdq_reg,
+ priv->regs, DISP_POSTMASK_CFG);
+}
+
+static void mtk_postmask_start(struct device *dev)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ writel(POSTMASK_EN, priv->regs + DISP_POSTMASK_EN);
+}
+
+static void mtk_postmask_stop(struct device *dev)
+{
+ struct mtk_ddp_comp_dev *priv = dev_get_drvdata(dev);
+
+ writel_relaxed(0x0, priv->regs + DISP_POSTMASK_EN);
+}
+
static const struct mtk_ddp_comp_funcs ddp_aal = {
.clk_enable = mtk_aal_clk_enable,
.clk_disable = mtk_aal_clk_disable,
@@ -289,6 +321,14 @@ static const struct mtk_ddp_comp_funcs ddp_ovl
= {
.bgclr_in_off = mtk_ovl_bgclr_in_off,
};
+static const struct mtk_ddp_comp_funcs ddp_postmask = {
+ .clk_enable = mtk_ddp_clk_enable,
+ .clk_disable = mtk_ddp_clk_disable,
+ .config = mtk_postmask_config,
+ .start = mtk_postmask_start,
+ .stop = mtk_postmask_stop,
+};
+
static const struct mtk_ddp_comp_funcs ddp_rdma = {
.clk_enable = mtk_rdma_clk_enable,
.clk_disable = mtk_rdma_clk_disable,
@@ -324,6 +364,7 @@ static const char * const
mtk_ddp_comp_stem[MTK_DDP_COMP_TYPE_MAX] = {
[MTK_DISP_MUTEX] = "mutex",
[MTK_DISP_OD] = "od",
[MTK_DISP_BLS] = "bls",
+ [MTK_DISP_POSTMASK] = "postmask",
};
struct mtk_ddp_comp_match {
@@ -333,36 +374,37 @@ struct mtk_ddp_comp_match {
};
static const struct mtk_ddp_comp_match
mtk_ddp_matches[DDP_COMPONENT_ID_MAX] = {
- [DDP_COMPONENT_AAL0]= { MTK_DISP_AAL, 0, _aal
},
- [DDP_COMPONENT_AAL1]= { MTK_DISP_AAL, 1, _aal
},
- [DDP_COMPONENT_BLS] = { MTK_DISP_BLS, 0, NULL },
- [DDP_COMPONENT_CCORR] = { MTK_DISP_CCORR, 0,
_ccorr },
- [DDP_COMPONENT_COLOR0] = { MTK_DISP_COLOR, 0,
_color },
- [DDP_COMPONENT_COLOR1] = { MTK_DISP_COLOR, 1,
_color },
- [DDP_COMPONENT_DITHER] = { MTK_DISP_DITHER,0,
_dither },
- [DDP_COMPONENT_DPI0]= { MTK_DPI,0, _dpi
},
- [DDP_COMPONENT_DPI1]= { MTK_DPI,1, _dpi
},
- [DDP_COMPONENT_DSI0]= { MTK_DSI,0, _dsi
},
- [DDP_COMPONENT_DSI1]= { MTK_DSI,1, _dsi
},
- [DDP_COMPONENT_DSI2]= { MTK_DSI,2, _dsi
},
- [DDP_COMPONENT_DSI3]= { MTK_DSI,3, _dsi
},
- [DDP_COMPONENT_GAMMA] = { MTK_DISP_GAMMA, 0,
_gamma },
- [DDP_COMPONENT_OD0] = { MTK_DISP_OD,0, _od },
- [DDP_COMPONENT_OD1] = { MTK_DISP_OD,1, _od },
- [DDP_COMPONENT_OVL0]= { MTK_DISP_OVL, 0, _ovl
},
- [DDP_COMPONENT_OVL1]= { MTK_DISP_OVL, 1, _ovl
},
- [DDP_COMPONENT_OVL_2L0] = { MTK_DISP_OVL_2L,0, _ovl
},
- [DDP_COMPONENT_OVL_2L1] = { MTK_DISP_OVL_2L,1, _ovl
},
- [DDP_COMPONENT_OVL_2L2] = { MTK_DISP_OVL_2L,2, _ovl },
- [DDP_COMPONENT_PWM0]= { MTK_DISP_PWM, 0, NULL },
- [DDP_COMPONENT_PWM1]= { MTK_DISP_PWM, 1, NULL },
- [DDP_COMPONENT_PWM2]= { MTK_DISP_PWM, 2, NULL },
- [DDP_COMPONENT_RDMA0] = {
Re: [PATCH v10, 4/5] soc: mediatek: add mtk mutex support for MT8192
On 30/09/2021 17:52, Yongqiang Niu wrote:
Add mtk mutex support for MT8192 SoC.
Signed-off-by: Yongqiang Niu
Signed-off-by: Hsin-Yi Wang
Reviewed-by: CK Hu
Applied to v5.15-next/soc
Thanks!
---
drivers/soc/mediatek/mtk-mutex.c | 35
1 file changed, 35 insertions(+)
diff --git a/drivers/soc/mediatek/mtk-mutex.c b/drivers/soc/mediatek/mtk-mutex.c
index 2e4bcc300576..2ca55bb5a8be 100644
--- a/drivers/soc/mediatek/mtk-mutex.c
+++ b/drivers/soc/mediatek/mtk-mutex.c
@@ -39,6 +39,18 @@
#define MT8167_MUTEX_MOD_DISP_DITHER 15
#define MT8167_MUTEX_MOD_DISP_UFOE16
+#define MT8192_MUTEX_MOD_DISP_OVL0 0
+#define MT8192_MUTEX_MOD_DISP_OVL0_2L 1
+#define MT8192_MUTEX_MOD_DISP_RDMA02
+#define MT8192_MUTEX_MOD_DISP_COLOR0 4
+#define MT8192_MUTEX_MOD_DISP_CCORR0 5
+#define MT8192_MUTEX_MOD_DISP_AAL0 6
+#define MT8192_MUTEX_MOD_DISP_GAMMA0 7
+#define MT8192_MUTEX_MOD_DISP_POSTMASK08
+#define MT8192_MUTEX_MOD_DISP_DITHER0 9
+#define MT8192_MUTEX_MOD_DISP_OVL2_2L 16
+#define MT8192_MUTEX_MOD_DISP_RDMA417
+
#define MT8183_MUTEX_MOD_DISP_RDMA0 0
#define MT8183_MUTEX_MOD_DISP_RDMA1 1
#define MT8183_MUTEX_MOD_DISP_OVL09
@@ -214,6 +226,20 @@ static const unsigned int
mt8183_mutex_mod[DDP_COMPONENT_ID_MAX] = {
[DDP_COMPONENT_WDMA0] = MT8183_MUTEX_MOD_DISP_WDMA0,
};
+static const unsigned int mt8192_mutex_mod[DDP_COMPONENT_ID_MAX] = {
+ [DDP_COMPONENT_AAL0] = MT8192_MUTEX_MOD_DISP_AAL0,
+ [DDP_COMPONENT_CCORR] = MT8192_MUTEX_MOD_DISP_CCORR0,
+ [DDP_COMPONENT_COLOR0] = MT8192_MUTEX_MOD_DISP_COLOR0,
+ [DDP_COMPONENT_DITHER] = MT8192_MUTEX_MOD_DISP_DITHER0,
+ [DDP_COMPONENT_GAMMA] = MT8192_MUTEX_MOD_DISP_GAMMA0,
+ [DDP_COMPONENT_POSTMASK0] = MT8192_MUTEX_MOD_DISP_POSTMASK0,
+ [DDP_COMPONENT_OVL0] = MT8192_MUTEX_MOD_DISP_OVL0,
+ [DDP_COMPONENT_OVL_2L0] = MT8192_MUTEX_MOD_DISP_OVL0_2L,
+ [DDP_COMPONENT_OVL_2L2] = MT8192_MUTEX_MOD_DISP_OVL2_2L,
+ [DDP_COMPONENT_RDMA0] = MT8192_MUTEX_MOD_DISP_RDMA0,
+ [DDP_COMPONENT_RDMA4] = MT8192_MUTEX_MOD_DISP_RDMA4,
+};
+
static const unsigned int mt2712_mutex_sof[MUTEX_SOF_DSI3 + 1] = {
[MUTEX_SOF_SINGLE_MODE] = MUTEX_SOF_SINGLE_MODE,
[MUTEX_SOF_DSI0] = MUTEX_SOF_DSI0,
@@ -275,6 +301,13 @@ static const struct mtk_mutex_data
mt8183_mutex_driver_data = {
.no_clk = true,
};
+static const struct mtk_mutex_data mt8192_mutex_driver_data = {
+ .mutex_mod = mt8192_mutex_mod,
+ .mutex_sof = mt8183_mutex_sof,
+ .mutex_mod_reg = MT8183_MUTEX0_MOD0,
+ .mutex_sof_reg = MT8183_MUTEX0_SOF0,
+};
+
struct mtk_mutex *mtk_mutex_get(struct device *dev)
{
struct mtk_mutex_ctx *mtx = dev_get_drvdata(dev);
@@ -507,6 +540,8 @@ static const struct of_device_id mutex_driver_dt_match[] = {
.data = _mutex_driver_data},
{ .compatible = "mediatek,mt8183-disp-mutex",
.data = _mutex_driver_data},
+ { .compatible = "mediatek,mt8192-disp-mutex",
+ .data = _mutex_driver_data},
{},
};
MODULE_DEVICE_TABLE(of, mutex_driver_dt_match);
[PATCH] dma-buf: Update obsoluted comments on dma_buf_vmap/vunmap()
A comment for the dma_buf_vmap/vunmap() is not catching up a corresponding implementation. Signed-off-by: Shunsuke Mie --- drivers/dma-buf/dma-buf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index beb504a92d60..7b619998f03a 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1052,8 +1052,8 @@ EXPORT_SYMBOL_GPL(dma_buf_move_notify); * * Interfaces:: * - * void \*dma_buf_vmap(struct dma_buf \*dmabuf) - * void dma_buf_vunmap(struct dma_buf \*dmabuf, void \*vaddr) + * void \*dma_buf_vmap(struct dma_buf \*dmabuf, struct dma_buf_map \*map) + * void dma_buf_vunmap(struct dma_buf \*dmabuf, struct dma_buf_map \*map) * * The vmap call can fail if there is no vmap support in the exporter, or if * it runs out of vmalloc space. Note that the dma-buf layer keeps a reference -- 2.17.1
DSI Bridge switching
Hi, I think this seems to be a known use case for industrial these days with i.mx8m. The host DSI would configure with two bridges one for DSI to LVDS (SN65DSI83) and another for DSI to HDMI Out (ADV7535). Technically we can use only one bridge at a time as host DSI support single out port. So we can have two separate device tree files for LVDS and HDMI and load them static. But, one of the use cases is to support both of them in single dts, and - Turn On LVDS (default) - Turn Off LVDS then Turn On HDMI when cable plug-in. The HDMI event can be detected via some HDMI-INT GPIO on-board design. The possible solution, I'm thinking of adding LVDS on port 1, HDMI on port 2 in the DSI host node, and trying to attach the respective bridge based on HDMI-INT like repeating the bridge attachment cycle based on the HDMI-INT. Can it be possible to do bridge attachment at runtime? something like a bridge hotplug event? or any other possible solutions? Any suggestions? Thanks, Jagan.
Re: [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling
On Fri, Oct 08, 2021 at 12:40:47PM +0300, Jani Nikula wrote: > On Fri, 08 Oct 2021, Nirmoy Das wrote: > > Debugfs API returns encoded error instead of NULL. > > This patch cleanups drm debugfs error handling to > > properly set dri and its minor's root dentry to NULL. > > > > Also do not error out if dri/minor debugfs directory > > creation fails as a debugfs error is not a fatal error. > > Cc: Greg > > I thought this is the opposite of what Greg's been telling everyone to > do with debugfs. Yes, that is not good. You should never care about the result of a debugfs_create* call. Just take the result, and if it is a directory, save it off to use it for creating a file, no need to check anything. And then throw it away, later, when you want to remove the directory, look it up with a call to debugfs_lookup() and pass that to debugfs_remove() (which does so recursively). There should never be a need to save, or check, the result of any debugfs call. If so, odds are it is being used incorrectly. thanks, greg k-h
Re: [PATCH] Revert "drm/fb-helper: improve DRM fbdev emulation device names"
On Fri, Oct 08, 2021 at 09:17:08AM +0200, Javier Martinez Canillas wrote:
> This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a.
>
> That change attempted to improve the DRM drivers fbdev emulation device
> names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb.
>
> But unfortunately there are user-space programs, such as pm-utils that
> query that information and so broke after the mentioned commit. Since
> the names in /proc/fb are used programs that consider it an ABI, let's
> restore the old names even when this lead to silly naming like the one
> mentioned above as an example.
The usage Johannes listed was this specificially:
using_kms() { grep -q -E '(nouveau|drm)fb' /proc/fb; }
So it actually looks like Daniel's
commit f243dd06180a ("drm/nouveau: Use drm_fb_helper_fill_info")
also broke the abi. But for the pm-utils use case at least
just having the "drmfb" in there should cover even nouveau.
Cc: sta...@vger.kernel.org
Reviewed-by: Ville Syrjälä
>
> Reported-by: Johannes Stezenbach
> Signed-off-by: Javier Martinez Canillas
> ---
>
> drivers/gpu/drm/drm_fb_helper.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c
> index 3ab07832104..8993b02e783 100644
> --- a/drivers/gpu/drm/drm_fb_helper.c
> +++ b/drivers/gpu/drm/drm_fb_helper.c
> @@ -1737,7 +1737,7 @@ void drm_fb_helper_fill_info(struct fb_info *info,
> sizes->fb_width, sizes->fb_height);
>
> info->par = fb_helper;
> - snprintf(info->fix.id, sizeof(info->fix.id), "%s",
> + snprintf(info->fix.id, sizeof(info->fix.id), "%sdrmfb",
>fb_helper->dev->driver->name);
>
> }
> --
> 2.31.1
--
Ville Syrjälä
Intel
Re: [PATCH v6 2/3] arm64: tegra: Add NVDEC to Tegra186/194 device trees
On 10/6/21 9:18 PM, Thierry Reding wrote: On Thu, Sep 16, 2021 at 05:55:16PM +0300, Mikko Perttunen wrote: Add a device tree node for NVDEC on Tegra186, and device tree nodes for NVDEC and NVDEC1 on Tegra194. Signed-off-by: Mikko Perttunen --- v5: * Change from nvidia,instance to nvidia,host1x-class v4: * Add dma-coherent markers v3: * Change read2 to read-1 v2: * Add NVDECSRD1 memory client * Add also to T194 (both NVDEC0/1) --- arch/arm64/boot/dts/nvidia/tegra186.dtsi | 16 ++ arch/arm64/boot/dts/nvidia/tegra194.dtsi | 38 2 files changed, 54 insertions(+) The driver patch adds support for Tegra210, so could we also add NVDEC entries for that? Thierry Yes. I don't have my T210 system set up right now to verify, though, and I don't have time to look at this in the next few weeks. Mikko
Re: [PATCH] dma-resv: Fix dma_resv_get_fences and dma_resv_copy_fences after conversion
On 08/10/2021 11:21, Christian König wrote:
Am 08.10.21 um 11:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Cache the count of shared fences in the iterator to avoid dereferencing
the dma_resv_object outside the RCU protection. Otherwise iterator and
its
users can observe an incosistent state which makes it impossible to use
safely.
Ah, of course! I've been staring at the code the whole morning and
couldn't see it.
Going to write a testcase to cover that.
Such as:
<6> [187.517041] [IGT] gem_sync: executing
<7> [187.536343] i915 :00:02.0: [drm:i915_gem_context_create_ioctl
[i915]] HW context 1 created
<7> [187.536793] i915 :00:02.0: [drm:i915_gem_context_create_ioctl
[i915]] HW context 1 created
<6> [187.551235] [IGT] gem_sync: starting subtest basic-many-each
<1> [188.935462] BUG: kernel NULL pointer dereference, address:
0010
<1> [188.935485] #PF: supervisor write access in kernel mode
<1> [188.935495] #PF: error_code(0x0002) - not-present page
<6> [188.935504] PGD 0 P4D 0
<4> [188.935512] Oops: 0002 [#1] PREEMPT SMP NOPTI
<4> [188.935521] CPU: 2 PID: 1467 Comm: gem_sync Not tainted
5.15.0-rc4-CI-Patchwork_21264+ #1
<4> [188.935535] Hardware name: /NUC6CAYB, BIOS
AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018
<4> [188.935546] RIP: 0010:dma_resv_get_fences+0x116/0x2d0
<4> [188.935560] Code: 10 85 c0 7f c9 be 03 00 00 00 e8 15 8b df ff eb
bd e8 8e c6 ff ff eb b6 41 8b 04 24 49 8b 55 00 48 89 e7 8d 48 01 41
89 0c 24 <4c> 89 34 c2 e8 41 f2 ff ff 49 89 c6 48 85 c0 75 8c 48 8b 44
24 10
<4> [188.935583] RSP: 0018:c900011dbcc8 EFLAGS: 00010202
<4> [188.935593] RAX: RBX: RCX:
0001
<4> [188.935603] RDX: 0010 RSI: 822e343c RDI:
c900011dbcc8
<4> [188.935613] RBP: c900011dbd48 R08: 88812d255bb8 R09:
fffe
<4> [188.935623] R10: 0001 R11: R12:
c900011dbd44
<4> [188.935633] R13: c900011dbd50 R14: 888113d29cc0 R15:
<4> [188.935643] FS: 7f68d17e9700() GS:88827790()
knlGS:
<4> [188.935655] CS: 0010 DS: ES: CR0: 80050033
<4> [188.935665] CR2: 0010 CR3: 00012d0a4000 CR4:
003506e0
<4> [188.935676] Call Trace:
<4> [188.935685] i915_gem_object_wait+0x1ff/0x410 [i915]
<4> [188.935988] i915_gem_wait_ioctl+0xf2/0x2a0 [i915]
<4> [188.936272] ? i915_gem_object_wait+0x410/0x410 [i915]
<4> [188.936533] drm_ioctl_kernel+0xae/0x140
<4> [188.936546] drm_ioctl+0x201/0x3d0
<4> [188.936555] ? i915_gem_object_wait+0x410/0x410 [i915]
<4> [188.936820] ? __fget_files+0xc2/0x1c0
<4> [188.936830] ? __fget_files+0xda/0x1c0
<4> [188.936839] __x64_sys_ioctl+0x6d/0xa0
<4> [188.936848] do_syscall_64+0x3a/0xb0
<4> [188.936859] entry_SYSCALL_64_after_hwframe+0x44/0xae
If the shared object has changed during the RCU unlocked period
callers will correctly handle the restart on the next iteration.
Signed-off-by: Tvrtko Ursulin
Fixes: 96601e8a4755 ("dma-buf: use new iterator in dma_resv_copy_fences")
Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences
v3")
Closes:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Fintel%2F-%2Fissues%2F4274data=04%7C01%7Cchristian.koenig%40amd.com%7C0a73b5d07f5f44cdc5a808d98a4109f9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692834972816537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=jhcO2Q8bGhLTW7b4%2BNn4TE3UCwBbAcQVuceJEwDK0fg%3Dreserved=0
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Maybe we should remove cursor->fences altogether, but either way the
patch is Reviewed-by: Christian König
Please push to drm-misc-next ASAP.
Not sure I can or if my push permissions are limited to Intel branches.
I can try once CI gives a green light.
Regards,
Tvrtko
Thanks,
Christian.
---
drivers/dma-buf/dma-resv.c | 18 ++
include/linux/dma-resv.h | 5 -
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index a480af9581bd..7b6d881c8904 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -333,10 +333,14 @@ static void
dma_resv_iter_restart_unlocked(struct dma_resv_iter *cursor)
{
cursor->seq = read_seqcount_begin(>obj->seq);
cursor->index = -1;
- if (cursor->all_fences)
+ cursor->shared_count = 0;
+ if (cursor->all_fences) {
cursor->fences = dma_resv_shared_list(cursor->obj);
- else
+ if (cursor->fences)
+ cursor->shared_count = cursor->fences->shared_count;
+ } else {
cursor->fences = NULL;
+ }
cursor->is_restarted = true;
}
@@ -363,7 +367,7 @@ static void
Re: [PATCH 3/5] drm/radeon: check dri root before debugfs init
[AMD Official Use Only]
I sent all the patches to dr-devel. I think there is an issue with our email
server. Thunderbird is asking for a password every few minutes.
https://patchwork.freedesktop.org/series/95603/
Nirmoy
[sending this from my browser]
From: Koenig, Christian
Sent: Friday, October 8, 2021 12:23 PM
To: Das, Nirmoy ; dri-devel@lists.freedesktop.org
Cc: intel-...@lists.freedesktop.org ; Deucher,
Alexander ; Pan, Xinhui
Subject: Re: [PATCH 3/5] drm/radeon: check dri root before debugfs init
Am 08.10.21 um 11:17 schrieb Nirmoy Das:
> Return early if dri minor root dentry is NULL.
>
> CC: Alex Deucher
> CC: "Christian König"
> CC: "Pan, Xinhui"
>
> Signed-off-by: Nirmoy Das
Acked-by: Christian König
Where are the other patches from the series?
Thanks,
Christian.
> ---
> drivers/gpu/drm/radeon/r100.c | 9 +
> drivers/gpu/drm/radeon/r300.c | 3 +++
> drivers/gpu/drm/radeon/r420.c | 3 +++
> drivers/gpu/drm/radeon/r600.c | 3 +++
> drivers/gpu/drm/radeon/radeon_dp_mst.c | 3 +++
> drivers/gpu/drm/radeon/radeon_fence.c | 3 +++
> drivers/gpu/drm/radeon/radeon_gem.c| 3 +++
> drivers/gpu/drm/radeon/radeon_ib.c | 3 +++
> drivers/gpu/drm/radeon/radeon_pm.c | 5 -
> drivers/gpu/drm/radeon/radeon_ring.c | 3 +++
> drivers/gpu/drm/radeon/radeon_ttm.c| 3 +++
> drivers/gpu/drm/radeon/rs400.c | 3 +++
> drivers/gpu/drm/radeon/rv515.c | 3 +++
> 13 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
> index 2dd85ba1faa2..ae6c95b34013 100644
> --- a/drivers/gpu/drm/radeon/r100.c
> +++ b/drivers/gpu/drm/radeon/r100.c
> @@ -3059,6 +3059,9 @@ void r100_debugfs_rbbm_init(struct radeon_device *rdev)
> #if defined(CONFIG_DEBUG_FS)
>struct dentry *root = rdev->ddev->primary->debugfs_root;
>
> + if (!root)
> + return;
> +
>debugfs_create_file("r100_rbbm_info", 0444, root, rdev,
>_debugfs_rbbm_info_fops);
> #endif
> @@ -3069,6 +3072,9 @@ void r100_debugfs_cp_init(struct radeon_device *rdev)
> #if defined(CONFIG_DEBUG_FS)
>struct dentry *root = rdev->ddev->primary->debugfs_root;
>
> + if (!root)
> + return;
> +
>debugfs_create_file("r100_cp_ring_info", 0444, root, rdev,
>_debugfs_cp_ring_info_fops);
>debugfs_create_file("r100_cp_csq_fifo", 0444, root, rdev,
> @@ -3081,6 +3087,9 @@ void r100_debugfs_mc_info_init(struct radeon_device
> *rdev)
> #if defined(CONFIG_DEBUG_FS)
>struct dentry *root = rdev->ddev->primary->debugfs_root;
>
> + if (!root)
> + return;
> +
>debugfs_create_file("r100_mc_info", 0444, root, rdev,
>_debugfs_mc_info_fops);
> #endif
> diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
> index 621ff174dff3..b22969e2394f 100644
> --- a/drivers/gpu/drm/radeon/r300.c
> +++ b/drivers/gpu/drm/radeon/r300.c
> @@ -618,6 +618,9 @@ static void rv370_debugfs_pcie_gart_info_init(struct
> radeon_device *rdev)
> #if defined(CONFIG_DEBUG_FS)
>struct dentry *root = rdev->ddev->primary->debugfs_root;
>
> + if (!root)
> + return;
> +
>debugfs_create_file("rv370_pcie_gart_info", 0444, root, rdev,
>_debugfs_pcie_gart_info_fops);
> #endif
> diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
> index 7e6320e8c6a0..cdb4ac3e346b 100644
> --- a/drivers/gpu/drm/radeon/r420.c
> +++ b/drivers/gpu/drm/radeon/r420.c
> @@ -494,6 +494,9 @@ void r420_debugfs_pipes_info_init(struct radeon_device
> *rdev)
> #if defined(CONFIG_DEBUG_FS)
>struct dentry *root = rdev->ddev->primary->debugfs_root;
>
> + if (!root)
> + return;
> +
>debugfs_create_file("r420_pipes_info", 0444, root, rdev,
>_debugfs_pipes_info_fops);
> #endif
> diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
> index ca3fcae2adb5..d8f525cf0c3b 100644
> --- a/drivers/gpu/drm/radeon/r600.c
> +++ b/drivers/gpu/drm/radeon/r600.c
> @@ -4360,6 +4360,9 @@ static void r600_debugfs_mc_info_init(struct
> radeon_device *rdev)
> #if defined(CONFIG_DEBUG_FS)
>struct dentry *root = rdev->ddev->primary->debugfs_root;
>
> + if (!root)
> + return;
> +
>debugfs_create_file("r600_mc_info", 0444, root, rdev,
>_debugfs_mc_info_fops);
>
> diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> index ec867fa880a4..cf06da89bb7c 100644
> --- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
> +++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
> @@ -771,6 +771,9 @@ void radeon_mst_debugfs_init(struct radeon_device *rdev)
> #if defined(CONFIG_DEBUG_FS)
>struct dentry *root =
Re: [PATCH v2] dma-buf: acquire name lock before read/write dma_buf.name
Am 08.10.21 um 09:54 schrieb guangming@mediatek.com: From: Guangming Cao Because dma-buf.name can be freed in func: "dma_buf_set_name", so, we need to acquire lock first before we read/write dma_buf.name to prevent Use After Free(UAF) issue. Signed-off-by: Guangming Cao Reviewed-by: Christian König Going to push that upstream if nobody else objects. Thanks, Christian. --- drivers/dma-buf/dma-buf.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 511fe0d217a0..a7f6fd13a635 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -1372,6 +1372,8 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused) if (ret) goto error_unlock; + + spin_lock(_obj->name_lock); seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\t%08lu\t%s\n", buf_obj->size, buf_obj->file->f_flags, buf_obj->file->f_mode, @@ -1379,6 +1381,7 @@ static int dma_buf_debug_show(struct seq_file *s, void *unused) buf_obj->exp_name, file_inode(buf_obj->file)->i_ino, buf_obj->name ?: ""); + spin_unlock(_obj->name_lock); robj = buf_obj->resv; fence = dma_resv_excl_fence(robj);
Re: [PATCH 3/5] drm/radeon: check dri root before debugfs init
Am 08.10.21 um 11:17 schrieb Nirmoy Das:
Return early if dri minor root dentry is NULL.
CC: Alex Deucher
CC: "Christian König"
CC: "Pan, Xinhui"
Signed-off-by: Nirmoy Das
Acked-by: Christian König
Where are the other patches from the series?
Thanks,
Christian.
---
drivers/gpu/drm/radeon/r100.c | 9 +
drivers/gpu/drm/radeon/r300.c | 3 +++
drivers/gpu/drm/radeon/r420.c | 3 +++
drivers/gpu/drm/radeon/r600.c | 3 +++
drivers/gpu/drm/radeon/radeon_dp_mst.c | 3 +++
drivers/gpu/drm/radeon/radeon_fence.c | 3 +++
drivers/gpu/drm/radeon/radeon_gem.c| 3 +++
drivers/gpu/drm/radeon/radeon_ib.c | 3 +++
drivers/gpu/drm/radeon/radeon_pm.c | 5 -
drivers/gpu/drm/radeon/radeon_ring.c | 3 +++
drivers/gpu/drm/radeon/radeon_ttm.c| 3 +++
drivers/gpu/drm/radeon/rs400.c | 3 +++
drivers/gpu/drm/radeon/rv515.c | 3 +++
13 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 2dd85ba1faa2..ae6c95b34013 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3059,6 +3059,9 @@ void r100_debugfs_rbbm_init(struct radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r100_rbbm_info", 0444, root, rdev,
_debugfs_rbbm_info_fops);
#endif
@@ -3069,6 +3072,9 @@ void r100_debugfs_cp_init(struct radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r100_cp_ring_info", 0444, root, rdev,
_debugfs_cp_ring_info_fops);
debugfs_create_file("r100_cp_csq_fifo", 0444, root, rdev,
@@ -3081,6 +3087,9 @@ void r100_debugfs_mc_info_init(struct radeon_device
*rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r100_mc_info", 0444, root, rdev,
_debugfs_mc_info_fops);
#endif
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 621ff174dff3..b22969e2394f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -618,6 +618,9 @@ static void rv370_debugfs_pcie_gart_info_init(struct
radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("rv370_pcie_gart_info", 0444, root, rdev,
_debugfs_pcie_gart_info_fops);
#endif
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 7e6320e8c6a0..cdb4ac3e346b 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -494,6 +494,9 @@ void r420_debugfs_pipes_info_init(struct radeon_device
*rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r420_pipes_info", 0444, root, rdev,
_debugfs_pipes_info_fops);
#endif
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index ca3fcae2adb5..d8f525cf0c3b 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -4360,6 +4360,9 @@ static void r600_debugfs_mc_info_init(struct
radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r600_mc_info", 0444, root, rdev,
_debugfs_mc_info_fops);
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index ec867fa880a4..cf06da89bb7c 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -771,6 +771,9 @@ void radeon_mst_debugfs_init(struct radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("radeon_mst_info", 0444, root, rdev,
_debugfs_mst_info_fops);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 73e3117420bf..11f30349de46 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -1006,6 +1006,9 @@ void radeon_debugfs_fence_init(struct radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("radeon_gpu_reset", 0444, root, rdev,
Re: [PATCH] dma-resv: Fix dma_resv_get_fences and dma_resv_copy_fences after conversion
Am 08.10.21 um 11:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Cache the count of shared fences in the iterator to avoid dereferencing
the dma_resv_object outside the RCU protection. Otherwise iterator and its
users can observe an incosistent state which makes it impossible to use
safely.
Ah, of course! I've been staring at the code the whole morning and
couldn't see it.
Going to write a testcase to cover that.
Such as:
<6> [187.517041] [IGT] gem_sync: executing
<7> [187.536343] i915 :00:02.0: [drm:i915_gem_context_create_ioctl [i915]]
HW context 1 created
<7> [187.536793] i915 :00:02.0: [drm:i915_gem_context_create_ioctl [i915]]
HW context 1 created
<6> [187.551235] [IGT] gem_sync: starting subtest basic-many-each
<1> [188.935462] BUG: kernel NULL pointer dereference, address: 0010
<1> [188.935485] #PF: supervisor write access in kernel mode
<1> [188.935495] #PF: error_code(0x0002) - not-present page
<6> [188.935504] PGD 0 P4D 0
<4> [188.935512] Oops: 0002 [#1] PREEMPT SMP NOPTI
<4> [188.935521] CPU: 2 PID: 1467 Comm: gem_sync Not tainted
5.15.0-rc4-CI-Patchwork_21264+ #1
<4> [188.935535] Hardware name: /NUC6CAYB, BIOS
AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018
<4> [188.935546] RIP: 0010:dma_resv_get_fences+0x116/0x2d0
<4> [188.935560] Code: 10 85 c0 7f c9 be 03 00 00 00 e8 15 8b df ff eb bd e8 8e c6 ff
ff eb b6 41 8b 04 24 49 8b 55 00 48 89 e7 8d 48 01 41 89 0c 24 <4c> 89 34 c2 e8 41 f2
ff ff 49 89 c6 48 85 c0 75 8c 48 8b 44 24 10
<4> [188.935583] RSP: 0018:c900011dbcc8 EFLAGS: 00010202
<4> [188.935593] RAX: RBX: RCX:
0001
<4> [188.935603] RDX: 0010 RSI: 822e343c RDI:
c900011dbcc8
<4> [188.935613] RBP: c900011dbd48 R08: 88812d255bb8 R09:
fffe
<4> [188.935623] R10: 0001 R11: R12:
c900011dbd44
<4> [188.935633] R13: c900011dbd50 R14: 888113d29cc0 R15:
<4> [188.935643] FS: 7f68d17e9700() GS:88827790()
knlGS:
<4> [188.935655] CS: 0010 DS: ES: CR0: 80050033
<4> [188.935665] CR2: 0010 CR3: 00012d0a4000 CR4:
003506e0
<4> [188.935676] Call Trace:
<4> [188.935685] i915_gem_object_wait+0x1ff/0x410 [i915]
<4> [188.935988] i915_gem_wait_ioctl+0xf2/0x2a0 [i915]
<4> [188.936272] ? i915_gem_object_wait+0x410/0x410 [i915]
<4> [188.936533] drm_ioctl_kernel+0xae/0x140
<4> [188.936546] drm_ioctl+0x201/0x3d0
<4> [188.936555] ? i915_gem_object_wait+0x410/0x410 [i915]
<4> [188.936820] ? __fget_files+0xc2/0x1c0
<4> [188.936830] ? __fget_files+0xda/0x1c0
<4> [188.936839] __x64_sys_ioctl+0x6d/0xa0
<4> [188.936848] do_syscall_64+0x3a/0xb0
<4> [188.936859] entry_SYSCALL_64_after_hwframe+0x44/0xae
If the shared object has changed during the RCU unlocked period
callers will correctly handle the restart on the next iteration.
Signed-off-by: Tvrtko Ursulin
Fixes: 96601e8a4755 ("dma-buf: use new iterator in dma_resv_copy_fences")
Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3")
Closes:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.freedesktop.org%2Fdrm%2Fintel%2F-%2Fissues%2F4274data=04%7C01%7Cchristian.koenig%40amd.com%7C0a73b5d07f5f44cdc5a808d98a4109f9%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637692834972816537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000sdata=jhcO2Q8bGhLTW7b4%2BNn4TE3UCwBbAcQVuceJEwDK0fg%3Dreserved=0
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Maybe we should remove cursor->fences altogether, but either way the
patch is Reviewed-by: Christian König
Please push to drm-misc-next ASAP.
Thanks,
Christian.
---
drivers/dma-buf/dma-resv.c | 18 ++
include/linux/dma-resv.h | 5 -
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index a480af9581bd..7b6d881c8904 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -333,10 +333,14 @@ static void dma_resv_iter_restart_unlocked(struct
dma_resv_iter *cursor)
{
cursor->seq = read_seqcount_begin(>obj->seq);
cursor->index = -1;
- if (cursor->all_fences)
+ cursor->shared_count = 0;
+ if (cursor->all_fences) {
cursor->fences = dma_resv_shared_list(cursor->obj);
- else
+ if (cursor->fences)
+ cursor->shared_count = cursor->fences->shared_count;
+ } else {
cursor->fences = NULL;
+ }
cursor->is_restarted = true;
}
@@ -363,7 +367,7 @@ static void dma_resv_iter_walk_unlocked(struct dma_resv_iter *cursor)
continue;
} else if (!cursor->fences ||
-
Re: [PATCH v2] drm/i915/gt: move remaining debugfs interfaces into gt
Hi Lucas,
> > I am reproposing this patch exactly as it was proposed initially
> > where the original interfaces are kept where they have been
> > originally placed. It might generate some duplicated code but,
> > well, it's debugfs and I don't see any issue. In the future we
> > can transform the upper interfaces to act upon all the GTs and
> > provide information from all the GTs. This is, for example, how
> > the sysfs interfaces will act.
>
> NACK. We've made this mistake in the past for other debugfs files.
> We don't want to do it again just to maintain 2 separate places for
> one year and then finally realize we want to merge them.
In my opinion it's all about what mistake you like the most
because until we will have multi-gt support in upstream all the
patches come with the "promise" of a follow-up and maintenance
cost.
> > The reason I removed them in V1 is because igt as only user is
> > not a strong reason to keep duplicated code, but as Chris
> > suggested offline:
> >
> > "It's debugfs, igt is the primary consumer. CI has to be bridged over
> > changes to the interfaces it is using in any case, as you want
> > comparable results before/after the patches land.
>
> That doesn't mean you have to copy and paste it. It may mean you
> do the implementation in one of them and the other calls that implementation.
> See how I did the deduplication in commit d0c560316d6f ("drm/i915:
> deduplicate frequency dump on debugfs")
In this case, from a user perspective, which gt is the interface
affecting? is it affecting all the system? or gt 0, 1...? Does
the user know? The maintenance cost is that later you will need
to use for_each_gt and make all those interfaces multitile, and
this would be your "promise".
How are you going to do it then? Will every interface iterate and
perform its own action? When you read, whad do you read? all the
gt values in 'or'? in 'and'? Is there any common strategy? Or
will we have inconsistent behaviors?
In sysfs (where we are left with the same questions) some times
ago I proposoed a common solution for all the upper level files
in order to provide the user with a consistent interface all
along the GTs.
This is my "promise" and until then it's just a matter of what
promise and what mistake you like the most.
> Alternative would be to prepare igt already and then add a Test-with:
> in this patch
> series But I think it makes more sense to support both locations
> for some time and then later
> remove the previous one.
Anyway, I can sure do something similar to how you did it, it
might look prettier but it doesn't exclude a follow-up
improvement.
Thanks for the review,
Andi
[PATCH] dma-resv: Fix dma_resv_get_fences and dma_resv_copy_fences after conversion
From: Tvrtko Ursulin
Cache the count of shared fences in the iterator to avoid dereferencing
the dma_resv_object outside the RCU protection. Otherwise iterator and its
users can observe an incosistent state which makes it impossible to use
safely. Such as:
<6> [187.517041] [IGT] gem_sync: executing
<7> [187.536343] i915 :00:02.0: [drm:i915_gem_context_create_ioctl [i915]]
HW context 1 created
<7> [187.536793] i915 :00:02.0: [drm:i915_gem_context_create_ioctl [i915]]
HW context 1 created
<6> [187.551235] [IGT] gem_sync: starting subtest basic-many-each
<1> [188.935462] BUG: kernel NULL pointer dereference, address: 0010
<1> [188.935485] #PF: supervisor write access in kernel mode
<1> [188.935495] #PF: error_code(0x0002) - not-present page
<6> [188.935504] PGD 0 P4D 0
<4> [188.935512] Oops: 0002 [#1] PREEMPT SMP NOPTI
<4> [188.935521] CPU: 2 PID: 1467 Comm: gem_sync Not tainted
5.15.0-rc4-CI-Patchwork_21264+ #1
<4> [188.935535] Hardware name: /NUC6CAYB, BIOS
AYAPLCEL.86A.0049.2018.0508.1356 05/08/2018
<4> [188.935546] RIP: 0010:dma_resv_get_fences+0x116/0x2d0
<4> [188.935560] Code: 10 85 c0 7f c9 be 03 00 00 00 e8 15 8b df ff eb bd e8 8e
c6 ff ff eb b6 41 8b 04 24 49 8b 55 00 48 89 e7 8d 48 01 41 89 0c 24 <4c> 89 34
c2 e8 41 f2 ff ff 49 89 c6 48 85 c0 75 8c 48 8b 44 24 10
<4> [188.935583] RSP: 0018:c900011dbcc8 EFLAGS: 00010202
<4> [188.935593] RAX: RBX: RCX:
0001
<4> [188.935603] RDX: 0010 RSI: 822e343c RDI:
c900011dbcc8
<4> [188.935613] RBP: c900011dbd48 R08: 88812d255bb8 R09:
fffe
<4> [188.935623] R10: 0001 R11: R12:
c900011dbd44
<4> [188.935633] R13: c900011dbd50 R14: 888113d29cc0 R15:
<4> [188.935643] FS: 7f68d17e9700() GS:88827790()
knlGS:
<4> [188.935655] CS: 0010 DS: ES: CR0: 80050033
<4> [188.935665] CR2: 0010 CR3: 00012d0a4000 CR4:
003506e0
<4> [188.935676] Call Trace:
<4> [188.935685] i915_gem_object_wait+0x1ff/0x410 [i915]
<4> [188.935988] i915_gem_wait_ioctl+0xf2/0x2a0 [i915]
<4> [188.936272] ? i915_gem_object_wait+0x410/0x410 [i915]
<4> [188.936533] drm_ioctl_kernel+0xae/0x140
<4> [188.936546] drm_ioctl+0x201/0x3d0
<4> [188.936555] ? i915_gem_object_wait+0x410/0x410 [i915]
<4> [188.936820] ? __fget_files+0xc2/0x1c0
<4> [188.936830] ? __fget_files+0xda/0x1c0
<4> [188.936839] __x64_sys_ioctl+0x6d/0xa0
<4> [188.936848] do_syscall_64+0x3a/0xb0
<4> [188.936859] entry_SYSCALL_64_after_hwframe+0x44/0xae
If the shared object has changed during the RCU unlocked period
callers will correctly handle the restart on the next iteration.
Signed-off-by: Tvrtko Ursulin
Fixes: 96601e8a4755 ("dma-buf: use new iterator in dma_resv_copy_fences")
Fixes: d3c80698c9f5 ("dma-buf: use new iterator in dma_resv_get_fences v3")
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4274
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-resv.c | 18 ++
include/linux/dma-resv.h | 5 -
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index a480af9581bd..7b6d881c8904 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -333,10 +333,14 @@ static void dma_resv_iter_restart_unlocked(struct
dma_resv_iter *cursor)
{
cursor->seq = read_seqcount_begin(>obj->seq);
cursor->index = -1;
- if (cursor->all_fences)
+ cursor->shared_count = 0;
+ if (cursor->all_fences) {
cursor->fences = dma_resv_shared_list(cursor->obj);
- else
+ if (cursor->fences)
+ cursor->shared_count = cursor->fences->shared_count;
+ } else {
cursor->fences = NULL;
+ }
cursor->is_restarted = true;
}
@@ -363,7 +367,7 @@ static void dma_resv_iter_walk_unlocked(struct
dma_resv_iter *cursor)
continue;
} else if (!cursor->fences ||
- cursor->index >= cursor->fences->shared_count) {
+ cursor->index >= cursor->shared_count) {
cursor->fence = NULL;
break;
@@ -448,10 +452,8 @@ int dma_resv_copy_fences(struct dma_resv *dst, struct
dma_resv *src)
dma_resv_list_free(list);
dma_fence_put(excl);
- if (cursor.fences) {
- unsigned int cnt = cursor.fences->shared_count;
-
- list = dma_resv_list_alloc(cnt);
+ if (cursor.shared_count) {
+ list = dma_resv_list_alloc(cursor.shared_count);
Re: [PATCH] drm/i915: Stop using I915_TILING_* in client blit selftest
On Thu, Sep 30, 2021 at 05:58:16PM -0700, Matt Roper wrote:
> The I915_TILING_* definitions in the uapi header are intended solely for
> tiling modes that are visible to the old de-tiling fence ioctls. Since
> modern hardware does not support de-tiling fences, we should not add new
> definitions for new tiling types going forward. However we do want the
> client blit selftest to eventually cover other new tiling modes (such as
> Tile4), so switch it to using its own enum of tiling modes.
>
> Cc: Ville Syrjälä
> Cc: Stanislav Lisovskiy
> Signed-off-by: Matt Roper
> ---
> .../i915/gem/selftests/i915_gem_client_blt.c | 29 ---
> include/uapi/drm/i915_drm.h | 6
> 2 files changed, 24 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> index ecbcbb86ae1e..8402ed925a69 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_client_blt.c
> @@ -17,13 +17,20 @@
> #include "huge_gem_object.h"
> #include "mock_context.h"
>
> +enum client_tiling {
> + CLIENT_TILING_LINEAR,
> + CLIENT_TILING_X,
> + CLIENT_TILING_Y,
> + CLIENT_NUM_TILING_TYPES
> +};
> +
> #define WIDTH 512
> #define HEIGHT 32
>
> struct blit_buffer {
> struct i915_vma *vma;
> u32 start_val;
> - u32 tiling;
> + enum client_tiling tiling;
> };
>
> struct tiled_blits {
> @@ -53,9 +60,9 @@ static int prepare_blit(const struct tiled_blits *t,
> *cs++ = MI_LOAD_REGISTER_IMM(1);
> *cs++ = i915_mmio_reg_offset(BCS_SWCTRL);
> cmd = (BCS_SRC_Y | BCS_DST_Y) << 16;
> - if (src->tiling == I915_TILING_Y)
> + if (src->tiling == CLIENT_TILING_Y)
> cmd |= BCS_SRC_Y;
> - if (dst->tiling == I915_TILING_Y)
> + if (dst->tiling == CLIENT_TILING_Y)
> cmd |= BCS_DST_Y;
> *cs++ = cmd;
>
> @@ -172,7 +179,7 @@ static int tiled_blits_create_buffers(struct tiled_blits
> *t,
>
> t->buffers[i].vma = vma;
> t->buffers[i].tiling =
> - i915_prandom_u32_max_state(I915_TILING_Y + 1, prng);
> + i915_prandom_u32_max_state(CLIENT_TILING_Y + 1, prng);
> }
>
> return 0;
> @@ -197,17 +204,17 @@ static u64 swizzle_bit(unsigned int bit, u64 offset)
> static u64 tiled_offset(const struct intel_gt *gt,
> u64 v,
> unsigned int stride,
> - unsigned int tiling)
> + enum client_tiling tiling)
> {
> unsigned int swizzle;
> u64 x, y;
>
> - if (tiling == I915_TILING_NONE)
> + if (tiling == CLIENT_TILING_LINEAR)
> return v;
>
> y = div64_u64_rem(v, stride, );
>
> - if (tiling == I915_TILING_X) {
> + if (tiling == CLIENT_TILING_X) {
> v = div64_u64_rem(y, 8, ) * stride * 8;
> v += y * 512;
> v += div64_u64_rem(x, 512, ) << 12;
> @@ -244,12 +251,12 @@ static u64 tiled_offset(const struct intel_gt *gt,
> return v;
> }
>
> -static const char *repr_tiling(int tiling)
> +static const char *repr_tiling(enum client_tiling tiling)
> {
> switch (tiling) {
> - case I915_TILING_NONE: return "linear";
> - case I915_TILING_X: return "X";
> - case I915_TILING_Y: return "Y";
> + case CLIENT_TILING_LINEAR: return "linear";
> + case CLIENT_TILING_X: return "X";
> + case CLIENT_TILING_Y: return "Y";
> default: return "unknown";
> }
> }
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index bde5860b3686..00311a63068e 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1522,6 +1522,12 @@ struct drm_i915_gem_caching {
> #define I915_TILING_NONE 0
> #define I915_TILING_X1
> #define I915_TILING_Y2
> +/*
> + * Do not add new tiling types here. The I915_TILING_* values are for
> + * de-tiling fence registers that no longer exist on modern platforms.
> Although
> + * the hardware may support new types of tiling in general (e.g., Tile4), we
> + * do not need to add them to the uapi that is specific to now-defunct
> ioctls.
> + */
> #define I915_TILING_LAST I915_TILING_Y
I think we should split this one into a separate patch to give it
some visibility. The people who care about gem uapi seem to be in
some kind of early winter hibernation and no one read this.
Apart from that
Reviewed-by: Ville Syrjälä
>
> #define I915_BIT_6_SWIZZLE_NONE 0
> --
> 2.33.0
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 1/5] dri: cleanup debugfs error handling
On Fri, 08 Oct 2021, Nirmoy Das wrote:
> Debugfs API returns encoded error instead of NULL.
> This patch cleanups drm debugfs error handling to
> properly set dri and its minor's root dentry to NULL.
>
> Also do not error out if dri/minor debugfs directory
> creation fails as a debugfs error is not a fatal error.
Cc: Greg
I thought this is the opposite of what Greg's been telling everyone to
do with debugfs.
BR,
Jani.
>
> CC: Maarten Lankhorst
> CC: Maxime Ripard
> CC: Thomas Zimmermann
> CC: David Airlie
> CC: Daniel Vetter
> Signed-off-by: Nirmoy Das
> ---
> drivers/gpu/drm/drm_debugfs.c | 25 +++--
> drivers/gpu/drm/drm_drv.c | 16 ++--
> drivers/gpu/drm/drm_internal.h | 7 +++
> 3 files changed, 36 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index b0a826489488..af275a0c09b4 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -180,6 +180,9 @@ void drm_debugfs_create_files(const struct drm_info_list
> *files, int count,
> struct drm_info_node *tmp;
> int i;
>
> + if (!minor->debugfs_root)
> + return;
> +
> for (i = 0; i < count; i++) {
> u32 features = files[i].driver_features;
>
> @@ -203,7 +206,7 @@ void drm_debugfs_create_files(const struct drm_info_list
> *files, int count,
> }
> EXPORT_SYMBOL(drm_debugfs_create_files);
>
> -int drm_debugfs_init(struct drm_minor *minor, int minor_id,
> +void drm_debugfs_init(struct drm_minor *minor, int minor_id,
>struct dentry *root)
> {
> struct drm_device *dev = minor->dev;
> @@ -212,8 +215,16 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
> INIT_LIST_HEAD(>debugfs_list);
> mutex_init(>debugfs_lock);
> sprintf(name, "%d", minor_id);
> +
> + if (!root)
> + goto error;
> +
> minor->debugfs_root = debugfs_create_dir(name, root);
>
> + if (IS_ERR(minor->debugfs_root))
> + goto error;
> +
> +
> drm_debugfs_create_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES,
>minor->debugfs_root, minor);
>
> @@ -230,7 +241,11 @@ int drm_debugfs_init(struct drm_minor *minor, int
> minor_id,
> if (dev->driver->debugfs_init)
> dev->driver->debugfs_init(minor);
>
> - return 0;
> + return;
> +
> +error:
> + minor->debugfs_root = NULL;
> + return;
> }
>
>
> @@ -241,6 +256,9 @@ int drm_debugfs_remove_files(const struct drm_info_list
> *files, int count,
> struct drm_info_node *tmp;
> int i;
>
> + if (!minor->debugfs_root)
> + return 0;
> +
> mutex_lock(>debugfs_lock);
> for (i = 0; i < count; i++) {
> list_for_each_safe(pos, q, >debugfs_list) {
> @@ -261,6 +279,9 @@ static void drm_debugfs_remove_all_files(struct drm_minor
> *minor)
> {
> struct drm_info_node *node, *tmp;
>
> + if (!minor->debugfs_root)
> + return;
> +
> mutex_lock(>debugfs_lock);
> list_for_each_entry_safe(node, tmp, >debugfs_list, list) {
> debugfs_remove(node->dent);
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 7a5097467ba5..fa57ec2d49bf 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -160,11 +160,7 @@ static int drm_minor_register(struct drm_device *dev,
> unsigned int type)
> if (!minor)
> return 0;
>
> - ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
> - if (ret) {
> - DRM_ERROR("DRM: Failed to initialize /sys/kernel/debug/dri.\n");
> - goto err_debugfs;
> - }
> + drm_debugfs_init(minor, minor->index, drm_debugfs_root);
>
> ret = device_add(minor->kdev);
> if (ret)
> @@ -1050,7 +1046,15 @@ static int __init drm_core_init(void)
> goto error;
> }
>
> - drm_debugfs_root = debugfs_create_dir("dri", NULL);
> + if (!debugfs_initialized()) {
> + drm_debugfs_root = NULL;
> + } else {
> + drm_debugfs_root = debugfs_create_dir("dri", NULL);
> + if (IS_ERR(drm_debugfs_root)) {
> + DRM_WARN("DRM: Failed to initialize
> /sys/kernel/debug/dri.\n");
> + drm_debugfs_root = NULL;
> + }
> + }
>
> ret = register_chrdev(DRM_MAJOR, "drm", _stub_fops);
> if (ret < 0)
> diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
> index 17f3548c8ed2..e27a40166178 100644
> --- a/drivers/gpu/drm/drm_internal.h
> +++ b/drivers/gpu/drm/drm_internal.h
> @@ -182,8 +182,8 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct
> drm_device *dev,
>
> /* drm_debugfs.c drm_debugfs_crc.c */
> #if defined(CONFIG_DEBUG_FS)
> -int drm_debugfs_init(struct drm_minor *minor, int minor_id,
> - struct dentry *root);
> +void drm_debugfs_init(struct
Re: [PATCH 1/5] dri: cleanup debugfs error handling
Hi
Am 08.10.21 um 11:17 schrieb Nirmoy Das:
Debugfs API returns encoded error instead of NULL.
This patch cleanups drm debugfs error handling to
properly set dri and its minor's root dentry to NULL.
Also do not error out if dri/minor debugfs directory
creation fails as a debugfs error is not a fatal error.
CC: Maarten Lankhorst
CC: Maxime Ripard
CC: Thomas Zimmermann
CC: David Airlie
CC: Daniel Vetter
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/drm_debugfs.c | 25 +++--
drivers/gpu/drm/drm_drv.c | 16 ++--
drivers/gpu/drm/drm_internal.h | 7 +++
3 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index b0a826489488..af275a0c09b4 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -180,6 +180,9 @@ void drm_debugfs_create_files(const struct drm_info_list
*files, int count,
struct drm_info_node *tmp;
int i;
+ if (!minor->debugfs_root)
+ return;
+
for (i = 0; i < count; i++) {
u32 features = files[i].driver_features;
@@ -203,7 +206,7 @@ void drm_debugfs_create_files(const struct drm_info_list
*files, int count,
}
EXPORT_SYMBOL(drm_debugfs_create_files);
-int drm_debugfs_init(struct drm_minor *minor, int minor_id,
+void drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
struct drm_device *dev = minor->dev;
@@ -212,8 +215,16 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
INIT_LIST_HEAD(>debugfs_list);
mutex_init(>debugfs_lock);
sprintf(name, "%d", minor_id);
+
+ if (!root)
+ goto error;
+
minor->debugfs_root = debugfs_create_dir(name, root);
+ if (IS_ERR(minor->debugfs_root))
+ goto error;
+
+
drm_debugfs_create_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES,
minor->debugfs_root, minor);
@@ -230,7 +241,11 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
if (dev->driver->debugfs_init)
dev->driver->debugfs_init(minor);
- return 0;
+ return;
+
+error:
+ minor->debugfs_root = NULL;
+ return;
}
@@ -241,6 +256,9 @@ int drm_debugfs_remove_files(const struct drm_info_list
*files, int count,
struct drm_info_node *tmp;
int i;
+ if (!minor->debugfs_root)
+ return 0;
+
mutex_lock(>debugfs_lock);
for (i = 0; i < count; i++) {
list_for_each_safe(pos, q, >debugfs_list) {
@@ -261,6 +279,9 @@ static void drm_debugfs_remove_all_files(struct drm_minor
*minor)
{
struct drm_info_node *node, *tmp;
+ if (!minor->debugfs_root)
+ return;
+
mutex_lock(>debugfs_lock);
list_for_each_entry_safe(node, tmp, >debugfs_list, list) {
debugfs_remove(node->dent);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7a5097467ba5..fa57ec2d49bf 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -160,11 +160,7 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
if (!minor)
return 0;
- ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
- if (ret) {
- DRM_ERROR("DRM: Failed to initialize /sys/kernel/debug/dri.\n");
Rather than deleting the error message, return an error code from
drm_debugfs_init() and print it here. I'd change DRM_ERROR() to
drm_dbg_core(NULL, ...).
- goto err_debugfs;
- }
+ drm_debugfs_init(minor, minor->index, drm_debugfs_root);
ret = device_add(minor->kdev);
if (ret)
@@ -1050,7 +1046,15 @@ static int __init drm_core_init(void)
goto error;
}
- drm_debugfs_root = debugfs_create_dir("dri", NULL);
+ if (!debugfs_initialized()) {
+ drm_debugfs_root = NULL;
+ } else {
+ drm_debugfs_root = debugfs_create_dir("dri", NULL);
+ if (IS_ERR(drm_debugfs_root)) {
+ DRM_WARN("DRM: Failed to initialize
/sys/kernel/debug/dri.\n");
This should also print the error code. I'd also change the call to
drm_dbg_core(). The message should say 'failed to create', so it's
differnt from the other one.
Best regards
Thomas
+ drm_debugfs_root = NULL;
+ }
+ }
ret = register_chrdev(DRM_MAJOR, "drm", _stub_fops);
if (ret < 0)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 17f3548c8ed2..e27a40166178 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -182,8 +182,8 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct
drm_device *dev,
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
-int drm_debugfs_init(struct
[PULL] drm-intel-gt-next
Hi Dave & Daniel, Here goes the first PR towards 5.16. As for the big things, this adds encrypted PXP (Protected Xe Path) support for Gen12 integrated. Take a look at the "drm/i915/pxp: add PXP documentation" for further details and the Mesa changes for how the uAPI will look like. Then adds DG1 PCI IDs (GuC is enabled by default) still behind force_probe, but not anymore behind the FAKE_LMEM compile time protection. There is of course immensive amount of rework and new code that lead to this. Suspend timeout is increased by factor of 2.5 to account for GuC submission added overhead. Ultimately this should lead to simpler kernel scheduler code that will converge towards drm/sched. Then there are the many of the other changes that trade previously made code (micro-)optimizations for code simplicity, so some performance regressions are expected. Removes ADL-S force_probe protection. Enables transparent hugepages when IOMMU is enabled (and then only), to offset the perf hit caused by IOMMU. That is greater than some of the perf hit from THP itself. Keeps adding support for Xe HP/Xe HP SDV. Backmerges drm-next at 5.15-rc1 and merges the tip/locking/wwmutex branch. Also includes patches for the MEI subsystem that go together with the PXP changes. Regards, Joonas *** drm-intel-gt-next-2021-10-08: UAPI Changes: - Add uAPI for using PXP protected objects Mesa changes: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8064 - Add PCI IDs and LMEM discovery/placement uAPI for DG1 Mesa changes: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/11584 - Disable engine bonding on Gen12+ except TGL, RKL and ADL-S Cross-subsystem Changes: - Merges 'tip/locking/wwmutex' branch (core kernel tip) - "mei: pxp: export pavp client to me client bus" Core Changes: - Update ttm_move_memcpy for async use (Thomas) Driver Changes: - Add PXP (Protected Xe Path) support for Gen12 integrated (Daniele, Sean, Anshuman) See "drm/i915/pxp: add PXP documentation" for details! - Enable GuC submission by default on DG1 (Matt B) - Remove force_probe protection for ADL-S (Raviteja) - Add base support for XeHP/XeHP SDV (Matt R, Stuart, Lucas) - Handle DRI_PRIME=1 on Intel igfx + Intel dgfx hybrid graphics setup (Tvrtko) - Use Transparent Hugepages when IOMMU is enabled (Tvrtko, Chris) - Implement LMEM backup and restore for suspend / resume (Thomas) - Report INSTDONE_GEOM values in error state for DG2 (Matt R) - Add DG2-specific shadow register table (Matt R) - Update Gen11/Gen12/XeHP shadow register tables (Matt R) - Maintain backward-compatible nested batch behavior on TGL+ (Matt R) - Add new LRI reg offsets for DG2 (Akeem) - Initialize unused MOCS entries to device specific values (Ayaz) - Track and use the correct UC MOCS index on Gen12 (Ayaz) - Add separate MOCS table for Gen12 devices other than TGL/RKL (Ayaz) - Simplify the locking and eliminate some RCU usage (Daniel) - Add some flushing for the 64K GTT path (Matt A) - Mark GPU wedging on driver unregister unrecoverable (Janusz) - Major rework in the GuC codebase, simplify locking and add docs (Matt B) - Add DG1 GuC/HuC firmwares (Daniele, Matt B) - Remember to call i915_sw_fence_fini on guc_state.blocked (Matt A) - Use "gt" forcewake domain name for error messages instead of "blitter" (Matt R) - Drop now duplicate LMEM uAPI RFC kerneldoc section (Daniel) - Fix early tracepoints for requests (Matt A) - Use locked access to ctx->engines in set_priority (Daniel) - Convert gen6/gen7/gen8 read operations to fwtable (Matt R) - Drop gen11/gen12 specific mmio write handlers (Matt R) - Drop gen11 specific mmio read handlers (Matt R) - Use designated initializers for init/exit table (Kees) - Fix syncmap memory leak (Matt B) - Add pretty printing for buddy allocator state debug (Matt A) - Fix potential error pointer dereference in pinned_context() (Dan) - Remove IS_ACTIVE macro (Lucas) - Static code checker fixes (Nathan) - Clean up disabled warnings (Nathan) - Increase timeout in i915_gem_contexts selftests 5x for GuC submission (Matt B) - Ensure wa_init_finish() is called for ctx workaround list (Matt R) - Initialize L3CC table in mocs init (Sreedhar, Ayaz, Ram) - Get PM ref before accessing HW register (Vinay) - Move __i915_gem_free_object to ttm_bo_destroy (Maarten) - Deduplicate frequency dump on debugfs (Lucas) - Make wa list per-gt (Venkata) - Do not define dummy vma in stack (Venkata) - Take pinning into account in __i915_gem_object_is_lmem (Matt B, Thomas) - Do not report currently active engine when describing objects (Tvrtko) - Fix pdfdocs build error by removing nested grid from GuC docs (Akira) - Remove false warning from the rps worker (Tejas) - Flush buffer pools on driver remove (Janusz) - Fix runtime pm handling in i915_gem_shrink (Maarten) - Rework TTM object initialization slightly (Thomas) - Use fixed offset for PTEs location (Michal Wa) - Verify result from CTB (de)register action and improve error messages (Michal Wa) - Fix bug
[PATCH 5/5] drm/tegra: check root dentry before debugfs init
Return early if crtc or connector's debugfs root dentries are NULL.
CC: Thierry Reding
CC: David Airlie
CC: Daniel Vetter
CC: Jonathan Hunter
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/tegra/dc.c | 5 +
drivers/gpu/drm/tegra/dsi.c | 4
drivers/gpu/drm/tegra/hdmi.c | 5 +
drivers/gpu/drm/tegra/sor.c | 4
4 files changed, 18 insertions(+)
diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c
index 16c7aabb94d3..87eeda68d231 100644
--- a/drivers/gpu/drm/tegra/dc.c
+++ b/drivers/gpu/drm/tegra/dc.c
@@ -1623,6 +1623,11 @@ static int tegra_dc_late_register(struct drm_crtc *crtc)
struct dentry *root;
struct tegra_dc *dc = to_tegra_dc(crtc);
+ if (!crtc->debugfs_entry) {
+ dc->debugfs_files = NULL;
+ return 0;
+ }
+
#ifdef CONFIG_DEBUG_FS
root = crtc->debugfs_entry;
#else
diff --git a/drivers/gpu/drm/tegra/dsi.c b/drivers/gpu/drm/tegra/dsi.c
index f46d377f0c30..f0263165e261 100644
--- a/drivers/gpu/drm/tegra/dsi.c
+++ b/drivers/gpu/drm/tegra/dsi.c
@@ -236,6 +236,10 @@ static int tegra_dsi_late_register(struct drm_connector
*connector)
struct dentry *root = connector->debugfs_entry;
struct tegra_dsi *dsi = to_dsi(output);
+ if (!root) {
+ dsi->debugfs_files = NULL;
+ return 0;
+ }
dsi->debugfs_files = kmemdup(debugfs_files, sizeof(debugfs_files),
GFP_KERNEL);
if (!dsi->debugfs_files)
diff --git a/drivers/gpu/drm/tegra/hdmi.c b/drivers/gpu/drm/tegra/hdmi.c
index e5d2a4026028..400319db0afc 100644
--- a/drivers/gpu/drm/tegra/hdmi.c
+++ b/drivers/gpu/drm/tegra/hdmi.c
@@ -1065,6 +1065,11 @@ static int tegra_hdmi_late_register(struct drm_connector
*connector)
struct dentry *root = connector->debugfs_entry;
struct tegra_hdmi *hdmi = to_hdmi(output);
+ if (!root) {
+ hdmi->debugfs_files = NULL;
+ return 0;
+ }
+
hdmi->debugfs_files = kmemdup(debugfs_files, sizeof(debugfs_files),
GFP_KERNEL);
if (!hdmi->debugfs_files)
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 0ea320c1092b..a8a3b0a587d9 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -1687,6 +1687,10 @@ static int tegra_sor_late_register(struct drm_connector
*connector)
struct dentry *root = connector->debugfs_entry;
struct tegra_sor *sor = to_sor(output);
+ if (!root) {
+ sor->debugfs_files = NULL;
+ return 0;
+ }
sor->debugfs_files = kmemdup(debugfs_files, sizeof(debugfs_files),
GFP_KERNEL);
if (!sor->debugfs_files)
--
2.32.0
[PATCH 2/5] drm/i915: check dri root before debugfs init
Return early if dri minor root dentry is NULL.
CC: Zhenyu Wang
CC: Zhi Wang
CC: Jani Nikula
CC: Joonas Lahtinen
CC: Rodrigo Vivi
CC: David Airlie
CC: Daniel Vetter
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gvt/debugfs.c | 3 +++
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gvt/debugfs.c
b/drivers/gpu/drm/i915/gvt/debugfs.c
index 9f1c209d9251..2d47acaa03ee 100644
--- a/drivers/gpu/drm/i915/gvt/debugfs.c
+++ b/drivers/gpu/drm/i915/gvt/debugfs.c
@@ -187,6 +187,9 @@ void intel_gvt_debugfs_init(struct intel_gvt *gvt)
{
struct drm_minor *minor = gvt->gt->i915->drm.primary;
+ if (!minor->debugfs_root)
+ return;
+
gvt->debugfs_root = debugfs_create_dir("gvt", minor->debugfs_root);
debugfs_create_ulong("num_tracked_mmio", 0444, gvt->debugfs_root,
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 44969f5dde50..d572b686edeb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1012,6 +1012,9 @@ void i915_debugfs_register(struct drm_i915_private
*dev_priv)
struct drm_minor *minor = dev_priv->drm.primary;
int i;
+ if (!minor->debugfs_root)
+ return;
+
i915_debugfs_params(dev_priv);
debugfs_create_file("i915_forcewake_user", S_IRUSR, minor->debugfs_root,
--
2.32.0
[PATCH 4/5] drm/armada: check dri/crtc root before debugfs init
Return early if dri minor root dentry is NULL.
CC: Russell King
CC: David Airlie
CC: Daniel Vetter
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/armada/armada_debugfs.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/armada/armada_debugfs.c
b/drivers/gpu/drm/armada/armada_debugfs.c
index 29f4b52e3c8d..b40003fe4a89 100644
--- a/drivers/gpu/drm/armada/armada_debugfs.c
+++ b/drivers/gpu/drm/armada/armada_debugfs.c
@@ -93,6 +93,9 @@ static const struct file_operations
armada_debugfs_crtc_reg_fops = {
void armada_drm_crtc_debugfs_init(struct armada_crtc *dcrtc)
{
+ if (!dcrtc->crtc.debugfs_entry)
+ return;
+
debugfs_create_file("armada-regs", 0600, dcrtc->crtc.debugfs_entry,
dcrtc, _debugfs_crtc_reg_fops);
}
@@ -104,6 +107,9 @@ static struct drm_info_list armada_debugfs_list[] = {
int armada_drm_debugfs_init(struct drm_minor *minor)
{
+ if (!minor->debugfs_root)
+ return;
+
drm_debugfs_create_files(armada_debugfs_list, ARMADA_DEBUGFS_ENTRIES,
minor->debugfs_root, minor);
--
2.32.0
[PATCH 3/5] drm/radeon: check dri root before debugfs init
Return early if dri minor root dentry is NULL.
CC: Alex Deucher
CC: "Christian König"
CC: "Pan, Xinhui"
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/radeon/r100.c | 9 +
drivers/gpu/drm/radeon/r300.c | 3 +++
drivers/gpu/drm/radeon/r420.c | 3 +++
drivers/gpu/drm/radeon/r600.c | 3 +++
drivers/gpu/drm/radeon/radeon_dp_mst.c | 3 +++
drivers/gpu/drm/radeon/radeon_fence.c | 3 +++
drivers/gpu/drm/radeon/radeon_gem.c| 3 +++
drivers/gpu/drm/radeon/radeon_ib.c | 3 +++
drivers/gpu/drm/radeon/radeon_pm.c | 5 -
drivers/gpu/drm/radeon/radeon_ring.c | 3 +++
drivers/gpu/drm/radeon/radeon_ttm.c| 3 +++
drivers/gpu/drm/radeon/rs400.c | 3 +++
drivers/gpu/drm/radeon/rv515.c | 3 +++
13 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 2dd85ba1faa2..ae6c95b34013 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -3059,6 +3059,9 @@ void r100_debugfs_rbbm_init(struct radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r100_rbbm_info", 0444, root, rdev,
_debugfs_rbbm_info_fops);
#endif
@@ -3069,6 +3072,9 @@ void r100_debugfs_cp_init(struct radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r100_cp_ring_info", 0444, root, rdev,
_debugfs_cp_ring_info_fops);
debugfs_create_file("r100_cp_csq_fifo", 0444, root, rdev,
@@ -3081,6 +3087,9 @@ void r100_debugfs_mc_info_init(struct radeon_device
*rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r100_mc_info", 0444, root, rdev,
_debugfs_mc_info_fops);
#endif
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 621ff174dff3..b22969e2394f 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -618,6 +618,9 @@ static void rv370_debugfs_pcie_gart_info_init(struct
radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("rv370_pcie_gart_info", 0444, root, rdev,
_debugfs_pcie_gart_info_fops);
#endif
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 7e6320e8c6a0..cdb4ac3e346b 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -494,6 +494,9 @@ void r420_debugfs_pipes_info_init(struct radeon_device
*rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r420_pipes_info", 0444, root, rdev,
_debugfs_pipes_info_fops);
#endif
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index ca3fcae2adb5..d8f525cf0c3b 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -4360,6 +4360,9 @@ static void r600_debugfs_mc_info_init(struct
radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("r600_mc_info", 0444, root, rdev,
_debugfs_mc_info_fops);
diff --git a/drivers/gpu/drm/radeon/radeon_dp_mst.c
b/drivers/gpu/drm/radeon/radeon_dp_mst.c
index ec867fa880a4..cf06da89bb7c 100644
--- a/drivers/gpu/drm/radeon/radeon_dp_mst.c
+++ b/drivers/gpu/drm/radeon/radeon_dp_mst.c
@@ -771,6 +771,9 @@ void radeon_mst_debugfs_init(struct radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("radeon_mst_info", 0444, root, rdev,
_debugfs_mst_info_fops);
diff --git a/drivers/gpu/drm/radeon/radeon_fence.c
b/drivers/gpu/drm/radeon/radeon_fence.c
index 73e3117420bf..11f30349de46 100644
--- a/drivers/gpu/drm/radeon/radeon_fence.c
+++ b/drivers/gpu/drm/radeon/radeon_fence.c
@@ -1006,6 +1006,9 @@ void radeon_debugfs_fence_init(struct radeon_device *rdev)
#if defined(CONFIG_DEBUG_FS)
struct dentry *root = rdev->ddev->primary->debugfs_root;
+ if (!root)
+ return;
+
debugfs_create_file("radeon_gpu_reset", 0444, root, rdev,
_debugfs_gpu_reset_fops);
debugfs_create_file("radeon_fence_info", 0444, root, rdev,
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
[PATCH 1/5] dri: cleanup debugfs error handling
Debugfs API returns encoded error instead of NULL.
This patch cleanups drm debugfs error handling to
properly set dri and its minor's root dentry to NULL.
Also do not error out if dri/minor debugfs directory
creation fails as a debugfs error is not a fatal error.
CC: Maarten Lankhorst
CC: Maxime Ripard
CC: Thomas Zimmermann
CC: David Airlie
CC: Daniel Vetter
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/drm_debugfs.c | 25 +++--
drivers/gpu/drm/drm_drv.c | 16 ++--
drivers/gpu/drm/drm_internal.h | 7 +++
3 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index b0a826489488..af275a0c09b4 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -180,6 +180,9 @@ void drm_debugfs_create_files(const struct drm_info_list
*files, int count,
struct drm_info_node *tmp;
int i;
+ if (!minor->debugfs_root)
+ return;
+
for (i = 0; i < count; i++) {
u32 features = files[i].driver_features;
@@ -203,7 +206,7 @@ void drm_debugfs_create_files(const struct drm_info_list
*files, int count,
}
EXPORT_SYMBOL(drm_debugfs_create_files);
-int drm_debugfs_init(struct drm_minor *minor, int minor_id,
+void drm_debugfs_init(struct drm_minor *minor, int minor_id,
struct dentry *root)
{
struct drm_device *dev = minor->dev;
@@ -212,8 +215,16 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
INIT_LIST_HEAD(>debugfs_list);
mutex_init(>debugfs_lock);
sprintf(name, "%d", minor_id);
+
+ if (!root)
+ goto error;
+
minor->debugfs_root = debugfs_create_dir(name, root);
+ if (IS_ERR(minor->debugfs_root))
+ goto error;
+
+
drm_debugfs_create_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES,
minor->debugfs_root, minor);
@@ -230,7 +241,11 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
if (dev->driver->debugfs_init)
dev->driver->debugfs_init(minor);
- return 0;
+ return;
+
+error:
+ minor->debugfs_root = NULL;
+ return;
}
@@ -241,6 +256,9 @@ int drm_debugfs_remove_files(const struct drm_info_list
*files, int count,
struct drm_info_node *tmp;
int i;
+ if (!minor->debugfs_root)
+ return 0;
+
mutex_lock(>debugfs_lock);
for (i = 0; i < count; i++) {
list_for_each_safe(pos, q, >debugfs_list) {
@@ -261,6 +279,9 @@ static void drm_debugfs_remove_all_files(struct drm_minor
*minor)
{
struct drm_info_node *node, *tmp;
+ if (!minor->debugfs_root)
+ return;
+
mutex_lock(>debugfs_lock);
list_for_each_entry_safe(node, tmp, >debugfs_list, list) {
debugfs_remove(node->dent);
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 7a5097467ba5..fa57ec2d49bf 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -160,11 +160,7 @@ static int drm_minor_register(struct drm_device *dev,
unsigned int type)
if (!minor)
return 0;
- ret = drm_debugfs_init(minor, minor->index, drm_debugfs_root);
- if (ret) {
- DRM_ERROR("DRM: Failed to initialize /sys/kernel/debug/dri.\n");
- goto err_debugfs;
- }
+ drm_debugfs_init(minor, minor->index, drm_debugfs_root);
ret = device_add(minor->kdev);
if (ret)
@@ -1050,7 +1046,15 @@ static int __init drm_core_init(void)
goto error;
}
- drm_debugfs_root = debugfs_create_dir("dri", NULL);
+ if (!debugfs_initialized()) {
+ drm_debugfs_root = NULL;
+ } else {
+ drm_debugfs_root = debugfs_create_dir("dri", NULL);
+ if (IS_ERR(drm_debugfs_root)) {
+ DRM_WARN("DRM: Failed to initialize
/sys/kernel/debug/dri.\n");
+ drm_debugfs_root = NULL;
+ }
+ }
ret = register_chrdev(DRM_MAJOR, "drm", _stub_fops);
if (ret < 0)
diff --git a/drivers/gpu/drm/drm_internal.h b/drivers/gpu/drm/drm_internal.h
index 17f3548c8ed2..e27a40166178 100644
--- a/drivers/gpu/drm/drm_internal.h
+++ b/drivers/gpu/drm/drm_internal.h
@@ -182,8 +182,8 @@ int drm_gem_dumb_destroy(struct drm_file *file, struct
drm_device *dev,
/* drm_debugfs.c drm_debugfs_crc.c */
#if defined(CONFIG_DEBUG_FS)
-int drm_debugfs_init(struct drm_minor *minor, int minor_id,
-struct dentry *root);
+void drm_debugfs_init(struct drm_minor *minor, int minor_id,
+ struct dentry *root);
void drm_debugfs_cleanup(struct drm_minor *minor);
void drm_debugfs_connector_add(struct drm_connector *connector);
void drm_debugfs_connector_remove(struct drm_connector *connector);
@@ -191,10 +191,9 @@ void
Re: [PATCH] drm/bridge: ti-sn65dsi83: Implement .detach callback
Applied to drm-misc-next
On Thu, 7 Oct 2021 at 21:51, Marek Vasut wrote:
>
> On 10/6/21 11:47 AM, Robert Foss wrote:
> >>
> > On Tue, 7 Sept 2021 at 04:40, Marek Vasut wrote:
> >>
> >> Move detach implementation from sn65dsi83_remove() to dedicated
> > .detach callback. There is no functional change to the code, but
> >> that detach is now in the correct location.
> >>
> >> Signed-off-by: Marek Vasut
> >> Cc: Jagan Teki
> >> Cc: Laurent Pinchart
> >> Cc: Linus Walleij
> >> Cc: Robert Foss
> >> Cc: Sam Ravnborg
> >> Cc: dri-devel@lists.freedesktop.org
> >> ---
> >> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 17 ++---
> >> 1 file changed, 14 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> >> b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> >> index 4ea71d7f0bfbc..13ee313daba96 100644
> >> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> >> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> >> @@ -288,6 +288,19 @@ static int sn65dsi83_attach(struct drm_bridge *bridge,
> >> return ret;
> >> }
> >>
> >> +static void sn65dsi83_detach(struct drm_bridge *bridge)
> >> +{
> >> + struct sn65dsi83 *ctx = bridge_to_sn65dsi83(bridge);
> >> +
> >> + if (!ctx->dsi)
> >> + return;
> >> +
> >> + mipi_dsi_detach(ctx->dsi);
> >> + mipi_dsi_device_unregister(ctx->dsi);
> >> + drm_bridge_remove(>bridge);
> >> + ctx->dsi = NULL;
> >
> > Is this assignment necessary? I'm not seeing it in the other drivers.
> >
> > WIth this cleared up feel free to add my r-b.
> > Reviewed-by: Robert Foss
>
> It works in tandem with the if (!ctx->dsi) return; at the beginning to
> prevent crash in case the detach callback was called multiple times for
> whatever reason.
