[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/bios: do not discard address space (rev2)
== Series Details == Series: series starting with [1/3] drm/i915/bios: do not discard address space (rev2) URL : https://patchwork.freedesktop.org/series/69567/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7359_full -> Patchwork_15308_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_15308_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_15308_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_15308_full: ### IGT changes ### Possible regressions * igt@gem_exec_reuse@baggage: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-iclb1/igt@gem_exec_re...@baggage.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-iclb7/igt@gem_exec_re...@baggage.html Known issues Here are the changes found in Patchwork_15308_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@vcs1-hostile-preempt: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-iclb1/igt@gem_ctx_persiste...@vcs1-hostile-preempt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-iclb7/igt@gem_ctx_persiste...@vcs1-hostile-preempt.html * igt@gem_ctx_switch@vcs1-heavy: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112080]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-iclb4/igt@gem_ctx_swi...@vcs1-heavy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-iclb6/igt@gem_ctx_swi...@vcs1-heavy.html * igt@gem_eio@in-flight-suspend: - shard-tglb: [PASS][7] -> [INCOMPLETE][8] ([fdo#111832] / [fdo#111850] / [fdo#112081]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-tglb9/igt@gem_...@in-flight-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-tglb3/igt@gem_...@in-flight-suspend.html * igt@gem_eio@unwedge-stress: - shard-snb: [PASS][9] -> [FAIL][10] ([fdo#109661]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-snb1/igt@gem_...@unwedge-stress.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-snb2/igt@gem_...@unwedge-stress.html * igt@gem_exec_schedule@wide-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-iclb7/igt@gem_exec_sched...@wide-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-iclb2/igt@gem_exec_sched...@wide-bsd.html * igt@gem_userptr_blits@dmabuf-sync: - shard-hsw: [PASS][13] -> [DMESG-WARN][14] ([fdo#111870]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-hsw2/igt@gem_userptr_bl...@dmabuf-sync.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-hsw8/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_workarounds@suspend-resume: - shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([fdo#111832] / [fdo#111850]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-tglb6/igt@gem_workarou...@suspend-resume.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-tglb5/igt@gem_workarou...@suspend-resume.html * igt@i915_pm_dc@dc5-dpms: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#111795 ]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-iclb8/igt@i915_pm...@dc5-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-iclb3/igt@i915_pm...@dc5-dpms.html * igt@i915_pm_rpm@system-suspend: - shard-tglb: [PASS][19] -> [INCOMPLETE][20] ([fdo#111747] / [fdo#111850]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-tglb1/igt@i915_pm_...@system-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-tglb8/igt@i915_pm_...@system-suspend.html * igt@i915_selftest@live_perf: - shard-hsw: [PASS][21] -> [INCOMPLETE][22] ([fdo#103540]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7359/shard-hsw6/igt@i915_selftest@live_perf.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15308/shard-hsw8/igt@i915_selftest@live_perf.html * igt@kms_draw_crc@draw-method-xrgb-blt-xtiled: - shard-snb: [PASS][23] -> [SKIP][24] ([fdo#109271]) +4 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7
Re: [Intel-gfx] [PATCH v7] drm/i915: Enable second dbuf slice for ICL and TGL
On Fri, 2019-11-15 at 22:19 +0200, Ville Syrjälä wrote:
> On Thu, Nov 14, 2019 at 02:24:49PM +0200, Stanislav Lisovskiy wrote:
> > Also implemented algorithm for choosing DBuf slice configuration
> > based on active pipes, pipe ratio as stated in BSpec 12716.
> >
> > Now pipe allocation still stays proportional to pipe width as
> > before,
> > however within allowed DBuf slice for this particular
> > configuration.
> >
> > v2: Remove unneeded check from commit as ddb enabled slices might
> > now differ from hw state.
> >
> > v3: - Added new field "supported_slices" to ddb to separate max
> > supported slices vs currently enabled, to avoid confusion.
> > - Removed obsolete comments and code related to DBuf(Matthew
> > Roper).
> > - Some code style and long line removal(Matthew Roper).
> > - Added WARN_ON to new ddb range offset calc function(Matthew
> > Roper).
> > - Removed platform specific call to calc pipe ratio from ddb
> > allocation function and fixed the return value(Matthew Roper)
> > - Refactored DBUF slice allocation table to improve readability
> > - Added DBUF slice allocation for TGL as well.
> > - ICL(however not TGL) seems to voluntarily enable second DBuf
> > slice
> > after pm suspend/resume causing a mismatch failure, because
> > we
> > update DBuf slices only if we do a modeset, however this
> > check
> > is done always. Fixed it to be done only when modeset for
> > ICL.
> >
> > v4: - Now enabled slices is not actually a number, but a bitmask,
> > because we might need to enable second slice only and number
> > of slices would still 1 and that current code doesn't allow.
> > - Remove redundant duplicate code to have some unified way of
> > enabling dbuf slices instead of hardcoding.
> >
> > v5: - Fix failing gen9_assert_dbuf_enabled as it was naively
> > thinking
> > that we have only one DBUF_CTL slice. Now another version for
> > gen11 will check both slices as only second one can be
> > enabled,
> > to keep CI happy.
> >
> > v6: - Removed enabled dbuf assertion completely. Previous code
> > was keeping dbuf enabled, even(!) when _dbuf_disable is
> > called.
> > Currently we enable/disable dbuf slices based on requrement
> > so no point in asserting this here.
> > - Removed unnecessary modeset check from
> > verify_wm_state(Matthew Roper)
> > - Slices intersection after union is same as final
> > result(Matthew Roper)
> > - Moved DBuf slices to intel_device_info(Matthew Roper)
> > - Some macros added(Matthew Roper)
> > - ddb range is now always less or equal to ddb size - no need
> > for additional
> > checks(previously needed as we had some bandwidth checks in
> > there which
> > could "suddenly" return ddb_size smaller than it is.
> >
> > v7: Minor costemic changes:
> > - Changed icl_dbuf_slices_restore name to
> > icl_program_dbuf_slices
> > as it more corresponds to the actual functionality.
> > - Some simplification with supported slices for BXT and GLK
> > - skl_pipe_downscale_amount -> icl_pipe_downscale_amount as
> > this is not used for skl anymore.
> > - Changed DBuf slice assignment order for TGL case
> >
> > Reviewed-by: Matthew Roper
> > Signed-off-by: Stanislav Lisovskiy
> > Cc: Matthew Roper
> > Cc: Ville Syrjälä
> > Cc: James Ausmus
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 26 +-
> > .../drm/i915/display/intel_display_power.c| 98 ++---
> > .../drm/i915/display/intel_display_power.h| 2 +
> > drivers/gpu/drm/i915/i915_drv.c | 5 +
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > drivers/gpu/drm/i915/i915_pci.c | 6 +-
> > drivers/gpu/drm/i915/i915_reg.h | 8 +-
> > drivers/gpu/drm/i915/intel_device_info.h | 1 +
> > drivers/gpu/drm/i915/intel_pm.c | 387
> > --
> > 9 files changed, 431 insertions(+), 104 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 876fc25968bf..bd7aff675198 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -13387,7 +13387,7 @@ static void verify_wm_state(struct
> > intel_crtc *crtc,
> >
> > if (INTEL_GEN(dev_priv) >= 11 &&
> > hw->ddb.enabled_slices != sw_ddb->enabled_slices)
> > - DRM_ERROR("mismatch in DBUF Slices (expected %u, got
> > %u)\n",
> > + DRM_ERROR("mismatch in DBUF Slices (expected %x, got
> > %x)\n",
> > sw_ddb->enabled_slices,
> > hw->ddb.enabled_slices);
> >
> > @@ -14614,15 +14614,24 @@ static void
> > skl_commit_modeset_enables(struct intel_atomic_state *state)
> > u8 hw_enabled_slices = dev_priv->wm.skl_hw.ddb.enabled_slices;
> > u8 required_slices = state->wm_
[Intel-gfx] [PATCH] drm/i915/selftests: Add intel_gt_driver_late_release for mock device
Having called intel_gt_init_early() to setup the mock intel_gt, we need
to call the corresponding intel_gt_driver_late_release() to clean up.
References: dea397e818b1 ("drm/i915/gt: Flush retire.work timer object on
unload")
References: 24635c5152af ("drm/i915: Move intel_gt initialization to a separate
file")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index e58b0bc9cdb6..d14ba8498f57 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -71,6 +71,7 @@ static void mock_device_release(struct drm_device *dev)
mock_fini_ggtt(&i915->ggtt);
destroy_workqueue(i915->wq);
+ intel_gt_driver_late_release(&i915->gt);
intel_memory_regions_driver_release(i915);
drm_mode_config_cleanup(&i915->drm);
@@ -204,6 +205,7 @@ struct drm_i915_private *mock_gem_device(void)
err_unlock:
destroy_workqueue(i915->wq);
err_drv:
+ intel_gt_driver_late_release(&i915->gt);
intel_memory_regions_driver_release(i915);
drm_mode_config_cleanup(&i915->drm);
drm_dev_fini(&i915->drm);
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/15] Retire dma_buf_k(un)map
Hi all, Way back when we created the dma-buf spec it made sense to have kmap/unmap interfaces, since 32bit kernels with limited vmalloc space were still rather ubiquitous. But that idea (like many others) never caught on, was quickly replaced by vmaps covering the entire buffer for all real uses, and nowadays 64bit kernels rule the world. Currently merged upstream drivers (and we have a pile now) don't even bother to kmap for their private buffers, much less for anything shared. So since it was never used, and this idea's time is clearly over, let's remove it all. Only real change I had to do (aside from deleting lots of dead code) was in the tegra driver. But even there I suspect the dma-buf kmap path has never been run in anger anywhere, it just doesn't make sense to put relocs into a dma-buf (as opposed to using a dma-buf for the target address of a reloc). Comments, reviews and testing very much appreciated. Cheers, Daniel Daniel Vetter (15): drm/tegra: Map cmdbuf once for reloc processing drm/tegra: Delete host1x_bo_ops->k(un)map drm/i915: Remove dma_buf_kmap selftest staging/android/ion: delete dma_buf->kmap/unmap implemenation drm/armada: Delete dma_buf->k(un)map implemenation drm/i915: Drop dma_buf->k(un)map drm/omapdrm: Drop dma_buf->k(un)map drm/tegra: Remove dma_buf->k(un)map dma-buf: Drop dma_buf_k(un)map drm/vmwgfx: Delete mmaping functions media/videobuf2: Drop dma_buf->k(un)map support drm/tee_shm: Drop dma_buf_k(unmap) support xen/gntdev-dmabuf: Ditch dummy map functions sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support dma-buf: Remove kernel map/unmap hooks drivers/dma-buf/dma-buf.c | 63 +-- drivers/gpu/drm/armada/armada_gem.c | 12 --- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 36 --- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 101 -- .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 16 --- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 drivers/gpu/drm/tegra/gem.c | 40 --- drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 33 -- drivers/gpu/host1x/job.c | 21 ++-- .../common/videobuf2/videobuf2-dma-contig.c | 8 -- .../media/common/videobuf2/videobuf2-dma-sg.c | 8 -- .../common/videobuf2/videobuf2-vmalloc.c | 8 -- drivers/misc/fastrpc.c| 8 -- drivers/staging/android/ion/ion.c | 14 --- drivers/tee/tee_shm.c | 6 -- drivers/xen/gntdev-dmabuf.c | 23 include/linux/dma-buf.h | 27 - include/linux/host1x.h| 13 --- samples/vfio-mdev/mbochs.c| 16 --- 19 files changed, 10 insertions(+), 464 deletions(-) -- 2.24.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/15] drm/tegra: Map cmdbuf once for reloc processing
A few reasons to drop kmap:
- For native objects all we do is look at obj->vaddr anyway, so might
as well not call functions for every page.
- Reloc-processing on dma-buf is ... questionable.
- Plus most dma-buf that bother kernel cpu mmaps give you at least
vmap, much less kmaps. And all the ones relevant for arm-soc are
again doing a obj->vaddr game anyway, there's no real kmap going on
on arm it seems.
Plus this seems to be the only real in-tree user of dma_buf_kmap, and
I'd like to get rid of that.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/host1x/job.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/host1x/job.c b/drivers/gpu/host1x/job.c
index 25ca54de8fc5..60b2fedd0061 100644
--- a/drivers/gpu/host1x/job.c
+++ b/drivers/gpu/host1x/job.c
@@ -244,8 +244,7 @@ static unsigned int pin_job(struct host1x *host, struct
host1x_job *job)
static int do_relocs(struct host1x_job *job, struct host1x_job_gather *g)
{
- u32 last_page = ~0;
- void *cmdbuf_page_addr = NULL;
+ void *cmdbuf_addr = NULL;
struct host1x_bo *cmdbuf = g->bo;
unsigned int i;
@@ -267,28 +266,22 @@ static int do_relocs(struct host1x_job *job, struct
host1x_job_gather *g)
goto patch_reloc;
}
- if (last_page != reloc->cmdbuf.offset >> PAGE_SHIFT) {
- if (cmdbuf_page_addr)
- host1x_bo_kunmap(cmdbuf, last_page,
-cmdbuf_page_addr);
+ if (!cmdbuf_addr) {
+ cmdbuf_addr = host1x_bo_mmap(cmdbuf);
- cmdbuf_page_addr = host1x_bo_kmap(cmdbuf,
- reloc->cmdbuf.offset >> PAGE_SHIFT);
- last_page = reloc->cmdbuf.offset >> PAGE_SHIFT;
-
- if (unlikely(!cmdbuf_page_addr)) {
+ if (unlikely(!cmdbuf_addr)) {
pr_err("Could not map cmdbuf for relocation\n");
return -ENOMEM;
}
}
- target = cmdbuf_page_addr + (reloc->cmdbuf.offset & ~PAGE_MASK);
+ target = cmdbuf_addr + reloc->cmdbuf.offset;
patch_reloc:
*target = reloc_addr;
}
- if (cmdbuf_page_addr)
- host1x_bo_kunmap(cmdbuf, last_page, cmdbuf_page_addr);
+ if (cmdbuf_addr)
+ host1x_bo_munmap(cmdbuf, cmdbuf_addr);
return 0;
}
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest
It's the only user left in the entire kernel for dma_buf_kmap/_kunmap.
Delete it, before we start garbage-collecting the various
implementations.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Matthew Auld
Cc: Daniel Vetter
Cc: Mika Kuoppala
Cc: Dave Airlie
---
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 101 --
1 file changed, 101 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index d85d1ce273ca..2a52b92586b9 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -254,106 +254,6 @@ static int igt_dmabuf_export_vmap(void *arg)
return err;
}
-static int igt_dmabuf_export_kmap(void *arg)
-{
- struct drm_i915_private *i915 = arg;
- struct drm_i915_gem_object *obj;
- struct dma_buf *dmabuf;
- void *ptr;
- int err;
-
- obj = i915_gem_object_create_shmem(i915, 2 * PAGE_SIZE);
- if (IS_ERR(obj))
- return PTR_ERR(obj);
-
- dmabuf = i915_gem_prime_export(&obj->base, 0);
- i915_gem_object_put(obj);
- if (IS_ERR(dmabuf)) {
- err = PTR_ERR(dmabuf);
- pr_err("i915_gem_prime_export failed with err=%d\n", err);
- return err;
- }
-
- ptr = dma_buf_kmap(dmabuf, 0);
- if (!ptr) {
- pr_err("dma_buf_kmap failed\n");
- err = -ENOMEM;
- goto err;
- }
-
- if (memchr_inv(ptr, 0, PAGE_SIZE)) {
- dma_buf_kunmap(dmabuf, 0, ptr);
- pr_err("Exported page[0] not initialiased to zero!\n");
- err = -EINVAL;
- goto err;
- }
-
- memset(ptr, 0xc5, PAGE_SIZE);
- dma_buf_kunmap(dmabuf, 0, ptr);
-
- ptr = i915_gem_object_pin_map(obj, I915_MAP_WB);
- if (IS_ERR(ptr)) {
- err = PTR_ERR(ptr);
- pr_err("i915_gem_object_pin_map failed with err=%d\n", err);
- goto err;
- }
- memset(ptr + PAGE_SIZE, 0xaa, PAGE_SIZE);
- i915_gem_object_flush_map(obj);
- i915_gem_object_unpin_map(obj);
-
- ptr = dma_buf_kmap(dmabuf, 1);
- if (!ptr) {
- pr_err("dma_buf_kmap failed\n");
- err = -ENOMEM;
- goto err;
- }
-
- if (memchr_inv(ptr, 0xaa, PAGE_SIZE)) {
- dma_buf_kunmap(dmabuf, 1, ptr);
- pr_err("Exported page[1] not set to 0xaa!\n");
- err = -EINVAL;
- goto err;
- }
-
- memset(ptr, 0xc5, PAGE_SIZE);
- dma_buf_kunmap(dmabuf, 1, ptr);
-
- ptr = dma_buf_kmap(dmabuf, 0);
- if (!ptr) {
- pr_err("dma_buf_kmap failed\n");
- err = -ENOMEM;
- goto err;
- }
- if (memchr_inv(ptr, 0xc5, PAGE_SIZE)) {
- dma_buf_kunmap(dmabuf, 0, ptr);
- pr_err("Exported page[0] did not retain 0xc5!\n");
- err = -EINVAL;
- goto err;
- }
- dma_buf_kunmap(dmabuf, 0, ptr);
-
- ptr = dma_buf_kmap(dmabuf, 2);
- if (ptr) {
- pr_err("Erroneously kmapped beyond the end of the object!\n");
- dma_buf_kunmap(dmabuf, 2, ptr);
- err = -EINVAL;
- goto err;
- }
-
- ptr = dma_buf_kmap(dmabuf, -1);
- if (ptr) {
- pr_err("Erroneously kmapped before the start of the object!\n");
- dma_buf_kunmap(dmabuf, -1, ptr);
- err = -EINVAL;
- goto err;
- }
-
- err = 0;
-err:
- dma_buf_put(dmabuf);
- return err;
-}
-
int i915_gem_dmabuf_mock_selftests(void)
{
static const struct i915_subtest tests[] = {
@@ -362,7 +262,6 @@ int i915_gem_dmabuf_mock_selftests(void)
SUBTEST(igt_dmabuf_import),
SUBTEST(igt_dmabuf_import_ownership),
SUBTEST(igt_dmabuf_export_vmap),
- SUBTEST(igt_dmabuf_export_kmap),
};
struct drm_i915_private *i915;
int err;
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/15] drm/tegra: Delete host1x_bo_ops->k(un)map
It doesn't have any callers anymore.
Aside: The ->mmap/munmap hooks have a bit a confusing name, they don't
do userspace mmaps, but a kernel vmap. I think most places use vmap
for this, except ttm, which uses kmap for vmap for added confusion.
mmap seems entirely for userspace mappings set up through mmap(2)
syscall.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/gem.c | 28
include/linux/host1x.h | 13 -
2 files changed, 41 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 746dae32c484..662cb7c87ef5 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -103,32 +103,6 @@ static void tegra_bo_munmap(struct host1x_bo *bo, void
*addr)
vunmap(addr);
}
-static void *tegra_bo_kmap(struct host1x_bo *bo, unsigned int page)
-{
- struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
- if (obj->vaddr)
- return obj->vaddr + page * PAGE_SIZE;
- else if (obj->gem.import_attach)
- return dma_buf_kmap(obj->gem.import_attach->dmabuf, page);
- else
- return vmap(obj->pages + page, 1, VM_MAP,
- pgprot_writecombine(PAGE_KERNEL));
-}
-
-static void tegra_bo_kunmap(struct host1x_bo *bo, unsigned int page,
- void *addr)
-{
- struct tegra_bo *obj = host1x_to_tegra_bo(bo);
-
- if (obj->vaddr)
- return;
- else if (obj->gem.import_attach)
- dma_buf_kunmap(obj->gem.import_attach->dmabuf, page, addr);
- else
- vunmap(addr);
-}
-
static struct host1x_bo *tegra_bo_get(struct host1x_bo *bo)
{
struct tegra_bo *obj = host1x_to_tegra_bo(bo);
@@ -145,8 +119,6 @@ static const struct host1x_bo_ops tegra_bo_ops = {
.unpin = tegra_bo_unpin,
.mmap = tegra_bo_mmap,
.munmap = tegra_bo_munmap,
- .kmap = tegra_bo_kmap,
- .kunmap = tegra_bo_kunmap,
};
static int tegra_bo_iommu_map(struct tegra_drm *tegra, struct tegra_bo *bo)
diff --git a/include/linux/host1x.h b/include/linux/host1x.h
index 6f8d772591ba..6edeb9228c4e 100644
--- a/include/linux/host1x.h
+++ b/include/linux/host1x.h
@@ -72,8 +72,6 @@ struct host1x_bo_ops {
void (*unpin)(struct device *dev, struct sg_table *sgt);
void *(*mmap)(struct host1x_bo *bo);
void (*munmap)(struct host1x_bo *bo, void *addr);
- void *(*kmap)(struct host1x_bo *bo, unsigned int pagenum);
- void (*kunmap)(struct host1x_bo *bo, unsigned int pagenum, void *addr);
};
struct host1x_bo {
@@ -119,17 +117,6 @@ static inline void host1x_bo_munmap(struct host1x_bo *bo,
void *addr)
bo->ops->munmap(bo, addr);
}
-static inline void *host1x_bo_kmap(struct host1x_bo *bo, unsigned int pagenum)
-{
- return bo->ops->kmap(bo, pagenum);
-}
-
-static inline void host1x_bo_kunmap(struct host1x_bo *bo,
- unsigned int pagenum, void *addr)
-{
- bo->ops->kunmap(bo, pagenum, addr);
-}
-
/*
* host1x syncpoints
*/
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support
No in-tree users left.
Signed-off-by: Daniel Vetter
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Tomasz Figa
Cc: linux-me...@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8
drivers/media/common/videobuf2/videobuf2-vmalloc.c| 8
3 files changed, 24 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index 44cd0e530bbd..d0c9dffe49e5 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf *dbuf)
vb2_dc_put(dbuf->priv);
}
-static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long pgnum)
-{
- struct vb2_dc_buf *buf = dbuf->priv;
-
- return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
{
struct vb2_dc_buf *buf = dbuf->priv;
@@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
.detach = vb2_dc_dmabuf_ops_detach,
.map_dma_buf = vb2_dc_dmabuf_ops_map,
.unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
- .map = vb2_dc_dmabuf_ops_kmap,
.vmap = vb2_dc_dmabuf_ops_vmap,
.mmap = vb2_dc_dmabuf_ops_mmap,
.release = vb2_dc_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index ed706b2a263c..6db60e9d5183 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf
*dbuf)
vb2_dma_sg_put(dbuf->priv);
}
-static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
pgnum)
-{
- struct vb2_dma_sg_buf *buf = dbuf->priv;
-
- return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
-}
-
static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
{
struct vb2_dma_sg_buf *buf = dbuf->priv;
@@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
.detach = vb2_dma_sg_dmabuf_ops_detach,
.map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
.unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
- .map = vb2_dma_sg_dmabuf_ops_kmap,
.vmap = vb2_dma_sg_dmabuf_ops_vmap,
.mmap = vb2_dma_sg_dmabuf_ops_mmap,
.release = vb2_dma_sg_dmabuf_ops_release,
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 04d51ca63223..4d5af352e249 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct dma_buf
*dbuf)
vb2_vmalloc_put(dbuf->priv);
}
-static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
pgnum)
-{
- struct vb2_vmalloc_buf *buf = dbuf->priv;
-
- return buf->vaddr + pgnum * PAGE_SIZE;
-}
-
static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
{
struct vb2_vmalloc_buf *buf = dbuf->priv;
@@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
.detach = vb2_vmalloc_dmabuf_ops_detach,
.map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
.unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
- .map = vb2_vmalloc_dmabuf_ops_kmap,
.vmap = vb2_vmalloc_dmabuf_ops_vmap,
.mmap = vb2_vmalloc_dmabuf_ops_mmap,
.release = vb2_vmalloc_dmabuf_ops_release,
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
drivers/xen/gntdev-dmabuf.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 2c4f324f8626..fe7bd69d6955 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf
*dma_buf)
mutex_unlock(&priv->lock);
}
-static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
-unsigned long page_num)
-{
- /* Not implemented. */
- return NULL;
-}
-
-static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
- unsigned long page_num, void *addr)
-{
- /* Not implemented. */
-}
-
-static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
- struct vm_area_struct *vma)
-{
- /* Not implemented. */
- return 0;
-}
-
static const struct dma_buf_ops dmabuf_exp_ops = {
.attach = dmabuf_exp_ops_attach,
.detach = dmabuf_exp_ops_detach,
.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
.release = dmabuf_exp_ops_release,
- .map = dmabuf_exp_ops_kmap,
- .unmap = dmabuf_exp_ops_kunmap,
- .mmap = dmabuf_exp_ops_mmap,
};
struct gntdev_dmabuf_export_args {
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support
There's no in-tree users anymore.
Signed-off-by: Daniel Vetter
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Jens Wiklander
Cc: tee-...@lists.linaro.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
drivers/misc/fastrpc.c | 8
drivers/tee/tee_shm.c | 6 --
2 files changed, 14 deletions(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index 1b1a794d639d..d0cbef9ec28a 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -555,13 +555,6 @@ static void fastrpc_dma_buf_detatch(struct dma_buf *dmabuf,
kfree(a);
}
-static void *fastrpc_kmap(struct dma_buf *dmabuf, unsigned long pgnum)
-{
- struct fastrpc_buf *buf = dmabuf->priv;
-
- return buf->virt ? buf->virt + pgnum * PAGE_SIZE : NULL;
-}
-
static void *fastrpc_vmap(struct dma_buf *dmabuf)
{
struct fastrpc_buf *buf = dmabuf->priv;
@@ -585,7 +578,6 @@ static const struct dma_buf_ops fastrpc_dma_buf_ops = {
.map_dma_buf = fastrpc_map_dma_buf,
.unmap_dma_buf = fastrpc_unmap_dma_buf,
.mmap = fastrpc_mmap,
- .map = fastrpc_kmap,
.vmap = fastrpc_vmap,
.release = fastrpc_release,
};
diff --git a/drivers/tee/tee_shm.c b/drivers/tee/tee_shm.c
index 09ddcd06c715..937ac5aaa6d8 100644
--- a/drivers/tee/tee_shm.c
+++ b/drivers/tee/tee_shm.c
@@ -71,11 +71,6 @@ static void tee_shm_op_release(struct dma_buf *dmabuf)
tee_shm_release(shm);
}
-static void *tee_shm_op_map(struct dma_buf *dmabuf, unsigned long pgnum)
-{
- return NULL;
-}
-
static int tee_shm_op_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
{
struct tee_shm *shm = dmabuf->priv;
@@ -93,7 +88,6 @@ static const struct dma_buf_ops tee_shm_dma_buf_ops = {
.map_dma_buf = tee_shm_op_map_dma_buf,
.unmap_dma_buf = tee_shm_op_unmap_dma_buf,
.release = tee_shm_op_release,
- .map = tee_shm_op_map,
.mmap = tee_shm_op_mmap,
};
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation
There's no callers in-tree anymore.
For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.
Signed-off-by: Daniel Vetter
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: de...@driverdev.osuosl.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/staging/android/ion/ion.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e6b1ca141b93..bb4ededc1150 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
_ion_buffer_destroy(buffer);
}
-static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
-{
- struct ion_buffer *buffer = dmabuf->priv;
-
- return buffer->vaddr + offset * PAGE_SIZE;
-}
-
-static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
- void *ptr)
-{
-}
-
static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
enum dma_data_direction direction)
{
@@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
.detach = ion_dma_buf_detatch,
.begin_cpu_access = ion_dma_buf_begin_cpu_access,
.end_cpu_access = ion_dma_buf_end_cpu_access,
- .map = ion_dma_buf_kmap,
- .unmap = ion_dma_buf_kunmap,
};
static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/15] drm/vmwgfx: Delete mmaping functions
No need for stubs, dma-buf.c takes care of that.
Aside, not having a ->release callback smelled like refcounting leak
somewhere. It will also score you a WARN_ON backtrace in dma-buf.c on
every export. But then I found that ttm_device_object_init overwrites
it. Overwriting const memory is not going to go down well in recent
kernels.
One more aside: The (un)map_dma_buf can't ever be called because
->attach rejects everything. Might want to drop a BUG_ON(1) in there.
Same for ->detach.
Signed-off-by: Daniel Vetter
Cc: VMware Graphics
Cc: Thomas Hellstrom
---
drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 33 ---
1 file changed, 33 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
index e420675e8db3..d9552a1efd13 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_prime.c
@@ -62,45 +62,12 @@ static void vmw_prime_unmap_dma_buf(struct
dma_buf_attachment *attach,
{
}
-static void *vmw_prime_dmabuf_vmap(struct dma_buf *dma_buf)
-{
- return NULL;
-}
-
-static void vmw_prime_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
-{
-}
-
-static void *vmw_prime_dmabuf_kmap(struct dma_buf *dma_buf,
- unsigned long page_num)
-{
- return NULL;
-}
-
-static void vmw_prime_dmabuf_kunmap(struct dma_buf *dma_buf,
- unsigned long page_num, void *addr)
-{
-
-}
-
-static int vmw_prime_dmabuf_mmap(struct dma_buf *dma_buf,
-struct vm_area_struct *vma)
-{
- WARN_ONCE(true, "Attempted use of dmabuf mmap. Bad.\n");
- return -ENOSYS;
-}
-
const struct dma_buf_ops vmw_prime_dmabuf_ops = {
.attach = vmw_prime_map_attach,
.detach = vmw_prime_map_detach,
.map_dma_buf = vmw_prime_map_dma_buf,
.unmap_dma_buf = vmw_prime_unmap_dma_buf,
.release = NULL,
- .map = vmw_prime_dmabuf_kmap,
- .unmap = vmw_prime_dmabuf_kunmap,
- .mmap = vmw_prime_dmabuf_mmap,
- .vmap = vmw_prime_dmabuf_vmap,
- .vunmap = vmw_prime_dmabuf_vunmap,
};
int vmw_prime_fd_to_handle(struct drm_device *dev,
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/15] drm/tegra: Remove dma_buf->k(un)map
No in-tree users left.
Signed-off-by: Daniel Vetter
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/gem.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gem.c b/drivers/gpu/drm/tegra/gem.c
index 662cb7c87ef5..84bb29070536 100644
--- a/drivers/gpu/drm/tegra/gem.c
+++ b/drivers/gpu/drm/tegra/gem.c
@@ -585,16 +585,6 @@ static int tegra_gem_prime_end_cpu_access(struct dma_buf
*buf,
return 0;
}
-static void *tegra_gem_prime_kmap(struct dma_buf *buf, unsigned long page)
-{
- return NULL;
-}
-
-static void tegra_gem_prime_kunmap(struct dma_buf *buf, unsigned long page,
- void *addr)
-{
-}
-
static int tegra_gem_prime_mmap(struct dma_buf *buf, struct vm_area_struct
*vma)
{
struct drm_gem_object *gem = buf->priv;
@@ -625,8 +615,6 @@ static const struct dma_buf_ops tegra_gem_prime_dmabuf_ops
= {
.release = tegra_gem_prime_release,
.begin_cpu_access = tegra_gem_prime_begin_cpu_access,
.end_cpu_access = tegra_gem_prime_end_cpu_access,
- .map = tegra_gem_prime_kmap,
- .unmap = tegra_gem_prime_kunmap,
.mmap = tegra_gem_prime_mmap,
.vmap = tegra_gem_prime_vmap,
.vunmap = tegra_gem_prime_vunmap,
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation
It's a dummy anyway.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/armada/armada_gem.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 93cf8b8bfcff..976685f2939e 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -461,16 +461,6 @@ static void armada_gem_prime_unmap_dma_buf(struct
dma_buf_attachment *attach,
kfree(sgt);
}
-static void *armada_gem_dmabuf_no_kmap(struct dma_buf *buf, unsigned long n)
-{
- return NULL;
-}
-
-static void
-armada_gem_dmabuf_no_kunmap(struct dma_buf *buf, unsigned long n, void *addr)
-{
-}
-
static int
armada_gem_dmabuf_mmap(struct dma_buf *buf, struct vm_area_struct *vma)
{
@@ -481,8 +471,6 @@ static const struct dma_buf_ops armada_gem_prime_dmabuf_ops
= {
.map_dma_buf= armada_gem_prime_map_dma_buf,
.unmap_dma_buf = armada_gem_prime_unmap_dma_buf,
.release= drm_gem_dmabuf_release,
- .map= armada_gem_dmabuf_no_kmap,
- .unmap = armada_gem_dmabuf_no_kunmap,
.mmap = armada_gem_dmabuf_mmap,
};
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map
No in-tree users left.
Note that this is one of the few (if only) implementations of dma-buf
that provided a kmap, but not a vmap implemenation. Given that the
only real user (in-tree at least) of kmap was tegra, and it's
impossible to buy a chip with tegra host1x and ompadrm on the same
SoC, there's no problem here.
Signed-off-by: Daniel Vetter
Cc: Tomi Valkeinen
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index 7344bb61936c..b319fe7f2371 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -85,25 +85,6 @@ static int omap_gem_dmabuf_end_cpu_access(struct dma_buf
*buffer,
return 0;
}
-static void *omap_gem_dmabuf_kmap(struct dma_buf *buffer,
- unsigned long page_num)
-{
- struct drm_gem_object *obj = buffer->priv;
- struct page **pages;
- omap_gem_get_pages(obj, &pages, false);
- omap_gem_cpu_sync_page(obj, page_num);
- return kmap(pages[page_num]);
-}
-
-static void omap_gem_dmabuf_kunmap(struct dma_buf *buffer,
- unsigned long page_num, void *addr)
-{
- struct drm_gem_object *obj = buffer->priv;
- struct page **pages;
- omap_gem_get_pages(obj, &pages, false);
- kunmap(pages[page_num]);
-}
-
static int omap_gem_dmabuf_mmap(struct dma_buf *buffer,
struct vm_area_struct *vma)
{
@@ -123,8 +104,6 @@ static const struct dma_buf_ops omap_dmabuf_ops = {
.release = drm_gem_dmabuf_release,
.begin_cpu_access = omap_gem_dmabuf_begin_cpu_access,
.end_cpu_access = omap_gem_dmabuf_end_cpu_access,
- .map = omap_gem_dmabuf_kmap,
- .unmap = omap_gem_dmabuf_kunmap,
.mmap = omap_gem_dmabuf_mmap,
};
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/15] dma-buf: Drop dma_buf_k(un)map
It's unused.
10 years ago, back when 32bit was still fairly common and trying to
not exhaust vmalloc space sounded like a worthwhile goal, adding these
to dma_buf made sense.
Reality is that they simply never caught on, and nowadays everyone who
needs plenty of buffers will run in 64bit mode anyway.
Also update the docs in this area to adjust them to reality.
The actual hooks in dma_buf_ops will be removed once all the
implementations are gone.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-buf.c | 63 ++-
include/linux/dma-buf.h | 2 --
2 files changed, 3 insertions(+), 62 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index d377b4ca66bf..97988ce1d2dc 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -880,29 +880,9 @@ EXPORT_SYMBOL_GPL(dma_buf_unmap_attachment);
* with calls to dma_buf_begin_cpu_access() and dma_buf_end_cpu_access()
* access.
*
- * To support dma_buf objects residing in highmem cpu access is page-based
- * using an api similar to kmap. Accessing a dma_buf is done in aligned
chunks
- * of PAGE_SIZE size. Before accessing a chunk it needs to be mapped, which
- * returns a pointer in kernel virtual address space. Afterwards the chunk
- * needs to be unmapped again. There is no limit on how often a given chunk
- * can be mapped and unmapped, i.e. the importer does not need to call
- * begin_cpu_access again before mapping the same chunk again.
- *
- * Interfaces::
- * void \*dma_buf_kmap(struct dma_buf \*, unsigned long);
- * void dma_buf_kunmap(struct dma_buf \*, unsigned long, void \*);
- *
- * Implementing the functions is optional for exporters and for importers all
- * the restrictions of using kmap apply.
- *
- * dma_buf kmap calls outside of the range specified in begin_cpu_access are
- * undefined. If the range is not PAGE_SIZE aligned, kmap needs to succeed on
- * the partial chunks at the beginning and end but may return stale or bogus
- * data outside of the range (in these partial chunks).
- *
- * For some cases the overhead of kmap can be too high, a vmap interface
- * is introduced. This interface should be used very carefully, as vmalloc
- * space is a limited resources on many architectures.
+ * Since for most kernel internal dma-buf accesses need the entire buffer, a
+ * vmap interface is introduced. Note that on very old 32-bit architectures
+ * vmalloc space might be limited and result in vmap calls failing.
*
* Interfaces::
* void \*dma_buf_vmap(struct dma_buf \*dmabuf)
@@ -1052,43 +1032,6 @@ int dma_buf_end_cpu_access(struct dma_buf *dmabuf,
}
EXPORT_SYMBOL_GPL(dma_buf_end_cpu_access);
-/**
- * dma_buf_kmap - Map a page of the buffer object into kernel address space.
The
- * same restrictions as for kmap and friends apply.
- * @dmabuf:[in]buffer to map page from.
- * @page_num: [in]page in PAGE_SIZE units to map.
- *
- * This call must always succeed, any necessary preparations that might fail
- * need to be done in begin_cpu_access.
- */
-void *dma_buf_kmap(struct dma_buf *dmabuf, unsigned long page_num)
-{
- WARN_ON(!dmabuf);
-
- if (!dmabuf->ops->map)
- return NULL;
- return dmabuf->ops->map(dmabuf, page_num);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kmap);
-
-/**
- * dma_buf_kunmap - Unmap a page obtained by dma_buf_kmap.
- * @dmabuf:[in]buffer to unmap page from.
- * @page_num: [in]page in PAGE_SIZE units to unmap.
- * @vaddr: [in]kernel space pointer obtained from dma_buf_kmap.
- *
- * This call must always succeed.
- */
-void dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long page_num,
- void *vaddr)
-{
- WARN_ON(!dmabuf);
-
- if (dmabuf->ops->unmap)
- dmabuf->ops->unmap(dmabuf, page_num, vaddr);
-}
-EXPORT_SYMBOL_GPL(dma_buf_kunmap);
-
/**
* dma_buf_mmap - Setup up a userspace mmap with the given vma
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index af73f835c51c..7feb9c3805ae 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -464,8 +464,6 @@ int dma_buf_begin_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direction dir);
int dma_buf_end_cpu_access(struct dma_buf *dma_buf,
enum dma_data_direction dir);
-void *dma_buf_kmap(struct dma_buf *, unsigned long);
-void dma_buf_kunmap(struct dma_buf *, unsigned long, void *);
int dma_buf_mmap(struct dma_buf *, struct vm_area_struct *,
unsigned long);
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map
No in-tree users left.
Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Matthew Auld
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sam Ravnborg
Cc: "Christian König"
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 36 ---
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 16 -
2 files changed, 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index eaea49d08eb5..372b57ca0efc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf,
void *vaddr)
i915_gem_object_unpin_map(obj);
}
-static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long
page_num)
-{
- struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
- struct page *page;
-
- if (page_num >= obj->base.size >> PAGE_SHIFT)
- return NULL;
-
- if (!i915_gem_object_has_struct_page(obj))
- return NULL;
-
- if (i915_gem_object_pin_pages(obj))
- return NULL;
-
- /* Synchronisation is left to the caller (via .begin_cpu_access()) */
- page = i915_gem_object_get_page(obj, page_num);
- if (IS_ERR(page))
- goto err_unpin;
-
- return kmap(page);
-
-err_unpin:
- i915_gem_object_unpin_pages(obj);
- return NULL;
-}
-
-static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
-{
- struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-
- kunmap(virt_to_page(addr));
- i915_gem_object_unpin_pages(obj);
-}
-
static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct
*vma)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
@@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
- .map = i915_gem_dmabuf_kmap,
- .unmap = i915_gem_dmabuf_kunmap,
.mmap = i915_gem_dmabuf_mmap,
.vmap = i915_gem_dmabuf_vmap,
.vunmap = i915_gem_dmabuf_vunmap,
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index b9e059d4328a..9272bef57092 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void
*vaddr)
vm_unmap_ram(vaddr, mock->npages);
}
-static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
- struct mock_dmabuf *mock = to_mock(dma_buf);
-
- return kmap(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
-{
- struct mock_dmabuf *mock = to_mock(dma_buf);
-
- return kunmap(mock->pages[page_num]);
-}
-
static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct
*vma)
{
return -ENODEV;
@@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops = {
.map_dma_buf = mock_map_dma_buf,
.unmap_dma_buf = mock_unmap_dma_buf,
.release = mock_dmabuf_release,
- .map = mock_dmabuf_kmap,
- .unmap = mock_dmabuf_kunmap,
.mmap = mock_dmabuf_mmap,
.vmap = mock_dmabuf_vmap,
.vunmap = mock_dmabuf_vunmap,
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
No in-tree users left.
Signed-off-by: Daniel Vetter
Cc: Kirti Wankhede
Cc: k...@vger.kernel.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
samples/vfio-mdev/mbochs.c | 16
1 file changed, 16 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index ac5c8c17b1ff..3cc5e5921682 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -891,26 +891,10 @@ static void mbochs_release_dmabuf(struct dma_buf *buf)
mutex_unlock(&mdev_state->ops_lock);
}
-static void *mbochs_kmap_dmabuf(struct dma_buf *buf, unsigned long page_num)
-{
- struct mbochs_dmabuf *dmabuf = buf->priv;
- struct page *page = dmabuf->pages[page_num];
-
- return kmap(page);
-}
-
-static void mbochs_kunmap_dmabuf(struct dma_buf *buf, unsigned long page_num,
-void *vaddr)
-{
- kunmap(vaddr);
-}
-
static struct dma_buf_ops mbochs_dmabuf_ops = {
.map_dma_buf = mbochs_map_dmabuf,
.unmap_dma_buf= mbochs_unmap_dmabuf,
.release = mbochs_release_dmabuf,
- .map = mbochs_kmap_dmabuf,
- .unmap= mbochs_kunmap_dmabuf,
.mmap = mbochs_mmap_dmabuf,
};
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks
All implementations are gone now.
Signed-off-by: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: linaro-mm-...@lists.linaro.org
---
include/linux/dma-buf.h | 25 -
1 file changed, 25 deletions(-)
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index 7feb9c3805ae..abf5459a5b9d 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -249,31 +249,6 @@ struct dma_buf_ops {
*/
int (*mmap)(struct dma_buf *, struct vm_area_struct *vma);
- /**
-* @map:
-*
-* Maps a page from the buffer into kernel address space. The page is
-* specified by offset into the buffer in PAGE_SIZE units.
-*
-* This callback is optional.
-*
-* Returns:
-*
-* Virtual address pointer where requested page can be accessed. NULL
-* on error or when this function is unimplemented by the exporter.
-*/
- void *(*map)(struct dma_buf *, unsigned long);
-
- /**
-* @unmap:
-*
-* Unmaps a page from the buffer. Page offset and address pointer should
-* be the same as the one passed to and returned by matching call to
map.
-*
-* This callback is optional.
-*/
- void (*unmap)(struct dma_buf *, unsigned long, void *);
-
void *(*vmap)(struct dma_buf *);
void (*vunmap)(struct dma_buf *, void *vaddr);
};
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V12 0/6] mdev based hardware virtio offloading support
On 2019/11/18 下午2:16, Jason Wang wrote:
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and register itself as a new kind of mdev driver. Then
it provides a unified way for kernel virtio driver to talk with mdev
device implementation.
Though the series only contains kernel driver support, the goal is to
make the transport generic enough to support userspace drivers. This
means vhost-mdev[1] could be built on top as well by resuing the
transport.
A sample driver is also implemented which simulate a virito-net
loopback ethernet device on top of vringh + workqueue. This could be
used as a reference implementation for real hardware driver.
Also a real IFC VF driver was also posted here[2] which is a good
reference for vendors who is interested in their own virtio datapath
offloading product.
Consider mdev framework only support VFIO device and driver right now,
this series also extend it to support other types. This is done
through decoupling VFIO specific bits out of mdev core and make mdev
an independent module that allows to be used by multiple types of
buses.
Pktgen test was done with virito-net + mvnet loop back device.
Please review.
[1] https://lkml.org/lkml/2019/11/5/424
[2] https://lkml.org/lkml/2019/11/5/227
Changes from V11:
- decouple VFIO specific bits out of mdev core
- make mdev an indepdent module to allow buses other than VFIO mdev
- allow structure composition of mdev through specifiy the size of
mdev structure
- introduce mdev_vfio structure and store the VFIO specific callbacks
there
- don't use "mdev" bus for virtio, use a new "mdev_virtio" bus, and
store the virtio specific callbacks in mdev_virtio structure.
- do the class_id, matching on top of "mdev_virtio" bus
It looks to me this series get some conflicts with gvt-linux.git. Will
fix them and post v13.
Thanks
Changes from V10:
- rename mvnet to mvnet_loopback
- fix typo in the help text for sample Kconfig
Changes from V9:
- Tweak the help text for virito-mdev kconfig
Changes from V8:
- try silent checkpatch, some are still there becuase they were inherited
from virtio_config_ops which needs to be resolved in an independent series
- tweak on the comment and doc
- remove VIRTIO_MDEV_F_VERSION_1 completely
- rename CONFIG_VIRTIO_MDEV_DEVICE to CONFIG_VIRTIO_MDEV
Changes from V7:
- drop {set|get}_mdev_features for virtio
- typo and comment style fixes
Changes from V6:
- rename ops files and compile guard
Changes from V5:
- use dev_warn() instead of WARN(1) when class id is not set
- validate id_table before trying to do matching between device and
driver
- add wildcard for modpost script
- use unique name for id_table
- move get_mdev_features() to be the first member of virtio_device_ops
and more comments for it
- typo fixes for the comments above virtio_mdev_ops
Changes from V4:
- keep mdev_set_class() for the device that doesn't use device ops
- use union for device ops pointer in mdev_device
- introduce class specific helper for getting is device ops
- use WARN_ON instead of BUG_ON in mdev_set_virtio_ops
- explain details of get_mdev_features() and get_vendor_id()
- distinguish the optional virito device ops from mandatory ones and
make get_generation() optional
- rename vfio_mdev.h to vfio_mdev_ops.h, rename virito_mdev.h to
virtio_mdev_ops.h
- don't abuse version fileds in virtio_mdev structure, use features
instead
- fix warning during device remove
- style & docs tweaks and typo fixes
Changes from V3:
- document that class id (device ops) must be specified in create()
- add WARN() when trying to set class_id when it has already set
- add WARN() when class_id is not specified in create() and correctly
return an error in this case
- correct the prototype of mdev_set_class() in the doc
- add documention of mdev_set_class()
- remove the unnecessary "class_id_fail" label when class id is not
specified in create()
- convert id_table in vfio_mdev to const
- move mdev_set_class and its friends after mdev_uuid()
- suqash the patch of bus uevent into patch of introducing class id
- tweak the words in the docs per Cornelia suggestion
- tie class_id and device ops through class specific initialization
routine like mdev_set_vfio_ops()
- typos fixes in the docs of virtio-mdev callbacks
- document the usage of virtqueues in struct virtio_mdev_device
- remove the useless vqs array in struct virtio_mdev_device
- rename MDEV_ID_XXX to MDEV_CLASS_ID_XXX
Changes from V2:
- fail when class_id is not specified
- drop the vringh patch
- match the doc to the code
- tweak the commit log
- move device_ops from parent to mdev device
- remove the unused MDEV_ID_VHOST
Changes from V1:
- move virtio_mdev.c to drivers/virtio
- store class_id in mdev_device
Re: [Intel-gfx] [PATCH V12 5/6] virtio: introduce a mdev based transport
On Mon, Nov 18, 2019 at 02:17:02PM +0800, Jason Wang wrote:
> This patch introduces a new mdev transport for virtio. This is used to
> use kernel virtio driver to drive the mediated device that is capable
> of populating virtqueue directly.
>
> A new virtio-mdev driver will be registered to the mdev bus, when a
> new virtio-mdev device is probed, it will register the device with
> mdev based config ops. This means it is a software transport between
> mdev driver and mdev device. The transport was implemented through
> bus_ops of mdev parent.
>
> Signed-off-by: Jason Wang
> ---
> drivers/virtio/Kconfig | 13 ++
> drivers/virtio/Makefile | 1 +
> drivers/virtio/virtio_mdev.c | 409 +++
> include/linux/mdev_virtio.h | 5 +
> 4 files changed, 428 insertions(+)
> create mode 100644 drivers/virtio/virtio_mdev.c
>
> diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> index 078615cf2afc..6a89b3de97d3 100644
> --- a/drivers/virtio/Kconfig
> +++ b/drivers/virtio/Kconfig
> @@ -43,6 +43,19 @@ config VIRTIO_PCI_LEGACY
>
> If unsure, say Y.
>
> +config VIRTIO_MDEV
> + tristate "MDEV driver for virtio devices"
> + depends on MDEV_VIRTIO
> + default n
> + help
> + This driver provides support for virtio based paravirtual
> + device driver over MDEV bus. For this to be useful, you need
> + an appropriate virtio mdev device implementation that
> + operates on a physical device to allow the datapath of virtio
> + to be offloaded to hardware.
> +
> + If unsure, say M.
> +
> config VIRTIO_PMEM
> tristate "Support for virtio pmem driver"
> depends on VIRTIO
> diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> index 3a2b5c5dcf46..f2997b6c812f 100644
> --- a/drivers/virtio/Makefile
> +++ b/drivers/virtio/Makefile
> @@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
> virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
> obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
> obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
> +obj-$(CONFIG_VIRTIO_MDEV) += virtio_mdev.o
> diff --git a/drivers/virtio/virtio_mdev.c b/drivers/virtio/virtio_mdev.c
> new file mode 100644
> index ..7fdb42f055df
> --- /dev/null
> +++ b/drivers/virtio/virtio_mdev.c
> @@ -0,0 +1,409 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * VIRTIO based driver for Mediated device
> + *
> + * Copyright (c) 2019, Red Hat. All rights reserved.
> + * Author: Jason Wang
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_VERSION "0.1"
> +#define DRIVER_AUTHOR "Red Hat Corporation"
> +#define DRIVER_DESC "VIRTIO based driver for Mediated device"
> +
> +#define to_virtio_mdev_device(dev) \
> + container_of(dev, struct virtio_mdev_device, vdev)
> +
> +struct virtio_mdev_device {
> + struct virtio_device vdev;
> + struct mdev_device *mdev;
> + u64 features;
> +
> + /* The lock to protect virtqueue list */
> + spinlock_t lock;
> + /* List of virtio_mdev_vq_info */
> + struct list_head virtqueues;
> +};
> +
> +struct virtio_mdev_vq_info {
> + /* the actual virtqueue */
> + struct virtqueue *vq;
> +
> + /* the list node for the virtqueues list */
> + struct list_head node;
> +};
> +
> +static struct mdev_device *vm_get_mdev(struct virtio_device *vdev)
> +{
> + struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
> + struct mdev_device *mdev = vm_dev->mdev;
> +
> + return mdev;
> +}
> +
> +static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset,
> + void *buf, unsigned len)
> +{
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
> +
> + ops->get_config(mdev, offset, buf, len);
> +}
> +
> +static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset,
> + const void *buf, unsigned len)
> +{
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
> +
> + ops->set_config(mdev, offset, buf, len);
> +}
> +
> +static u32 virtio_mdev_generation(struct virtio_device *vdev)
> +{
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
> +
> +
> + if (ops->get_generation)
> + return ops->get_generation(mdev);
> +
> + return 0;
> +}
> +
> +static u8 virtio_mdev_get_status(struct virtio_device *vdev)
> +{
> + struct mdev_device *mdev = vm_get_mdev(vdev);
> + const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
> +
> + return ops->get_status(mdev);
> +}
> +
> +static void virtio_mdev_set_status(struct virtio_device *vdev, u8 status)
> +{
> + struct mdev_device *m
[Intel-gfx] [PATCH] drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
Since igt now defaults to not enabling ftrace-on-oops, we need to
manually invoke GEM_TRACE_DUMP() to see the debug log prior to a
GEM_BUG_ON panicking.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.h b/drivers/gpu/drm/i915/i915_gem.h
index c7985767296a..1753c84d6c0d 100644
--- a/drivers/gpu/drm/i915/i915_gem.h
+++ b/drivers/gpu/drm/i915/i915_gem.h
@@ -30,6 +30,8 @@
#include
+#include "i915_utils.h"
+
struct drm_i915_private;
#ifdef CONFIG_DRM_I915_DEBUG_GEM
@@ -39,6 +41,7 @@ struct drm_i915_private;
#define GEM_BUG_ON(condition) do { if (unlikely((condition))) {\
GEM_TRACE_ERR("%s:%d GEM_BUG_ON(%s)\n", \
__func__, __LINE__, __stringify(condition)); \
+ GEM_TRACE_DUMP(); \
BUG(); \
} \
} while(0)
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Xen-devel] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions
On 11/18/19 12:35 PM, Daniel Vetter wrote:
There's no in-kernel users for the k(un)map stuff. And the mmap one is
actively harmful - return 0 and then _not_ actually mmaping can't end
well.
Signed-off-by: Daniel Vetter
Reviewed-by: Oleksandr Andrushchenko
Cc: Boris Ostrovsky
Cc: Juergen Gross
Cc: Stefano Stabellini
Cc: xen-de...@lists.xenproject.org
--
Ack for merging this through drm trees very much appreciated.
-Daniel
---
drivers/xen/gntdev-dmabuf.c | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/xen/gntdev-dmabuf.c b/drivers/xen/gntdev-dmabuf.c
index 2c4f324f8626..fe7bd69d6955 100644
--- a/drivers/xen/gntdev-dmabuf.c
+++ b/drivers/xen/gntdev-dmabuf.c
@@ -342,35 +342,12 @@ static void dmabuf_exp_ops_release(struct dma_buf
*dma_buf)
mutex_unlock(&priv->lock);
}
-static void *dmabuf_exp_ops_kmap(struct dma_buf *dma_buf,
-unsigned long page_num)
-{
- /* Not implemented. */
- return NULL;
-}
-
-static void dmabuf_exp_ops_kunmap(struct dma_buf *dma_buf,
- unsigned long page_num, void *addr)
-{
- /* Not implemented. */
-}
-
-static int dmabuf_exp_ops_mmap(struct dma_buf *dma_buf,
- struct vm_area_struct *vma)
-{
- /* Not implemented. */
- return 0;
-}
-
static const struct dma_buf_ops dmabuf_exp_ops = {
.attach = dmabuf_exp_ops_attach,
.detach = dmabuf_exp_ops_detach,
.map_dma_buf = dmabuf_exp_ops_map_dma_buf,
.unmap_dma_buf = dmabuf_exp_ops_unmap_dma_buf,
.release = dmabuf_exp_ops_release,
- .map = dmabuf_exp_ops_kmap,
- .unmap = dmabuf_exp_ops_kunmap,
- .mmap = dmabuf_exp_ops_mmap,
};
struct gntdev_dmabuf_export_args {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/15] xen/gntdev-dmabuf: Ditch dummy map functions
On 18.11.19 11:35, Daniel Vetter wrote: There's no in-kernel users for the k(un)map stuff. And the mmap one is actively harmful - return 0 and then _not_ actually mmaping can't end well. Signed-off-by: Daniel Vetter Cc: Boris Ostrovsky Cc: Juergen Gross Cc: Stefano Stabellini Cc: xen-de...@lists.xenproject.org Reviewed-by: Juergen Gross -- Ack for merging this through drm trees very much appreciated. Yes, I'm fine with that. Juergen ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V12 5/6] virtio: introduce a mdev based transport
On 2019/11/18 下午6:44, Michael S. Tsirkin wrote:
+static const struct mdev_virtio_class_id virtio_id_table[] = {
+ { MDEV_VIRTIO_CLASS_ID_VIRTIO },
+ { 0 },
+};
+
Do we still need the class ID? It's a virtio mdev bus,
do we need a virtio class as well?
If we want to have auto match between vhost-mdev driver and vhost-mdev
device, we need this.
Otherwise, user need to manually probe or bind driver to the device.
Thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support
On 18.11.2019 11:35, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: linux-me...@vger.kernel.org
Acked-by: Marek Szyprowski
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8
> drivers/media/common/videobuf2/videobuf2-vmalloc.c| 8
> 3 files changed, 24 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf
> *dbuf)
> vb2_dc_put(dbuf->priv);
> }
>
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
> pgnum)
> -{
> - struct vb2_dc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
> static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
> {
> struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
> .detach = vb2_dc_dmabuf_ops_detach,
> .map_dma_buf = vb2_dc_dmabuf_ops_map,
> .unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> - .map = vb2_dc_dmabuf_ops_kmap,
> .vmap = vb2_dc_dmabuf_ops_vmap,
> .mmap = vb2_dc_dmabuf_ops_mmap,
> .release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf
> *dbuf)
> vb2_dma_sg_put(dbuf->priv);
> }
>
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
> pgnum)
> -{
> - struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
> static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
> {
> struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
> .detach = vb2_dma_sg_dmabuf_ops_detach,
> .map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
> .unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> - .map = vb2_dma_sg_dmabuf_ops_kmap,
> .vmap = vb2_dma_sg_dmabuf_ops_vmap,
> .mmap = vb2_dma_sg_dmabuf_ops_mmap,
> .release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct
> dma_buf *dbuf)
> vb2_vmalloc_put(dbuf->priv);
> }
>
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
> pgnum)
> -{
> - struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
> static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
> {
> struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
> .detach = vb2_vmalloc_dmabuf_ops_detach,
> .map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
> .unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> - .map = vb2_vmalloc_dmabuf_ops_kmap,
> .vmap = vb2_vmalloc_dmabuf_ops_vmap,
> .mmap = vb2_vmalloc_dmabuf_ops_mmap,
> .release = vb2_vmalloc_dmabuf_ops_release,
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH V13 0/6] mdev based hardware virtio offloading support
Hi all:
There are hardwares that can do virtio datapath offloading while
having its own control path. This path tries to implement a mdev based
unified API to support using kernel virtio driver to drive those
devices. This is done by introducing a new mdev transport for virtio
(virtio_mdev) and register itself as a new kind of mdev driver. Then
it provides a unified way for kernel virtio driver to talk with mdev
device implementation.
Though the series only contains kernel driver support, the goal is to
make the transport generic enough to support userspace drivers. This
means vhost-mdev[1] could be built on top as well by resuing the
transport.
A sample driver is also implemented which simulate a virito-net
loopback ethernet device on top of vringh + workqueue. This could be
used as a reference implementation for real hardware driver.
Also a real IFC VF driver was also posted here[2] which is a good
reference for vendors who is interested in their own virtio datapath
offloading product.
Consider mdev framework only support VFIO device and driver right now,
this series also extend it to support other types. This is done
through decoupling VFIO specific bits out of mdev core and make mdev
an independent module that allows to be used by multiple types of
buses.
Pktgen test was done with virito-net + mvnet loop back device.
Please review.
[1] https://lkml.org/lkml/2019/11/7/62
[2] https://lkml.org/lkml/2019/11/12/215
Changes from V12:
- rebase on top of gvt-linux.git
Changes from V11:
- decouple VFIO specific bits out of mdev core
- make mdev an indepdent module to allow buses other than VFIO mdev
- allow structure composition of mdev through specifiy the size of
mdev structure
- introduce mdev_vfio structure and store the VFIO specific callbacks
there
- don't use "mdev" bus for virtio, use a new "mdev_virtio" bus, and
store the virtio specific callbacks in mdev_virtio structure.
- do the class_id, matching on top of "mdev_virtio" bus
Changes from V10:
- rename mvnet to mvnet_loopback
- fix typo in the help text for sample Kconfig
Changes from V9:
- Tweak the help text for virito-mdev kconfig
Changes from V8:
- try silent checkpatch, some are still there becuase they were inherited
from virtio_config_ops which needs to be resolved in an independent series
- tweak on the comment and doc
- remove VIRTIO_MDEV_F_VERSION_1 completely
- rename CONFIG_VIRTIO_MDEV_DEVICE to CONFIG_VIRTIO_MDEV
Changes from V7:
- drop {set|get}_mdev_features for virtio
- typo and comment style fixes
Changes from V6:
- rename ops files and compile guard
Changes from V5:
- use dev_warn() instead of WARN(1) when class id is not set
- validate id_table before trying to do matching between device and
driver
- add wildcard for modpost script
- use unique name for id_table
- move get_mdev_features() to be the first member of virtio_device_ops
and more comments for it
- typo fixes for the comments above virtio_mdev_ops
Changes from V4:
- keep mdev_set_class() for the device that doesn't use device ops
- use union for device ops pointer in mdev_device
- introduce class specific helper for getting is device ops
- use WARN_ON instead of BUG_ON in mdev_set_virtio_ops
- explain details of get_mdev_features() and get_vendor_id()
- distinguish the optional virito device ops from mandatory ones and
make get_generation() optional
- rename vfio_mdev.h to vfio_mdev_ops.h, rename virito_mdev.h to
virtio_mdev_ops.h
- don't abuse version fileds in virtio_mdev structure, use features
instead
- fix warning during device remove
- style & docs tweaks and typo fixes
Changes from V3:
- document that class id (device ops) must be specified in create()
- add WARN() when trying to set class_id when it has already set
- add WARN() when class_id is not specified in create() and correctly
return an error in this case
- correct the prototype of mdev_set_class() in the doc
- add documention of mdev_set_class()
- remove the unnecessary "class_id_fail" label when class id is not
specified in create()
- convert id_table in vfio_mdev to const
- move mdev_set_class and its friends after mdev_uuid()
- suqash the patch of bus uevent into patch of introducing class id
- tweak the words in the docs per Cornelia suggestion
- tie class_id and device ops through class specific initialization
routine like mdev_set_vfio_ops()
- typos fixes in the docs of virtio-mdev callbacks
- document the usage of virtqueues in struct virtio_mdev_device
- remove the useless vqs array in struct virtio_mdev_device
- rename MDEV_ID_XXX to MDEV_CLASS_ID_XXX
Changes from V2:
- fail when class_id is not specified
- drop the vringh patch
- match the doc to the code
- tweak the commit log
- move device_ops from parent to mdev device
- remove the unused MDEV_ID_VHOST
Changes from V1:
- move virtio_mdev.c to drivers/virtio
- store class_id in mdev_device instead of mdev_parent
- store device_ops in mdev_device instead of mdev_parent
- reorder the patch, vringh fix c
[Intel-gfx] [PATCH V13 1/6] mdev: make mdev bus agnostic
Current mdev is tied to a VFIO specific "mdev" bus. This prevent mdev from being used by other types of API/buses. So this patch tries to make mdev bus agnostic through making a mdev core a thin module: - decouple VFIO bus specific bits from mdev_core.c to mdev_vfio.c and introduce mdev_vfio module - require to specify the type of bus when registering mdev device and mdev driver With those modifications mdev become a generic module that could be used by multiple types of virtual buses and devices. Signed-off-by: Jason Wang --- .../driver-api/vfio-mediated-device.rst | 68 ++-- MAINTAINERS | 1 + drivers/gpu/drm/i915/gvt/kvmgt.c | 8 +- drivers/s390/cio/vfio_ccw_ops.c | 6 +- drivers/s390/crypto/vfio_ap_ops.c | 21 ++-- drivers/s390/crypto/vfio_ap_private.h | 2 +- drivers/vfio/mdev/Kconfig | 17 ++- drivers/vfio/mdev/Makefile| 4 +- drivers/vfio/mdev/mdev_core.c | 104 +- drivers/vfio/mdev/mdev_driver.c | 29 ++--- drivers/vfio/mdev/mdev_private.h | 13 ++- drivers/vfio/mdev/mdev_vfio.c | 48 drivers/vfio/mdev/vfio_mdev.c | 5 +- drivers/vfio/vfio_iommu_type1.c | 6 +- include/linux/mdev.h | 16 ++- include/linux/mdev_vfio.h | 25 + samples/vfio-mdev/mbochs.c| 8 +- samples/vfio-mdev/mdpy.c | 8 +- samples/vfio-mdev/mtty.c | 8 +- 19 files changed, 269 insertions(+), 128 deletions(-) create mode 100644 drivers/vfio/mdev/mdev_vfio.c create mode 100644 include/linux/mdev_vfio.h diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst index 25eb7d5b834b..1887d27a565e 100644 --- a/Documentation/driver-api/vfio-mediated-device.rst +++ b/Documentation/driver-api/vfio-mediated-device.rst @@ -49,35 +49,37 @@ devices as examples, as these devices are the first devices to use this module:: +---+ | | - | +---+ | mdev_register_driver() +--+ - | | | +<+ | - | | mdev | | | | - | | bus | +>+ vfio_mdev.ko |<-> VFIO user - | | driver | | probe()/remove()| |APIs - | | | | +--+ - | +---+ | + | MDEV CORE | mdev_register_driver() +--+ + |MODULE +<+ | + |mdev.ko| | | + | +>+ vfio_mdev.ko |<-> VFIO user + | | probe()/remove()| |APIs + | | +--+ + +---+---+---+ + | /|\ + | | +callbacks| | mdev_register_device() + | | mdev_register_bus() +\|/ | + +---+---+---+ + | | mdev_vfio_register_device() +--+ + | +<-+ | + | | | nvidia.ko |<-> physical + | +->+ |device + | MDEV VFIO |callbacks +--+ + | Physical| + |device | mdev_vfio_register_device() +--+ + | interface |<-+ | + | | | i915.ko |<-> physical + | mdev_vfio.ko +->+ |device + | |callbacks +--+ + | | + | | mdev_vfio_register_device() +--+ + | +<-+ | + | | | ccw_device.ko|<-> physical + | +->+ |device + | |callbacks +--+ | | - | MDEV CORE| - | MODULE | - | mdev.ko | - | +---+ | mdev_register_device() +--+ - | | | +<+ | - | | | | | nvidia.ko |<-> physical - | | | +>+ |device - | | | |callbacks+--+ - | | Physical | | - | | device | | mdev_register_device() +--+ - | | interface | |<---
[Intel-gfx] [PATCH V13 2/6] mdev: split out VFIO bus specific parent ops
The only thing left for generalizing mdev is the VFIO specific parent
ops. This is basically the open/release/read/write/ioctl/mmap.
To support this, mdev core is extend to support a specific size
of structure during create, this will allow to compose mdev structure
into mdev vfio structure and place the VFIO specific callbacks there
like:
struct mdev_vfio {
struct mdev_device mdev;
const struct mdev_vfio_ops *ops;
};
Helpers for setting and getting the ops were introduced to support
mdev vfio device to set ops and vfio mdev driver to use the ops.
Signed-off-by: Jason Wang
---
.../driver-api/vfio-mediated-device.rst | 34 +--
drivers/gpu/drm/i915/gvt/kvmgt.c | 16 ---
drivers/s390/cio/vfio_ccw_ops.c | 17 +---
drivers/s390/crypto/vfio_ap_ops.c | 13 --
drivers/vfio/mdev/mdev_core.c | 5 ++-
drivers/vfio/mdev/mdev_private.h | 5 +++
drivers/vfio/mdev/mdev_vfio.c | 30 -
drivers/vfio/mdev/vfio_mdev.c | 38
include/linux/mdev.h | 37
include/linux/mdev_vfio.h | 43 +++
samples/vfio-mdev/mbochs.c| 18 +---
samples/vfio-mdev/mdpy.c | 19 +---
samples/vfio-mdev/mtty.c | 16 ---
13 files changed, 189 insertions(+), 102 deletions(-)
diff --git a/Documentation/driver-api/vfio-mediated-device.rst
b/Documentation/driver-api/vfio-mediated-device.rst
index 1887d27a565e..9045584e4ea3 100644
--- a/Documentation/driver-api/vfio-mediated-device.rst
+++ b/Documentation/driver-api/vfio-mediated-device.rst
@@ -153,26 +153,36 @@ callbacks per mdev parent device, per mdev type, or any
other categorization.
Vendor drivers are expected to be fully asynchronous in this respect or
provide their own internal resource protection.)
-The callbacks in the mdev_parent_ops structure are as follows:
+A driver should use the mdev_parent_ops structure in the function call
+to register itself with the mdev core driver::
-* open: open callback of mediated device
-* close: close callback of mediated device
-* ioctl: ioctl callback of mediated device
+ extern int mdev_vfio_register_device(struct device *dev,
+ const struct mdev_parent_ops
*ops);
+
+However, the mdev_parent_ops structure is not required in the function call
+that a driver should use to unregister itself with the mdev core driver::
+
+ extern void mdev_vfio_unregister_device(struct device *dev);
+
+The VFIO specific callbacks is abstracted in mdev_vfio_ops structure
+are as follows:
+
+* open: open callback of VFIO mediated device
+* close: close callback of VFIO mediated device
+* ioctl: ioctl callback of VFIO mediated device
* read : read emulation callback
* write: write emulation callback
* mmap: mmap emulation callback
-A driver should use the mdev_parent_ops structure and bus type in the
-function call to register itself with the mdev core driver::
+During the creation of VFIO mediated device, mdev_vfio_ops need to be
+specified::
- extern int mdev_register_device(struct device *dev,
-const struct mdev_parent_ops *ops,
- struct bus_type *bus);
+void mdev_vfio_set_ops(struct mdev_device *mdev,
+const struct mdev_vfio_ops *ops);
-However, the mdev_parent_ops structure is not required in the function call
-that a driver should use to unregister itself with the mdev core driver::
+Those callbacks could be fetched by drivers through::
- extern void mdev_unregister_device(struct device *dev);
+const struct mdev_vfio_ops *mdev_vfio_get_ops(struct mdev_device
*mdev);
Mediated Device Management Interface Through sysfs
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index afdb3de5ce2f..e72c36174035 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -643,6 +643,8 @@ static void kvmgt_put_vfio_device(void *vgpu)
vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device);
}
+static const struct mdev_vfio_ops intel_mdev_vfio_ops;
+
static int intel_vgpu_create(struct kobject *kobj, struct mdev_device *mdev)
{
struct intel_vgpu *vgpu = NULL;
@@ -678,6 +680,7 @@ static int intel_vgpu_create(struct kobject *kobj, struct
mdev_device *mdev)
dev_name(mdev_dev(mdev)));
ret = 0;
+ mdev_vfio_set_ops(mdev, &intel_mdev_vfio_ops);
out:
return ret;
}
@@ -1581,20 +1584,21 @@ static const struct attribute_group
*intel_vgpu_groups[] = {
NULL,
};
-static struct mdev_parent_ops intel_vgpu_ops = {
- .mdev_attr_groups = intel_vgpu_groups,
- .create = intel_vgpu_create,
-
[Intel-gfx] [PATCH V13 3/6] mdev: move to drivers/
Mdev now is nothing VFIO specific, let's move it to upper
directory.
Signed-off-by: Jason Wang
---
MAINTAINERS | 7 +--
drivers/Kconfig | 2 ++
drivers/Makefile | 1 +
drivers/mdev/Kconfig | 19 ++
drivers/mdev/Makefile | 5 +
drivers/{vfio => }/mdev/mdev_core.c | 0
drivers/{vfio => }/mdev/mdev_driver.c | 0
drivers/{vfio => }/mdev/mdev_private.h| 0
drivers/{vfio => }/mdev/mdev_sysfs.c | 0
.../{vfio/mdev/mdev_vfio.c => mdev/vfio.c}| 0
drivers/vfio/mdev/Kconfig | 20 ---
drivers/vfio/mdev/Makefile| 4
drivers/vfio/mdev/vfio_mdev.c | 2 --
13 files changed, 32 insertions(+), 28 deletions(-)
create mode 100644 drivers/mdev/Kconfig
create mode 100644 drivers/mdev/Makefile
rename drivers/{vfio => }/mdev/mdev_core.c (100%)
rename drivers/{vfio => }/mdev/mdev_driver.c (100%)
rename drivers/{vfio => }/mdev/mdev_private.h (100%)
rename drivers/{vfio => }/mdev/mdev_sysfs.c (100%)
rename drivers/{vfio/mdev/mdev_vfio.c => mdev/vfio.c} (100%)
diff --git a/MAINTAINERS b/MAINTAINERS
index 6d590afb62c3..5d7e8badf58c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17129,15 +17129,18 @@ T:git git://github.com/awilliam/linux-vfio.git
S: Maintained
F: Documentation/driver-api/vfio.rst
F: drivers/vfio/
+F: drivers/mdev/vfio.c
F: include/linux/vfio.h
F: include/uapi/linux/vfio.h
-VFIO MEDIATED DEVICE DRIVERS
+MEDIATED DEVICE DRIVERS
+M: Alex Williamson
M: Kirti Wankhede
+R: Cornelia Huck
L: k...@vger.kernel.org
S: Maintained
F: Documentation/driver-api/vfio-mediated-device.rst
-F: drivers/vfio/mdev/
+F: drivers/mdev
F: include/linux/mdev.h
F: include/linux/mdev_vfio.h
F: samples/vfio-mdev/
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 8befa53f43be..3e2839048fe6 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -228,4 +228,6 @@ source "drivers/interconnect/Kconfig"
source "drivers/counter/Kconfig"
+source "drivers/mdev/Kconfig"
+
endmenu
diff --git a/drivers/Makefile b/drivers/Makefile
index aaef17cc6512..592e23f2e629 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -186,3 +186,4 @@ obj-$(CONFIG_SIOX) += siox/
obj-$(CONFIG_GNSS) += gnss/
obj-$(CONFIG_INTERCONNECT) += interconnect/
obj-$(CONFIG_COUNTER) += counter/
+obj-$(CONFIG_MDEV) += mdev/
diff --git a/drivers/mdev/Kconfig b/drivers/mdev/Kconfig
new file mode 100644
index ..4561f2d4178f
--- /dev/null
+++ b/drivers/mdev/Kconfig
@@ -0,0 +1,19 @@
+
+config MDEV
+ tristate "Mediated device driver framework"
+ default n
+ help
+ Provides a framework to virtualize devices.
+
+ If you don't know what do here, say N.
+
+config VFIO_MDEV
+ tristate "VFIO Mediated device driver"
+depends on VFIO && MDEV
+default n
+ help
+ Proivdes a mediated BUS for userspace driver through VFIO
+ framework. See Documentation/vfio-mediated-device.txt for
+ more details.
+
+ If you don't know what do here, say N.
diff --git a/drivers/mdev/Makefile b/drivers/mdev/Makefile
new file mode 100644
index ..0b749e7f8ff4
--- /dev/null
+++ b/drivers/mdev/Makefile
@@ -0,0 +1,5 @@
+
+mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o
+mdev_vfio-y := vfio.o
+obj-$(CONFIG_MDEV) += mdev.o
+obj-$(CONFIG_VFIO_MDEV) += mdev_vfio.o
diff --git a/drivers/vfio/mdev/mdev_core.c b/drivers/mdev/mdev_core.c
similarity index 100%
rename from drivers/vfio/mdev/mdev_core.c
rename to drivers/mdev/mdev_core.c
diff --git a/drivers/vfio/mdev/mdev_driver.c b/drivers/mdev/mdev_driver.c
similarity index 100%
rename from drivers/vfio/mdev/mdev_driver.c
rename to drivers/mdev/mdev_driver.c
diff --git a/drivers/vfio/mdev/mdev_private.h b/drivers/mdev/mdev_private.h
similarity index 100%
rename from drivers/vfio/mdev/mdev_private.h
rename to drivers/mdev/mdev_private.h
diff --git a/drivers/vfio/mdev/mdev_sysfs.c b/drivers/mdev/mdev_sysfs.c
similarity index 100%
rename from drivers/vfio/mdev/mdev_sysfs.c
rename to drivers/mdev/mdev_sysfs.c
diff --git a/drivers/vfio/mdev/mdev_vfio.c b/drivers/mdev/vfio.c
similarity index 100%
rename from drivers/vfio/mdev/mdev_vfio.c
rename to drivers/mdev/vfio.c
diff --git a/drivers/vfio/mdev/Kconfig b/drivers/vfio/mdev/Kconfig
index 2e07ca915a96..9a9234c3e00e 100644
--- a/drivers/vfio/mdev/Kconfig
+++ b/drivers/vfio/mdev/Kconfig
@@ -1,24 +1,4 @@
-config MDEV
- tristate "Mediated device driver framework"
- default n
- help
- Provides a framework to virtualize devices.
-
- If you don't know what do here, say N.
-
-config VFIO_MDEV
- tristate "VFIO Mediated device driver"
-depends on VFIO
[Intel-gfx] [PATCH V13 4/6] mdev: introduce mediated virtio bus
This patch implements a mediated virtio bus over mdev framework. This
will be used by the future virtio-mdev and vhost-mdev on top to allow
driver from either userspace or kernel to control the device which is
capable of offloading virtio datapath.
Signed-off-by: Jason Wang
---
MAINTAINERS | 2 +
drivers/mdev/Kconfig | 10 ++
drivers/mdev/Makefile | 2 +
drivers/mdev/virtio.c | 126 +++
include/linux/mdev_virtio.h | 163 ++
include/linux/mod_devicetable.h | 8 ++
scripts/mod/devicetable-offsets.c | 3 +
scripts/mod/file2alias.c | 12 +++
8 files changed, 326 insertions(+)
create mode 100644 drivers/mdev/virtio.c
create mode 100644 include/linux/mdev_virtio.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 5d7e8badf58c..e1b57c84f249 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17269,6 +17269,8 @@ F: include/linux/virtio*.h
F: include/uapi/linux/virtio_*.h
F: drivers/crypto/virtio/
F: mm/balloon_compaction.c
+F: include/linux/mdev_virtio.h
+F: drivers/mdev/virtio.c
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin"
diff --git a/drivers/mdev/Kconfig b/drivers/mdev/Kconfig
index 4561f2d4178f..cd84d4670552 100644
--- a/drivers/mdev/Kconfig
+++ b/drivers/mdev/Kconfig
@@ -17,3 +17,13 @@ config VFIO_MDEV
more details.
If you don't know what do here, say N.
+
+config MDEV_VIRTIO
+ tristate "Mediated VIRTIO bus"
+ depends on VIRTIO && MDEV
+ default n
+ help
+ Proivdes a mediated BUS for virtio. It could be used by
+ either kenrel driver or userspace driver.
+
+ If you don't know what do here, say N.
diff --git a/drivers/mdev/Makefile b/drivers/mdev/Makefile
index 0b749e7f8ff4..eb14031c9944 100644
--- a/drivers/mdev/Makefile
+++ b/drivers/mdev/Makefile
@@ -1,5 +1,7 @@
mdev-y := mdev_core.o mdev_sysfs.o mdev_driver.o
mdev_vfio-y := vfio.o
+mdev_virtio-y := virtio.o
obj-$(CONFIG_MDEV) += mdev.o
obj-$(CONFIG_VFIO_MDEV) += mdev_vfio.o
+obj-$(CONFIG_MDEV_VIRTIO) += mdev_virtio.o
diff --git a/drivers/mdev/virtio.c b/drivers/mdev/virtio.c
new file mode 100644
index ..25de329615c4
--- /dev/null
+++ b/drivers/mdev/virtio.c
@@ -0,0 +1,126 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Mediated VIRTIO bus
+ *
+ * Copyright (c) 2019, Red Hat. All rights reserved.
+ * Author: Jason Wang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "mdev_private.h"
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Jason Wang"
+#define DRIVER_DESC"Mediated VIRTIO bus"
+
+struct bus_type mdev_virtio_bus_type;
+
+struct mdev_virtio_device {
+ struct mdev_device mdev;
+ const struct mdev_virtio_ops *ops;
+ u16 class_id;
+};
+
+#define to_mdev_virtio(mdev) container_of(mdev, \
+ struct mdev_virtio_device, mdev)
+#define to_mdev_virtio_drv(mdrv) container_of(mdrv, \
+ struct mdev_virtio_driver, drv)
+
+static int mdev_virtio_match(struct device *dev, struct device_driver *drv)
+{
+ unsigned int i;
+ struct mdev_device *mdev = mdev_from_dev(dev, &mdev_virtio_bus_type);
+ struct mdev_virtio_device *mdev_virtio = to_mdev_virtio(mdev);
+ struct mdev_driver *mdrv = to_mdev_driver(drv);
+ struct mdev_virtio_driver *mdrv_virtio = to_mdev_virtio_drv(mdrv);
+ const struct mdev_virtio_class_id *ids = mdrv_virtio->id_table;
+
+ if (!ids)
+ return 0;
+
+ for (i = 0; ids[i].id; i++)
+ if (ids[i].id == mdev_virtio->class_id)
+ return 1;
+ return 0;
+}
+
+static int mdev_virtio_uevent(struct device *dev, struct kobj_uevent_env *env)
+{
+ struct mdev_device *mdev = mdev_from_dev(dev, &mdev_virtio_bus_type);
+ struct mdev_virtio_device *mdev_virtio = to_mdev_virtio(mdev);
+
+ return add_uevent_var(env, "MODALIAS=mdev_virtio:c%02X",
+ mdev_virtio->class_id);
+}
+
+struct bus_type mdev_virtio_bus_type = {
+ .name = "mdev_virtio",
+ .probe = mdev_probe,
+ .remove = mdev_remove,
+ .match = mdev_virtio_match,
+ .uevent = mdev_virtio_uevent,
+};
+EXPORT_SYMBOL(mdev_virtio_bus_type);
+
+void mdev_virtio_set_class_id(struct mdev_device *mdev, u16 class_id)
+{
+ struct mdev_virtio_device *mdev_virtio = to_mdev_virtio(mdev);
+
+ mdev_virtio->class_id = class_id;
+}
+EXPORT_SYMBOL(mdev_virtio_set_class_id);
+
+int mdev_virtio_register_device(struct device *dev,
+ const struct mdev_parent_ops *ops)
+{
+ return mdev_register_device(dev, ops, &mdev_virtio_bus_type,
+ sizeof(struct mdev_virtio_device));
+}
+EXPORT_SYMBOL(mdev_virtio_reg
[Intel-gfx] [PATCH V13 5/6] virtio: introduce a mdev based transport
This patch introduces a new mdev transport for virtio. This is used to
use kernel virtio driver to drive the mediated device that is capable
of populating virtqueue directly.
A new virtio-mdev driver will be registered to the mdev bus, when a
new virtio-mdev device is probed, it will register the device with
mdev based config ops. This means it is a software transport between
mdev driver and mdev device. The transport was implemented through
bus_ops of mdev parent.
Signed-off-by: Jason Wang
---
drivers/virtio/Kconfig | 13 ++
drivers/virtio/Makefile | 1 +
drivers/virtio/virtio_mdev.c | 409 +++
include/linux/mdev_virtio.h | 5 +
4 files changed, 428 insertions(+)
create mode 100644 drivers/virtio/virtio_mdev.c
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 078615cf2afc..6a89b3de97d3 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -43,6 +43,19 @@ config VIRTIO_PCI_LEGACY
If unsure, say Y.
+config VIRTIO_MDEV
+ tristate "MDEV driver for virtio devices"
+ depends on MDEV_VIRTIO
+ default n
+ help
+ This driver provides support for virtio based paravirtual
+ device driver over MDEV bus. For this to be useful, you need
+ an appropriate virtio mdev device implementation that
+ operates on a physical device to allow the datapath of virtio
+ to be offloaded to hardware.
+
+ If unsure, say M.
+
config VIRTIO_PMEM
tristate "Support for virtio pmem driver"
depends on VIRTIO
diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
index 3a2b5c5dcf46..f2997b6c812f 100644
--- a/drivers/virtio/Makefile
+++ b/drivers/virtio/Makefile
@@ -6,3 +6,4 @@ virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
virtio_pci-$(CONFIG_VIRTIO_PCI_LEGACY) += virtio_pci_legacy.o
obj-$(CONFIG_VIRTIO_BALLOON) += virtio_balloon.o
obj-$(CONFIG_VIRTIO_INPUT) += virtio_input.o
+obj-$(CONFIG_VIRTIO_MDEV) += virtio_mdev.o
diff --git a/drivers/virtio/virtio_mdev.c b/drivers/virtio/virtio_mdev.c
new file mode 100644
index ..7fdb42f055df
--- /dev/null
+++ b/drivers/virtio/virtio_mdev.c
@@ -0,0 +1,409 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * VIRTIO based driver for Mediated device
+ *
+ * Copyright (c) 2019, Red Hat. All rights reserved.
+ * Author: Jason Wang
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_VERSION "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+#define DRIVER_DESC "VIRTIO based driver for Mediated device"
+
+#define to_virtio_mdev_device(dev) \
+ container_of(dev, struct virtio_mdev_device, vdev)
+
+struct virtio_mdev_device {
+ struct virtio_device vdev;
+ struct mdev_device *mdev;
+ u64 features;
+
+ /* The lock to protect virtqueue list */
+ spinlock_t lock;
+ /* List of virtio_mdev_vq_info */
+ struct list_head virtqueues;
+};
+
+struct virtio_mdev_vq_info {
+ /* the actual virtqueue */
+ struct virtqueue *vq;
+
+ /* the list node for the virtqueues list */
+ struct list_head node;
+};
+
+static struct mdev_device *vm_get_mdev(struct virtio_device *vdev)
+{
+ struct virtio_mdev_device *vm_dev = to_virtio_mdev_device(vdev);
+ struct mdev_device *mdev = vm_dev->mdev;
+
+ return mdev;
+}
+
+static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset,
+ void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+ ops->get_config(mdev, offset, buf, len);
+}
+
+static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset,
+ const void *buf, unsigned len)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+ ops->set_config(mdev, offset, buf, len);
+}
+
+static u32 virtio_mdev_generation(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+
+ if (ops->get_generation)
+ return ops->get_generation(mdev);
+
+ return 0;
+}
+
+static u8 virtio_mdev_get_status(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+ return ops->get_status(mdev);
+}
+
+static void virtio_mdev_set_status(struct virtio_device *vdev, u8 status)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ const struct mdev_virtio_ops *ops = mdev_virtio_get_ops(mdev);
+
+ return ops->set_status(mdev, status);
+}
+
+static void virtio_mdev_reset(struct virtio_device *vdev)
+{
+ struct mdev_device *mdev = vm_get_mdev(vdev);
+ con
[Intel-gfx] [PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
This sample driver creates mdev device that simulate virtio net device
over virtio mdev transport. The device is implemented through vringh
and workqueue. A device specific dma ops is to make sure HVA is used
directly as the IOVA. This should be sufficient for kernel virtio
driver to work.
Only 'virtio' type is supported right now. I plan to add 'vhost' type
on top which requires some virtual IOMMU implemented in this sample
driver.
Signed-off-by: Jason Wang
---
MAINTAINERS| 1 +
samples/Kconfig| 10 +
samples/vfio-mdev/Makefile | 1 +
samples/vfio-mdev/mvnet_loopback.c | 690 +
4 files changed, 702 insertions(+)
create mode 100644 samples/vfio-mdev/mvnet_loopback.c
diff --git a/MAINTAINERS b/MAINTAINERS
index e1b57c84f249..36f9fe9034be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17246,6 +17246,7 @@ F: net/vmw_vsock/virtio_transport.c
F: drivers/net/vsockmon.c
F: drivers/vhost/vsock.c
F: tools/testing/vsock/
+F: samples/vfio-mdev/mvnet_loopback.c
VIRTIO CONSOLE DRIVER
M: Amit Shah
diff --git a/samples/Kconfig b/samples/Kconfig
index c8dacb4dda80..1bef029cc977 100644
--- a/samples/Kconfig
+++ b/samples/Kconfig
@@ -131,6 +131,16 @@ config SAMPLE_VFIO_MDEV_MDPY
mediated device. It is a simple framebuffer and supports
the region display interface (VFIO_GFX_PLANE_TYPE_REGION).
+config SAMPLE_VIRTIO_MDEV_NET_LOOPBACK
+ tristate "Build loopback VIRTIO net example mediated device sample code
-- loadable modules only"
+ depends on MDEV_VIRTIO && VHOST_RING && m
+ help
+ Build a networking sample device for use as a virtio
+ mediated device. The device cooperates with virtio-mdev bus
+ driver to present an virtio ethernet driver for
+ kernel. It simply loopbacks all packets from its TX
+ virtqueue to its RX virtqueue.
+
config SAMPLE_VFIO_MDEV_MDPY_FB
tristate "Build VFIO mdpy example guest fbdev driver -- loadable module
only"
depends on FB && m
diff --git a/samples/vfio-mdev/Makefile b/samples/vfio-mdev/Makefile
index 10d179c4fdeb..817618569848 100644
--- a/samples/vfio-mdev/Makefile
+++ b/samples/vfio-mdev/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_SAMPLE_VFIO_MDEV_MTTY) += mtty.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY) += mdpy.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MDPY_FB) += mdpy-fb.o
obj-$(CONFIG_SAMPLE_VFIO_MDEV_MBOCHS) += mbochs.o
+obj-$(CONFIG_SAMPLE_VIRTIO_MDEV_NET_LOOPBACK) += mvnet_loopback.o
diff --git a/samples/vfio-mdev/mvnet_loopback.c
b/samples/vfio-mdev/mvnet_loopback.c
new file mode 100644
index ..79059a177f39
--- /dev/null
+++ b/samples/vfio-mdev/mvnet_loopback.c
@@ -0,0 +1,690 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Mediated virtual virtio-net device driver.
+ *
+ * Copyright (c) 2019, Red Hat Inc. All rights reserved.
+ * Author: Jason Wang
+ *
+ * Sample driver that creates mdev device that simulates ethernet loopback
+ * device.
+ *
+ * Usage:
+ *
+ * # modprobe virtio_mdev
+ * # modprobe mvnet_loopback
+ * # cd /sys/devices/virtual/mvnet_loopback/mvnet_loopback/ \
+ * mdev_supported_types/mvnet_loopback-virtio
+ * # echo "83b8f4f2-509f-382f-3c1e-e6bfe0fa1001" > ./create
+ * # cd devices/83b8f4f2-509f-382f-3c1e-e6bfe0fa1001
+ * # ls -d virtio0
+ * virtio0
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define VERSION_STRING "0.1"
+#define DRIVER_AUTHOR "Red Hat Corporation"
+
+#define MVNET_CLASS_NAME "mvnet_loopback"
+#define MVNET_NAME "mvnet_loopback"
+
+#define VIRTIO_MDEV_DEVICE_API_STRING "virtio-mdev"
+
+/*
+ * Global Structures
+ */
+
+static struct mvnet_dev {
+ struct class*vd_class;
+ struct idr vd_idr;
+ struct device dev;
+} mvnet_dev;
+
+struct mvnet_virtqueue {
+ struct vringh vring;
+ struct vringh_kiov iov;
+ unsigned short head;
+ bool ready;
+ u64 desc_addr;
+ u64 device_addr;
+ u64 driver_addr;
+ u32 num;
+ void *private;
+ irqreturn_t (*cb)(void *data);
+};
+
+#define MVNET_QUEUE_ALIGN PAGE_SIZE
+#define MVNET_QUEUE_MAX 256
+#define MVNET_DEVICE_ID 0x1
+#define MVNET_VENDOR_ID 0
+
+u64 mvnet_features = (1ULL << VIRTIO_F_ANY_LAYOUT) |
+(1ULL << VIRTIO_F_VERSION_1) |
+(1ULL << VIRTIO_F_IOMMU_PLATFORM);
+
+/* State of each mdev device */
+struct mvnet_state {
+ struct mvnet_virtqueue vqs[2];
+ struct work_struct work;
+ /* spinlock to synchronize virtqueue state */
+ spinlock_t lock;
+ struct mdev_device *mdev;
+ struct virtio_net_config config;
+ void *buffer;
+ u32 status;
+ u32 generation;
+ u64 features;
+ struct list_head next;
+};
+
+static struct mutex
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Add intel_gt_driver_late_release for mock device
== Series Details ==
Series: drm/i915/selftests: Add intel_gt_driver_late_release for mock device
URL : https://patchwork.freedesktop.org/series/69609/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ddc0fcd5661f drm/i915/selftests: Add intel_gt_driver_late_release for mock
device
-:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#10:
References: dea397e818b1 ("drm/i915/gt: Flush retire.work timer object on
unload")
-:10: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit dea397e818b1 ("drm/i915/gt:
Flush retire.work timer object on unload")'
#10:
References: dea397e818b1 ("drm/i915/gt: Flush retire.work timer object on
unload")
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 24635c5152af ("drm/i915: Move
intel_gt initialization to a separate file")'
#11:
References: 24635c5152af ("drm/i915: Move intel_gt initialization to a separate
file")
total: 2 errors, 1 warnings, 0 checks, 14 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] media/videobuf2: Drop dma_buf->k(un)map support
On 11/18/19 11:35 AM, Daniel Vetter wrote:
> No in-tree users left.
>
> Signed-off-by: Daniel Vetter
Acked-by: Hans Verkuil
Thanks!
Hans
> Cc: Pawel Osciak
> Cc: Marek Szyprowski
> Cc: Kyungmin Park
> Cc: Tomasz Figa
> Cc: linux-me...@vger.kernel.org
> --
> Ack for merging this through drm trees very much appreciated.
> -Daniel
> ---
> drivers/media/common/videobuf2/videobuf2-dma-contig.c | 8
> drivers/media/common/videobuf2/videobuf2-dma-sg.c | 8
> drivers/media/common/videobuf2/videobuf2-vmalloc.c| 8
> 3 files changed, 24 deletions(-)
>
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> index 44cd0e530bbd..d0c9dffe49e5 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
> @@ -335,13 +335,6 @@ static void vb2_dc_dmabuf_ops_release(struct dma_buf
> *dbuf)
> vb2_dc_put(dbuf->priv);
> }
>
> -static void *vb2_dc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
> pgnum)
> -{
> - struct vb2_dc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
> static void *vb2_dc_dmabuf_ops_vmap(struct dma_buf *dbuf)
> {
> struct vb2_dc_buf *buf = dbuf->priv;
> @@ -360,7 +353,6 @@ static const struct dma_buf_ops vb2_dc_dmabuf_ops = {
> .detach = vb2_dc_dmabuf_ops_detach,
> .map_dma_buf = vb2_dc_dmabuf_ops_map,
> .unmap_dma_buf = vb2_dc_dmabuf_ops_unmap,
> - .map = vb2_dc_dmabuf_ops_kmap,
> .vmap = vb2_dc_dmabuf_ops_vmap,
> .mmap = vb2_dc_dmabuf_ops_mmap,
> .release = vb2_dc_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> index ed706b2a263c..6db60e9d5183 100644
> --- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> +++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
> @@ -470,13 +470,6 @@ static void vb2_dma_sg_dmabuf_ops_release(struct dma_buf
> *dbuf)
> vb2_dma_sg_put(dbuf->priv);
> }
>
> -static void *vb2_dma_sg_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
> pgnum)
> -{
> - struct vb2_dma_sg_buf *buf = dbuf->priv;
> -
> - return buf->vaddr ? buf->vaddr + pgnum * PAGE_SIZE : NULL;
> -}
> -
> static void *vb2_dma_sg_dmabuf_ops_vmap(struct dma_buf *dbuf)
> {
> struct vb2_dma_sg_buf *buf = dbuf->priv;
> @@ -495,7 +488,6 @@ static const struct dma_buf_ops vb2_dma_sg_dmabuf_ops = {
> .detach = vb2_dma_sg_dmabuf_ops_detach,
> .map_dma_buf = vb2_dma_sg_dmabuf_ops_map,
> .unmap_dma_buf = vb2_dma_sg_dmabuf_ops_unmap,
> - .map = vb2_dma_sg_dmabuf_ops_kmap,
> .vmap = vb2_dma_sg_dmabuf_ops_vmap,
> .mmap = vb2_dma_sg_dmabuf_ops_mmap,
> .release = vb2_dma_sg_dmabuf_ops_release,
> diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> index 04d51ca63223..4d5af352e249 100644
> --- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> +++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
> @@ -319,13 +319,6 @@ static void vb2_vmalloc_dmabuf_ops_release(struct
> dma_buf *dbuf)
> vb2_vmalloc_put(dbuf->priv);
> }
>
> -static void *vb2_vmalloc_dmabuf_ops_kmap(struct dma_buf *dbuf, unsigned long
> pgnum)
> -{
> - struct vb2_vmalloc_buf *buf = dbuf->priv;
> -
> - return buf->vaddr + pgnum * PAGE_SIZE;
> -}
> -
> static void *vb2_vmalloc_dmabuf_ops_vmap(struct dma_buf *dbuf)
> {
> struct vb2_vmalloc_buf *buf = dbuf->priv;
> @@ -344,7 +337,6 @@ static const struct dma_buf_ops vb2_vmalloc_dmabuf_ops = {
> .detach = vb2_vmalloc_dmabuf_ops_detach,
> .map_dma_buf = vb2_vmalloc_dmabuf_ops_map,
> .unmap_dma_buf = vb2_vmalloc_dmabuf_ops_unmap,
> - .map = vb2_vmalloc_dmabuf_ops_kmap,
> .vmap = vb2_vmalloc_dmabuf_ops_vmap,
> .mmap = vb2_vmalloc_dmabuf_ops_mmap,
> .release = vb2_vmalloc_dmabuf_ops_release,
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Allow userspace to specify ringsize on construction
Hi Chris,
Only some minor comments from me, mostly out of my curiosity.
On Friday, November 15, 2019 5:05:45 PM CET Chris Wilson wrote:
> No good reason why we must always use a static ringsize, so let
> userspace select one during construction.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 139 +++-
> drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
> include/uapi/drm/i915_drm.h | 19 +++
> 3 files changed, 153 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 1284f47303fa..ee9a4634fed8 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -597,23 +597,30 @@ __create_context(struct drm_i915_private *i915)
> return ERR_PTR(err);
> }
>
> -static void
> +static int
> context_apply_all(struct i915_gem_context *ctx,
> - void (*fn)(struct intel_context *ce, void *data),
> + int (*fn)(struct intel_context *ce, void *data),
> void *data)
> {
> struct i915_gem_engines_iter it;
> struct intel_context *ce;
> + int err = 0;
>
> - for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it)
> - fn(ce, data);
> + for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
> + err = fn(ce, data);
> + if (err)
> + break;
> + }
> i915_gem_context_unlock_engines(ctx);
> +
> + return err;
> }
>
> -static void __apply_ppgtt(struct intel_context *ce, void *vm)
> +static int __apply_ppgtt(struct intel_context *ce, void *vm)
> {
> i915_vm_put(ce->vm);
> ce->vm = i915_vm_get(vm);
> + return 0;
> }
>
> static struct i915_address_space *
> @@ -651,9 +658,10 @@ static void __set_timeline(struct intel_timeline **dst,
> intel_timeline_put(old);
> }
>
> -static void __apply_timeline(struct intel_context *ce, void *timeline)
> +static int __apply_timeline(struct intel_context *ce, void *timeline)
> {
> __set_timeline(&ce->timeline, timeline);
> + return 0;
> }
>
> static void __assign_timeline(struct i915_gem_context *ctx,
> @@ -1223,6 +1231,104 @@ static int set_ppgtt(struct drm_i915_file_private
> *file_priv,
> return err;
> }
>
> +static int __apply_ringsize(struct intel_context *ce, void *sz)
> +{
> + int err;
> +
> + err = i915_active_wait(&ce->active);
> + if (err < 0)
> + return err;
> +
> + if (intel_context_lock_pinned(ce))
> + return -EINTR;
> +
> + if (intel_context_is_pinned(ce)) {
> + err = -EBUSY; /* In active use, come back later! */
> + goto unlock;
> + }
> +
> + if (test_bit(CONTEXT_ALLOC_BIT, &ce->flags)) {
> + struct intel_ring *ring;
> +
> + /* Replace the existing ringbuffer */
> + ring = intel_engine_create_ring(ce->engine,
> + (unsigned long)sz);
> + if (IS_ERR(ring)) {
> + err = PTR_ERR(ring);
> + goto unlock;
> + }
> +
> + intel_ring_put(ce->ring);
> + ce->ring = ring;
> +
> + /* Context image will be updated on next pin */
> + } else {
> + ce->ring = sz;
> + }
> +
> +unlock:
> + intel_context_unlock_pinned(ce);
> + return err;
> +}
I'm wondering if this function (and __get_ringsize() below as well), with its
dependency on intel_context internals, especially on that dual meaning of
ce->ring which depends on (ce->flags & CONTEXT_ALLOC_BIT), would better fit
into drivers/gpu/drm/i915/gt/intel_context.c.
> +
> +static int set_ringsize(struct i915_gem_context *ctx,
> + struct drm_i915_gem_context_param *args)
> +{
> + if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
> + return -ENODEV;
> +
> + if (args->size)
> + return -EINVAL;
> +
> + if (!IS_ALIGNED(args->value, I915_GTT_PAGE_SIZE))
> + return -EINVAL;
> +
> + if (args->value < I915_GTT_PAGE_SIZE)
> + return -EINVAL;
> +
> + if (args->value > 128 * I915_GTT_PAGE_SIZE)
> + return -EINVAL;
> +
> + return context_apply_all(ctx,
> + __apply_ringsize,
> + __intel_context_ring_size(args->value));
> +}
> +
> +static int __get_ringsize(struct intel_context *ce, void *arg)
> +{
> + int num_pages;
> +
> + if (intel_context_lock_pinned(ce))
> + return -EINTR;
> +
> + if (test_bit(CONTEXT_ALLOC_BIT, &ce->flags))
> + num_pages = ce->ring->size / I915_GTT_PAGE_SIZE;
> + else
> + num_pages = (uintptr_t)ce->ring / I915_GTT_PAGE_SIZE;
> +
> + intel_context_unlock_pinned(ce);
> + return num_pages; /* s
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: fix accidental static variable use
On Sat, 16 Nov 2019, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: fix accidental static variable use
> URL : https://patchwork.freedesktop.org/series/69525/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7352_full -> Patchwork_15280_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_15280_full absolutely need to
> be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_15280_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_15280_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@prime_vgem@fence-wait-bsd1:
> - shard-tglb: [PASS][1] -> [INCOMPLETE][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7352/shard-tglb9/igt@prime_v...@fence-wait-bsd1.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-tglb4/igt@prime_v...@fence-wait-bsd1.html
>
Hardly caused by this patch.
Pushed, thanks for the review.
BR,
Jani.
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@gem_exec_parse_blt@bb-chained}:
> - shard-tglb: NOTRUN -> [SKIP][3]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-tglb9/igt@gem_exec_parse_...@bb-chained.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_15280_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_ctx_isolation@vecs0-s3:
> - shard-apl: [PASS][4] -> [DMESG-WARN][5] ([fdo#108566])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7352/shard-apl1/igt@gem_ctx_isolat...@vecs0-s3.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-apl4/igt@gem_ctx_isolat...@vecs0-s3.html
>
> * igt@gem_ctx_persistence@vcs1-mixed-process:
> - shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#109276] /
> [fdo#112080]) +2 similar issues
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7352/shard-iclb1/igt@gem_ctx_persiste...@vcs1-mixed-process.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-iclb5/igt@gem_ctx_persiste...@vcs1-mixed-process.html
>
> * igt@gem_ctx_switch@queue-light:
> - shard-tglb: [PASS][8] -> [INCOMPLETE][9] ([fdo#111672])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7352/shard-tglb3/igt@gem_ctx_swi...@queue-light.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-tglb6/igt@gem_ctx_swi...@queue-light.html
>
> * igt@gem_exec_schedule@pi-ringfull-bsd:
> - shard-iclb: [PASS][10] -> [SKIP][11] ([fdo#112146]) +3 similar
> issues
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7352/shard-iclb7/igt@gem_exec_sched...@pi-ringfull-bsd.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-iclb2/igt@gem_exec_sched...@pi-ringfull-bsd.html
>
> * igt@gem_exec_schedule@preempt-contexts-bsd2:
> - shard-iclb: [PASS][12] -> [SKIP][13] ([fdo#109276]) +13 similar
> issues
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7352/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd2.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-iclb5/igt@gem_exec_sched...@preempt-contexts-bsd2.html
>
> * igt@gem_exec_schedule@preempt-queue-chain-blt:
> - shard-tglb: [PASS][14] -> [INCOMPLETE][15] ([fdo#111606] /
> [fdo#111677])
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7352/shard-tglb4/igt@gem_exec_sched...@preempt-queue-chain-blt.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-tglb6/igt@gem_exec_sched...@preempt-queue-chain-blt.html
>
> * igt@gem_exec_suspend@basic-s3:
> - shard-tglb: [PASS][16] -> [INCOMPLETE][17] ([fdo#111736] /
> [fdo#111850])
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7352/shard-tglb5/igt@gem_exec_susp...@basic-s3.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-tglb8/igt@gem_exec_susp...@basic-s3.html
>
> * igt@gem_persistent_relocs@forked-interruptible-thrash-inactive:
> - shard-apl: [PASS][18] -> [TIMEOUT][19] ([fdo#112113])
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7352/shard-apl1/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15280/shard-apl4/igt@gem_persistent_rel...@forked-interruptible-thrash-inactive.html
>
> * igt@gem_userp
Re: [Intel-gfx] [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support
On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote: > There's no in-tree users anymore. > > Signed-off-by: Daniel Vetter > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman > Cc: Jens Wiklander > Cc: tee-...@lists.linaro.org > -- > Ack for merging this through drm trees very much appreciated. > -Daniel Acked-by: Greg Kroah-Hartman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation
On Mon, Nov 18, 2019 at 11:35:25AM +0100, Daniel Vetter wrote: > There's no callers in-tree anymore. > > For merging probably best to stuff this into drm-misc, since that's > where the dma-buf heaps will land too. And the resulting conflict > hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap > implemenation. > > Signed-off-by: Daniel Vetter > Cc: Laura Abbott > Cc: Sumit Semwal > Cc: de...@driverdev.osuosl.org > Cc: linaro-mm-...@lists.linaro.org > --- > drivers/staging/android/ion/ion.c | 14 -- > 1 file changed, 14 deletions(-) Acked-by: Greg Kroah-Hartman ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Add intel_gt_driver_late_release for mock device
== Series Details ==
Series: drm/i915/selftests: Add intel_gt_driver_late_release for mock device
URL : https://patchwork.freedesktop.org/series/69609/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7360 -> Patchwork_15310
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/index.html
Known issues
Here are the changes found in Patchwork_15310 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-cml-s: [PASS][1] -> [DMESG-WARN][2] ([fdo#111764])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/fi-cml-s/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@gem_exec_suspend@basic-s0:
- fi-icl-u3: [DMESG-WARN][3] ([fdo#106107]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/fi-icl-u3/igt@gem_exec_susp...@basic-s0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/fi-icl-u3/igt@gem_exec_susp...@basic-s0.html
* igt@i915_module_load@reload-with-fault-injection:
- fi-skl-6770hq: [DMESG-WARN][5] ([fdo#105541]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/fi-skl-6770hq/igt@i915_module_l...@reload-with-fault-injection.html
* igt@i915_selftest@live_blt:
- fi-bsw-nick:[DMESG-FAIL][7] ([fdo#112176]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/fi-bsw-nick/igt@i915_selftest@live_blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/fi-bsw-nick/igt@i915_selftest@live_blt.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-guc: [FAIL][9] ([fdo#103167]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105541]: https://bugs.freedesktop.org/show_bug.cgi?id=105541
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
[fdo#111764]: https://bugs.freedesktop.org/show_bug.cgi?id=111764
[fdo#112176]: https://bugs.freedesktop.org/show_bug.cgi?id=112176
[fdo#112298]: https://bugs.freedesktop.org/show_bug.cgi?id=112298
Participating hosts (50 -> 44)
--
Additional (1): fi-tgl-u
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-byt-clapper fi-kbl-r
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7360 -> Patchwork_15310
CI-20190529: 20190529
CI_DRM_7360: c8cc75b06238355d2214457ffe643c0560bdd1d8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5290: 14d19371610fabafa0ee5a21160373b90ada0a30 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15310: ddc0fcd5661fda4aaed89cc053865d5a49dcd97e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ddc0fcd5661f drm/i915/selftests: Add intel_gt_driver_late_release for mock
device
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Allow userspace to specify ringsize on construction
Quoting Janusz Krzysztofik (2019-11-18 11:14:12)
> Hi Chris,
>
> Only some minor comments from me, mostly out of my curiosity.
>
> On Friday, November 15, 2019 5:05:45 PM CET Chris Wilson wrote:
> > No good reason why we must always use a static ringsize, so let
> > userspace select one during construction.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > ---
> > +static int __apply_ringsize(struct intel_context *ce, void *sz)
> > +{
> > + int err;
> > +
> > + err = i915_active_wait(&ce->active);
> > + if (err < 0)
> > + return err;
> > +
> > + if (intel_context_lock_pinned(ce))
> > + return -EINTR;
> > +
> > + if (intel_context_is_pinned(ce)) {
> > + err = -EBUSY; /* In active use, come back later! */
> > + goto unlock;
> > + }
> > +
> > + if (test_bit(CONTEXT_ALLOC_BIT, &ce->flags)) {
> > + struct intel_ring *ring;
> > +
> > + /* Replace the existing ringbuffer */
> > + ring = intel_engine_create_ring(ce->engine,
> > + (unsigned long)sz);
> > + if (IS_ERR(ring)) {
> > + err = PTR_ERR(ring);
> > + goto unlock;
> > + }
> > +
> > + intel_ring_put(ce->ring);
> > + ce->ring = ring;
> > +
> > + /* Context image will be updated on next pin */
> > + } else {
> > + ce->ring = sz;
> > + }
> > +
> > +unlock:
> > + intel_context_unlock_pinned(ce);
> > + return err;
> > +}
>
> I'm wondering if this function (and __get_ringsize() below as well), with its
> dependency on intel_context internals, especially on that dual meaning of
> ce->ring which depends on (ce->flags & CONTEXT_ALLOC_BIT), would better fit
> into drivers/gpu/drm/i915/gt/intel_context.c.
Possibly, but at the same time it's currently only implementing a
feature of the GEM context.
I hear you, I'm just resisting, mainly because I don't want to have to
think of a good name :)
intel_context_param.c
intel_context_ring.c
I might be able to find friends for either.
> > +static int set_ringsize(struct i915_gem_context *ctx,
> > + struct drm_i915_gem_context_param *args)
> > +{
> > + if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
> > + return -ENODEV;
> > +
> > + if (args->size)
> > + return -EINVAL;
> > +
> > + if (!IS_ALIGNED(args->value, I915_GTT_PAGE_SIZE))
> > + return -EINVAL;
> > +
> > + if (args->value < I915_GTT_PAGE_SIZE)
> > + return -EINVAL;
> > +
> > + if (args->value > 128 * I915_GTT_PAGE_SIZE)
> > + return -EINVAL;
> > +
> > + return context_apply_all(ctx,
> > + __apply_ringsize,
> > + __intel_context_ring_size(args->value));
> > +}
> > +
> > +static int __get_ringsize(struct intel_context *ce, void *arg)
> > +{
> > + int num_pages;
> > +
> > + if (intel_context_lock_pinned(ce))
> > + return -EINTR;
> > +
> > + if (test_bit(CONTEXT_ALLOC_BIT, &ce->flags))
> > + num_pages = ce->ring->size / I915_GTT_PAGE_SIZE;
> > + else
> > + num_pages = (uintptr_t)ce->ring / I915_GTT_PAGE_SIZE;
> > +
> > + intel_context_unlock_pinned(ce);
> > + return num_pages; /* stop on first engine */
>
> Location of this comment seems not perfect to me as it is not quite obvious
> how that works without examining how this function is used, but having spent
> a
> while looking around, I'm not able to suggest a better place.
Yeah, the comment is for the intent of returning the positive, so
there's definitely a case for explaining the unusual pattern here.
The calling loop is just a standard if (err) return err; propagation so
that hardly merits a long winded explanation.
> > +static int get_ringsize(struct i915_gem_context *ctx,
> > + struct drm_i915_gem_context_param *args)
> > +{
> > + int num_pages;
> > +
> > + if (!HAS_LOGICAL_RING_CONTEXTS(ctx->i915))
> > + return -ENODEV;
> > +
> > + if (args->size)
> > + return -EINVAL;
> > +
> > + num_pages = context_apply_all(ctx, __get_ringsize, NULL);
> > + if (num_pages < 0)
> > + return num_pages;
> > +
> > + args->value = (u64)num_pages * I915_GTT_PAGE_SIZE;
>
> Do you convert to num_pages inside __get_ringsize() then back to size in
> bytes
> to avoid an overflow? Or any other reason? Something that may be useful in
> the future?
Just being prudent in making sure we have sufficient bits across all the
type-narrowing.
> > @@ -2003,6 +2113,19 @@ static int clone_engines(struct i915_gem_context
> > *dst,
> > __free_engines(clone, n);
> > goto err_unlock;
> > }
> > +
> > + /* Copy across the preferred ringsize */
> > + clone->engines[n]-
Re: [Intel-gfx] [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map
Am 18.11.19 um 11:35 schrieb Daniel Vetter:
No in-tree users left.
Good to know, thanks.
Aside, I think mock_dmabuf would be a nice addition to drm
mock/selftest helpers (we have some already), with an
EXPORT_SYMBOL_FOR_TESTS_ONLY.
Signed-off-by: Daniel Vetter
Cc: Chris Wilson
Cc: Matthew Auld
Cc: Daniel Vetter
Cc: Jani Nikula
Cc: Sam Ravnborg
Cc: "Christian König"
Acked-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 36 ---
.../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 16 -
2 files changed, 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index eaea49d08eb5..372b57ca0efc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -93,40 +93,6 @@ static void i915_gem_dmabuf_vunmap(struct dma_buf *dma_buf,
void *vaddr)
i915_gem_object_unpin_map(obj);
}
-static void *i915_gem_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
- struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
- struct page *page;
-
- if (page_num >= obj->base.size >> PAGE_SHIFT)
- return NULL;
-
- if (!i915_gem_object_has_struct_page(obj))
- return NULL;
-
- if (i915_gem_object_pin_pages(obj))
- return NULL;
-
- /* Synchronisation is left to the caller (via .begin_cpu_access()) */
- page = i915_gem_object_get_page(obj, page_num);
- if (IS_ERR(page))
- goto err_unpin;
-
- return kmap(page);
-
-err_unpin:
- i915_gem_object_unpin_pages(obj);
- return NULL;
-}
-
-static void i915_gem_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
-{
- struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
-
- kunmap(virt_to_page(addr));
- i915_gem_object_unpin_pages(obj);
-}
-
static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf, struct
vm_area_struct *vma)
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
@@ -195,8 +161,6 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
.map_dma_buf = i915_gem_map_dma_buf,
.unmap_dma_buf = i915_gem_unmap_dma_buf,
.release = drm_gem_dmabuf_release,
- .map = i915_gem_dmabuf_kmap,
- .unmap = i915_gem_dmabuf_kunmap,
.mmap = i915_gem_dmabuf_mmap,
.vmap = i915_gem_dmabuf_vmap,
.vunmap = i915_gem_dmabuf_vunmap,
diff --git a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
index b9e059d4328a..9272bef57092 100644
--- a/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/mock_dmabuf.c
@@ -76,20 +76,6 @@ static void mock_dmabuf_vunmap(struct dma_buf *dma_buf, void
*vaddr)
vm_unmap_ram(vaddr, mock->npages);
}
-static void *mock_dmabuf_kmap(struct dma_buf *dma_buf, unsigned long page_num)
-{
- struct mock_dmabuf *mock = to_mock(dma_buf);
-
- return kmap(mock->pages[page_num]);
-}
-
-static void mock_dmabuf_kunmap(struct dma_buf *dma_buf, unsigned long
page_num, void *addr)
-{
- struct mock_dmabuf *mock = to_mock(dma_buf);
-
- return kunmap(mock->pages[page_num]);
-}
-
static int mock_dmabuf_mmap(struct dma_buf *dma_buf, struct vm_area_struct
*vma)
{
return -ENODEV;
@@ -99,8 +85,6 @@ static const struct dma_buf_ops mock_dmabuf_ops = {
.map_dma_buf = mock_map_dma_buf,
.unmap_dma_buf = mock_unmap_dma_buf,
.release = mock_dmabuf_release,
- .map = mock_dmabuf_kmap,
- .unmap = mock_dmabuf_kunmap,
.mmap = mock_dmabuf_mmap,
.vmap = mock_dmabuf_vmap,
.vunmap = mock_dmabuf_vunmap,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [CI v5 2/2] drm/i915/vbt: Handle generic DTD block
On Fri, 15 Nov 2019, Matt Roper wrote:
> VBT revision 229 adds a new "Generic DTD" block 58 and deprecates the
> old LFP panel mode data in block 42. Let's start parsing this block to
> fill in the panel fixed mode on devices with a >=229 VBT.
>
> v2:
> * Update according to the recent updates:
> - DTD size is now 16 bits instead of 24
> - polarity is now just a single bit for hsync and vsync and is
> properly documented
> * Minor checkpatch fix
>
> v3:
> * Now that panel options are parsed separately from the previous patch,
>move generic DTD parsing into a function parallel to
>parse_lfp_panel_dtd. We'll still fall back to looking at the legacy
>LVDS timing block if the generic DTD fails. (Jani)
> * Don't forget to actually set lfp_lvds_vbt_mode! (Jani)
> * Drop "bdb_" prefix from dtd entry structure. (Jani)
> * Follow C99 standard for structure's flexible array member. (Jani)
>
> v4:
> * Add "positive" to polarity field names for clarity. (Jani)
> * Move VBT version check and fallback to legacy DTD parsing logic to a
>helper to keep top-level VBT parsing uncluttered. (Jani)
> * Restructure reserved bit packing at end of generic_dtd_entry from
>"u32 rsvd:24" to "u8 rsvd[3]" to prevent copy/paste mistakes in the
>future. (Jani)
Thanks, looks nice.
BR,
Jani.
>
> Bspec: 54751
> Bspec: 20148
> Cc: Jani Nikula
> Signed-off-by: Matt Roper
> Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 96 ++-
> drivers/gpu/drm/i915/display/intel_vbt_defs.h | 31 ++
> 2 files changed, 125 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index d13ce0b7db8b..f6a9a5ccb556 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -296,7 +296,7 @@ parse_lfp_panel_dtd(struct drm_i915_private *dev_priv,
>
> dev_priv->vbt.lfp_lvds_vbt_mode = panel_fixed_mode;
>
> - DRM_DEBUG_KMS("Found panel mode in BIOS VBT tables:\n");
> + DRM_DEBUG_KMS("Found panel mode in BIOS VBT legacy lfp table:\n");
> drm_mode_debug_printmodeline(panel_fixed_mode);
>
> fp_timing = get_lvds_fp_timing(bdb, lvds_lfp_data,
> @@ -313,6 +313,98 @@ parse_lfp_panel_dtd(struct drm_i915_private *dev_priv,
> }
> }
>
> +static void
> +parse_generic_dtd(struct drm_i915_private *dev_priv,
> + const struct bdb_header *bdb)
> +{
> + const struct bdb_generic_dtd *generic_dtd;
> + const struct generic_dtd_entry *dtd;
> + struct drm_display_mode *panel_fixed_mode;
> + int num_dtd;
> +
> + generic_dtd = find_section(bdb, BDB_GENERIC_DTD);
> + if (!generic_dtd)
> + return;
> +
> + if (generic_dtd->gdtd_size < sizeof(struct generic_dtd_entry)) {
> + DRM_ERROR("GDTD size %u is too small.\n",
> + generic_dtd->gdtd_size);
> + return;
> + } else if (generic_dtd->gdtd_size !=
> +sizeof(struct generic_dtd_entry)) {
> + DRM_ERROR("Unexpected GDTD size %u\n", generic_dtd->gdtd_size);
> + /* DTD has unknown fields, but keep going */
> + }
> +
> + num_dtd = (get_blocksize(generic_dtd) -
> +sizeof(struct bdb_generic_dtd)) / generic_dtd->gdtd_size;
> + if (dev_priv->vbt.panel_type > num_dtd) {
> + DRM_ERROR("Panel type %d not found in table of %d DTD's\n",
> + dev_priv->vbt.panel_type, num_dtd);
> + return;
> + }
> +
> + dtd = &generic_dtd->dtd[dev_priv->vbt.panel_type];
> +
> + panel_fixed_mode = kzalloc(sizeof(*panel_fixed_mode), GFP_KERNEL);
> + if (!panel_fixed_mode)
> + return;
> +
> + panel_fixed_mode->hdisplay = dtd->hactive;
> + panel_fixed_mode->hsync_start =
> + panel_fixed_mode->hdisplay + dtd->hfront_porch;
> + panel_fixed_mode->hsync_end =
> + panel_fixed_mode->hsync_start + dtd->hsync;
> + panel_fixed_mode->htotal = panel_fixed_mode->hsync_end;
> +
> + panel_fixed_mode->vdisplay = dtd->vactive;
> + panel_fixed_mode->vsync_start =
> + panel_fixed_mode->vdisplay + dtd->vfront_porch;
> + panel_fixed_mode->vsync_end =
> + panel_fixed_mode->vsync_start + dtd->vsync;
> + panel_fixed_mode->vtotal = panel_fixed_mode->vsync_end;
> +
> + panel_fixed_mode->clock = dtd->pixel_clock;
> + panel_fixed_mode->width_mm = dtd->width_mm;
> + panel_fixed_mode->height_mm = dtd->height_mm;
> +
> + panel_fixed_mode->type = DRM_MODE_TYPE_PREFERRED;
> + drm_mode_set_name(panel_fixed_mode);
> +
> + if (dtd->hsync_positive_polarity)
> + panel_fixed_mode->flags |= DRM_MODE_FLAG_PHSYNC;
> + else
> + panel_fixed_mode->flags |= DRM_MODE_FLAG_NHSYNC;
> +
> + if (dtd->vsync_positive_polarity)
> + panel_fixed_mode->flags |= DRM_MO
Re: [Intel-gfx] [PATCH 14/15] sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
On Mon, Nov 18, 2019 at 11:35:35AM +0100, Daniel Vetter wrote: > No in-tree users left. > > Signed-off-by: Daniel Vetter > Cc: Kirti Wankhede > Cc: k...@vger.kernel.org > -- > Ack for merging this through drm trees very much appreciated. > -Daniel Acked-by: Gerd Hoffmann cheers, Gerd ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Retire dma_buf_k(un)map
== Series Details == Series: Retire dma_buf_k(un)map URL : https://patchwork.freedesktop.org/series/69616/ State : warning == Summary == $ dim checkpatch origin/drm-tip 4c6a4728b6b2 drm/tegra: Map cmdbuf once for reloc processing -:73: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 43 lines checked 4e767396c955 drm/tegra: Delete host1x_bo_ops->k(un)map -:95: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 65 lines checked 59215a0d0fd8 drm/i915: Remove dma_buf_kmap selftest -:135: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 113 lines checked 03af633b49d7 staging/android/ion: delete dma_buf->kmap/unmap implemenation -:4: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'? #4: Subject: [PATCH] staging/android/ion: delete dma_buf->kmap/unmap implemenation -:11: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'? #11: implemenation. -:51: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 3 warnings, 0 checks, 26 lines checked 985f778728c5 drm/armada: Delete dma_buf->k(un)map implemenation -:4: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'? #4: Subject: [PATCH] drm/armada: Delete dma_buf->k(un)map implemenation -:40: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 24 lines checked 039c203e8d68 drm/i915: Drop dma_buf->k(un)map -:111: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 76 lines checked 08b98defec59 drm/omapdrm: Drop dma_buf->k(un)map -:9: WARNING:TYPO_SPELLING: 'implemenation' may be misspelled - perhaps 'implementation'? #9: that provided a kmap, but not a vmap implemenation. Given that the -:55: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 33 lines checked 92e11aa1752d drm/tegra: Remove dma_buf->k(un)map -:42: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 24 lines checked 8329ea9797e4 dma-buf: Drop dma_buf_k(un)map -:118: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 83 lines checked 91d8088a8fe6 drm/vmwgfx: Delete mmaping functions -:71: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 45 lines checked a0db1db5b4cc media/videobuf2: Drop dma_buf->k(un)map support -:94: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 60 lines checked 973d8ca089b6 drm/tee_shm: Drop dma_buf_k(unmap) support -:64: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 38 lines checked 6b42ade9bc8f xen/gntdev-dmabuf: Ditch dummy map functions -:57: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 35 lines checked a6d61e4e0454 sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support -:43: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 26 lines checked 23be2279c0eb dma-buf: Remove kernel map/unmap hooks -:48: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 31 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/15] drm/omapdrm: Drop dma_buf->k(un)map
On 18/11/2019 12:35, Daniel Vetter wrote: > No in-tree users left. > > Note that this is one of the few (if only) implementations of dma-buf > that provided a kmap, but not a vmap implemenation. Given that the > only real user (in-tree at least) of kmap was tegra, and it's > impossible to buy a chip with tegra host1x and ompadrm on the same > SoC, there's no problem here. > > Signed-off-by: Daniel Vetter > Cc: Tomi Valkeinen > --- > drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 - > 1 file changed, 21 deletions(-) We're using dma_buf_kmap in TI kernel, in some rpmsg code: https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/rpmsg/rpmsg_rpc_dmabuf.c?h=ti-linux-4.19.y I'm not familiar with the code, Cc'ing Suman. In any case, if no one else needs dmabuf kmap, I would guess that TI doesn't need it either... Presuming that's the case, for the omapdrm part: Acked-by: Tomi Valkeinen Also, don't downplay the 32bit kernels, there are still plenty of users for arm32, and will be for a long time =) Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/15] drm/i915: Drop dma_buf->k(un)map
Quoting Daniel Vetter (2019-11-18 10:35:27) > No in-tree users left. Fair enough then, Reviewed-by: Chris Wilson > Aside, I think mock_dmabuf would be a nice addition to drm > mock/selftest helpers (we have some already), with an > EXPORT_SYMBOL_FOR_TESTS_ONLY. We've also started on some dmabuf selftests, so maybe we can go further and make mock objects and EXPORT_SYMBOL_FOR_TESTS_ONLY global. And of course, make sure the efforts align with kunit... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/15] drm/i915: Remove dma_buf_kmap selftest
Quoting Daniel Vetter (2019-11-18 10:35:24) > It's the only user left in the entire kernel for dma_buf_kmap/_kunmap. > Delete it, before we start garbage-collecting the various > implementations. Ok then, I'm still mourning the loss of kmap. I definitely do not think we should _only_ have a whole-object-at-a-time interface as we may have to deal with objects larger than the aperture, or even larger than system memory. I feel we have a bridge to cross in future... Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Retire dma_buf_k(un)map
== Series Details ==
Series: Retire dma_buf_k(un)map
URL : https://patchwork.freedesktop.org/series/69616/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7361 -> Patchwork_15311
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/index.html
Known issues
Here are the changes found in Patchwork_15311 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][1] -> [DMESG-WARN][2] ([fdo#102614])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_module_load@reload-with-fault-injection:
- {fi-kbl-7560u}: [DMESG-WARN][3] ([fdo#112260]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-kbl-7560u/igt@i915_module_l...@reload-with-fault-injection.html
* igt@i915_selftest@live_blt:
- fi-hsw-4770r: [DMESG-FAIL][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-4770r/igt@i915_selftest@live_blt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-hsw-4770r/igt@i915_selftest@live_blt.html
- fi-hsw-peppy: [DMESG-FAIL][7] ([fdo#112147]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-peppy/igt@i915_selftest@live_blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-hsw-peppy/igt@i915_selftest@live_blt.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][9] ([fdo#111045] / [fdo#111096]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
[fdo#112260]: https://bugs.freedesktop.org/show_bug.cgi?id=112260
Participating hosts (50 -> 44)
--
Additional (1): fi-icl-y
Missing(7): fi-tgl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7361 -> Patchwork_15311
CI-20190529: 20190529
CI_DRM_7361: 9dff9fddfefbd9c185b84b30e24a78687dce62c8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5292: ea9cd47fdb72c16d5ec84c04a85122c451c30025 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15311: 23be2279c0ebd531d05bc41cfbef57d2ffe879b7 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
23be2279c0eb dma-buf: Remove kernel map/unmap hooks
a6d61e4e0454 sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support
6b42ade9bc8f xen/gntdev-dmabuf: Ditch dummy map functions
973d8ca089b6 drm/tee_shm: Drop dma_buf_k(unmap) support
a0db1db5b4cc media/videobuf2: Drop dma_buf->k(un)map support
91d8088a8fe6 drm/vmwgfx: Delete mmaping functions
8329ea9797e4 dma-buf: Drop dma_buf_k(un)map
92e11aa1752d drm/tegra: Remove dma_buf->k(un)map
08b98defec59 drm/omapdrm: Drop dma_buf->k(un)map
039c203e8d68 drm/i915: Drop dma_buf->k(un)map
985f778728c5 drm/armada: Delete dma_buf->k(un)map implemenation
03af633b49d7 staging/android/ion: delete dma_buf->kmap/unmap implemenation
59215a0d0fd8 drm/i915: Remove dma_buf_kmap selftest
4e767396c955 drm/tegra: Delete host1x_bo_ops->k(un)map
4c6a4728b6b2 drm/tegra: Map cmdbuf once for reloc processing
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15311/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
== Series Details ==
Series: drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
URL : https://patchwork.freedesktop.org/series/69617/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7361 -> Patchwork_15312
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15312/index.html
Known issues
Here are the changes found in Patchwork_15312 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-lmem:[PASS][1] -> [DMESG-WARN][2] ([fdo#112261])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-skl-lmem/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15312/fi-skl-lmem/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_gem_contexts:
- fi-cfl-8700k: [PASS][3] -> [INCOMPLETE][4] ([fdo#111700])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15312/fi-cfl-8700k/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@i915_selftest@live_blt:
- fi-hsw-4770r: [DMESG-FAIL][5] -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-4770r/igt@i915_selftest@live_blt.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15312/fi-hsw-4770r/igt@i915_selftest@live_blt.html
- fi-hsw-peppy: [DMESG-FAIL][7] ([fdo#112147]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-peppy/igt@i915_selftest@live_blt.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15312/fi-hsw-peppy/igt@i915_selftest@live_blt.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][9] ([fdo#111045] / [fdo#111096]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15312/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111700]: https://bugs.freedesktop.org/show_bug.cgi?id=111700
[fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
[fdo#112260]: https://bugs.freedesktop.org/show_bug.cgi?id=112260
[fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261
[fdo#112298]: https://bugs.freedesktop.org/show_bug.cgi?id=112298
Participating hosts (50 -> 44)
--
Additional (1): fi-icl-y
Missing(7): fi-tgl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7361 -> Patchwork_15312
CI-20190529: 20190529
CI_DRM_7361: 9dff9fddfefbd9c185b84b30e24a78687dce62c8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5292: ea9cd47fdb72c16d5ec84c04a85122c451c30025 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15312: 2010e00d35ee9e8b7c3502da67618970a9aeb839 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
2010e00d35ee drm/i915/gem: Manually dump the debug trace on GEM_BUG_ON
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15312/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for mdev based hardware virtio offloading support
== Series Details == Series: mdev based hardware virtio offloading support URL : https://patchwork.freedesktop.org/series/69621/ State : warning == Summary == $ dim checkpatch origin/drm-tip 67f3ea3cda70 mdev: make mdev bus agnostic -:648: CHECK:LINE_SPACING: Please don't use multiple blank lines #648: FILE: drivers/vfio/mdev/mdev_private.h:42: + + -:651: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'bus' - possible side-effects? #651: FILE: drivers/vfio/mdev/mdev_private.h:44: +#define dev_is_mdev(d, bus)((d)->bus == bus) -:651: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'bus' may be better as '(bus)' to avoid precedence issues #651: FILE: drivers/vfio/mdev/mdev_private.h:44: +#define dev_is_mdev(d, bus)((d)->bus == bus) -:656: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #656: new file mode 100644 total: 0 errors, 1 warnings, 3 checks, 776 lines checked f69d8d9902fd mdev: split out VFIO bus specific parent ops -:285: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mdev' - possible side-effects? #285: FILE: drivers/vfio/mdev/mdev_vfio.c:20: +#define to_vfio_mdev_device(mdev) container_of(mdev, \ + struct mdev_vfio_device, mdev) total: 0 errors, 0 warnings, 1 checks, 585 lines checked 8544fcd816bc mdev: move to drivers/ -:57: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #57: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 92 lines checked fe3f935905d1 mdev: introduce mediated virtio bus -:57: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #57: new file mode 100644 -:91: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mdev' - possible side-effects? #91: FILE: drivers/mdev/virtio.c:30: +#define to_mdev_virtio(mdev) container_of(mdev, \ + struct mdev_virtio_device, mdev) -:405: CHECK:LINE_SPACING: Please don't use multiple blank lines #405: FILE: scripts/mod/file2alias.c:1348: + + total: 0 errors, 1 warnings, 2 checks, 361 lines checked bbb2f0eac428 virtio: introduce a mdev based transport -:52: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #52: new file mode 100644 -:111: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #111: FILE: drivers/virtio/virtio_mdev.c:55: +static void virtio_mdev_get(struct virtio_device *vdev, unsigned offset, -:112: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #112: FILE: drivers/virtio/virtio_mdev.c:56: + void *buf, unsigned len) -:120: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #120: FILE: drivers/virtio/virtio_mdev.c:64: +static void virtio_mdev_set(struct virtio_device *vdev, unsigned offset, -:121: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #121: FILE: drivers/virtio/virtio_mdev.c:65: + const void *buf, unsigned len) -:134: CHECK:LINE_SPACING: Please don't use multiple blank lines #134: FILE: drivers/virtio/virtio_mdev.c:78: + + -:302: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #302: FILE: drivers/virtio/virtio_mdev.c:246: +static int virtio_mdev_find_vqs(struct virtio_device *vdev, unsigned nvqs, total: 0 errors, 6 warnings, 1 checks, 443 lines checked 8a37245a6260 docs: sample driver to demonstrate how to implement virtio-mdev framework -:62: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #62: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 717 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/perf: Configure OAR for specific context
On 14/11/2019 21:21, Umesh Nerlige Ramappa wrote:
Gen12 supports saving/restoring render counters per context. Apply OAR
configuration only for the context that is passed in to perf.
v2:
- Fix OACTXCONTROL value to only stop/resume counters.
- Remove gen12_update_reg_state_unlocked as power state is already
applied by the caller.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 193 +--
1 file changed, 108 insertions(+), 85 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 221c1090ae93..2f0be5fbef4b 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -2078,20 +2078,12 @@ gen8_update_reg_state_unlocked(const struct
intel_context *ce,
u32 *reg_state = ce->lrc_reg_state;
int i;
- if (IS_GEN(stream->perf->i915, 12)) {
- u32 format = stream->oa_buffer.format;
+ reg_state[ctx_oactxctrl + 1] =
+ (stream->period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT) |
+ (stream->periodic ? GEN8_OA_TIMER_ENABLE : 0) |
+ GEN8_OA_COUNTER_RESUME;
- reg_state[ctx_oactxctrl + 1] =
- (format << GEN12_OAR_OACONTROL_COUNTER_FORMAT_SHIFT) |
- (stream->oa_config ? GEN12_OAR_OACONTROL_COUNTER_ENABLE
: 0);
- } else {
- reg_state[ctx_oactxctrl + 1] =
- (stream->period_exponent << GEN8_OA_TIMER_PERIOD_SHIFT)
|
- (stream->periodic ? GEN8_OA_TIMER_ENABLE : 0) |
- GEN8_OA_COUNTER_RESUME;
- }
-
- for (i = 0; !!ctx_flexeu0 && i < ARRAY_SIZE(flex_regs); i++)
+ for (i = 0; i < ARRAY_SIZE(flex_regs); i++)
reg_state[ctx_flexeu0 + i * 2 + 1] =
oa_config_flex_reg(stream->oa_config, flex_regs[i]);
@@ -2224,34 +2216,49 @@ static int gen8_configure_context(struct i915_gem_context *ctx,
return err;
}
-static int gen12_emit_oar_config(struct intel_context *ce, bool enable)
+static int gen12_configure_oar_context(struct i915_perf_stream *stream, bool
enable)
{
- struct i915_request *rq;
- u32 *cs;
- int err = 0;
-
- rq = i915_request_create(ce);
- if (IS_ERR(rq))
- return PTR_ERR(rq);
+ int err;
+ struct intel_context *ce = stream->pinned_ctx;
+ struct flex regs_context[] = {
+ {
+ GEN8_OACTXCONTROL,
+ stream->perf->ctx_oactxctrl_offset + 1,
+ enable ? GEN8_OA_COUNTER_RESUME : 0,
+ },
+ };
When do we configure the Flex registers?
+ struct flex regs_lri[] = {
+ {
+ GEN12_OAR_OACONTROL,
+ },
+ {
+ RING_CONTEXT_CONTROL(ce->engine->mmio_base),
+ },
+ };
+ u32 format = stream->oa_buffer.format;
- cs = intel_ring_begin(rq, 4);
- if (IS_ERR(cs)) {
- err = PTR_ERR(cs);
- goto out;
- }
+ regs_lri[0].value =
+ (format << GEN12_OAR_OACONTROL_COUNTER_FORMAT_SHIFT) |
+ (enable ? GEN12_OAR_OACONTROL_COUNTER_ENABLE : 0);
- *cs++ = MI_LOAD_REGISTER_IMM(1);
- *cs++ =
i915_mmio_reg_offset(RING_CONTEXT_CONTROL(ce->engine->mmio_base));
- *cs++ = _MASKED_FIELD(GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE,
- enable ? GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE : 0);
- *cs++ = MI_NOOP;
+ regs_lri[1].value =
+ _MASKED_FIELD(GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE,
+ enable ?
+ GEN12_CTX_CTRL_OAR_CONTEXT_ENABLE :
+ 0);
Can't we put those values in the array above?
- intel_ring_advance(rq, cs);
+ /* Modify the context image of pinned context with regs_context*/
+ err = intel_context_lock_pinned(ce);
+ if (err)
+ return err;
-out:
- i915_request_add(rq);
+ err = gen8_modify_context(ce, regs_context, ARRAY_SIZE(regs_context));
+ intel_context_unlock_pinned(ce);
+ if (err)
+ return err;
- return err;
+ /* Apply regs_lri using LRI with pinned context */
+ return gen8_modify_self(ce, regs_lri, ARRAY_SIZE(regs_lri));
}
/*
@@ -2277,53 +2284,16 @@ static int gen12_emit_oar_config(struct intel_context
*ce, bool enable)
* per-context OA state.
*
* Note: it's only the RCS/Render context that has any OA state.
+ * Note: the first flex register passed must always be R_PWR_CLK_STATE
*/
-static int lrc_configure_all_contexts(struct i915_perf_stream *stream,
- const struct i915_oa_config *oa_config)
+static int oa_configure_all_contexts(struct i915_perf_stream *stream,
+struct flex *re
[Intel-gfx] ✗ Fi.CI.DOCS: warning for mdev based hardware virtio offloading support
== Series Details == Series: mdev based hardware virtio offloading support URL : https://patchwork.freedesktop.org/series/69621/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 | | | i915.ko |<-> physical ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7] drm/i915: Enable second dbuf slice for ICL and TGL
On Thu, 14 Nov 2019, Stanislav Lisovskiy wrote:
> Also implemented algorithm for choosing DBuf slice configuration
> based on active pipes, pipe ratio as stated in BSpec 12716.
>
> Now pipe allocation still stays proportional to pipe width as before,
> however within allowed DBuf slice for this particular configuration.
>
> v2: Remove unneeded check from commit as ddb enabled slices might
> now differ from hw state.
>
> v3: - Added new field "supported_slices" to ddb to separate max
> supported slices vs currently enabled, to avoid confusion.
> - Removed obsolete comments and code related to DBuf(Matthew Roper).
> - Some code style and long line removal(Matthew Roper).
> - Added WARN_ON to new ddb range offset calc function(Matthew Roper).
> - Removed platform specific call to calc pipe ratio from ddb
> allocation function and fixed the return value(Matthew Roper)
> - Refactored DBUF slice allocation table to improve readability
> - Added DBUF slice allocation for TGL as well.
> - ICL(however not TGL) seems to voluntarily enable second DBuf slice
> after pm suspend/resume causing a mismatch failure, because we
> update DBuf slices only if we do a modeset, however this check
> is done always. Fixed it to be done only when modeset for ICL.
>
> v4: - Now enabled slices is not actually a number, but a bitmask,
> because we might need to enable second slice only and number
> of slices would still 1 and that current code doesn't allow.
> - Remove redundant duplicate code to have some unified way of
> enabling dbuf slices instead of hardcoding.
>
> v5: - Fix failing gen9_assert_dbuf_enabled as it was naively thinking
> that we have only one DBUF_CTL slice. Now another version for
> gen11 will check both slices as only second one can be enabled,
> to keep CI happy.
>
> v6: - Removed enabled dbuf assertion completely. Previous code
> was keeping dbuf enabled, even(!) when _dbuf_disable is called.
> Currently we enable/disable dbuf slices based on requrement
> so no point in asserting this here.
> - Removed unnecessary modeset check from verify_wm_state(Matthew Roper)
> - Slices intersection after union is same as final result(Matthew Roper)
> - Moved DBuf slices to intel_device_info(Matthew Roper)
> - Some macros added(Matthew Roper)
> - ddb range is now always less or equal to ddb size - no need for
> additional
> checks(previously needed as we had some bandwidth checks in there which
> could "suddenly" return ddb_size smaller than it is.
>
> v7: Minor costemic changes:
> - Changed icl_dbuf_slices_restore name to icl_program_dbuf_slices
> as it more corresponds to the actual functionality.
> - Some simplification with supported slices for BXT and GLK
> - skl_pipe_downscale_amount -> icl_pipe_downscale_amount as
> this is not used for skl anymore.
> - Changed DBuf slice assignment order for TGL case
>
> Reviewed-by: Matthew Roper
> Signed-off-by: Stanislav Lisovskiy
> Cc: Matthew Roper
> Cc: Ville Syrjälä
> Cc: James Ausmus
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 26 +-
> .../drm/i915/display/intel_display_power.c| 98 ++---
> .../drm/i915/display/intel_display_power.h| 2 +
> drivers/gpu/drm/i915/i915_drv.c | 5 +
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/i915_pci.c | 6 +-
> drivers/gpu/drm/i915/i915_reg.h | 8 +-
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> drivers/gpu/drm/i915/intel_pm.c | 387 --
> 9 files changed, 431 insertions(+), 104 deletions(-)
This is a rather big patch, and that's one of the few things we can't
fix after committing.
If there's a bug, by our rate of change this turns practically
un-revertible in a matter of weeks due to conflicts. If there's a
bisected regression, and this is the regressing commit, what are our
chances of identifying the bug based on the sha1 alone? Can't revert and
can't immediately spot the bug/fix is a bad combination to have.
Also we have this nice CI infrastructure reporting about valid
checkpatch and sparse issues for several versions of the patch. Please
fix.
BR,
Jani.
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 876fc25968bf..bd7aff675198 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13387,7 +13387,7 @@ static void verify_wm_state(struct intel_crtc *crtc,
>
> if (INTEL_GEN(dev_priv) >= 11 &&
> hw->ddb.enabled_slices != sw_ddb->enabled_slices)
> - DRM_ERROR("mismatch in DBUF Slices (expected %u, got %u)\n",
> + DRM_ERROR("mismatch in DBUF Slices (expected %x, got %x)\n",
> sw_ddb->enabled_slices,
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for mdev based hardware virtio offloading support
== Series Details ==
Series: mdev based hardware virtio offloading support
URL : https://patchwork.freedesktop.org/series/69621/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7361 -> Patchwork_15313
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_15313 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_15313, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15313/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_15313:
### IGT changes ###
Possible regressions
* igt@i915_module_load@reload:
- fi-apl-guc: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-apl-guc/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15313/fi-apl-guc/igt@i915_module_l...@reload.html
Known issues
Here are the changes found in Patchwork_15313 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][3] -> [DMESG-WARN][4] ([fdo#112261])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15313/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
- fi-skl-lmem:[PASS][5] -> [DMESG-WARN][6] ([fdo#112261])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-skl-lmem/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15313/fi-skl-lmem/igt@i915_pm_...@module-reload.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-guc: [PASS][7] -> [FAIL][8] ([fdo#103167])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15313/fi-icl-guc/igt@kms_frontbuffer_track...@basic.html
- fi-hsw-peppy: [PASS][9] -> [DMESG-WARN][10] ([fdo#102614])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15313/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@i915_selftest@live_blt:
- fi-hsw-4770r: [DMESG-FAIL][11] -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-4770r/igt@i915_selftest@live_blt.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15313/fi-hsw-4770r/igt@i915_selftest@live_blt.html
- fi-hsw-peppy: [DMESG-FAIL][13] ([fdo#112147]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7361/fi-hsw-peppy/igt@i915_selftest@live_blt.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15313/fi-hsw-peppy/igt@i915_selftest@live_blt.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#109964]: https://bugs.freedesktop.org/show_bug.cgi?id=109964
[fdo#112147]: https://bugs.freedesktop.org/show_bug.cgi?id=112147
[fdo#112260]: https://bugs.freedesktop.org/show_bug.cgi?id=112260
[fdo#112261]: https://bugs.freedesktop.org/show_bug.cgi?id=112261
[fdo#112298]: https://bugs.freedesktop.org/show_bug.cgi?id=112298
Participating hosts (50 -> 44)
--
Additional (1): fi-icl-y
Missing(7): fi-tgl-u fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_7361 -> Patchwork_15313
CI-20190529: 20190529
CI_DRM_7361: 9dff9fddfefbd9c185b84b30e24a78687dce62c8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5292: ea9cd47fdb72c16d5ec84c04a85122c451c30025 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_15313: 8a37245a6260e49cd01d8d2e346a2caf8f7c2462 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8a37245a6260 docs: sample driver to demonstrate how to implement virtio-mdev
framework
bbb2f0eac428 virtio: introduce a mdev based transport
fe3f935905d1 mdev: introduce mediated virtio bus
8544fcd816bc mdev: move to drivers/
f69d8d9902fd mdev: split out VFIO bus specific parent ops
67f3ea3cda70 mdev: make mdev bus agnostic
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15313/index.html
_
Re: [Intel-gfx] [PATCH v7] drm/i915: Enable second dbuf slice for ICL and TGL
On Mon, 2019-11-18 at 16:22 +0200, Jani Nikula wrote: > On Thu, 14 Nov 2019, Stanislav Lisovskiy < > stanislav.lisovs...@intel.com> wrote: > > Also implemented algorithm for choosing DBuf slice configuration > > based on active pipes, pipe ratio as stated in BSpec 12716. > > > > Now pipe allocation still stays proportional to pipe width as > > before, > > however within allowed DBuf slice for this particular > > configuration. > > > > v2: Remove unneeded check from commit as ddb enabled slices might > > now differ from hw state. > > > > v3: - Added new field "supported_slices" to ddb to separate max > > supported slices vs currently enabled, to avoid confusion. > > - Removed obsolete comments and code related to DBuf(Matthew > > Roper). > > - Some code style and long line removal(Matthew Roper). > > - Added WARN_ON to new ddb range offset calc function(Matthew > > Roper). > > - Removed platform specific call to calc pipe ratio from ddb > > allocation function and fixed the return value(Matthew Roper) > > - Refactored DBUF slice allocation table to improve readability > > - Added DBUF slice allocation for TGL as well. > > - ICL(however not TGL) seems to voluntarily enable second DBuf > > slice > > after pm suspend/resume causing a mismatch failure, because > > we > > update DBuf slices only if we do a modeset, however this > > check > > is done always. Fixed it to be done only when modeset for > > ICL. > > > > v4: - Now enabled slices is not actually a number, but a bitmask, > > because we might need to enable second slice only and number > > of slices would still 1 and that current code doesn't allow. > > - Remove redundant duplicate code to have some unified way of > > enabling dbuf slices instead of hardcoding. > > > > v5: - Fix failing gen9_assert_dbuf_enabled as it was naively > > thinking > > that we have only one DBUF_CTL slice. Now another version for > > gen11 will check both slices as only second one can be > > enabled, > > to keep CI happy. > > > > v6: - Removed enabled dbuf assertion completely. Previous code > > was keeping dbuf enabled, even(!) when _dbuf_disable is > > called. > > Currently we enable/disable dbuf slices based on requrement > > so no point in asserting this here. > > - Removed unnecessary modeset check from > > verify_wm_state(Matthew Roper) > > - Slices intersection after union is same as final > > result(Matthew Roper) > > - Moved DBuf slices to intel_device_info(Matthew Roper) > > - Some macros added(Matthew Roper) > > - ddb range is now always less or equal to ddb size - no need > > for additional > > checks(previously needed as we had some bandwidth checks in > > there which > > could "suddenly" return ddb_size smaller than it is. > > > > v7: Minor costemic changes: > > - Changed icl_dbuf_slices_restore name to > > icl_program_dbuf_slices > > as it more corresponds to the actual functionality. > > - Some simplification with supported slices for BXT and GLK > > - skl_pipe_downscale_amount -> icl_pipe_downscale_amount as > > this is not used for skl anymore. > > - Changed DBuf slice assignment order for TGL case > > > > Reviewed-by: Matthew Roper > > Signed-off-by: Stanislav Lisovskiy > > Cc: Matthew Roper > > Cc: Ville Syrjälä > > Cc: James Ausmus > > --- > > drivers/gpu/drm/i915/display/intel_display.c | 26 +- > > .../drm/i915/display/intel_display_power.c| 98 ++--- > > .../drm/i915/display/intel_display_power.h| 2 + > > drivers/gpu/drm/i915/i915_drv.c | 5 + > > drivers/gpu/drm/i915/i915_drv.h | 2 +- > > drivers/gpu/drm/i915/i915_pci.c | 6 +- > > drivers/gpu/drm/i915/i915_reg.h | 8 +- > > drivers/gpu/drm/i915/intel_device_info.h | 1 + > > drivers/gpu/drm/i915/intel_pm.c | 387 > > -- > > 9 files changed, 431 insertions(+), 104 deletions(-) > > This is a rather big patch, and that's one of the few things we can't > fix after committing. > > If there's a bug, by our rate of change this turns practically > un-revertible in a matter of weeks due to conflicts. If there's a > bisected regression, and this is the regressing commit, what are our > chances of identifying the bug based on the sha1 alone? Can't revert > and > can't immediately spot the bug/fix is a bad combination to have. > > Also we have this nice CI infrastructure reporting about valid > checkpatch and sparse issues for several versions of the patch. > Please > fix. > > > BR, > Jani. I'm fine with fixing checkpatch and sparse failures(even though most of those are about 80 line width limitation violation or line continuations, which tbh are anyway quite common in our code). One thing I don't get is why this should cause any regression, as both BAT and IGT are green here for two runs in a row. W
[Intel-gfx] [PATCH] drm/i915/gt: Schedule request retirement when submission idles
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine switched over to the kernel
context. If userspace is idle, this task falls onto our background idle
worker, which only runs roughly once a second, meaning that userspace has
to have been idle for a couple of seconds before we enable RC6 again.
Naturally, this causes us to consume considerably more energy than
before as powersaving is effectively disabled while a display server
(here's looking at you Xorg) is running.
As execlists will get a completion event as the last context is
completed and the GPU goes idle, we can use our submission tasklet to
notice when the GPU is idle and kick the retire worker. Thus during
light workloads, we will do much more work to idle the GPU faster...
Hopefully with commensurate power saving!
References: https://bugs.freedesktop.org/show_bug.cgi?id=112315
References: 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_requests.h | 9 -
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 +++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
index fde546424c63..94b8758a45d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
@@ -7,7 +7,9 @@
#ifndef INTEL_GT_REQUESTS_H
#define INTEL_GT_REQUESTS_H
-struct intel_gt;
+#include
+
+#include "intel_gt_types.h"
long intel_gt_retire_requests_timeout(struct intel_gt *gt, long timeout);
static inline void intel_gt_retire_requests(struct intel_gt *gt)
@@ -15,6 +17,11 @@ static inline void intel_gt_retire_requests(struct intel_gt
*gt)
intel_gt_retire_requests_timeout(gt, 0);
}
+static inline void intel_gt_schedule_retire_requests(struct intel_gt *gt)
+{
+ mod_delayed_work(system_wq, >->requests.retire_work, 0);
+}
+
int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
void intel_gt_init_requests(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 33ce258d484f..4da2e04c0a89 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -142,6 +142,7 @@
#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_reset.h"
@@ -2278,6 +2279,16 @@ static void execlists_submission_tasklet(unsigned long
data)
if (timeout && preempt_timeout(engine))
preempt_reset(engine);
}
+
+ /*
+* If the GPU is currently idle, retire the outstanding completed
+* requests. This will allow us to enter soft-rc6 as soon as possible,
+* albeit at the cost of running the retire worker much more frequently
+* (over the entire GT not just this engine) and emitting more idle
+* barriers (i.e. kernel context switches) which may some extra latency.
+*/
+ if (!execlists_execlists(&engine->execlists))
+ intel_gt_schedule_retire_requests(engine->gt);
}
static void __execlists_kick(struct intel_engine_execlists *execlists)
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Schedule request retirement when submission idles
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine switched over to the kernel
context. If userspace is idle, this task falls onto our background idle
worker, which only runs roughly once a second, meaning that userspace has
to have been idle for a couple of seconds before we enable RC6 again.
Naturally, this causes us to consume considerably more energy than
before as powersaving is effectively disabled while a display server
(here's looking at you Xorg) is running.
As execlists will get a completion event as the last context is
completed and the GPU goes idle, we can use our submission tasklet to
notice when the GPU is idle and kick the retire worker. Thus during
light workloads, we will do much more work to idle the GPU faster...
Hopefully with commensurate power saving!
References: https://bugs.freedesktop.org/show_bug.cgi?id=112315
References: 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_requests.h | 9 -
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 +++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
index fde546424c63..94b8758a45d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
@@ -7,7 +7,9 @@
#ifndef INTEL_GT_REQUESTS_H
#define INTEL_GT_REQUESTS_H
-struct intel_gt;
+#include
+
+#include "intel_gt_types.h"
long intel_gt_retire_requests_timeout(struct intel_gt *gt, long timeout);
static inline void intel_gt_retire_requests(struct intel_gt *gt)
@@ -15,6 +17,11 @@ static inline void intel_gt_retire_requests(struct intel_gt
*gt)
intel_gt_retire_requests_timeout(gt, 0);
}
+static inline void intel_gt_schedule_retire_requests(struct intel_gt *gt)
+{
+ mod_delayed_work(system_wq, >->requests.retire_work, 0);
+}
+
int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
void intel_gt_init_requests(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 33ce258d484f..4485fe3e5066 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -142,6 +142,7 @@
#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_reset.h"
@@ -2278,6 +2279,16 @@ static void execlists_submission_tasklet(unsigned long
data)
if (timeout && preempt_timeout(engine))
preempt_reset(engine);
}
+
+ /*
+* If the GPU is currently idle, retire the outstanding completed
+* requests. This will allow us to enter soft-rc6 as soon as possible,
+* albeit at the cost of running the retire worker much more frequently
+* (over the entire GT not just this engine) and emitting more idle
+* barriers (i.e. kernel context switches) which may some extra latency.
+*/
+ if (!execlists_active(&engine->execlists))
+ intel_gt_schedule_retire_requests(engine->gt);
}
static void __execlists_kick(struct intel_engine_execlists *execlists)
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/15] staging/android/ion: delete dma_buf->kmap/unmap implemenation
On 11/18/19 5:35 AM, Daniel Vetter wrote:
There's no callers in-tree anymore.
For merging probably best to stuff this into drm-misc, since that's
where the dma-buf heaps will land too. And the resulting conflict
hopefully ensures that dma-buf heaps wont have a new ->kmap/unmap
implemenation.
Signed-off-by: Daniel Vetter
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: de...@driverdev.osuosl.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/staging/android/ion/ion.c | 14 --
1 file changed, 14 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index e6b1ca141b93..bb4ededc1150 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -274,18 +274,6 @@ static void ion_dma_buf_release(struct dma_buf *dmabuf)
_ion_buffer_destroy(buffer);
}
-static void *ion_dma_buf_kmap(struct dma_buf *dmabuf, unsigned long offset)
-{
- struct ion_buffer *buffer = dmabuf->priv;
-
- return buffer->vaddr + offset * PAGE_SIZE;
-}
-
-static void ion_dma_buf_kunmap(struct dma_buf *dmabuf, unsigned long offset,
- void *ptr)
-{
-}
-
static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
enum dma_data_direction direction)
{
@@ -349,8 +337,6 @@ static const struct dma_buf_ops dma_buf_ops = {
.detach = ion_dma_buf_detatch,
.begin_cpu_access = ion_dma_buf_begin_cpu_access,
.end_cpu_access = ion_dma_buf_end_cpu_access,
- .map = ion_dma_buf_kmap,
- .unmap = ion_dma_buf_kunmap,
};
static int ion_alloc(size_t len, unsigned int heap_id_mask, unsigned int flags)
Acked-by: Laura Abbott
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Add intel_gt_driver_late_release for mock device
== Series Details == Series: drm/i915/selftests: Add intel_gt_driver_late_release for mock device URL : https://patchwork.freedesktop.org/series/69609/ State : success == Summary == CI Bug Log - changes from CI_DRM_7360_full -> Patchwork_15310_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_15310_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([fdo#111832]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-tglb3/igt@gem_ctx_isolat...@vecs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-tglb2/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_ctx_persistence@vcs1-queued: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276] / [fdo#112080]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-iclb1/igt@gem_ctx_persiste...@vcs1-queued.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-iclb6/igt@gem_ctx_persiste...@vcs1-queued.html * igt@gem_ctx_switch@vcs1-heavy: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#112080]) +11 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-iclb2/igt@gem_ctx_swi...@vcs1-heavy.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-iclb6/igt@gem_ctx_swi...@vcs1-heavy.html * igt@gem_eio@in-flight-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-skl6/igt@gem_...@in-flight-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-skl5/igt@gem_...@in-flight-suspend.html * igt@gem_exec_schedule@preempt-queue-chain-blt: - shard-tglb: [PASS][9] -> [INCOMPLETE][10] ([fdo#111606] / [fdo#111677]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-tglb1/igt@gem_exec_sched...@preempt-queue-chain-blt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-tglb6/igt@gem_exec_sched...@preempt-queue-chain-blt.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][11] -> [SKIP][12] ([fdo#112146]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-iclb6/igt@gem_exec_sched...@reorder-wide-bsd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_sync@basic-store-each: - shard-tglb: [PASS][13] -> [INCOMPLETE][14] ([fdo#111747] / [fdo#111880]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-tglb8/igt@gem_s...@basic-store-each.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-tglb6/igt@gem_s...@basic-store-each.html * igt@gem_userptr_blits@dmabuf-unsync: - shard-hsw: [PASS][15] -> [DMESG-WARN][16] ([fdo#111870]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-hsw6/igt@gem_userptr_bl...@dmabuf-unsync.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-hsw6/igt@gem_userptr_bl...@dmabuf-unsync.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: - shard-snb: [PASS][17] -> [DMESG-WARN][18] ([fdo#111870]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html * igt@i915_selftest@live_hangcheck: - shard-hsw: [PASS][19] -> [DMESG-FAIL][20] ([fdo#111991]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-hsw5/igt@i915_selftest@live_hangcheck.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-hsw6/igt@i915_selftest@live_hangcheck.html - shard-snb: [PASS][21] -> [INCOMPLETE][22] ([fdo#105411]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-snb5/igt@i915_selftest@live_hangcheck.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-snb7/igt@i915_selftest@live_hangcheck.html * igt@kms_color@pipe-a-ctm-0-5: - shard-skl: [PASS][23] -> [DMESG-WARN][24] ([fdo#106107]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-skl2/igt@kms_co...@pipe-a-ctm-0-5.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15310/shard-skl2/igt@kms_co...@pipe-a-ctm-0-5.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][25] -> [DMESG-WARN][26] ([fdo#108566]) +1 similar issue [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7360/shard-apl4/igt@kms_f...@flip-vs-susp
Re: [Intel-gfx] [PATCH] drm/i915/gt: Schedule request retirement when submission idles
On 18/11/2019 14:46, Chris Wilson wrote:
The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
corruption WA") is that it disables RC6 while Skylake (and friends) is
active, and we do not consider the GPU idle until all outstanding
requests have been retired and the engine switched over to the kernel
context. If userspace is idle, this task falls onto our background idle
worker, which only runs roughly once a second, meaning that userspace has
to have been idle for a couple of seconds before we enable RC6 again.
Naturally, this causes us to consume considerably more energy than
before as powersaving is effectively disabled while a display server
(here's looking at you Xorg) is running.
As execlists will get a completion event as the last context is
completed and the GPU goes idle, we can use our submission tasklet to
notice when the GPU is idle and kick the retire worker. Thus during
light workloads, we will do much more work to idle the GPU faster...
Hopefully with commensurate power saving!
References: https://bugs.freedesktop.org/show_bug.cgi?id=112315
References: 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gt_requests.h | 9 -
drivers/gpu/drm/i915/gt/intel_lrc.c | 11 +++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
index fde546424c63..94b8758a45d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
@@ -7,7 +7,9 @@
#ifndef INTEL_GT_REQUESTS_H
#define INTEL_GT_REQUESTS_H
-struct intel_gt;
+#include
+
+#include "intel_gt_types.h"
long intel_gt_retire_requests_timeout(struct intel_gt *gt, long timeout);
static inline void intel_gt_retire_requests(struct intel_gt *gt)
@@ -15,6 +17,11 @@ static inline void intel_gt_retire_requests(struct intel_gt
*gt)
intel_gt_retire_requests_timeout(gt, 0);
}
+static inline void intel_gt_schedule_retire_requests(struct intel_gt *gt)
+{
+ mod_delayed_work(system_wq, >->requests.retire_work, 0);
+}
+
int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
void intel_gt_init_requests(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 33ce258d484f..4485fe3e5066 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -142,6 +142,7 @@
#include "intel_engine_pm.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
+#include "intel_gt_requests.h"
#include "intel_lrc_reg.h"
#include "intel_mocs.h"
#include "intel_reset.h"
@@ -2278,6 +2279,16 @@ static void execlists_submission_tasklet(unsigned long
data)
if (timeout && preempt_timeout(engine))
preempt_reset(engine);
}
+
+ /*
+* If the GPU is currently idle, retire the outstanding completed
+* requests. This will allow us to enter soft-rc6 as soon as possible,
+* albeit at the cost of running the retire worker much more frequently
+* (over the entire GT not just this engine) and emitting more idle
+ * barriers (i.e. kernel context switches) which may some extra
May add, or something like that.
latency.
+*/
+ if (!execlists_active(&engine->execlists))
+ intel_gt_schedule_retire_requests(engine->gt);
Looking at "drm/i915/gen8+: Add RC6 CTX corruption WA" it seems it
should be possible to only do this if tha RC6 WA is active. So why not
limit the impact?
Regards,
Tvrtko
}
static void __execlists_kick(struct intel_engine_execlists *execlists)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Add intel_gt_driver_late_release for mock device
On 18/11/2019 09:43, Chris Wilson wrote:
Having called intel_gt_init_early() to setup the mock intel_gt, we need
to call the corresponding intel_gt_driver_late_release() to clean up.
References: dea397e818b1 ("drm/i915/gt: Flush retire.work timer object on
unload")
References: 24635c5152af ("drm/i915: Move intel_gt initialization to a separate
file")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index e58b0bc9cdb6..d14ba8498f57 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -71,6 +71,7 @@ static void mock_device_release(struct drm_device *dev)
mock_fini_ggtt(&i915->ggtt);
destroy_workqueue(i915->wq);
+ intel_gt_driver_late_release(&i915->gt);
intel_memory_regions_driver_release(i915);
drm_mode_config_cleanup(&i915->drm);
@@ -204,6 +205,7 @@ struct drm_i915_private *mock_gem_device(void)
err_unlock:
destroy_workqueue(i915->wq);
err_drv:
+ intel_gt_driver_late_release(&i915->gt);
intel_memory_regions_driver_release(i915);
drm_mode_config_cleanup(&i915->drm);
drm_dev_fini(&i915->drm);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
On Mon, Nov 18, 2019 at 06:59:23PM +0800, Jason Wang wrote:
> +static void mvnet_device_release(struct device *dev)
> +{
> + dev_dbg(dev, "mvnet: released\n");
> +}
We used to have documentation in the kernel source tree that said that
whenever anyone did this, I got to make fun of them. Unfortunately that
has been removed.
Think about what you did right here. You silenced a kernel runtime
warning that said something like "ERROR! NO RELEASE FUNCTION FOUND!" by
doing the above because "I am smarter than the kernel, I will silence it
by putting an empty release function in there."
{sigh}
Did you ever think _why_ we took the time and effort to add that warning
there? It wasn't just so that people can circumvent it, it is to
PREVENT A MAJOR BUG IN YOUR DESIGN! We are trying to be nice here and
give people a _chance_ to get things right instead of having you just
live with a silent memory leak.
After 13 versions of this series, basic things like this are still here?
Who is reviewing this thing?
{ugh}
Also, see the other conversations we are having about a "virtual" bus
and devices. I do not want to have two different ways of doing the same
thing in the kernel at the same time please. Please work together with
the Intel developers to solve this in a unified way, as you both
need/want the same thing here.
Neither this, nor the other proposal can be accepted until you all agree
on the design and implementation.
/me goes off to find a nice fruity drink with an umbrella.
greg k-h
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Schedule request retirement when submission idles
Quoting Tvrtko Ursulin (2019-11-18 15:12:17)
>
> On 18/11/2019 14:46, Chris Wilson wrote:
> > The major drawback of commit 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX
> > corruption WA") is that it disables RC6 while Skylake (and friends) is
> > active, and we do not consider the GPU idle until all outstanding
> > requests have been retired and the engine switched over to the kernel
> > context. If userspace is idle, this task falls onto our background idle
> > worker, which only runs roughly once a second, meaning that userspace has
> > to have been idle for a couple of seconds before we enable RC6 again.
> > Naturally, this causes us to consume considerably more energy than
> > before as powersaving is effectively disabled while a display server
> > (here's looking at you Xorg) is running.
> >
> > As execlists will get a completion event as the last context is
> > completed and the GPU goes idle, we can use our submission tasklet to
> > notice when the GPU is idle and kick the retire worker. Thus during
> > light workloads, we will do much more work to idle the GPU faster...
> > Hopefully with commensurate power saving!
> >
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=112315
> > References: 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_requests.h | 9 -
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 11 +++
> > 2 files changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > index fde546424c63..94b8758a45d9 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.h
> > @@ -7,7 +7,9 @@
> > #ifndef INTEL_GT_REQUESTS_H
> > #define INTEL_GT_REQUESTS_H
> >
> > -struct intel_gt;
> > +#include
> > +
> > +#include "intel_gt_types.h"
> >
> > long intel_gt_retire_requests_timeout(struct intel_gt *gt, long timeout);
> > static inline void intel_gt_retire_requests(struct intel_gt *gt)
> > @@ -15,6 +17,11 @@ static inline void intel_gt_retire_requests(struct
> > intel_gt *gt)
> > intel_gt_retire_requests_timeout(gt, 0);
> > }
> >
> > +static inline void intel_gt_schedule_retire_requests(struct intel_gt *gt)
> > +{
> > + mod_delayed_work(system_wq, >->requests.retire_work, 0);
> > +}
> > +
> > int intel_gt_wait_for_idle(struct intel_gt *gt, long timeout);
> >
> > void intel_gt_init_requests(struct intel_gt *gt);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index 33ce258d484f..4485fe3e5066 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -142,6 +142,7 @@
> > #include "intel_engine_pm.h"
> > #include "intel_gt.h"
> > #include "intel_gt_pm.h"
> > +#include "intel_gt_requests.h"
> > #include "intel_lrc_reg.h"
> > #include "intel_mocs.h"
> > #include "intel_reset.h"
> > @@ -2278,6 +2279,16 @@ static void execlists_submission_tasklet(unsigned
> > long data)
> > if (timeout && preempt_timeout(engine))
> > preempt_reset(engine);
> > }
> > +
> > + /*
> > + * If the GPU is currently idle, retire the outstanding completed
> > + * requests. This will allow us to enter soft-rc6 as soon as possible,
> > + * albeit at the cost of running the retire worker much more
> > frequently
> > + * (over the entire GT not just this engine) and emitting more idle
> > + * barriers (i.e. kernel context switches) which may some extra
>
> May add, or something like that.
>
> latency.
> > + */
> > + if (!execlists_active(&engine->execlists))
> > + intel_gt_schedule_retire_requests(engine->gt);
>
> Looking at "drm/i915/gen8+: Add RC6 CTX corruption WA" it seems it
> should be possible to only do this if tha RC6 WA is active. So why not
> limit the impact?
My starting pov is: If the impact is intolerable for one, it is
intolerable for all.
At the moment, is is reasonably consistently triggering
__i915_request_add_to_timeline:1167 GEM_BUG_ON(timeline->seqno !=
rq->fence.seqno)
which is a bit of a wtf. Once we get past the pebkac, we can then start
to see if this is noticeable on interesting workloads. Speaking of which
we should ping Dmitry to see if he's noticed a regression in gen9 power
figures.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on v5.4-rc8 next-20191115]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 7.4.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.4.0 make.cross ARCH=m68k
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no
>> member named 'map'; did you mean 'mmap'?
.map= kmap_udmabuf,
^~~
mmap
>> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible
>> pointer type [-Werror=incompatible-pointer-types]
.map= kmap_udmabuf,
^~~~
drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for
'udmabuf_ops.begin_cpu_access')
>> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no
>> member named 'unmap'; did you mean 'vunmap'?
.unmap= kunmap_udmabuf,
^
vunmap
drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible
pointer type [-Werror=incompatible-pointer-types]
.unmap= kunmap_udmabuf,
^~
drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for
'udmabuf_ops.end_cpu_access')
cc1: some warnings being treated as errors
--
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops'
>> has no member named 'map'; did you mean 'mmap'?
.map = udl_dmabuf_kmap,
^~~
mmap
>> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from
>> incompatible pointer type [-Werror=incompatible-pointer-types]
.map = udl_dmabuf_kmap,
^~~
drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for
'udl_dmabuf_ops.release')
>> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops'
>> has no member named 'unmap'; did you mean 'vunmap'?
.unmap = udl_dmabuf_kunmap,
^
vunmap
drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from
incompatible pointer type [-Werror=incompatible-pointer-types]
.unmap = udl_dmabuf_kunmap,
^
drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for
'udl_dmabuf_ops.begin_cpu_access')
cc1: some warnings being treated as errors
vim +114 drivers/dma-buf/udmabuf.c
fbb0de79507819 Gerd Hoffmann 2018-08-27 109
a34852891ba45d Gerd Hoffmann 2018-09-11 110 static const struct dma_buf_ops
udmabuf_ops = {
fbb0de79507819 Gerd Hoffmann 2018-08-27 111.map_dma_buf = map_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 112.unmap_dma_buf=
unmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 113.release =
release_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @114.map =
kmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 @115.unmap=
kunmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 116.mmap =
mmap_udmabuf,
fbb0de79507819 Gerd Hoffmann 2018-08-27 117 };
fbb0de79507819 Gerd Hoffmann 2018-08-27 118
:: The code at line 114 was first introduced by commit
:: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
:: TO: Gerd Hoffmann
:: CC: Gerd Hoffmann
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7] drm/i915: Enable second dbuf slice for ICL and TGL
On Mon, 18 Nov 2019, "Lisovskiy, Stanislav" wrote: > I'm fine with fixing checkpatch and sparse failures(even though > most of those are about 80 line width limitation violation or line > continuations, which tbh are anyway quite common in our code). Please look through the warnings again. Only the COMMIT_LOG_LONG_LINE one is to be ignored in this case. There's nothing else about 80 character line width. Line continuation is about using backslash to continue to another line while that's only needed in macros. Please let's just try to leave the code in neater shape after our changes. We have these steps in CI so people wouldn't have to nitpick about them separately. > One thing I don't get is why this should cause any regression, as both > BAT and IGT are green here for two runs in a row. > > What is the point of having a CI then. Are you saying there's no point in having CI if it can't catch absolutely everything? Our CI is like every other CI everywhere; imperfect. Both in terms of hardware and software coverage. We would have no bugs reported by the community otherwise. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7] drm/i915: Enable second dbuf slice for ICL and TGL
On Mon, Nov 18, 2019 at 09:19:18AM +, Lisovskiy, Stanislav wrote:
> On Fri, 2019-11-15 at 22:19 +0200, Ville Syrjälä wrote:
> > On Thu, Nov 14, 2019 at 02:24:49PM +0200, Stanislav Lisovskiy wrote:
> > > Also implemented algorithm for choosing DBuf slice configuration
> > > based on active pipes, pipe ratio as stated in BSpec 12716.
> > >
> > > Now pipe allocation still stays proportional to pipe width as
> > > before,
> > > however within allowed DBuf slice for this particular
> > > configuration.
> > >
> > > v2: Remove unneeded check from commit as ddb enabled slices might
> > > now differ from hw state.
> > >
> > > v3: - Added new field "supported_slices" to ddb to separate max
> > > supported slices vs currently enabled, to avoid confusion.
> > > - Removed obsolete comments and code related to DBuf(Matthew
> > > Roper).
> > > - Some code style and long line removal(Matthew Roper).
> > > - Added WARN_ON to new ddb range offset calc function(Matthew
> > > Roper).
> > > - Removed platform specific call to calc pipe ratio from ddb
> > > allocation function and fixed the return value(Matthew Roper)
> > > - Refactored DBUF slice allocation table to improve readability
> > > - Added DBUF slice allocation for TGL as well.
> > > - ICL(however not TGL) seems to voluntarily enable second DBuf
> > > slice
> > > after pm suspend/resume causing a mismatch failure, because
> > > we
> > > update DBuf slices only if we do a modeset, however this
> > > check
> > > is done always. Fixed it to be done only when modeset for
> > > ICL.
> > >
> > > v4: - Now enabled slices is not actually a number, but a bitmask,
> > > because we might need to enable second slice only and number
> > > of slices would still 1 and that current code doesn't allow.
> > > - Remove redundant duplicate code to have some unified way of
> > > enabling dbuf slices instead of hardcoding.
> > >
> > > v5: - Fix failing gen9_assert_dbuf_enabled as it was naively
> > > thinking
> > > that we have only one DBUF_CTL slice. Now another version for
> > > gen11 will check both slices as only second one can be
> > > enabled,
> > > to keep CI happy.
> > >
> > > v6: - Removed enabled dbuf assertion completely. Previous code
> > > was keeping dbuf enabled, even(!) when _dbuf_disable is
> > > called.
> > > Currently we enable/disable dbuf slices based on requrement
> > > so no point in asserting this here.
> > > - Removed unnecessary modeset check from
> > > verify_wm_state(Matthew Roper)
> > > - Slices intersection after union is same as final
> > > result(Matthew Roper)
> > > - Moved DBuf slices to intel_device_info(Matthew Roper)
> > > - Some macros added(Matthew Roper)
> > > - ddb range is now always less or equal to ddb size - no need
> > > for additional
> > > checks(previously needed as we had some bandwidth checks in
> > > there which
> > > could "suddenly" return ddb_size smaller than it is.
> > >
> > > v7: Minor costemic changes:
> > > - Changed icl_dbuf_slices_restore name to
> > > icl_program_dbuf_slices
> > > as it more corresponds to the actual functionality.
> > > - Some simplification with supported slices for BXT and GLK
> > > - skl_pipe_downscale_amount -> icl_pipe_downscale_amount as
> > > this is not used for skl anymore.
> > > - Changed DBuf slice assignment order for TGL case
> > >
> > > Reviewed-by: Matthew Roper
> > > Signed-off-by: Stanislav Lisovskiy
> > > Cc: Matthew Roper
> > > Cc: Ville Syrjälä
> > > Cc: James Ausmus
> > > ---
> > > drivers/gpu/drm/i915/display/intel_display.c | 26 +-
> > > .../drm/i915/display/intel_display_power.c| 98 ++---
> > > .../drm/i915/display/intel_display_power.h| 2 +
> > > drivers/gpu/drm/i915/i915_drv.c | 5 +
> > > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > > drivers/gpu/drm/i915/i915_pci.c | 6 +-
> > > drivers/gpu/drm/i915/i915_reg.h | 8 +-
> > > drivers/gpu/drm/i915/intel_device_info.h | 1 +
> > > drivers/gpu/drm/i915/intel_pm.c | 387
> > > --
> > > 9 files changed, 431 insertions(+), 104 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 876fc25968bf..bd7aff675198 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -13387,7 +13387,7 @@ static void verify_wm_state(struct
> > > intel_crtc *crtc,
> > >
> > > if (INTEL_GEN(dev_priv) >= 11 &&
> > > hw->ddb.enabled_slices != sw_ddb->enabled_slices)
> > > - DRM_ERROR("mismatch in DBUF Slices (expected %u, got
> > > %u)\n",
> > > + DRM_ERROR("mismatch in DBUF Slices (expected %x, got
> > > %x)\n",
> > > sw_ddb->enabled_slices,
> >
Re: [Intel-gfx] [PATCH xf86-video-intel v2] SNA: fix PRIME output support since xserver 1.20
On Sat, Nov 16, 2019 at 05:13:17PM +0100, Peter Wu wrote:
> On Fri, Nov 15, 2019 at 08:14:05PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 15, 2019 at 04:32:47PM +0100, Peter Wu wrote:
> > > Since "Make PixmapDirtyUpdateRec::src a DrawablePtr" in xserver, the
> > > "src" pointer might point to the root window (created by the server)
> > > instead of a pixmap (as created by xf86-video-intel). Use
> > > get_drawable_pixmap to handle both cases.
> > >
> > > When built with -fsanitize=address, the following test on a hybrid
> > > graphics laptop will trigger a heap-buffer-overflow error due to
> > > to_sna_from_pixmap receiving a window instead of a pixmap:
> > >
> > > xrandr --setprovideroutputsource modesetting Intel
> > > xrandr --output DP-1-1 --mode 2560x1440 # should not crash
> > > glxgears # should display gears on both screens
> > >
> > > With nouveau instead of modesetting, it does not crash but the external
> > > monitor remains blank aside from a mouse cursor. This patch fixes both.
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100086
> >
> > Also
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111976
>
> I marked this bug as duplicate of the former since it is the same issue.
>
> About the CI failure
> (https://lists.freedesktop.org/archives/intel-gfx/2019-November/220187.html),
> should I be concerned? I can't see what tree it is trying to apply the
> patch to. Is it actually trying to apply it to xf86-video-intel, or is
> it trying the Linux kernel instead?
Yeah, I think it's trying to apply it to the kernel. We have no CI
for the ddx unfortunately.
>
> > > Signed-off-by: Peter Wu
> > > ---
> > > v1:
> > > https://lists.freedesktop.org/archives/intel-gfx/2018-August/173522.html
> > > v2: rebased on current master (2.99.917-893-gbff5eca4), reworded commit.
> > >
> > > This patch has been tested at https://bugs.archlinux.org/task/64238, I
> > > have additionally tested it with both modesetting and nouveau under
> > > ASAN, the modesetting ASAN trace for unpatched intel can be found at:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=100086#c24
> > >
> > > commit 2.99.917-891-g581ddc5d ("sna: Fix compiler warnings due to
> > > DrawablePtr vs. PixmapPtr") incorporated all compiler warning fixes from
> > > v1 of this patch, but unfortunately lacks this crucial bugfix.
> > > ---
> > > src/sna/sna_accel.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c
> > > index fa386ff6..ee857a14 100644
> > > --- a/src/sna/sna_accel.c
> > > +++ b/src/sna/sna_accel.c
> > > @@ -17684,10 +17684,10 @@ static void sna_accel_post_damage(struct sna
> > > *sna)
> > > continue;
> > >
> > > #ifdef HAS_DIRTYTRACKING_DRAWABLE_SRC
> > > - assert(dirty->src->type == DRAWABLE_PIXMAP);
> > > + src = get_drawable_pixmap(dirty->src);
> > > +#else
> > > + src = dirty->src;
> > > #endif
> > > -
> > > - src = (PixmapPtr)dirty->src;
> > > dst = dirty->slave_dst->master_pixmap;
> > >
> > > region.extents.x1 = dirty->x;
> > > --
> > > 2.23.0
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V13 6/6] docs: sample driver to demonstrate how to implement virtio-mdev framework
On Mon, 18 Nov 2019 18:59:23 +0800
Jason Wang wrote:
[Note: I have not looked into the reworked architecture of this *at all*
so far; just something that I noted...]
> This sample driver creates mdev device that simulate virtio net device
> over virtio mdev transport. The device is implemented through vringh
> and workqueue. A device specific dma ops is to make sure HVA is used
> directly as the IOVA. This should be sufficient for kernel virtio
> driver to work.
>
> Only 'virtio' type is supported right now. I plan to add 'vhost' type
> on top which requires some virtual IOMMU implemented in this sample
> driver.
>
> Signed-off-by: Jason Wang
> ---
> MAINTAINERS| 1 +
> samples/Kconfig| 10 +
> samples/vfio-mdev/Makefile | 1 +
> samples/vfio-mdev/mvnet_loopback.c | 690 +
> 4 files changed, 702 insertions(+)
> create mode 100644 samples/vfio-mdev/mvnet_loopback.c
>
> +static struct mvnet_dev {
> + struct class*vd_class;
> + struct idr vd_idr;
> + struct device dev;
> +} mvnet_dev;
This structure embeds a struct device (a reference-counted structure),
yet it is a static variable. This is giving a bad example to potential
implementers; just allocate it dynamically.
> +static void mvnet_device_release(struct device *dev)
> +{
> + dev_dbg(dev, "mvnet: released\n");
And that also means you need a proper release function here, of
course.
> +}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix detection for a CMP-V PCH
On Tue, 12 Nov 2019, Imre Deak wrote:
> According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
This seems to be pushed already, but I'm just confused about difference
between the id here in the commit message vs. the one in the patch.
BR,
Jani.
> belongs to a CMP-V chipset. Based on the same docs the programming of
> the PCH is compatible with that of KBP. Fix up my previous wrong
> assumption accordingly using the SPT programming which in turn is the
> basis for KBP.
>
> The original bug reporter verified that this is the correct PCH
> identification (the only way we'll program valid DDC pin-pair values to
> the GMBUS register) and the Windows team uses the same identification
> (that is using the KBP programming model for this PCH).
>
> I filed the necessary Bspec update requests (BSpec/33734).
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051
> Fixes: 37c92dc303dd ("drm/i915: Add new CNL PCH ID seen on a CML platform")
> Reported-and-tested-by: Cyrus
> Cc: Cyrus
> Cc: Timo Aaltonen
> Cc: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_pch.c | 6 +-
> drivers/gpu/drm/i915/intel_pch.h | 2 +-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pch.c
> b/drivers/gpu/drm/i915/intel_pch.c
> index fd22355b9a96..43b68b5fc562 100644
> --- a/drivers/gpu/drm/i915/intel_pch.c
> +++ b/drivers/gpu/drm/i915/intel_pch.c
> @@ -62,7 +62,6 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> unsigned short id)
> /* KBP is SPT compatible */
> return PCH_SPT;
> case INTEL_PCH_CNP_DEVICE_ID_TYPE:
> - case INTEL_PCH_CNP2_DEVICE_ID_TYPE:
> DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
> WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
> return PCH_CNP;
> @@ -76,6 +75,11 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> unsigned short id)
> WARN_ON(!IS_COFFEELAKE(dev_priv));
> /* CometPoint is CNP Compatible */
> return PCH_CNP;
> + case INTEL_PCH_CMP_V_DEVICE_ID_TYPE:
> + DRM_DEBUG_KMS("Found Comet Lake V PCH (CMP-V)\n");
> + WARN_ON(!IS_COFFEELAKE(dev_priv));
> + /* Comet Lake V PCH is based on KBP, which is SPT compatible */
> + return PCH_SPT;
> case INTEL_PCH_ICP_DEVICE_ID_TYPE:
> DRM_DEBUG_KMS("Found Ice Lake PCH\n");
> WARN_ON(!IS_ICELAKE(dev_priv));
> diff --git a/drivers/gpu/drm/i915/intel_pch.h
> b/drivers/gpu/drm/i915/intel_pch.h
> index 52d145dcdb15..3053d1ce398b 100644
> --- a/drivers/gpu/drm/i915/intel_pch.h
> +++ b/drivers/gpu/drm/i915/intel_pch.h
> @@ -40,10 +40,10 @@ enum intel_pch {
> #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE 0x9D00
> #define INTEL_PCH_KBP_DEVICE_ID_TYPE 0xA280
> #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> -#define INTEL_PCH_CNP2_DEVICE_ID_TYPE0xA380
> #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE 0x9D80
> #define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
> #define INTEL_PCH_CMP2_DEVICE_ID_TYPE0x0680
> +#define INTEL_PCH_CMP_V_DEVICE_ID_TYPE 0xA380
> #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
> #define INTEL_PCH_TGP_DEVICE_ID_TYPE 0xA080
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix detection for a CMP-V PCH
On Mon, Nov 18, 2019 at 05:49:44PM +0200, Jani Nikula wrote:
> On Tue, 12 Nov 2019, Imre Deak wrote:
> > According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
>
> This seems to be pushed already, but I'm just confused about difference
> between the id here in the commit message vs. the one in the patch.
#define INTEL_PCH_DEVICE_ID_MASK0xff80
Ie. we only match the top 9 bits.
>
> BR,
> Jani.
>
> > belongs to a CMP-V chipset. Based on the same docs the programming of
> > the PCH is compatible with that of KBP. Fix up my previous wrong
> > assumption accordingly using the SPT programming which in turn is the
> > basis for KBP.
> >
> > The original bug reporter verified that this is the correct PCH
> > identification (the only way we'll program valid DDC pin-pair values to
> > the GMBUS register) and the Windows team uses the same identification
> > (that is using the KBP programming model for this PCH).
> >
> > I filed the necessary Bspec update requests (BSpec/33734).
> >
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051
> > Fixes: 37c92dc303dd ("drm/i915: Add new CNL PCH ID seen on a CML platform")
> > Reported-and-tested-by: Cyrus
> > Cc: Cyrus
> > Cc: Timo Aaltonen
> > Cc: José Roberto de Souza
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_pch.c | 6 +-
> > drivers/gpu/drm/i915/intel_pch.h | 2 +-
> > 2 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_pch.c
> > b/drivers/gpu/drm/i915/intel_pch.c
> > index fd22355b9a96..43b68b5fc562 100644
> > --- a/drivers/gpu/drm/i915/intel_pch.c
> > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > @@ -62,7 +62,6 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> > unsigned short id)
> > /* KBP is SPT compatible */
> > return PCH_SPT;
> > case INTEL_PCH_CNP_DEVICE_ID_TYPE:
> > - case INTEL_PCH_CNP2_DEVICE_ID_TYPE:
> > DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
> > WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
> > return PCH_CNP;
> > @@ -76,6 +75,11 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> > unsigned short id)
> > WARN_ON(!IS_COFFEELAKE(dev_priv));
> > /* CometPoint is CNP Compatible */
> > return PCH_CNP;
> > + case INTEL_PCH_CMP_V_DEVICE_ID_TYPE:
> > + DRM_DEBUG_KMS("Found Comet Lake V PCH (CMP-V)\n");
> > + WARN_ON(!IS_COFFEELAKE(dev_priv));
> > + /* Comet Lake V PCH is based on KBP, which is SPT compatible */
> > + return PCH_SPT;
> > case INTEL_PCH_ICP_DEVICE_ID_TYPE:
> > DRM_DEBUG_KMS("Found Ice Lake PCH\n");
> > WARN_ON(!IS_ICELAKE(dev_priv));
> > diff --git a/drivers/gpu/drm/i915/intel_pch.h
> > b/drivers/gpu/drm/i915/intel_pch.h
> > index 52d145dcdb15..3053d1ce398b 100644
> > --- a/drivers/gpu/drm/i915/intel_pch.h
> > +++ b/drivers/gpu/drm/i915/intel_pch.h
> > @@ -40,10 +40,10 @@ enum intel_pch {
> > #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
> > #define INTEL_PCH_KBP_DEVICE_ID_TYPE 0xA280
> > #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> > -#define INTEL_PCH_CNP2_DEVICE_ID_TYPE 0xA380
> > #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
> > #define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
> > #define INTEL_PCH_CMP2_DEVICE_ID_TYPE 0x0680
> > +#define INTEL_PCH_CMP_V_DEVICE_ID_TYPE 0xA380
> > #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> > #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
> > #define INTEL_PCH_TGP_DEVICE_ID_TYPE 0xA080
>
> --
> Jani Nikula, Intel Open Source Graphics Center
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/15] Retire dma_buf_k(un)map
Hello Daniel, On Mon, 18 Nov 2019 at 16:05, Daniel Vetter wrote: > > Hi all, > > Way back when we created the dma-buf spec it made sense to have kmap/unmap > interfaces, since 32bit kernels with limited vmalloc space were still > rather ubiquitous. But that idea (like many others) never caught on, was > quickly replaced by vmaps covering the entire buffer for all real uses, > and nowadays 64bit kernels rule the world. Currently merged upstream > drivers (and we have a pile now) don't even bother to kmap for their > private buffers, much less for anything shared. > > So since it was never used, and this idea's time is clearly over, let's > remove it all. As always, thanks for helping keep this code sane :) Fwiw, for the series, please feel free to add my Acked-by: Sumit Semwal > > Only real change I had to do (aside from deleting lots of dead code) was > in the tegra driver. But even there I suspect the dma-buf kmap path has > never been run in anger anywhere, it just doesn't make sense to put relocs > into a dma-buf (as opposed to using a dma-buf for the target address of a > reloc). > > Comments, reviews and testing very much appreciated. > > Cheers, Daniel > > Daniel Vetter (15): > drm/tegra: Map cmdbuf once for reloc processing > drm/tegra: Delete host1x_bo_ops->k(un)map > drm/i915: Remove dma_buf_kmap selftest > staging/android/ion: delete dma_buf->kmap/unmap implemenation > drm/armada: Delete dma_buf->k(un)map implemenation > drm/i915: Drop dma_buf->k(un)map > drm/omapdrm: Drop dma_buf->k(un)map > drm/tegra: Remove dma_buf->k(un)map > dma-buf: Drop dma_buf_k(un)map > drm/vmwgfx: Delete mmaping functions > media/videobuf2: Drop dma_buf->k(un)map support > drm/tee_shm: Drop dma_buf_k(unmap) support > xen/gntdev-dmabuf: Ditch dummy map functions > sample/vfio-mdev/mbocs: Remove dma_buf_k(un)map support > dma-buf: Remove kernel map/unmap hooks > > drivers/dma-buf/dma-buf.c | 63 +-- > drivers/gpu/drm/armada/armada_gem.c | 12 --- > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 36 --- > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 101 -- > .../gpu/drm/i915/gem/selftests/mock_dmabuf.c | 16 --- > drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 21 > drivers/gpu/drm/tegra/gem.c | 40 --- > drivers/gpu/drm/vmwgfx/vmwgfx_prime.c | 33 -- > drivers/gpu/host1x/job.c | 21 ++-- > .../common/videobuf2/videobuf2-dma-contig.c | 8 -- > .../media/common/videobuf2/videobuf2-dma-sg.c | 8 -- > .../common/videobuf2/videobuf2-vmalloc.c | 8 -- > drivers/misc/fastrpc.c| 8 -- > drivers/staging/android/ion/ion.c | 14 --- > drivers/tee/tee_shm.c | 6 -- > drivers/xen/gntdev-dmabuf.c | 23 > include/linux/dma-buf.h | 27 - > include/linux/host1x.h| 13 --- > samples/vfio-mdev/mbochs.c| 16 --- > 19 files changed, 10 insertions(+), 464 deletions(-) > > -- > 2.24.0 > > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel Best, Sumit. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix a bug calling sleep function in atomic context
On Wed, 13 Nov 2019, Bruce Chang wrote:
> below is the call trace when this issue is hit
>
> <3> [113.316247] BUG: sleeping function called from invalid context at
> mm/page_alloc.c:4653
> <3> [113.318190] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name:
> debugfs_test
> <4> [113.319900] no locks held by debugfs_test/678.
> <3> [113.321002] Preemption disabled at:
> <4> [113.321130] [] i915_error_object_create+0x494/0x610
> [i915]
> <4> [113.327259] Call Trace:
> <4> [113.327871] dump_stack+0x67/0x9b
> <4> [113.328683] ___might_sleep+0x167/0x250
> <4> [113.329618] __alloc_pages_nodemask+0x26b/0x1110
> <4> [113.330731] ? ___slab_alloc.constprop.34+0x21c/0x380
> <4> [113.331943] ? ___slab_alloc.constprop.34+0x21c/0x380
> <4> [113.333169] ? __slab_alloc.isra.28.constprop.33+0x4d/0x70
> <4> [113.334614] pool_alloc.constprop.19+0x14/0x60 [i915]
> <4> [113.335951] compress_page+0x7c/0x100 [i915]
> <4> [113.337110] i915_error_object_create+0x4bd/0x610 [i915]
> <4> [113.338515] i915_capture_gpu_state+0x384/0x1680 [i915]
> <4> [113.339771] ? __lock_acquire+0x4ac/0x1e90
> <4> [113.340785] ? _raw_spin_lock_irqsave_nested+0x1/0x50
> <4> [113.342127] i915_gpu_info_open+0x44/0x70 [i915]
> <4> [113.343243] full_proxy_open+0x139/0x1b0
> <4> [113.344196] ? open_proxy_open+0xc0/0xc0
> <4> [113.345149] do_dentry_open+0x1ce/0x3a0
> <4> [113.346084] path_openat+0x4c9/0xac0
> <4> [113.346967] do_filp_open+0x96/0x110
> <4> [113.347848] ? __alloc_fd+0xe0/0x1f0
> <4> [113.348736] ? do_sys_open+0x1b8/0x250
> <4> [113.349647] do_sys_open+0x1b8/0x250
> <4> [113.350526] do_syscall_64+0x55/0x1c0
> <4> [113.351418] entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> After the io_mapping_map_atomic_wc/kmap_atomic, the kernel enters atomic
> context
> but after that, compress_page calls pool_alloc with GFP_KERNEL flag which can
> potentially go to sleep. When the kernel is in atomic context, sleeping is not
> allowed. This is why this bug got triggered.
>
> In order to fix this issue, we either
> 1) not enter into atomic context, i.e., to use non atomic version of
> functions like io_mapping_map_wc/kmap,
> or
> 2) make compress_page run in atomic context.
>
> But it is not a good idea to run slow compression in atomic context, so,
> 1) above is preferred solution which is the implementation of this patch.
>
> Signed-off-by: Bruce Chang
> Reviewed-by: Brian Welty
> Fixes: 895d8ebeaa924 ("drm/i915: error capture with no ggtt slot")
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
> b/drivers/gpu/drm/i915/i915_gpu_error.c
> index 1f2f266f26af..7118ecb7f144 100644
> --- a/drivers/gpu/drm/i915/i915_gpu_error.c
> +++ b/drivers/gpu/drm/i915/i915_gpu_error.c
> @@ -1007,67 +1007,67 @@ i915_error_object_create(struct drm_i915_private
> *i915,
> compress->wc = i915_gem_object_is_lmem(vma->obj) ||
> drm_mm_node_allocated(&ggtt->error_capture);
>
> ret = -EINVAL;
> if (drm_mm_node_allocated(&ggtt->error_capture)) {
> void __iomem *s;
> dma_addr_t dma;
>
> for_each_sgt_daddr(dma, iter, vma->pages) {
> ggtt->vm.insert_page(&ggtt->vm, dma, slot,
>I915_CACHE_NONE, 0);
>
> s = io_mapping_map_wc(&ggtt->iomap, slot, PAGE_SIZE);
> ret = compress_page(compress, (void __force *)s, dst);
> io_mapping_unmap(s);
> if (ret)
> break;
> }
> } else if (i915_gem_object_is_lmem(vma->obj)) {
> struct intel_memory_region *mem = vma->obj->mm.region;
> dma_addr_t dma;
>
> for_each_sgt_daddr(dma, iter, vma->pages) {
> void __iomem *s;
>
> - s = io_mapping_map_atomic_wc(&mem->iomap, dma);
> + s = io_mapping_map_wc(&mem->iomap, dma, PAGE_SIZE);
> ret = compress_page(compress, (void __force *)s, dst);
> - io_mapping_unmap_atomic(s);
> + io_mapping_unmap(s);
> if (ret)
> break;
> }
> } else {
> struct page *page;
>
> for_each_sgt_page(page, iter, vma->pages) {
> void *s;
>
> drm_clflush_pages(&page, 1);
>
> - s = kmap_atomic(page);
> + s = kmap(page);
> ret = compress_page(compress, s, dst);
> - kunmap_atomic(s);
> + kunmap(s);
>
> drm_clflush_pages(&page, 1);
>
> if (ret)
> break;
> }
> }
>
> if (ret || compress_flush(compress,
Re: [Intel-gfx] [PATCH 2/2] drm/i915/dsb: fix extra warning on error path handling
On Fri, 15 Nov 2019, Lucas De Marchi wrote:
> On Fri, Nov 15, 2019 at 12:52:49PM -0800, Matt Roper wrote:
>>On Mon, Nov 11, 2019 at 12:50:25PM -0800, Lucas De Marchi wrote:
>>> When we call intel_dsb_get(), the dsb initialization may fail for
>>> various reasons. We already log the error message in that path, making
>>> it unnecessary to trigger a warning that refcount == 0 when calling
>>> intel_dsb_put().
>>>
>>> So here we simplify the logic and do lazy shutdown: leaving the extra
>>> refcount alive so when we call intel_dsb_put() we end up calling
>>> i915_vma_unpin_and_release().
>>>
>>> Signed-off-by: Lucas De Marchi
>>
>>Due to the lack of any actual concurrency, it seems like we could
>>eventually get rid of the whole get/put design and just allocate the
>>buffer once (and pin it during the prepare step). But this seems good
>
> I assumed this was designed to accept the pattern
>
> intel_dsb_get();
> intel_dsb_get();
> intel_dsb_put();
> intel_dsb_put();
Yeah it wasn't necessarily for concurrency. More to ensure the buffer
doesn't vanish under the engine.
BR,
Jani.
>
>>enough for now.
>>
>>Reviewed-by: Matt Roper
>
> thanks
> Lucas De Marchi
>
>>
>>
>>> ---
>>> drivers/gpu/drm/i915/display/intel_dsb.c | 21 ++---
>>> 1 file changed, 14 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
>>> b/drivers/gpu/drm/i915/display/intel_dsb.c
>>> index 4feebbeb0b0c..858af6be9c36 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
>>> @@ -102,6 +102,7 @@ intel_dsb_get(struct intel_crtc *crtc)
>>> struct intel_dsb *dsb = &crtc->dsb;
>>> struct drm_i915_gem_object *obj;
>>> struct i915_vma *vma;
>>> + u32 *buf;
>>> intel_wakeref_t wakeref;
>>>
>>> if (!HAS_DSB(i915))
>>> @@ -110,7 +111,6 @@ intel_dsb_get(struct intel_crtc *crtc)
>>> if (++dsb->refcount != 1)
>>> return dsb;
>>>
>>> - dsb->id = DSB1;
>>> wakeref = intel_runtime_pm_get(&i915->runtime_pm);
>>>
>>> obj = i915_gem_object_create_internal(i915, DSB_BUF_SIZE);
>>> @@ -123,22 +123,29 @@ intel_dsb_get(struct intel_crtc *crtc)
>>> if (IS_ERR(vma)) {
>>> DRM_ERROR("Vma creation failed\n");
>>> i915_gem_object_put(obj);
>>> - dsb->refcount--;
>>> goto err;
>>> }
>>>
>>> - dsb->cmd_buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
>>> - if (IS_ERR(dsb->cmd_buf)) {
>>> + buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
>>> + if (IS_ERR(buf)) {
>>> DRM_ERROR("Command buffer creation failed\n");
>>> - i915_vma_unpin_and_release(&vma, 0);
>>> - dsb->cmd_buf = NULL;
>>> - dsb->refcount--;
>>> goto err;
>>> }
>>> +
>>> + dsb->id = DSB1;
>>> dsb->vma = vma;
>>> + dsb->cmd_buf = buf;
>>>
>>> err:
>>> + /*
>>> +* Set cmd_buf to NULL so the writes pass-through, but leave the
>>> +* dangling refcount to be removed later by the corresponding
>>> +* intel_dsb_put(): the important error message will already be
>>> +* logged above.
>>> +*/
>>> + dsb->cmd_buf = NULL;
>>> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
>>> +
>>> return dsb;
>>> }
>>>
>>> --
>>> 2.24.0
>>>
>>> ___
>>> Intel-gfx mailing list
>>> Intel-gfx@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>>
>>--
>>Matt Roper
>>Graphics Software Engineer
>>VTT-OSGC Platform Enablement
>>Intel Corporation
>>(916) 356-2795
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for VBT "generic DTD" block (rev3)
On Sun, Nov 17, 2019 at 04:59:01PM +, Patchwork wrote:
> == Series Details ==
>
> Series: VBT "generic DTD" block (rev3)
> URL : https://patchwork.freedesktop.org/series/69481/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_7357_full -> Patchwork_15300_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_15300_full absolutely need to
> be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_15300_full, please notify your bug team to allow
> them
> to document this new failure mode, which will reduce false positives in CI.
>
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_15300_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@gem_persistent_relocs@forked-thrash-inactive:
> - shard-apl: [PASS][1] -> [DMESG-FAIL][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7357/shard-apl6/igt@gem_persistent_rel...@forked-thrash-inactive.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-apl4/igt@gem_persistent_rel...@forked-thrash-inactive.html
Maybe fdo #112271? Not related to this patch series anyway.
Patches applied to dinq. Thanks Jani and Jesse for the reviews!
Matt
>
>
> Suppressed
>
> The following results come from untrusted machines, tests, or statuses.
> They do not affect the overall result.
>
> * {igt@gem_exec_parse_blt@unaligned-jump}:
> - shard-tglb: NOTRUN -> [SKIP][3]
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-tglb9/igt@gem_exec_parse_...@unaligned-jump.html
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_15300_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_ctx_persistence@vcs0-mixed-process:
> - shard-skl: [PASS][4] -> [FAIL][5] ([fdo#112194])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7357/shard-skl5/igt@gem_ctx_persiste...@vcs0-mixed-process.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-skl2/igt@gem_ctx_persiste...@vcs0-mixed-process.html
>
> * igt@gem_ctx_persistence@vcs1-mixed-process:
> - shard-iclb: [PASS][6] -> [SKIP][7] ([fdo#109276] / [fdo#112080])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7357/shard-iclb1/igt@gem_ctx_persiste...@vcs1-mixed-process.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-iclb6/igt@gem_ctx_persiste...@vcs1-mixed-process.html
>
> * igt@gem_eio@kms:
> - shard-snb: [PASS][8] -> [INCOMPLETE][9] ([fdo#105411])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7357/shard-snb7/igt@gem_...@kms.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-snb6/igt@gem_...@kms.html
>
> * igt@gem_exec_gttfill@basic:
> - shard-tglb: [PASS][10] -> [INCOMPLETE][11] ([fdo#111593])
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7357/shard-tglb4/igt@gem_exec_gttf...@basic.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-tglb5/igt@gem_exec_gttf...@basic.html
>
> * igt@gem_exec_nop@basic-series:
> - shard-tglb: [PASS][12] -> [INCOMPLETE][13] ([fdo#111747])
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7357/shard-tglb1/igt@gem_exec_...@basic-series.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-tglb6/igt@gem_exec_...@basic-series.html
>
> * igt@gem_exec_schedule@fifo-bsd:
> - shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#112146]) +1 similar
> issue
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7357/shard-iclb3/igt@gem_exec_sched...@fifo-bsd.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-iclb4/igt@gem_exec_sched...@fifo-bsd.html
>
> * igt@gem_exec_schedule@preempt-queue-contexts-render:
> - shard-tglb: [PASS][16] -> [INCOMPLETE][17] ([fdo#111606] /
> [fdo#111677])
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7357/shard-tglb9/igt@gem_exec_sched...@preempt-queue-contexts-render.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-tglb6/igt@gem_exec_sched...@preempt-queue-contexts-render.html
>
> * igt@gem_persistent_relocs@forked-interruptible-thrashing:
> - shard-snb: [PASS][18] -> [TIMEOUT][19] ([fdo#112068 ])
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7357/shard-snb1/igt@gem_persistent_rel...@forked-interruptible-thrashing.html
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15300/shard-snb5/igt@gem_persistent_rel...@forked-interruptible-thrashing.html
>
> *
Re: [Intel-gfx] [PATCH] drm/i915: Fix detection for a CMP-V PCH
On Mon, Nov 18, 2019 at 05:53:37PM +0200, Ville Syrjälä wrote:
> On Mon, Nov 18, 2019 at 05:49:44PM +0200, Jani Nikula wrote:
> > On Tue, 12 Nov 2019, Imre Deak wrote:
> > > According to internal documents I found for CMP PCHs the PCI ID 0xA3C1
> >
> > This seems to be pushed already, but I'm just confused about difference
> > between the id here in the commit message vs. the one in the patch.
>
> #define INTEL_PCH_DEVICE_ID_MASK0xff80
>
> Ie. we only match the top 9 bits.
Yes, and the whole 0xa380 - 0xa3ff range is reserved for the CMP-V PCH
(similarly to other PCH types, where either the whole 0xXX00 - 0xXX7F or
0xXX80 - 0xXXFF range is reserved for the given PCH).
>
> >
> > BR,
> > Jani.
> >
> > > belongs to a CMP-V chipset. Based on the same docs the programming of
> > > the PCH is compatible with that of KBP. Fix up my previous wrong
> > > assumption accordingly using the SPT programming which in turn is the
> > > basis for KBP.
> > >
> > > The original bug reporter verified that this is the correct PCH
> > > identification (the only way we'll program valid DDC pin-pair values to
> > > the GMBUS register) and the Windows team uses the same identification
> > > (that is using the KBP programming model for this PCH).
> > >
> > > I filed the necessary Bspec update requests (BSpec/33734).
> > >
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051
> > > Fixes: 37c92dc303dd ("drm/i915: Add new CNL PCH ID seen on a CML
> > > platform")
> > > Reported-and-tested-by: Cyrus
> > > Cc: Cyrus
> > > Cc: Timo Aaltonen
> > > Cc: José Roberto de Souza
> > > Signed-off-by: Imre Deak
> > > ---
> > > drivers/gpu/drm/i915/intel_pch.c | 6 +-
> > > drivers/gpu/drm/i915/intel_pch.h | 2 +-
> > > 2 files changed, 6 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_pch.c
> > > b/drivers/gpu/drm/i915/intel_pch.c
> > > index fd22355b9a96..43b68b5fc562 100644
> > > --- a/drivers/gpu/drm/i915/intel_pch.c
> > > +++ b/drivers/gpu/drm/i915/intel_pch.c
> > > @@ -62,7 +62,6 @@ intel_pch_type(const struct drm_i915_private *dev_priv,
> > > unsigned short id)
> > > /* KBP is SPT compatible */
> > > return PCH_SPT;
> > > case INTEL_PCH_CNP_DEVICE_ID_TYPE:
> > > - case INTEL_PCH_CNP2_DEVICE_ID_TYPE:
> > > DRM_DEBUG_KMS("Found Cannon Lake PCH (CNP)\n");
> > > WARN_ON(!IS_CANNONLAKE(dev_priv) && !IS_COFFEELAKE(dev_priv));
> > > return PCH_CNP;
> > > @@ -76,6 +75,11 @@ intel_pch_type(const struct drm_i915_private
> > > *dev_priv, unsigned short id)
> > > WARN_ON(!IS_COFFEELAKE(dev_priv));
> > > /* CometPoint is CNP Compatible */
> > > return PCH_CNP;
> > > + case INTEL_PCH_CMP_V_DEVICE_ID_TYPE:
> > > + DRM_DEBUG_KMS("Found Comet Lake V PCH (CMP-V)\n");
> > > + WARN_ON(!IS_COFFEELAKE(dev_priv));
> > > + /* Comet Lake V PCH is based on KBP, which is SPT compatible */
> > > + return PCH_SPT;
> > > case INTEL_PCH_ICP_DEVICE_ID_TYPE:
> > > DRM_DEBUG_KMS("Found Ice Lake PCH\n");
> > > WARN_ON(!IS_ICELAKE(dev_priv));
> > > diff --git a/drivers/gpu/drm/i915/intel_pch.h
> > > b/drivers/gpu/drm/i915/intel_pch.h
> > > index 52d145dcdb15..3053d1ce398b 100644
> > > --- a/drivers/gpu/drm/i915/intel_pch.h
> > > +++ b/drivers/gpu/drm/i915/intel_pch.h
> > > @@ -40,10 +40,10 @@ enum intel_pch {
> > > #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE 0x9D00
> > > #define INTEL_PCH_KBP_DEVICE_ID_TYPE 0xA280
> > > #define INTEL_PCH_CNP_DEVICE_ID_TYPE 0xA300
> > > -#define INTEL_PCH_CNP2_DEVICE_ID_TYPE0xA380
> > > #define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE 0x9D80
> > > #define INTEL_PCH_CMP_DEVICE_ID_TYPE 0x0280
> > > #define INTEL_PCH_CMP2_DEVICE_ID_TYPE0x0680
> > > +#define INTEL_PCH_CMP_V_DEVICE_ID_TYPE 0xA380
> > > #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480
> > > #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00
> > > #define INTEL_PCH_TGP_DEVICE_ID_TYPE 0xA080
> >
> > --
> > Jani Nikula, Intel Open Source Graphics Center
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Schedule request retirement when submission idles (rev2)
== Series Details ==
Series: drm/i915/gt: Schedule request retirement when submission idles (rev2)
URL : https://patchwork.freedesktop.org/series/69628/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a864196824b7 drm/i915/gt: Schedule request retirement when submission idles
-:25: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 7e34f4e4aad3 ("drm/i915/gen8+:
Add RC6 CTX corruption WA")'
#25:
References: 7e34f4e4aad3 ("drm/i915/gen8+: Add RC6 CTX corruption WA")
total: 1 errors, 0 warnings, 0 checks, 44 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gt: Unlock engine-pm after queuing the kernel context switch
In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
the backend"), I erroneously concluded that we last modify the engine
inside __i915_request_commit() meaning that we could enable concurrent
submission for userspace as we enqueued this request. However, this
falls into a trap with other users of the engine->kernel_context waking
up and submitting their request before the idle-switch is queued, with
the result that the kernel_context is executed out-of-sequence most
likely upsetting the GPU and certainly ourselves when we try to retire
the out-of-sequence requests.
As such we need to hold onto the effective engine->kernel_context mutex
lock (via the engine pm mutex proxy) until we have finish queuing the
request to the engine.
Fixes: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
backend")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 3c0f490ff2c7..2d2a21752ae4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -116,11 +116,12 @@ static bool switch_to_kernel_context(struct
intel_engine_cs *engine)
rq->sched.attr.priority = I915_PRIORITY_BARRIER;
__i915_request_commit(rq);
- /* Release our exclusive hold on the engine */
- __intel_wakeref_defer_park(&engine->wakeref);
__i915_request_queue(rq, NULL);
+ /* Release our exclusive hold on the engine */
+ __intel_wakeref_defer_park(&engine->wakeref);
result = false;
+
out_unlock:
__timeline_mark_unlock(engine->kernel_context, flags);
return result;
--
2.24.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] i915: Expose panel power cycle delay to i915_panel_timings
Putting down the AUX power domain reference count in edp vdd off async sequence takes too much of time (relative to panel power cycle delay) therefore it make sense to expose the panel power cycle delay to i915_panel_timings along with other delays. It can be use by DC state IGT to wait for strict power cycle delay in order to check for various DC state counters. Cc: Imre Deak Signed-off-by: Anshuman Gupta --- drivers/gpu/drm/i915/i915_debugfs.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index cab632791f73..c075cc2b7bb5 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -4436,6 +4436,8 @@ static int i915_panel_show(struct seq_file *m, void *data) intel_dp->panel_power_up_delay); seq_printf(m, "Panel power down delay: %d\n", intel_dp->panel_power_down_delay); + seq_printf(m, "Panel power cycle delay: %d\n", + intel_dp->panel_power_cycle_delay); seq_printf(m, "Backlight on delay: %d\n", intel_dp->backlight_on_delay); seq_printf(m, "Backlight off delay: %d\n", -- 2.24.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Schedule request retirement when submission idles (rev2)
== Series Details == Series: drm/i915/gt: Schedule request retirement when submission idles (rev2) URL : https://patchwork.freedesktop.org/series/69628/ State : failure == Summary == CI Bug Log - changes from CI_DRM_7363 -> Patchwork_15314 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_15314 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_15314, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_15314: ### IGT changes ### Possible regressions * igt@i915_selftest@live_execlists: - fi-bdw-5557u: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-bdw-5557u/igt@i915_selftest@live_execlists.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-bdw-5557u/igt@i915_selftest@live_execlists.html * igt@i915_selftest@live_gem_contexts: - fi-skl-lmem:[PASS][3] -> [TIMEOUT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-skl-lmem/igt@i915_selftest@live_gem_contexts.html - fi-whl-u: [PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-whl-u/igt@i915_selftest@live_gem_contexts.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-whl-u/igt@i915_selftest@live_gem_contexts.html - fi-skl-6770hq: [PASS][7] -> [TIMEOUT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-skl-6770hq/igt@i915_selftest@live_gem_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-skl-6770hq/igt@i915_selftest@live_gem_contexts.html * igt@i915_selftest@live_gt_contexts: - fi-kbl-soraka: [PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-kbl-soraka/igt@i915_selftest@live_gt_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-kbl-soraka/igt@i915_selftest@live_gt_contexts.html - fi-bsw-n3050: [PASS][11] -> [DMESG-FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-bsw-n3050/igt@i915_selftest@live_gt_contexts.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-bsw-n3050/igt@i915_selftest@live_gt_contexts.html * igt@i915_selftest@live_workarounds: - fi-cfl-8700k: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-cfl-8700k/igt@i915_selftest@live_workarounds.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-cfl-8700k/igt@i915_selftest@live_workarounds.html * igt@runner@aborted: - fi-kbl-soraka: NOTRUN -> [FAIL][15] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-kbl-soraka/igt@run...@aborted.html - fi-whl-u: NOTRUN -> [FAIL][16] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-whl-u/igt@run...@aborted.html - fi-cfl-8700k: NOTRUN -> [FAIL][17] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-cfl-8700k/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_15314 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-pci-d3-state: - fi-icl-dsi: [PASS][18] -> [INCOMPLETE][19] ([fdo#107713] / [fdo#108840]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-icl-dsi/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live_blt: - fi-hsw-peppy: [PASS][20] -> [DMESG-FAIL][21] ([fdo#112147]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-hsw-peppy/igt@i915_selftest@live_blt.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-hsw-peppy/igt@i915_selftest@live_blt.html * igt@i915_selftest@live_gem_contexts: - fi-icl-y: [PASS][22] -> [INCOMPLETE][23] ([fdo#107713]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-icl-y/igt@i915_selftest@live_gem_contexts.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_15314/fi-icl-y/igt@i915_selftest@live_gem_contexts.html - fi-icl-u3: [PASS][24] -> [INCOMPLETE][25] ([fdo#107713]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7363/fi-icl-u3/igt@i915_selftest@live_gem_contexts.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Pa
[Intel-gfx] [PATCH] drm/i915/ehl: Update voltage level checks
The bspec was recently updated with new cdclk -> voltage level tables to
accomodate the new 324/326.4 cdclk values.
Bspec: 21809
Cc: José Roberto de Souza
Cc: Vivek Kasireddy
Cc: Bob Paauwe
Signed-off-by: Matt Roper
---
There are some platform tagging issues on this bspec page and multiple
tables are actually tagged with the EHL label, but the bspec changelog
makes it pretty clear which table we're supposed to be using (plus the
other tables don't match the set of cdclks supported by the platform).
drivers/gpu/drm/i915/display/intel_cdclk.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 8b702317557e..7d1ab1e5b7c3 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1273,7 +1273,9 @@ static u8 icl_calc_voltage_level(int cdclk)
static u8 ehl_calc_voltage_level(int cdclk)
{
- if (cdclk > 312000)
+ if (cdclk > 326400)
+ return 3;
+ else if (cdclk > 312000)
return 2;
else if (cdclk > 18)
return 1;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/15] dma-buf: Remove kernel map/unmap hooks
On Mon, Nov 18, 2019 at 4:23 PM kbuild test robot wrote:
>
> Hi Daniel,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on drm-intel/for-linux-next]
> [also build test ERROR on v5.4-rc8 next-20191115]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
Too old tree, on latest drm-tip this compiles since udl has lots its
own dma-buf implementation. Also, the patch set will start to compile
once linux-next is open for 5.6.
Cheers, Daniel
>
> url:
> https://github.com/0day-ci/linux/commits/Daniel-Vetter/Retire-dma_buf_k-un-map/20191118-184537
> base: git://anongit.freedesktop.org/drm-intel for-linux-next
> config: m68k-allmodconfig (attached as .config)
> compiler: m68k-linux-gcc (GCC) 7.4.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> GCC_VERSION=7.4.0 make.cross ARCH=m68k
>
> If you fix the issue, kindly add following tag
> Reported-by: kbuild test robot
>
> All errors (new ones prefixed by >>):
>
> >> drivers/dma-buf/udmabuf.c:114:3: error: 'const struct dma_buf_ops' has no
> >> member named 'map'; did you mean 'mmap'?
> .map= kmap_udmabuf,
> ^~~
> mmap
> >> drivers/dma-buf/udmabuf.c:114:12: error: initialization from incompatible
> >> pointer type [-Werror=incompatible-pointer-types]
> .map= kmap_udmabuf,
>^~~~
>drivers/dma-buf/udmabuf.c:114:12: note: (near initialization for
> 'udmabuf_ops.begin_cpu_access')
> >> drivers/dma-buf/udmabuf.c:115:3: error: 'const struct dma_buf_ops' has no
> >> member named 'unmap'; did you mean 'vunmap'?
> .unmap= kunmap_udmabuf,
> ^
> vunmap
>drivers/dma-buf/udmabuf.c:115:14: error: initialization from incompatible
> pointer type [-Werror=incompatible-pointer-types]
> .unmap= kunmap_udmabuf,
> ^~
>drivers/dma-buf/udmabuf.c:115:14: note: (near initialization for
> 'udmabuf_ops.end_cpu_access')
>cc1: some warnings being treated as errors
> --
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:3: error: 'const struct dma_buf_ops'
> >> has no member named 'map'; did you mean 'mmap'?
> .map = udl_dmabuf_kmap,
> ^~~
> mmap
> >> drivers/gpu/drm/udl/udl_dmabuf.c:169:11: error: initialization from
> >> incompatible pointer type [-Werror=incompatible-pointer-types]
> .map = udl_dmabuf_kmap,
> ^~~
>drivers/gpu/drm/udl/udl_dmabuf.c:169:11: note: (near initialization for
> 'udl_dmabuf_ops.release')
> >> drivers/gpu/drm/udl/udl_dmabuf.c:170:3: error: 'const struct dma_buf_ops'
> >> has no member named 'unmap'; did you mean 'vunmap'?
> .unmap = udl_dmabuf_kunmap,
> ^
> vunmap
>drivers/gpu/drm/udl/udl_dmabuf.c:170:13: error: initialization from
> incompatible pointer type [-Werror=incompatible-pointer-types]
> .unmap = udl_dmabuf_kunmap,
> ^
>drivers/gpu/drm/udl/udl_dmabuf.c:170:13: note: (near initialization for
> 'udl_dmabuf_ops.begin_cpu_access')
>cc1: some warnings being treated as errors
>
> vim +114 drivers/dma-buf/udmabuf.c
>
> fbb0de79507819 Gerd Hoffmann 2018-08-27 109
> a34852891ba45d Gerd Hoffmann 2018-09-11 110 static const struct dma_buf_ops
> udmabuf_ops = {
> fbb0de79507819 Gerd Hoffmann 2018-08-27 111.map_dma_buf =
> map_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 112.unmap_dma_buf=
> unmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 113.release =
> release_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @114.map =
> kmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 @115.unmap=
> kunmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 116.mmap =
> mmap_udmabuf,
> fbb0de79507819 Gerd Hoffmann 2018-08-27 117 };
> fbb0de79507819 Gerd Hoffmann 2018-08-27 118
>
> :: The code at line 114 was first introduced by commit
> :: fbb0de795078190a9834b3409e4b009cfb18a6d4 Add udmabuf misc device
>
> :: TO: Gerd Hoffmann
> :: CC: Gerd Hoffmann
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org Intel Corporation
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 00/10] drm/i915: Cleanups around .crtc_enable/disable()
From: Ville Syrjälä Rebased for CI. All reviewed already. Ville Syrjälä (10): drm/i915: Change intel_encoders_() calling convention drm/i915: Add intel_crtc_vblank_off() drm/i915: Move assert_vblank_disabled() into intel_crtc_vblank_on() drm/i915: Move crtc_state to tighter scope drm/i915: Pass intel_crtc to ironlake_fdi_disable() drm/i915: Change watermark hook calling convention drm/i915: Pass dev_priv to cpt_verify_modeset() drm/i915: s/intel_crtc/crtc/ in .crtc_enable() and .crtc_disable() drm/i915: s/pipe_config/new_crtc_state/ in .crtc_enable() drm/i915: Change .crtc_enable/disable() calling convention drivers/gpu/drm/i915/display/intel_display.c | 459 +-- drivers/gpu/drm/i915/i915_drv.h | 14 +- drivers/gpu/drm/i915/intel_pm.c | 63 +-- 3 files changed, 271 insertions(+), 265 deletions(-) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 05/10] drm/i915: Pass intel_crtc to ironlake_fdi_disable()
From: Ville Syrjälä
Switch to intel_crtc from drm_crtc.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 084f94ec79a4..c873c85a69a7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5061,12 +5061,10 @@ static void ironlake_fdi_pll_disable(struct intel_crtc
*intel_crtc)
udelay(100);
}
-static void ironlake_fdi_disable(struct drm_crtc *crtc)
+static void ironlake_fdi_disable(struct intel_crtc *crtc)
{
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe;
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
i915_reg_t reg;
u32 temp;
@@ -6772,7 +6770,7 @@ static void ironlake_crtc_disable(struct intel_crtc_state
*old_crtc_state,
ironlake_pfit_disable(old_crtc_state);
if (old_crtc_state->has_pch_encoder)
- ironlake_fdi_disable(crtc);
+ ironlake_fdi_disable(intel_crtc);
intel_encoders_post_disable(state, intel_crtc);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 02/10] drm/i915: Add intel_crtc_vblank_off()
From: Ville Syrjälä
We already have intel_crtc_vblank_on(). Add a counterpart so we
don't have to inline the disable+assert all over.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 5d2ab40def8f..bf7faaf061a3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1843,6 +1843,12 @@ static void intel_crtc_vblank_on(const struct
intel_crtc_state *crtc_state)
drm_crtc_vblank_on(&crtc->base);
}
+static void intel_crtc_vblank_off(struct intel_crtc *crtc)
+{
+ drm_crtc_vblank_off(&crtc->base);
+ assert_vblank_disabled(&crtc->base);
+}
+
static void intel_enable_pipe(const struct intel_crtc_state *new_crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
@@ -6760,8 +6766,7 @@ static void ironlake_crtc_disable(struct intel_crtc_state
*old_crtc_state,
intel_encoders_disable(state, intel_crtc);
- drm_crtc_vblank_off(crtc);
- assert_vblank_disabled(crtc);
+ intel_crtc_vblank_off(intel_crtc);
intel_disable_pipe(old_crtc_state);
@@ -6810,8 +6815,7 @@ static void haswell_crtc_disable(struct intel_crtc_state
*old_crtc_state,
intel_encoders_disable(state, intel_crtc);
- drm_crtc_vblank_off(crtc);
- assert_vblank_disabled(crtc);
+ intel_crtc_vblank_off(intel_crtc);
/* XXX: Do the pipe assertions at the right place for BXT DSI. */
if (!transcoder_is_dsi(cpu_transcoder))
@@ -7184,8 +7188,7 @@ static void i9xx_crtc_disable(struct intel_crtc_state
*old_crtc_state,
intel_encoders_disable(state, intel_crtc);
- drm_crtc_vblank_off(crtc);
- assert_vblank_disabled(crtc);
+ intel_crtc_vblank_off(intel_crtc);
intel_disable_pipe(old_crtc_state);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 04/10] drm/i915: Move crtc_state to tighter scope
From: Ville Syrjälä
intel_modeset_setup_hw_state() doesn't need the crtc_state at the
top level scope. Move it to where it's needed.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 854ccca2bf6e..084f94ec79a4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17785,7 +17785,6 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
struct drm_modeset_acquire_ctx *ctx)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc_state *crtc_state;
struct intel_encoder *encoder;
struct intel_crtc *crtc;
intel_wakeref_t wakeref;
@@ -17818,7 +17817,8 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
* waits, so we need vblank interrupts restored beforehand.
*/
for_each_intel_crtc(&dev_priv->drm, crtc) {
- crtc_state = to_intel_crtc_state(crtc->base.state);
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
drm_crtc_vblank_reset(&crtc->base);
@@ -17832,7 +17832,9 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
intel_sanitize_encoder(encoder);
for_each_intel_crtc(&dev_priv->drm, crtc) {
- crtc_state = to_intel_crtc_state(crtc->base.state);
+ struct intel_crtc_state *crtc_state =
+ crtc_state = to_intel_crtc_state(crtc->base.state);
+
intel_sanitize_crtc(crtc, ctx);
intel_dump_pipe_config(crtc_state, NULL, "[setup_hw_state]");
}
@@ -17865,9 +17867,10 @@ intel_modeset_setup_hw_state(struct drm_device *dev,
}
for_each_intel_crtc(dev, crtc) {
+ struct intel_crtc_state *crtc_state =
+ to_intel_crtc_state(crtc->base.state);
u64 put_domains;
- crtc_state = to_intel_crtc_state(crtc->base.state);
put_domains = modeset_get_crtc_power_domains(crtc_state);
if (WARN_ON(put_domains))
modeset_put_power_domains(dev_priv, put_domains);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 06/10] drm/i915: Change watermark hook calling convention
From: Ville Syrjälä
Just pass the atomic_state+crtc to the watermarks hooks. Eeasier
time for the caller when it doesn't have to think what to pass.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 32 +-
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/intel_pm.c | 63 +++-
3 files changed, 53 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c873c85a69a7..68a7e5d467ff 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6189,9 +6189,8 @@ static void intel_pre_plane_update(struct
intel_crtc_state *old_crtc_state,
* we'll continue to update watermarks the old way, if flags tell
* us to.
*/
- if (dev_priv->display.initial_watermarks != NULL)
- dev_priv->display.initial_watermarks(intel_state,
-pipe_config);
+ if (dev_priv->display.initial_watermarks)
+ dev_priv->display.initial_watermarks(intel_state, crtc);
else if (pipe_config->update_wm_pre)
intel_update_watermarks(crtc);
}
@@ -6539,8 +6538,8 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
/* update DSPCNTR to configure gamma for pipe bottom color */
intel_disable_primary_plane(pipe_config);
- if (dev_priv->display.initial_watermarks != NULL)
- dev_priv->display.initial_watermarks(state, pipe_config);
+ if (dev_priv->display.initial_watermarks)
+ dev_priv->display.initial_watermarks(state, intel_crtc);
intel_enable_pipe(pipe_config);
if (pipe_config->has_pch_encoder)
@@ -6698,8 +6697,8 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_enable_transcoder_func(pipe_config);
- if (dev_priv->display.initial_watermarks != NULL)
- dev_priv->display.initial_watermarks(state, pipe_config);
+ if (dev_priv->display.initial_watermarks)
+ dev_priv->display.initial_watermarks(state, intel_crtc);
if (INTEL_GEN(dev_priv) >= 11)
icl_pipe_mbus_enable(intel_crtc);
@@ -7083,7 +7082,7 @@ static void valleyview_crtc_enable(struct
intel_crtc_state *pipe_config,
/* update DSPCNTR to configure gamma for pipe bottom color */
intel_disable_primary_plane(pipe_config);
- dev_priv->display.initial_watermarks(state, pipe_config);
+ dev_priv->display.initial_watermarks(state, intel_crtc);
intel_enable_pipe(pipe_config);
intel_crtc_vblank_on(pipe_config);
@@ -7138,9 +7137,8 @@ static void i9xx_crtc_enable(struct intel_crtc_state
*pipe_config,
/* update DSPCNTR to configure gamma for pipe bottom color */
intel_disable_primary_plane(pipe_config);
- if (dev_priv->display.initial_watermarks != NULL)
- dev_priv->display.initial_watermarks(state,
-pipe_config);
+ if (dev_priv->display.initial_watermarks)
+ dev_priv->display.initial_watermarks(state, intel_crtc);
else
intel_update_watermarks(intel_crtc);
intel_enable_pipe(pipe_config);
@@ -14316,6 +14314,7 @@ static void commit_pipe_config(struct
intel_atomic_state *state,
struct intel_crtc_state *old_crtc_state,
struct intel_crtc_state *new_crtc_state)
{
+ struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(state->base.dev);
bool modeset = needs_modeset(new_crtc_state);
@@ -14339,8 +14338,7 @@ static void commit_pipe_config(struct
intel_atomic_state *state,
}
if (dev_priv->display.atomic_update_watermarks)
- dev_priv->display.atomic_update_watermarks(state,
- new_crtc_state);
+ dev_priv->display.atomic_update_watermarks(state, crtc);
}
static void intel_update_crtc(struct intel_crtc *crtc,
@@ -1,8 +14442,7 @@ static void intel_old_crtc_state_disables(struct
intel_atomic_state *state,
if (!new_crtc_state->hw.active &&
!HAS_GMCH(dev_priv) &&
dev_priv->display.initial_watermarks)
- dev_priv->display.initial_watermarks(state,
-new_crtc_state);
+ dev_priv->display.initial_watermarks(state, crtc);
}
static void intel_trans_port_sync_modeset_disables(struct intel_atomic_state
*state,
@@ -14895,8 +14892,7 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
*/
for_each_ne
[Intel-gfx] [PATCH v2 09/10] drm/i915: s/pipe_config/new_crtc_state/ in .crtc_enable()
From: Ville Syrjälä
Rename pipe_config to new_crtc_state in the .crtc_enable() hooks.
The 'pipe_config' name is a zombie that we need to finally put down.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 173 +--
1 file changed, 85 insertions(+), 88 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index d6ad32179a17..27204a499f93 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6472,10 +6472,10 @@ static void intel_disable_primary_plane(const struct
intel_crtc_state *crtc_stat
plane->disable_plane(plane, crtc_state);
}
-static void ironlake_crtc_enable(struct intel_crtc_state *pipe_config,
+static void ironlake_crtc_enable(struct intel_crtc_state *new_crtc_state,
struct intel_atomic_state *state)
{
- struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
+ struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
@@ -6495,55 +6495,54 @@ static void ironlake_crtc_enable(struct
intel_crtc_state *pipe_config,
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, false);
- if (pipe_config->has_pch_encoder)
- intel_prepare_shared_dpll(pipe_config);
+ if (new_crtc_state->has_pch_encoder)
+ intel_prepare_shared_dpll(new_crtc_state);
- if (intel_crtc_has_dp_encoder(pipe_config))
- intel_dp_set_m_n(pipe_config, M1_N1);
+ if (intel_crtc_has_dp_encoder(new_crtc_state))
+ intel_dp_set_m_n(new_crtc_state, M1_N1);
- intel_set_pipe_timings(pipe_config);
- intel_set_pipe_src_size(pipe_config);
+ intel_set_pipe_timings(new_crtc_state);
+ intel_set_pipe_src_size(new_crtc_state);
- if (pipe_config->has_pch_encoder) {
- intel_cpu_transcoder_set_m_n(pipe_config,
-&pipe_config->fdi_m_n, NULL);
- }
+ if (new_crtc_state->has_pch_encoder)
+ intel_cpu_transcoder_set_m_n(new_crtc_state,
+&new_crtc_state->fdi_m_n, NULL);
- ironlake_set_pipeconf(pipe_config);
+ ironlake_set_pipeconf(new_crtc_state);
crtc->active = true;
intel_encoders_pre_enable(state, crtc);
- if (pipe_config->has_pch_encoder) {
+ if (new_crtc_state->has_pch_encoder) {
/* Note: FDI PLL enabling _must_ be done before we enable the
* cpu pipes, hence this is separate from all the other fdi/pch
* enabling. */
- ironlake_fdi_pll_enable(pipe_config);
+ ironlake_fdi_pll_enable(new_crtc_state);
} else {
assert_fdi_tx_disabled(dev_priv, pipe);
assert_fdi_rx_disabled(dev_priv, pipe);
}
- ironlake_pfit_enable(pipe_config);
+ ironlake_pfit_enable(new_crtc_state);
/*
* On ILK+ LUT must be loaded before the pipe is running but with
* clocks enabled
*/
- intel_color_load_luts(pipe_config);
- intel_color_commit(pipe_config);
+ intel_color_load_luts(new_crtc_state);
+ intel_color_commit(new_crtc_state);
/* update DSPCNTR to configure gamma for pipe bottom color */
- intel_disable_primary_plane(pipe_config);
+ intel_disable_primary_plane(new_crtc_state);
if (dev_priv->display.initial_watermarks)
dev_priv->display.initial_watermarks(state, crtc);
- intel_enable_pipe(pipe_config);
+ intel_enable_pipe(new_crtc_state);
- if (pipe_config->has_pch_encoder)
- ironlake_pch_enable(state, pipe_config);
+ if (new_crtc_state->has_pch_encoder)
+ ironlake_pch_enable(state, new_crtc_state);
- intel_crtc_vblank_on(pipe_config);
+ intel_crtc_vblank_on(new_crtc_state);
intel_encoders_enable(state, crtc);
@@ -6556,7 +6555,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
* some interlaced HDMI modes. Let's do the double wait always
* in case there are more corner cases we don't know about.
*/
- if (pipe_config->has_pch_encoder) {
+ if (new_crtc_state->has_pch_encoder) {
intel_wait_for_vblank(dev_priv, pipe);
intel_wait_for_vblank(dev_priv, pipe);
}
@@ -6616,13 +6615,13 @@ static void hsw_set_frame_start_delay(const struct
intel_crtc_state *crtc_state)
I915_WRITE(reg, val);
}
-static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
+static void haswell_crtc_enable(struct intel_crtc_state *new_c
[Intel-gfx] [PATCH v2 01/10] drm/i915: Change intel_encoders_() calling convention
From: Ville Syrjälä
Just pass the atomic state and the crtc to intel_encoders_enable() & co.
Make life simpler when you don't have to think which state (old vs. new)
you have to pass in. Also constify the states while at it.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 101 ++-
1 file changed, 54 insertions(+), 47 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 23f00a651738..5d2ab40def8f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6311,11 +6311,12 @@ static void intel_encoders_update_complete(struct
intel_atomic_state *state)
}
}
-static void intel_encoders_pre_pll_enable(struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state,
- struct intel_atomic_state *state)
+static void intel_encoders_pre_pll_enable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
- struct drm_connector_state *conn_state;
+ const struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ const struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
@@ -6331,11 +6332,12 @@ static void intel_encoders_pre_pll_enable(struct
intel_crtc *crtc,
}
}
-static void intel_encoders_pre_enable(struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state,
- struct intel_atomic_state *state)
+static void intel_encoders_pre_enable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
- struct drm_connector_state *conn_state;
+ const struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ const struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
@@ -6351,11 +6353,12 @@ static void intel_encoders_pre_enable(struct intel_crtc
*crtc,
}
}
-static void intel_encoders_enable(struct intel_crtc *crtc,
- struct intel_crtc_state *crtc_state,
- struct intel_atomic_state *state)
+static void intel_encoders_enable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
- struct drm_connector_state *conn_state;
+ const struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+ const struct drm_connector_state *conn_state;
struct drm_connector *conn;
int i;
@@ -6372,11 +6375,12 @@ static void intel_encoders_enable(struct intel_crtc
*crtc,
}
}
-static void intel_encoders_disable(struct intel_crtc *crtc,
- struct intel_crtc_state *old_crtc_state,
- struct intel_atomic_state *state)
+static void intel_encoders_disable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
- struct drm_connector_state *old_conn_state;
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(state, crtc);
+ const struct drm_connector_state *old_conn_state;
struct drm_connector *conn;
int i;
@@ -6393,11 +6397,12 @@ static void intel_encoders_disable(struct intel_crtc
*crtc,
}
}
-static void intel_encoders_post_disable(struct intel_crtc *crtc,
- struct intel_crtc_state *old_crtc_state,
- struct intel_atomic_state *state)
+static void intel_encoders_post_disable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
- struct drm_connector_state *old_conn_state;
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(state, crtc);
+ const struct drm_connector_state *old_conn_state;
struct drm_connector *conn;
int i;
@@ -6413,11 +6418,12 @@ static void intel_encoders_post_disable(struct
intel_crtc *crtc,
}
}
-static void intel_encoders_post_pll_disable(struct intel_crtc *crtc,
- struct intel_crtc_state
*old_crtc_state,
- struct intel_atomic_state *state)
+static void intel_encoders_post_pll_disable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
- struct drm_connector_state *old_conn_state;
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(state, crtc);
+ const struct drm_conn
[Intel-gfx] [PATCH v2 07/10] drm/i915: Pass dev_priv to cpt_verify_modeset()
From: Ville Syrjälä
Get rid of the last 'dev' usage in ironlake_crtc_enable() by
passing dev_priv to cpt_verify_modeset().
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 68a7e5d467ff..556b31bf2fb0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -5474,9 +5474,9 @@ static void lpt_pch_enable(const struct
intel_atomic_state *state,
lpt_enable_pch_transcoder(dev_priv, cpu_transcoder);
}
-static void cpt_verify_modeset(struct drm_device *dev, enum pipe pipe)
+static void cpt_verify_modeset(struct drm_i915_private *dev_priv,
+ enum pipe pipe)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
i915_reg_t dslreg = PIPEDSL(pipe);
u32 temp;
@@ -6550,7 +6550,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_encoders_enable(state, intel_crtc);
if (HAS_PCH_CPT(dev_priv))
- cpt_verify_modeset(dev, intel_crtc->pipe);
+ cpt_verify_modeset(dev_priv, pipe);
/*
* Must wait for vblank to avoid spurious PCH FIFO underruns.
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 08/10] drm/i915: s/intel_crtc/crtc/ in .crtc_enable() and .crtc_disable()
From: Ville Syrjälä
Get rid of the horrible aliasing drm_crtc and intel_crtc variables
in the crtc enable/disable hooks.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 142 +--
1 file changed, 65 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 556b31bf2fb0..d6ad32179a17 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6475,13 +6475,11 @@ static void intel_disable_primary_plane(const struct
intel_crtc_state *crtc_stat
static void ironlake_crtc_enable(struct intel_crtc_state *pipe_config,
struct intel_atomic_state *state)
{
- struct drm_crtc *crtc = pipe_config->uapi.crtc;
- struct drm_device *dev = crtc->dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe;
+ struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
- if (WARN_ON(intel_crtc->active))
+ if (WARN_ON(crtc->active))
return;
/*
@@ -6513,9 +6511,9 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
ironlake_set_pipeconf(pipe_config);
- intel_crtc->active = true;
+ crtc->active = true;
- intel_encoders_pre_enable(state, intel_crtc);
+ intel_encoders_pre_enable(state, crtc);
if (pipe_config->has_pch_encoder) {
/* Note: FDI PLL enabling _must_ be done before we enable the
@@ -6539,7 +6537,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_disable_primary_plane(pipe_config);
if (dev_priv->display.initial_watermarks)
- dev_priv->display.initial_watermarks(state, intel_crtc);
+ dev_priv->display.initial_watermarks(state, crtc);
intel_enable_pipe(pipe_config);
if (pipe_config->has_pch_encoder)
@@ -6547,7 +6545,7 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_crtc_vblank_on(pipe_config);
- intel_encoders_enable(state, intel_crtc);
+ intel_encoders_enable(state, crtc);
if (HAS_PCH_CPT(dev_priv))
cpt_verify_modeset(dev_priv, pipe);
@@ -6621,22 +6619,21 @@ static void hsw_set_frame_start_delay(const struct
intel_crtc_state *crtc_state)
static void haswell_crtc_enable(struct intel_crtc_state *pipe_config,
struct intel_atomic_state *state)
{
- struct drm_crtc *crtc = pipe_config->uapi.crtc;
- struct drm_i915_private *dev_priv = to_i915(crtc->dev);
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- enum pipe pipe = intel_crtc->pipe, hsw_workaround_pipe;
+ struct intel_crtc *crtc = to_intel_crtc(pipe_config->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
enum transcoder cpu_transcoder = pipe_config->cpu_transcoder;
bool psl_clkgate_wa;
- if (WARN_ON(intel_crtc->active))
+ if (WARN_ON(crtc->active))
return;
- intel_encoders_pre_pll_enable(state, intel_crtc);
+ intel_encoders_pre_pll_enable(state, crtc);
if (pipe_config->shared_dpll)
intel_enable_shared_dpll(pipe_config);
- intel_encoders_pre_enable(state, intel_crtc);
+ intel_encoders_pre_enable(state, crtc);
if (intel_crtc_has_dp_encoder(pipe_config))
intel_dp_set_m_n(pipe_config, M1_N1);
@@ -6668,7 +6665,7 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
bdw_set_pipemisc(pipe_config);
- intel_crtc->active = true;
+ crtc->active = true;
/* Display WA #1180: WaDisableScalarClockGating: glk, cnl */
psl_clkgate_wa = (IS_GEMINILAKE(dev_priv) || IS_CANNONLAKE(dev_priv)) &&
@@ -6692,16 +6689,16 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_disable_primary_plane(pipe_config);
if (INTEL_GEN(dev_priv) >= 11)
- icl_set_pipe_chicken(intel_crtc);
+ icl_set_pipe_chicken(crtc);
if (!transcoder_is_dsi(cpu_transcoder))
intel_ddi_enable_transcoder_func(pipe_config);
if (dev_priv->display.initial_watermarks)
- dev_priv->display.initial_watermarks(state, intel_crtc);
+ dev_priv->display.initial_watermarks(state, crtc);
if (INTEL_GEN(dev_priv) >= 11)
- icl_pipe_mbus_enable(intel_crtc);
+ icl_pipe_mbus_enable(crtc)
[Intel-gfx] [PATCH v2 03/10] drm/i915: Move assert_vblank_disabled() into intel_crtc_vblank_on()
From: Ville Syrjälä
Move the assert_vblank_disabled() into intel_crtc_vblank_on()
so that we don't have to inline it all over.
This does mean we now assert_vblank_disabled() during readout as well
but that is totally fine as it happens after drm_crtc_vblank_reset().
One can even argue it's what we want to do anyway to make sure
the reset actually happened.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index bf7faaf061a3..854ccca2bf6e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1838,6 +1838,7 @@ static void intel_crtc_vblank_on(const struct
intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ assert_vblank_disabled(&crtc->base);
drm_crtc_set_max_vblank_count(&crtc->base,
intel_crtc_max_vblank_count(crtc_state));
drm_crtc_vblank_on(&crtc->base);
@@ -6547,7 +6548,6 @@ static void ironlake_crtc_enable(struct intel_crtc_state
*pipe_config,
if (pipe_config->has_pch_encoder)
ironlake_pch_enable(state, pipe_config);
- assert_vblank_disabled(crtc);
intel_crtc_vblank_on(pipe_config);
intel_encoders_enable(state, intel_crtc);
@@ -6713,7 +6713,6 @@ static void haswell_crtc_enable(struct intel_crtc_state
*pipe_config,
if (pipe_config->has_pch_encoder)
lpt_pch_enable(state, pipe_config);
- assert_vblank_disabled(crtc);
intel_crtc_vblank_on(pipe_config);
intel_encoders_enable(state, intel_crtc);
@@ -7089,7 +7088,6 @@ static void valleyview_crtc_enable(struct
intel_crtc_state *pipe_config,
dev_priv->display.initial_watermarks(state, pipe_config);
intel_enable_pipe(pipe_config);
- assert_vblank_disabled(crtc);
intel_crtc_vblank_on(pipe_config);
intel_encoders_enable(state, intel_crtc);
@@ -7149,7 +7147,6 @@ static void i9xx_crtc_enable(struct intel_crtc_state
*pipe_config,
intel_update_watermarks(intel_crtc);
intel_enable_pipe(pipe_config);
- assert_vblank_disabled(crtc);
intel_crtc_vblank_on(pipe_config);
intel_encoders_enable(state, intel_crtc);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 10/10] drm/i915: Change .crtc_enable/disable() calling convention
From: Ville Syrjälä
Just pass the atomic state+crtc to the .crtc_enable()
.crtc_disable(). Life is easier when you don't have to think
whether to pass the old or the new crtc state.
Reviewed-by: Manasi Navare
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 58 +++-
drivers/gpu/drm/i915/i915_drv.h | 8 +--
2 files changed, 37 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 27204a499f93..cbe5ceea20fa 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -6472,10 +6472,11 @@ static void intel_disable_primary_plane(const struct
intel_crtc_state *crtc_stat
plane->disable_plane(plane, crtc_state);
}
-static void ironlake_crtc_enable(struct intel_crtc_state *new_crtc_state,
-struct intel_atomic_state *state)
+static void ironlake_crtc_enable(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+ const struct intel_crtc_state *new_crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
@@ -6615,10 +6616,11 @@ static void hsw_set_frame_start_delay(const struct
intel_crtc_state *crtc_state)
I915_WRITE(reg, val);
}
-static void haswell_crtc_enable(struct intel_crtc_state *new_crtc_state,
- struct intel_atomic_state *state)
+static void haswell_crtc_enable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+ const struct intel_crtc_state *new_crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe, hsw_workaround_pipe;
enum transcoder cpu_transcoder = new_crtc_state->cpu_transcoder;
@@ -6737,10 +6739,11 @@ static void ironlake_pfit_disable(const struct
intel_crtc_state *old_crtc_state)
}
}
-static void ironlake_crtc_disable(struct intel_crtc_state *old_crtc_state,
- struct intel_atomic_state *state)
+static void ironlake_crtc_disable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
@@ -6793,10 +6796,11 @@ static void ironlake_crtc_disable(struct
intel_crtc_state *old_crtc_state,
intel_set_pch_fifo_underrun_reporting(dev_priv, pipe, true);
}
-static void haswell_crtc_disable(struct intel_crtc_state *old_crtc_state,
-struct intel_atomic_state *state)
+static void haswell_crtc_disable(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->uapi.crtc);
+ const struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum transcoder cpu_transcoder = old_crtc_state->cpu_transcoder;
@@ -7025,10 +7029,11 @@ static void modeset_put_power_domains(struct
drm_i915_private *dev_priv,
intel_display_power_put_unchecked(dev_priv, domain);
}
-static void valleyview_crtc_enable(struct intel_crtc_state *new_crtc_state,
- struct intel_atomic_state *state)
+static void valleyview_crtc_enable(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+ const struct intel_crtc_state *new_crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
enum pipe pipe = crtc->pipe;
@@ -7088,10 +7093,11 @@ static void i9xx_set_pll_dividers(const struct
intel_crtc_state *crtc_state)
I915_WRITE(FP1(crtc->pipe), crtc_state->dpll_hw_state.fp1);
}
-static void i9xx_crtc_enable(struct intel_crtc_state *new_crtc_state,
-struct intel_atomic_state *state)
+static void i9xx_crtc_enable(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
{
- struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+ const struct intel_crtc_state *new_crtc_s
Re: [Intel-gfx] [PATCH] drm/i915/ehl: Update voltage level checks
On Mon, Nov 18, 2019 at 08:44:12AM -0800, Matt Roper wrote:
> The bspec was recently updated with new cdclk -> voltage level tables to
> accomodate the new 324/326.4 cdclk values.
>
> Bspec: 21809
> Cc: José Roberto de Souza
> Cc: Vivek Kasireddy
> Cc: Bob Paauwe
> Signed-off-by: Matt Roper
And
Fixes: 63c9dae71dc5 ("drm/i915/ehl: Add voltage level requirement table")
since using the old table could result in us requesting too low a
voltage level for the highest cdclk values.
Matt
> ---
> There are some platform tagging issues on this bspec page and multiple
> tables are actually tagged with the EHL label, but the bspec changelog
> makes it pretty clear which table we're supposed to be using (plus the
> other tables don't match the set of cdclks supported by the platform).
>
> drivers/gpu/drm/i915/display/intel_cdclk.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 8b702317557e..7d1ab1e5b7c3 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1273,7 +1273,9 @@ static u8 icl_calc_voltage_level(int cdclk)
>
> static u8 ehl_calc_voltage_level(int cdclk)
> {
> - if (cdclk > 312000)
> + if (cdclk > 326400)
> + return 3;
> + else if (cdclk > 312000)
> return 2;
> else if (cdclk > 18)
> return 1;
> --
> 2.21.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gt: Unlock engine-pm after queuing the kernel context switch
Quoting Chris Wilson (2019-11-18 16:23:42)
> In commit a79ca656b648 ("drm/i915: Push the wakeref->count deferral to
> the backend"), I erroneously concluded that we last modify the engine
> inside __i915_request_commit() meaning that we could enable concurrent
> submission for userspace as we enqueued this request. However, this
> falls into a trap with other users of the engine->kernel_context waking
> up and submitting their request before the idle-switch is queued, with
> the result that the kernel_context is executed out-of-sequence most
> likely upsetting the GPU and certainly ourselves when we try to retire
> the out-of-sequence requests.
>
> As such we need to hold onto the effective engine->kernel_context mutex
> lock (via the engine pm mutex proxy) until we have finish queuing the
> request to the engine.
>
> Fixes: a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the
> backend")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 3c0f490ff2c7..2d2a21752ae4 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -116,11 +116,12 @@ static bool switch_to_kernel_context(struct
> intel_engine_cs *engine)
> rq->sched.attr.priority = I915_PRIORITY_BARRIER;
> __i915_request_commit(rq);
>
> - /* Release our exclusive hold on the engine */
> - __intel_wakeref_defer_park(&engine->wakeref);
> __i915_request_queue(rq, NULL);
>
> + /* Release our exclusive hold on the engine */
> + __intel_wakeref_defer_park(&engine->wakeref);
> result = false;
Gah, now I remember why I put it before:
if there is a concurrent retire requests, it may now see the request
completion prior to us marking the engine as awake => counter underflow.
Watch this space for more tricks :(
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v7] drm/i915: Enable second dbuf slice for ICL and TGL
On Mon, 2019-11-18 at 17:27 +0200, Ville Syrjälä wrote: > On Mon, Nov 18, 2019 at 09:19:18AM +, Lisovskiy, Stanislav wrote: > > On Fri, 2019-11-15 at 22:19 +0200, Ville Syrjälä wrote: > > > On Thu, Nov 14, 2019 at 02:24:49PM +0200, Stanislav Lisovskiy > > > wrote: > > > > Also implemented algorithm for choosing DBuf slice > > > > configuration > > > > based on active pipes, pipe ratio as stated in BSpec 12716. > > > > > > > > Now pipe allocation still stays proportional to pipe width as > > > > before, > > > > however within allowed DBuf slice for this particular > > > > configuration. > > > > > > > > v2: Remove unneeded check from commit as ddb enabled slices > > > > might > > > > now differ from hw state. > > > > > > > > v3: - Added new field "supported_slices" to ddb to separate max > > > > supported slices vs currently enabled, to avoid > > > > confusion. > > > > - Removed obsolete comments and code related to > > > > DBuf(Matthew > > > > Roper). > > > > - Some code style and long line removal(Matthew Roper). > > > > - Added WARN_ON to new ddb range offset calc > > > > function(Matthew > > > > Roper). > > > > - Removed platform specific call to calc pipe ratio from > > > > ddb > > > > allocation function and fixed the return value(Matthew > > > > Roper) > > > > - Refactored DBUF slice allocation table to improve > > > > readability > > > > - Added DBUF slice allocation for TGL as well. > > > > - ICL(however not TGL) seems to voluntarily enable second > > > > DBuf > > > > slice > > > > after pm suspend/resume causing a mismatch failure, > > > > because > > > > we > > > > update DBuf slices only if we do a modeset, however this > > > > check > > > > is done always. Fixed it to be done only when modeset for > > > > ICL. > > > > > > > > v4: - Now enabled slices is not actually a number, but a > > > > bitmask, > > > > because we might need to enable second slice only and > > > > number > > > > of slices would still 1 and that current code doesn't > > > > allow. > > > > - Remove redundant duplicate code to have some unified way > > > > of > > > > enabling dbuf slices instead of hardcoding. > > > > > > > > v5: - Fix failing gen9_assert_dbuf_enabled as it was naively > > > > thinking > > > > that we have only one DBUF_CTL slice. Now another version > > > > for > > > > gen11 will check both slices as only second one can be > > > > enabled, > > > > to keep CI happy. > > > > > > > > v6: - Removed enabled dbuf assertion completely. Previous code > > > > was keeping dbuf enabled, even(!) when _dbuf_disable is > > > > called. > > > > Currently we enable/disable dbuf slices based on > > > > requrement > > > > so no point in asserting this here. > > > > - Removed unnecessary modeset check from > > > > verify_wm_state(Matthew Roper) > > > > - Slices intersection after union is same as final > > > > result(Matthew Roper) > > > > - Moved DBuf slices to intel_device_info(Matthew Roper) > > > > - Some macros added(Matthew Roper) > > > > - ddb range is now always less or equal to ddb size - no > > > > need > > > > for additional > > > > checks(previously needed as we had some bandwidth checks > > > > in > > > > there which > > > > could "suddenly" return ddb_size smaller than it is. > > > > > > > > v7: Minor costemic changes: > > > > - Changed icl_dbuf_slices_restore name to > > > > icl_program_dbuf_slices > > > > as it more corresponds to the actual functionality. > > > > - Some simplification with supported slices for BXT and GLK > > > > - skl_pipe_downscale_amount -> icl_pipe_downscale_amount as > > > > this is not used for skl anymore. > > > > - Changed DBuf slice assignment order for TGL case > > > > > > > > Reviewed-by: Matthew Roper > > > > Signed-off-by: Stanislav Lisovskiy < > > > > stanislav.lisovs...@intel.com> > > > > Cc: Matthew Roper > > > > Cc: Ville Syrjälä > > > > Cc: James Ausmus > > > > --- > > > > drivers/gpu/drm/i915/display/intel_display.c | 26 +- > > > > .../drm/i915/display/intel_display_power.c| 98 ++--- > > > > .../drm/i915/display/intel_display_power.h| 2 + > > > > drivers/gpu/drm/i915/i915_drv.c | 5 + > > > > drivers/gpu/drm/i915/i915_drv.h | 2 +- > > > > drivers/gpu/drm/i915/i915_pci.c | 6 +- > > > > drivers/gpu/drm/i915/i915_reg.h | 8 +- > > > > drivers/gpu/drm/i915/intel_device_info.h | 1 + > > > > drivers/gpu/drm/i915/intel_pm.c | 387 > > > > -- > > > > 9 files changed, 431 insertions(+), 104 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > > > > b/drivers/gpu/drm/i915/display/intel_display.c > > > > index 876fc25968bf..bd7aff675198 100644 > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c > > > > +++ b/drivers/gpu/drm/i915/displa
Re: [Intel-gfx] [PATCH 02/11] drm/i915: Remove hw.mode
On Thu, Nov 14, 2019 at 05:05:13PM +0100, Maarten Lankhorst wrote:
> The members in hw.mode can be used from adjusted_mode as well,
> use that when available.
>
> Some places that use hw.mode can be converted to use adjusted_mode
> as well.
>
> Signed-off-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 49 ++-
> .../drm/i915/display/intel_display_types.h| 2 +-
> drivers/gpu/drm/i915/display/intel_dvo.c | 2 +-
> drivers/gpu/drm/i915/display/intel_sdvo.c | 16 +++---
> 4 files changed, 34 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index adf50c4b38ad..18acecc3642d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8440,9 +8440,6 @@ static void intel_get_pipe_src_size(struct intel_crtc
> *crtc,
> tmp = I915_READ(PIPESRC(crtc->pipe));
> pipe_config->pipe_src_h = (tmp & 0x) + 1;
> pipe_config->pipe_src_w = ((tmp >> 16) & 0x) + 1;
> -
> - pipe_config->hw.mode.vdisplay = pipe_config->pipe_src_h;
> - pipe_config->hw.mode.hdisplay = pipe_config->pipe_src_w;
> }
>
> void intel_mode_from_pipe_config(struct drm_display_mode *mode,
> @@ -12098,8 +12095,8 @@ static int icl_add_sync_mode_crtcs(struct
> intel_crtc_state *crtc_state)
> continue;
> if (!connector->has_tile)
> continue;
> - if (crtc_state->hw.mode.hdisplay != connector->tile_h_size ||
> - crtc_state->hw.mode.vdisplay != connector->tile_v_size)
> + if (crtc_state->hw.adjusted_mode.crtc_hdisplay !=
> connector->tile_h_size ||
> + crtc_state->hw.adjusted_mode.crtc_vdisplay !=
> connector->tile_v_size)
Using adjusted_mode before .compute_config() seems like a bad idea.
> return 0;
> if (connector->tile_h_loc == connector->num_h_tile - 1 &&
> connector->tile_v_loc == connector->num_v_tile - 1)
> @@ -12506,7 +12503,7 @@ static void intel_dump_pipe_config(const struct
> intel_crtc_state *pipe_config,
> intel_dump_infoframe(dev_priv, &pipe_config->infoframes.hdmi);
>
> DRM_DEBUG_KMS("requested mode:\n");
> - drm_mode_debug_printmodeline(&pipe_config->hw.mode);
> + drm_mode_debug_printmodeline(&pipe_config->uapi.mode);
> DRM_DEBUG_KMS("adjusted mode:\n");
> drm_mode_debug_printmodeline(&pipe_config->hw.adjusted_mode);
> intel_dump_crtc_timings(&pipe_config->hw.adjusted_mode);
> @@ -12640,16 +12637,16 @@ intel_crtc_copy_uapi_to_hw_state(struct
> intel_crtc_state *crtc_state)
> {
> crtc_state->hw.enable = crtc_state->uapi.enable;
> crtc_state->hw.active = crtc_state->uapi.active;
> - crtc_state->hw.mode = crtc_state->uapi.mode;
> crtc_state->hw.adjusted_mode = crtc_state->uapi.adjusted_mode;
> intel_crtc_copy_uapi_to_hw_state_nomodeset(crtc_state);
> }
>
> -static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
> *crtc_state)
> +static void intel_crtc_copy_hw_to_uapi_state(struct intel_crtc_state
> *crtc_state,
> + struct drm_display_mode *user_mode)
> {
> crtc_state->uapi.enable = crtc_state->hw.enable;
> crtc_state->uapi.active = crtc_state->hw.active;
> - WARN_ON(drm_atomic_set_mode_for_crtc(&crtc_state->uapi,
> &crtc_state->hw.mode) < 0);
> + WARN_ON(drm_atomic_set_mode_for_crtc(&crtc_state->uapi, user_mode) < 0);
>
> crtc_state->uapi.adjusted_mode = crtc_state->hw.adjusted_mode;
>
> @@ -12702,6 +12699,10 @@ intel_crtc_prepare_cleared_state(struct
> intel_crtc_state *crtc_state)
> memcpy(crtc_state, saved_state, sizeof(*crtc_state));
> kfree(saved_state);
>
> + /* Clear I915_MODE_FLAG_INHERITED */
> + crtc_state->uapi.mode.private_flags = 0;
> + crtc_state->uapi.adjusted_mode.private_flags = 0;
> +
> intel_crtc_copy_uapi_to_hw_state(crtc_state);
>
> return 0;
> @@ -12750,7 +12751,7 @@ intel_modeset_pipe_config(struct intel_crtc_state
> *pipe_config)
>* computation to clearly distinguish it from the adjusted mode, which
>* can be changed by the connectors in the below retry loop.
>*/
> - drm_mode_get_hv_timing(&pipe_config->hw.mode,
> + drm_mode_get_hv_timing(&pipe_config->hw.pipe_mode,
> &pipe_config->pipe_src_w,
> &pipe_config->pipe_src_h);
>
> @@ -12852,6 +12853,8 @@ intel_modeset_pipe_config(struct intel_crtc_state
> *pipe_config)
>*/
> pipe_config->uapi.adjusted_mode = pipe_config->hw.adjusted_mode;
>
> + /* without bigjoiner, pipe_mode == adjusted_mode */
> + pipe_config->hw.pipe_mode = pipe_config->hw.adjusted_mode;
Misplaced hunks?
> return 0;
> }
>
> @@ -12995,8 +12998,8 @@ intel_pi
Re: [Intel-gfx] [PATCH V13 4/6] mdev: introduce mediated virtio bus
On Mon, Nov 18, 2019 at 06:59:21PM +0800, Jason Wang wrote:
> +struct bus_type mdev_virtio_bus_type;
> +
> +struct mdev_virtio_device {
> + struct mdev_device mdev;
> + const struct mdev_virtio_ops *ops;
> + u16 class_id;
> +};
This seems to share nothing with mdev (ie mdev-vfio), why is it on the
same bus?
We went over this recently with Greg and he seemed pretty clear on
this..
> +struct mdev_virtio_ops {
> + /* Virtqueue ops */
> + int (*set_vq_address)(struct mdev_device *mdev,
> + u16 idx, u64 desc_area, u64 driver_area,
> + u64 device_area);
> + void (*set_vq_num)(struct mdev_device *mdev, u16 idx, u32 num);
> + void (*kick_vq)(struct mdev_device *mdev, u16 idx);
> + void (*set_vq_cb)(struct mdev_device *mdev, u16 idx,
> + struct virtio_mdev_callback *cb);
> + void (*set_vq_ready)(struct mdev_device *mdev, u16 idx, bool ready);
> + bool (*get_vq_ready)(struct mdev_device *mdev, u16 idx);
> + int (*set_vq_state)(struct mdev_device *mdev, u16 idx, u64 state);
> + u64 (*get_vq_state)(struct mdev_device *mdev, u16 idx);
> +
> + /* Device ops */
> + u16 (*get_vq_align)(struct mdev_device *mdev);
> + u64 (*get_features)(struct mdev_device *mdev);
> + int (*set_features)(struct mdev_device *mdev, u64 features);
> + void (*set_config_cb)(struct mdev_device *mdev,
> + struct virtio_mdev_callback *cb);
> + u16 (*get_vq_num_max)(struct mdev_device *mdev);
> + u32 (*get_device_id)(struct mdev_device *mdev);
> + u32 (*get_vendor_id)(struct mdev_device *mdev);
> + u8 (*get_status)(struct mdev_device *mdev);
> + void (*set_status)(struct mdev_device *mdev, u8 status);
> + void (*get_config)(struct mdev_device *mdev, unsigned int offset,
> +void *buf, unsigned int len);
> + void (*set_config)(struct mdev_device *mdev, unsigned int offset,
> +const void *buf, unsigned int len);
> + u32 (*get_generation)(struct mdev_device *mdev);
> +};
Why aren't all of these 'struct mdev_device_virtio *' ?
Jason
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/8] drm/xen: Simplify fb_create
On 11/15/19 11:21 AM, Daniel Vetter wrote:
> The current code is a pretty good wtf moment, since we drop the
> reference before we use it. It's not a big deal, because a) we only
> use the pointer, so doesn't blow up and the real reason b) fb->obj[0]
> already holds a full reference for us.
>
> Might as well take the real pointer ins't of complicated games that
> baffle.
>
> Signed-off-by: Daniel Vetter
> Cc: Oleksandr Andrushchenko
> Cc: xen-de...@lists.xenproject.org
Reviewed-by: Oleksandr Andrushchenko
> ---
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> index ff506bc99414..4f34c5208180 100644
> --- a/drivers/gpu/drm/xen/xen_drm_front_kms.c
> +++ b/drivers/gpu/drm/xen/xen_drm_front_kms.c
> @@ -63,14 +63,7 @@ fb_create(struct drm_device *dev, struct drm_file *filp,
> if (IS_ERR_OR_NULL(fb))
> return fb;
>
> - gem_obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
> - if (!gem_obj) {
> - DRM_ERROR("Failed to lookup GEM object\n");
> - ret = -ENOENT;
> - goto fail;
> - }
> -
> - drm_gem_object_put_unlocked(gem_obj);
> + gem_obj = fb->obj[0];
>
> ret = xen_drm_front_fb_attach(drm_info->front_info,
> xen_drm_front_dbuf_to_cookie(gem_obj),
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/15] drm/tee_shm: Drop dma_buf_k(unmap) support
On Mon, Nov 18, 2019 at 11:35:33AM +0100, Daniel Vetter wrote: > There's no in-tree users anymore. > > Signed-off-by: Daniel Vetter > Cc: Arnd Bergmann > Cc: Greg Kroah-Hartman > Cc: Jens Wiklander > Cc: tee-...@lists.linaro.org > -- > Ack for merging this through drm trees very much appreciated. > -Daniel Acked-by: Jens Wiklander Cheers, Jens ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
