dri-devel July 2021

dri-devel@lists.freedesktop.org

321 participants
829 discussions

RE: refactor the i915 GVT support
by Wang, Zhi A 29 Jul '21

29 Jul '21

Hi Christoph: Thanks so much for the patches and the testing. The abstraction between i915 and KVMGT module is for our customers who can easily port GVT-g into their own hypervisors. As you can see, all the hypervisor related functions were put in "hypervisor" module. The GVT-g module talks with the "hypervisor" module through the MPT layer. The customers just need to focus on their "hypervisor" module, implement and attach their own "hypervisor" modules to the MPT layer without touching the GVT-g core logic, which reduce great efforts during the porting as the core logic of GVT-g in i915 is pretty vendor-specific and customers aren't motivated to touch it unless they have to. The boundary between GVT-g core logic and "hypervisor" module also helps a lot on narrowing down the problems when supporting our customers. According to our experience during the support, the less a customer touches the core logic, the less problem will be introduced. We get many customers who are using commercial hypervisors like QNX or their private hypervisors in many areas in the industry. An reference implementation of "Xen hypervisor" module to demonstrate our customer how to port GVT-g to a type-1 hypervisor instead of KVM can be found here: https://github.com/intel/gvt-linux/blob/topic/gvt-xengt/drivers/gpu/drm/i91… But it's hard for some customers to contribute their own "hypervisor" module to the upstream Linux kernel. I am thinking what would be a better solution here? The MPT layer in the kernel helps a lot for customers, but only one open-source "hypervisor" module is there in the kernel. That can confuse people which don't know the story. One thing I was thinking is to put a document about the background and more description in the MPT headers. So it won't confuse more people. Feel free to drop more comments. 😊 Thanks, Zhi. -----Original Message----- From: Christoph Hellwig <hch(a)lst.de> Sent: Wednesday, July 21, 2021 6:54 PM To: Jani Nikula <jani.nikula(a)linux.intel.com>; Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>; Vivi, Rodrigo <rodrigo.vivi(a)intel.com>; Zhenyu Wang <zhenyuw(a)linux.intel.com>; Wang, Zhi A <zhi.a.wang(a)intel.com> Cc: intel-gfx(a)lists.freedesktop.org; intel-gvt-dev(a)lists.freedesktop.org; dri-devel(a)lists.freedesktop.org; linux-kernel(a)vger.kernel.org Subject: refactor the i915 GVT support Hi all, the GVT code in the i915 is a bit of a mess right now due to strange abstractions and lots of indirect calls. This series refactors various bits to clean that up. The main user visible change is that almost all of the GVT code moves out of the main i915 driver and into the kvmgt module. Tested on my Thinkpad with a Kaby Lake CPU and integrated graphics. Git tree: git://git.infradead.org/users/hch/misc.git i915-gvt Gitweb: http://git.infradead.org/users/hch/misc.git/shortlog/refs/heads/i915-gvt Diffstat: b/drivers/gpu/drm/i915/Kconfig | 31 b/drivers/gpu/drm/i915/Makefile | 30 b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 b/drivers/gpu/drm/i915/gvt/cfg_space.c | 89 -- b/drivers/gpu/drm/i915/gvt/cmd_parser.c | 4 b/drivers/gpu/drm/i915/gvt/dmabuf.c | 36 b/drivers/gpu/drm/i915/gvt/execlist.c | 12 b/drivers/gpu/drm/i915/gvt/gtt.c | 55 - b/drivers/gpu/drm/i915/gvt/gvt.c | 100 -- b/drivers/gpu/drm/i915/gvt/gvt.h | 132 ++- b/drivers/gpu/drm/i915/gvt/interrupt.c | 38 - b/drivers/gpu/drm/i915/gvt/kvmgt.c | 634 ++++------------- b/drivers/gpu/drm/i915/gvt/mmio.c | 4 b/drivers/gpu/drm/i915/gvt/opregion.c | 148 --- b/drivers/gpu/drm/i915/gvt/page_track.c | 8 b/drivers/gpu/drm/i915/gvt/scheduler.c | 37 b/drivers/gpu/drm/i915/gvt/trace.h | 2 b/drivers/gpu/drm/i915/gvt/vgpu.c | 22 b/drivers/gpu/drm/i915/i915_drv.h | 7 b/drivers/gpu/drm/i915/i915_params.c | 2 b/drivers/gpu/drm/i915/intel_gvt.c | 64 + b/drivers/gpu/drm/i915/intel_gvt.h | 4 drivers/gpu/drm/i915/gvt/Makefile | 9 drivers/gpu/drm/i915/gvt/hypercall.h | 82 -- drivers/gpu/drm/i915/gvt/mpt.h | 400 ---------- 25 files changed, 541 insertions(+), 1413 deletions(-)

4 7

Re: [Intel-gfx] refactor the i915 GVT support
by Daniel Vetter 29 Jul '21

29 Jul '21

On Thu, Jul 29, 2021 at 09:20:22AM +0200, Christoph Hellwig wrote: > On Wed, Jul 28, 2021 at 02:59:25PM -0300, Jason Gunthorpe wrote: > > On Wed, Jul 28, 2021 at 01:38:58PM +0000, Wang, Zhi A wrote: > > > > > I guess those APIs you were talking about are KVM-only. For other > > > hypervisors, e.g. Xen, ARCN cannot use the APIs you mentioned. Not > > > sure if you have already noticed that VFIO is KVM-only right now. > > > > There is very little hard connection between VFIO and KVM, so no, I > > don't think that is completely true. > > The only connection is the SET_KVM notifier as far as I can tell. > Which is used by a total of two drivers, including i915/gvt. That > being said gvt does not only use vfio, but also does quite a few > direct cals to KVM. > > > In an event, an in-tree version of other hypervisor support for GVT > > needs to go through enabling VFIO support so that the existing API > > multiplexers we have can be used properly, not adding a shim layer > > trying to recreate VFIO inside a GPU driver. > > Yes. And if we go back to actually looking at the series a lot of > it just removes entirely pointless indirect calls that go to generic > code and not even the kvm code, or questionable data structure designs. > If we were to support another upstream hypervisor we'd just need to > union a few fields in struct intel_gpu and maybe introduce a few > methods. Preferably in a way that avoids expensive indirect calls > in the fast path. fwiw I concur with the direction of this series. gvt landed 5 years ago, that should have been plenty of time to merge at least one of the other backends that float around. If it didn't happen in 5 years it aint suddenly happening in the next few, and the abstraction layer should be sunset. Also yes structuring it more as a helper layer with some unions/subclassing than full blown backend abstractor layer would be a good idea too I guess (it usually is the right thing to do). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch

1 0

[early pull] drm/msm: drm-msm-next-2021-07-28 for v5.15
by Rob Clark 29 Jul '21

29 Jul '21

Hi Dave & Daniel, An early pull for v5.15 (there'll be more coming in a week or two), consisting of the drm/scheduler conversion and a couple other small series that one was based one. Mostly sending this now because IIUC danvet wanted it in drm-next so he could rebase on it. (Daniel, if you disagree then speak up, and I'll instead include this in the main pull request once that is ready.) This also has a core patch to drop drm_gem_object_put_locked() now that the last use of it is removed. The following changes since commit ff1176468d368232b684f75e82563369208bc371: Linux 5.14-rc3 (2021-07-25 15:35:14 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/drm/msm.git drm-msm-next-2021-07-28 for you to fetch changes up to 4541e4f2225c30b0e9442be9eb2fb8b7086cdd1f: drm/msm/gem: Mark active before pinning (2021-07-28 09:19:00 -0700) ---------------------------------------------------------------- Rob Clark (18): drm/msm: Let fences read directly from memptrs drm/msm: Signal fences sooner drm/msm: Split out devfreq handling drm/msm: Split out get_freq() helper drm/msm: Devfreq tuning drm/msm: Docs and misc cleanup drm/msm: Small submitqueue creation cleanup drm/msm: drop drm_gem_object_put_locked() drm: Drop drm_gem_object_put_locked() drm/msm/submit: Simplify out-fence-fd handling drm/msm: Consolidate submit bo state drm/msm: Track "seqno" fences by idr drm/msm: Return ERR_PTR() from submit_create() drm/msm: Conversion to drm scheduler drm/msm: Drop submit bo_list drm/msm: Drop struct_mutex in submit path drm/msm: Utilize gpu scheduler priorities drm/msm/gem: Mark active before pinning drivers/gpu/drm/drm_gem.c | 22 -- drivers/gpu/drm/msm/Kconfig | 1 + drivers/gpu/drm/msm/Makefile | 1 + drivers/gpu/drm/msm/adreno/a5xx_debugfs.c | 4 +- drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/a5xx_power.c | 2 +- drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 7 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 12 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 6 +- drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 4 +- drivers/gpu/drm/msm/adreno/adreno_gpu.c | 6 +- drivers/gpu/drm/msm/msm_drv.c | 30 ++- drivers/gpu/drm/msm/msm_fence.c | 53 +---- drivers/gpu/drm/msm/msm_fence.h | 44 +++- drivers/gpu/drm/msm/msm_gem.c | 94 +------- drivers/gpu/drm/msm/msm_gem.h | 47 ++-- drivers/gpu/drm/msm/msm_gem_submit.c | 344 +++++++++++++++++----------- drivers/gpu/drm/msm/msm_gpu.c | 220 ++++-------------- drivers/gpu/drm/msm/msm_gpu.h | 139 ++++++++++- drivers/gpu/drm/msm/msm_gpu_devfreq.c | 203 ++++++++++++++++ drivers/gpu/drm/msm/msm_rd.c | 6 +- drivers/gpu/drm/msm/msm_ringbuffer.c | 69 +++++- drivers/gpu/drm/msm/msm_ringbuffer.h | 12 + drivers/gpu/drm/msm/msm_submitqueue.c | 53 +++-- include/drm/drm_gem.h | 2 - include/uapi/drm/msm_drm.h | 14 +- 26 files changed, 865 insertions(+), 536 deletions(-) create mode 100644 drivers/gpu/drm/msm/msm_gpu_devfreq.c

3 5

[PATCH v3] drm: clarify usage of drm leases
by Desmond Cheong Zhi Xi 29 Jul '21

29 Jul '21

We make the following changes to the documentation of drm leases to make it easier to reason about their usage. In particular, we clarify the lifetime and locking rules of lease fields in drm_master: 1. Make it clear that &drm_device.mode_config.idr_mutex protects the lease idr and list structures for drm_master. The lessor field itself doesn't need to be protected as it doesn't change after it's set in drm_lease_create. 2. Add descriptions for the lifetime of lessors and leases. 3. Add an overview DOC: section in drm-uapi.rst that defines the terminology for drm leasing, and explains how leases work and why they're used. Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx(a)gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- v2 -> v3 (suggestions from Daniel Vetter): - Clarified that device owners are changed through SETMASTER or DROPMASTER IOCTL. - Removed unneccessary includes for drm_lease.[hc] and kerneldoc formatting changes. v1 -> v2 (suggestions from Daniel Vetter): - Clarified description of lease fields in drm_master. - Added an overview DOC: section for drm leases in drm-uapi.rst. - Cleaned up function documentation in drm_lease.c to use kernel-doc formatting. Documentation/gpu/drm-uapi.rst | 9 +++++ drivers/gpu/drm/drm_lease.c | 51 ++++++++++++++++++++++++++ include/drm/drm_auth.h | 67 ++++++++++++++++++++++++++++------ 3 files changed, 116 insertions(+), 11 deletions(-) diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst index 7e51dd40bf6e..199afb503ab1 100644 --- a/Documentation/gpu/drm-uapi.rst +++ b/Documentation/gpu/drm-uapi.rst @@ -37,6 +37,15 @@ Primary Nodes, DRM Master and Authentication .. kernel-doc:: include/drm/drm_auth.h :internal: + +.. _drm_leasing: + +DRM Display Resource Leasing +============================ + +.. kernel-doc:: drivers/gpu/drm/drm_lease.c + :doc: drm leasing + Open-Source Userspace Requirements ================================== diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c index 92eac73d9001..79be797e8689 100644 --- a/drivers/gpu/drm/drm_lease.c +++ b/drivers/gpu/drm/drm_lease.c @@ -15,6 +15,57 @@ #include "drm_crtc_internal.h" #include "drm_internal.h" +/** + * DOC: drm leasing + * + * DRM leases provide information about whether a DRM master may control a DRM + * mode setting object. This enables the creation of multiple DRM masters that + * manage subsets of display resources. + * + * The original DRM master of a device 'owns' the available drm resources. It + * may create additional DRM masters and 'lease' resources which it controls + * to the new DRM master. This gives the new DRM master control over the + * leased resources until the owner revokes the lease, or the new DRM master + * is closed. Some helpful terminology: + * + * - An 'owner' is a &struct drm_master that is not leasing objects from + * another &struct drm_master, and hence 'owns' the objects. The owner can be + * identified as the &struct drm_master for which &drm_master.lessor is NULL. + * + * - A 'lessor' is a &struct drm_master which is leasing objects to one or more + * other &struct drm_master. Currently, lessees are not allowed to + * create sub-leases, hence the lessor is the same as the owner. + * + * - A 'lessee' is a &struct drm_master which is leasing objects from some + * other &struct drm_master. Each lessee only leases resources from a single + * lessor recorded in &drm_master.lessor, and holds the set of objects that + * it is leasing in &drm_master.leases. + * + * - A 'lease' is a contract between the lessor and lessee that identifies + * which resources may be controlled by the lessee. All of the resources + * that are leased must be owned by or leased to the lessor, and lessors are + * not permitted to lease the same object to multiple lessees. + * + * The set of objects any &struct drm_master 'controls' is limited to the set + * of objects it leases (for lessees) or all objects (for owners). + * + * Objects not controlled by a &struct drm_master cannot be modified through + * the various state manipulating ioctls, and any state reported back to user + * space will be edited to make them appear idle and/or unusable. For + * instance, connectors always report 'disconnected', while encoders + * report no possible crtcs or clones. + * + * Since each lessee may lease objects from a single lessor, display resource + * leases form a tree of &struct drm_master. As lessees are currently not + * allowed to create sub-leases, the tree depth is limited to 1. All of + * these get activated simultaneously when the top level device owner changes + * through the SETMASTER or DROPMASTER IOCTL, so &drm_device.master points to + * the owner at the top of the lease tree (i.e. the &struct drm_master for which + * &drm_master.lessor is NULL). The full list of lessees that are leasing + * objects from the owner can be searched via the owner's + * &drm_master.lessee_idr. + */ + #define drm_for_each_lessee(lessee, lessor) \ list_for_each_entry((lessee), &(lessor)->lessees, lessee_list) diff --git a/include/drm/drm_auth.h b/include/drm/drm_auth.h index f99d3417f304..ba248ca8866f 100644 --- a/include/drm/drm_auth.h +++ b/include/drm/drm_auth.h @@ -58,12 +58,6 @@ struct drm_lock_data { * @refcount: Refcount for this master object. * @dev: Link back to the DRM device * @driver_priv: Pointer to driver-private information. - * @lessor: Lease holder - * @lessee_id: id for lessees. Owners always have id 0 - * @lessee_list: other lessees of the same master - * @lessees: drm_masters leasing from this one - * @leases: Objects leased to this drm_master. - * @lessee_idr: All lessees under this owner (only used where lessor == NULL) * * Note that master structures are only relevant for the legacy/primary device * nodes, hence there can only be one per device, not one per drm_minor. @@ -88,17 +82,68 @@ struct drm_master { struct idr magic_map; void *driver_priv; - /* Tree of display resource leases, each of which is a drm_master struct - * All of these get activated simultaneously, so drm_device master points - * at the top of the tree (for which lessor is NULL). Protected by - * &drm_device.mode_config.idr_mutex. + /** + * @lessor: + * + * Lease grantor, only set if this &struct drm_master represents a + * lessee holding a lease of objects from @lessor. Full owners of the + * device have this set to NULL. + * + * The lessor does not change once it's set in drm_lease_create(), and + * each lessee holds a reference to its lessor that it releases upon + * being destroyed in drm_lease_destroy(). + * + * See also the :ref:`section on display resource leasing + * <drm_leasing>`. */ - struct drm_master *lessor; + + /** + * @lessee_id: + * + * ID for lessees. Owners (i.e. @lessor is NULL) always have ID 0. + * Protected by &drm_device.mode_config's &drm_mode_config.idr_mutex. + */ int lessee_id; + + /** + * @lessee_list: + * + * List entry of lessees of @lessor, where they are linked to @lessees. + * Not used for owners. Protected by &drm_device.mode_config's + * &drm_mode_config.idr_mutex. + */ struct list_head lessee_list; + + /** + * @lessees: + * + * List of drm_masters leasing from this one. Protected by + * &drm_device.mode_config's &drm_mode_config.idr_mutex. + * + * This list is empty if no leases have been granted, or if all lessees + * have been destroyed. Since lessors are referenced by all their + * lessees, this master cannot be destroyed unless the list is empty. + */ struct list_head lessees; + + /** + * @leases: + * + * Objects leased to this drm_master. Protected by + * &drm_device.mode_config's &drm_mode_config.idr_mutex. + * + * Objects are leased all together in drm_lease_create(), and are + * removed all together when the lease is revoked. + */ struct idr leases; + + /** + * @lessee_idr: + * + * All lessees under this owner (only used where @lessor is NULL). + * Protected by &drm_device.mode_config's &drm_mode_config.idr_mutex. + */ struct idr lessee_idr; /* private: */ #if IS_ENABLED(CONFIG_DRM_LEGACY) -- 2.25.1

2 1

[PATCH] drm/msm: remove a repeated including of <linux/debugfs.h>
by Guo Zhengkui 29 Jul '21

29 Jul '21

Remove a repeated "#include <linux/debugfs.h>" in line 19 of the original file. Signed-off-by: Guo Zhengkui <guozhengkui(a)vivo.com> --- drivers/gpu/drm/msm/disp/msm_disp_snapshot.h | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/msm_disp_snapshot.h b/drivers/gpu/drm/msm/disp/msm_disp_snapshot.h index c92a9508c8d3..c22b07f68670 100644 --- a/drivers/gpu/drm/msm/disp/msm_disp_snapshot.h +++ b/drivers/gpu/drm/msm/disp/msm_disp_snapshot.h @@ -16,7 +16,6 @@ #include <linux/delay.h> #include <linux/spinlock.h> #include <linux/ktime.h> -#include <linux/debugfs.h> #include <linux/uaccess.h> #include <linux/dma-buf.h> #include <linux/slab.h> -- 2.17.1

1 0

[pull] amdgpu drm-fixes-5.14
by Alex Deucher 29 Jul '21

29 Jul '21

Hi Dave, Daniel, Fixes for 5.14. The following changes since commit ff1176468d368232b684f75e82563369208bc371: Linux 5.14-rc3 (2021-07-25 15:35:14 -0700) are available in the Git repository at: https://gitlab.freedesktop.org/agd5f/linux.git tags/amd-drm-fixes-5.14-2021-07-28 for you to fetch changes up to ec30ce41f03820b6289513344b4281ca3a1151f4: maintainers: add bugs and chat URLs for amdgpu (2021-07-27 12:48:59 -0400) ---------------------------------------------------------------- amd-drm-fixes-5.14-2021-07-28: amdgpu: - Fix resource leak in an error path - Avoid stack contents exposure in error path - pmops check fix for S0ix vs S3 - DCN 2.1 display fixes - DCN 2.0 display fix - Backlight control fix for laptops with HDR panels - Maintainers updates ---------------------------------------------------------------- Alex Deucher (1): drm/amdgpu/display: only enable aux backlight control for OLED panels Dale Zhao (1): drm/amd/display: ensure dentist display clock update finished in DCN20 Jiri Kosina (2): drm/amdgpu: Fix resource leak on probe error path drm/amdgpu: Avoid printing of stack contents on firmware load error Pratik Vishwakarma (1): drm/amdgpu: Check pmops for desired suspend state Simon Ser (1): maintainers: add bugs and chat URLs for amdgpu Victor Lu (2): drm/amd/display: Guard DST_Y_PREFETCH register overflow in DCN21 drm/amd/display: Add missing DCN21 IP parameter MAINTAINERS | 2 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 3 ++- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 8 ++------ drivers/gpu/drm/amd/amdgpu/psp_v12_0.c | 7 +++---- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 ++-- drivers/gpu/drm/amd/display/dc/clk_mgr/dcn20/dcn20_clk_mgr.c | 2 +- drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 1 + drivers/gpu/drm/amd/display/dc/dml/dcn21/display_mode_vba_21.c | 3 +++ 8 files changed, 16 insertions(+), 14 deletions(-)

1 0

[PATCH] drm/i915/selftests: prefer the create_user helper
by Matthew Auld 29 Jul '21

29 Jul '21

No need to hand roll the set_placements stuff, now that that we have a helper for this. Also no need to handle the -ENODEV case here, since NULL mr implies missing device support, where the for_each_memory_region helper will always skip over such regions. Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Jason Ekstrand <jason(a)jlekstrand.net> --- .../drm/i915/gem/selftests/i915_gem_mman.c | 46 ++----------------- 1 file changed, 4 insertions(+), 42 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c index 0b2b73d8a364..eed1c2c64e75 100644 --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c @@ -860,24 +860,6 @@ static bool can_mmap(struct drm_i915_gem_object *obj, enum i915_mmap_type type) return !no_map; } -static void object_set_placements(struct drm_i915_gem_object *obj, - struct intel_memory_region **placements, - unsigned int n_placements) -{ - GEM_BUG_ON(!n_placements); - - if (n_placements == 1) { - struct drm_i915_private *i915 = to_i915(obj->base.dev); - struct intel_memory_region *mr = placements[0]; - - obj->mm.placements = &i915->mm.regions[mr->id]; - obj->mm.n_placements = 1; - } else { - obj->mm.placements = placements; - obj->mm.n_placements = n_placements; - } -} - #define expand32(x) (((x) << 0) | ((x) << 8) | ((x) << 16) | ((x) << 24)) static int __igt_mmap(struct drm_i915_private *i915, struct drm_i915_gem_object *obj, @@ -972,15 +954,10 @@ static int igt_mmap(void *arg) struct drm_i915_gem_object *obj; int err; - obj = i915_gem_object_create_region(mr, sizes[i], 0, I915_BO_ALLOC_USER); - if (obj == ERR_PTR(-ENODEV)) - continue; - + obj = __i915_gem_object_create_user(i915, sizes[i], &mr, 1); if (IS_ERR(obj)) return PTR_ERR(obj); - object_set_placements(obj, &mr, 1); - err = __igt_mmap(i915, obj, I915_MMAP_TYPE_GTT); if (err == 0) err = __igt_mmap(i915, obj, I915_MMAP_TYPE_WC); @@ -1101,15 +1078,10 @@ static int igt_mmap_access(void *arg) struct drm_i915_gem_object *obj; int err; - obj = i915_gem_object_create_region(mr, PAGE_SIZE, 0, I915_BO_ALLOC_USER); - if (obj == ERR_PTR(-ENODEV)) - continue; - + obj = __i915_gem_object_create_user(i915, PAGE_SIZE, &mr, 1); if (IS_ERR(obj)) return PTR_ERR(obj); - object_set_placements(obj, &mr, 1); - err = __igt_mmap_access(i915, obj, I915_MMAP_TYPE_GTT); if (err == 0) err = __igt_mmap_access(i915, obj, I915_MMAP_TYPE_WB); @@ -1248,15 +1220,10 @@ static int igt_mmap_gpu(void *arg) struct drm_i915_gem_object *obj; int err; - obj = i915_gem_object_create_region(mr, PAGE_SIZE, 0, I915_BO_ALLOC_USER); - if (obj == ERR_PTR(-ENODEV)) - continue; - + obj = __i915_gem_object_create_user(i915, PAGE_SIZE, &mr, 1); if (IS_ERR(obj)) return PTR_ERR(obj); - object_set_placements(obj, &mr, 1); - err = __igt_mmap_gpu(i915, obj, I915_MMAP_TYPE_GTT); if (err == 0) err = __igt_mmap_gpu(i915, obj, I915_MMAP_TYPE_WC); @@ -1405,15 +1372,10 @@ static int igt_mmap_revoke(void *arg) struct drm_i915_gem_object *obj; int err; - obj = i915_gem_object_create_region(mr, PAGE_SIZE, 0, I915_BO_ALLOC_USER); - if (obj == ERR_PTR(-ENODEV)) - continue; - + obj = __i915_gem_object_create_user(i915, PAGE_SIZE, &mr, 1); if (IS_ERR(obj)) return PTR_ERR(obj); - object_set_placements(obj, &mr, 1); - err = __igt_mmap_revoke(i915, obj, I915_MMAP_TYPE_GTT); if (err == 0) err = __igt_mmap_revoke(i915, obj, I915_MMAP_TYPE_WC); -- 2.26.3

2 1

[Bug 213373] New: [drm] [radeon] memory leak at parsing radeon_atombios_parse_power_table
by bugzilla-daemon＠bugzilla.kernel.org 29 Jul '21

29 Jul '21

https://bugzilla.kernel.org/show_bug.cgi?id=213373 Bug ID: 213373 Summary: [drm] [radeon] memory leak at parsing radeon_atombios_parse_power_table Product: Drivers Version: 2.5 Kernel Version: 5.13-rc5 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: erhard_f(a)mailbox.org Regression: No Created attachment 297247 --> https://bugzilla.kernel.org/attachment.cgi?id=297247&action=edit output of /sys/kernel/debug/kmemleak Radeon driver on this machine was defunct from 5.6.x on until the issue was fixed in bug #211537. What remains after the fix is this memory leak: unreferenced object 0xffff88810e6c3dc8 (size 96): comm "systemd-udevd", pid 136, jiffies 4294895831 (age 1145.117s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 40 56 fe 08 80 88 ff ff ........@V...... 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000010cd8f43>] __kmalloc+0x163/0x1d4 [<00000000f14786c6>] radeon_atombios_parse_power_table_1_3+0x43f/0x1b1f [radeon] [<00000000638c7538>] radeon_atombios_get_power_modes+0x144/0x1888 [radeon] [<00000000db824f7d>] radeon_pm_init+0xffd/0x18cc [radeon] [<000000007dfbb45f>] rs690_init+0x76e/0x84a [radeon] [<0000000035475290>] radeon_device_init+0x1c1a/0x21c1 [radeon] [<00000000f4096cf8>] radeon_driver_load_kms+0xf5/0x30b [radeon] [<00000000b3f3c46b>] drm_dev_register+0x255/0x4a0 [drm] [<00000000da8d532e>] radeon_pci_probe+0x246/0x2f6 [radeon] [<00000000667a4010>] pci_device_probe+0x1aa/0x294 [<00000000435523ff>] really_probe+0x30e/0x850 [<0000000016679ebc>] driver_probe_device+0x112/0x161 [<00000000e75e3390>] device_driver_attach+0xc1/0xf8 [<0000000078c4dcd6>] __driver_attach+0x16b/0x172 [<000000007d3f0ac0>] bus_for_each_dev+0xfa/0x146 [<000000008ee66f7b>] bus_add_driver+0x2b3/0x447 unreferenced object 0xffff888008fe5640 (size 64): comm "systemd-udevd", pid 136, jiffies 4294895831 (age 1145.117s) hex dump (first 32 bytes): 00 00 00 00 40 9c 00 00 00 00 00 00 00 00 00 00 ....@........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000006edcc7c8>] kmem_cache_alloc_trace+0x10f/0x15e [<0000000079a5480d>] radeon_atombios_parse_power_table_1_3+0x546/0x1b1f [radeon] [<00000000638c7538>] radeon_atombios_get_power_modes+0x144/0x1888 [radeon] [<00000000db824f7d>] radeon_pm_init+0xffd/0x18cc [radeon] [<000000007dfbb45f>] rs690_init+0x76e/0x84a [radeon] [<0000000035475290>] radeon_device_init+0x1c1a/0x21c1 [radeon] [<00000000f4096cf8>] radeon_driver_load_kms+0xf5/0x30b [radeon] [<00000000b3f3c46b>] drm_dev_register+0x255/0x4a0 [drm] [<00000000da8d532e>] radeon_pci_probe+0x246/0x2f6 [radeon] [<00000000667a4010>] pci_device_probe+0x1aa/0x294 [<00000000435523ff>] really_probe+0x30e/0x850 [<0000000016679ebc>] driver_probe_device+0x112/0x161 [<00000000e75e3390>] device_driver_attach+0xc1/0xf8 [<0000000078c4dcd6>] __driver_attach+0x16b/0x172 [<000000007d3f0ac0>] bus_for_each_dev+0xfa/0x146 [<000000008ee66f7b>] bus_add_driver+0x2b3/0x447 # lspci -vv -s 01:05.0 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS690M [Radeon Xpress 1200/1250/1270] (prog-if 00 [VGA controller]) Subsystem: Gateway, Inc. RS690M [Radeon Xpress 1200/1250/1270] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 64, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 26 Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at f0100000 (64-bit, non-prefetchable) [size=64K] Region 4: I/O ports at 9400 [size=256] Region 5: Memory at f0000000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at 000c0000 [virtual] [disabled] [size=128K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee01004 Data: 0025 Kernel driver in use: radeon Kernel modules: radeon # inxi -bz System: Kernel: 5.13.0-rc5-E620 x86_64 bits: 64 Console: tty 0 Distro: Gentoo Base System release 2.7 Machine: Type: Laptop System: eMachines product: eMachines E620 v: V1.03 serial: <filter> Mobo: eMachines model: Nile serial: <filter> BIOS: eMachines v: 1.03 date: 09/30/2008 Battery: ID-1: BAT1 charge: N/A condition: N/A CPU: Info: Dual Core AMD Athlon X2 3250e [MCP] speed: 1496 MHz Graphics: Device-1: AMD RS690M [Radeon Xpress 1200/1250/1270] driver: radeon v: kernel Display: server: X.org 1.20.11 driver: ati,radeon unloaded: fbdev,modesetting tty: 104x57 Message: Advanced graphics data unavailable in console for root. Network: Device-1: Qualcomm Atheros AR242x / AR542x Wireless Network Adapter driver: ath5k Device-2: Realtek RTL810xE PCI Express Fast Ethernet driver: r8169 -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.

1 4

[PATCH] drm: rcar-du: crtc: force depends on cmm
by Jackie Liu 28 Jul '21

28 Jul '21

From: Jackie Liu <liuyun01(a)kylinos.cn> After the patch 78b6bb1d24db ("drm: rcar-du: crtc: Control CMM operations"), the cmm module must be included in the crtc. We cannot remove this configuration option separately. Therefore, simply linking them together is the best solution, otherwise some errors will be reported. rcar_du_crtc.c:(.text+0x194): undefined reference to `rcar_cmm_setup' rcar_du_crtc.c:(.text+0x11bc): undefined reference to `rcar_cmm_enable' rcar_du_crtc.c:(.text+0x1604): undefined reference to `rcar_cmm_disable' rcar_du_kms.c:(.text+0x768): undefined reference to `rcar_cmm_init' Fixes: 78b6bb1d24db ("rm: rcar-du: crtc: Control CMM operations") Reported-by: kernel-bot <k2ci(a)kylinos.cn> Signed-off-by: Jackie Liu <liuyun01(a)kylinos.cn> --- drivers/gpu/drm/rcar-du/Kconfig | 8 -------- drivers/gpu/drm/rcar-du/Makefile | 2 +- 2 files changed, 1 insertion(+), 9 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig index b47e74421e34..bc71ad2a472f 100644 --- a/drivers/gpu/drm/rcar-du/Kconfig +++ b/drivers/gpu/drm/rcar-du/Kconfig @@ -4,7 +4,6 @@ config DRM_RCAR_DU depends on DRM && OF depends on ARM || ARM64 depends on ARCH_RENESAS || COMPILE_TEST - imply DRM_RCAR_CMM imply DRM_RCAR_LVDS select DRM_KMS_HELPER select DRM_KMS_CMA_HELPER @@ -14,13 +13,6 @@ config DRM_RCAR_DU Choose this option if you have an R-Car chipset. If M is selected the module will be called rcar-du-drm. -config DRM_RCAR_CMM - tristate "R-Car DU Color Management Module (CMM) Support" - depends on DRM && OF - depends on DRM_RCAR_DU - help - Enable support for R-Car Color Management Module (CMM). - config DRM_RCAR_DW_HDMI tristate "R-Car Gen3 and RZ/G2 DU HDMI Encoder Support" depends on DRM && OF diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile index 4d1187ccc3e5..76ff2e15bc2d 100644 --- a/drivers/gpu/drm/rcar-du/Makefile +++ b/drivers/gpu/drm/rcar-du/Makefile @@ -5,6 +5,7 @@ rcar-du-drm-y := rcar_du_crtc.o \ rcar_du_group.o \ rcar_du_kms.o \ rcar_du_plane.o \ + rcar_cmm.o rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \ rcar_du_of_lvds_r8a7790.dtb.o \ @@ -15,7 +16,6 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o -obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o -- 2.25.1

5 13

[GIT PULL FOR v5.15] R-Car DU fixes and improvements
by Laurent Pinchart 28 Jul '21

28 Jul '21

Hi Dave and Daniel, The following changes since commit 15d27b15de965043d6f8e23bc7f34386fcd1a772: efi: sysfb_efi: fix build when EFI is not set (2021-07-27 11:52:51 +0200) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/du-next-20210728 for you to fetch changes up to 6571a76af380290dd9a003a3bc90d4779ec4f8f8: drm: rcar-du: lvds: Use dev_err_probe() (2021-07-28 16:33:32 +0300) ---------------------------------------------------------------- - R-Car DU shutdown fixes - R-Car DU conversion to bridge connector helper - Misc small fixes ---------------------------------------------------------------- Colin Ian King (1): drm/bridge: make a const array static, makes object smaller Laurent Pinchart (10): drm: rcar-du: Shutdown the display on system shutdown drm: rcar-du: Don't put reference to drm_device in rcar_du_remove() drm: rcar-du: Shutdown the display on remove drm/bridge: Centralize error message when bridge attach fails drm: bridge: dw-hdmi: Attach to next bridge if available drm: rcar-du: lvds: Convert to DRM panel bridge helper drm: rcar-du: dw-hdmi: Set output port number drm: rcar-du: Use drm_bridge_connector_init() helper drm: rcar-du: lvds: Don't set bridge driver_private field drm: rcar-du: lvds: Use dev_err_probe() drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 9 +- drivers/gpu/drm/bridge/analogix/anx7625.c | 5 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 55 ++++++++- drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 10 +- drivers/gpu/drm/bridge/tc358768.c | 2 +- drivers/gpu/drm/drm_bridge.c | 10 ++ drivers/gpu/drm/exynos/exynos_dp.c | 5 +- drivers/gpu/drm/exynos/exynos_hdmi.c | 5 +- drivers/gpu/drm/hisilicon/kirin/dw_drm_dsi.c | 9 +- drivers/gpu/drm/imx/dcss/dcss-kms.c | 5 +- drivers/gpu/drm/imx/imx-ldb.c | 4 +- drivers/gpu/drm/imx/parallel-display.c | 5 +- drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 4 +- drivers/gpu/drm/kmb/kmb_dsi.c | 1 - drivers/gpu/drm/mcde/mcde_dsi.c | 9 +- drivers/gpu/drm/mediatek/mtk_dpi.c | 4 +- drivers/gpu/drm/mediatek/mtk_hdmi.c | 5 +- drivers/gpu/drm/omapdrm/omap_drv.c | 6 +- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 11 +- drivers/gpu/drm/rcar-du/rcar_du_encoder.c | 26 ++++- drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 1 + drivers/gpu/drm/rcar-du/rcar_lvds.c | 126 +++------------------ drivers/gpu/drm/rockchip/rockchip_lvds.c | 5 +- drivers/gpu/drm/rockchip/rockchip_rgb.c | 5 +- drivers/gpu/drm/sti/sti_dvo.c | 4 +- drivers/gpu/drm/sun4i/sun4i_lvds.c | 4 +- drivers/gpu/drm/sun4i/sun4i_rgb.c | 4 +- drivers/gpu/drm/tegra/rgb.c | 5 +- drivers/gpu/drm/tidss/tidss_kms.c | 4 +- drivers/gpu/drm/tilcdc/tilcdc_external.c | 4 +- drivers/gpu/drm/vc4/vc4_dsi.c | 4 +- include/drm/bridge/dw_hdmi.h | 2 + 32 files changed, 134 insertions(+), 224 deletions(-) -- Regards, Laurent Pinchart

1 0

← Newer
1
...
25
26
27
28
29
30
31
...
83
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel July 2021