dri-devel May 2019

dri-devel@lists.freedesktop.org

299 participants
2118 discussions

[PATCH] drm/msm/mdp5: Fix mdp5_cfg_init error return
by Jeffrey Hugo 01 May '19

01 May '19

If mdp5_cfg_init fails because of an unknown major version, a null pointer dereference occurs. This is because the caller of init expects error pointers, but init returns NULL on error. Fix this by returning the expected values on error. Fixes: 2e362e1772b8 (drm/msm/mdp5: introduce mdp5_cfg module) Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo(a)gmail.com> --- drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c index ea8f7d7daf7f..52e23780fce1 100644 --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c @@ -721,7 +721,7 @@ struct mdp5_cfg_handler *mdp5_cfg_init(struct mdp5_kms *mdp5_kms, if (cfg_handler) mdp5_cfg_destroy(cfg_handler); - return NULL; + return ERR_PTR(ret); } static struct mdp5_cfg_platform *mdp5_get_config(struct platform_device *dev) -- 2.17.1

2 1

[Bug 203473] New: ring gfx timeout when returning from suspension
by bugzilla-daemon＠bugzilla.kernel.org 01 May '19

01 May '19

https://bugzilla.kernel.org/show_bug.cgi?id=203473 Bug ID: 203473 Summary: ring gfx timeout when returning from suspension Product: Drivers Version: 2.5 Kernel Version: 5.x Hardware: x86-64 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: brunoalexandremiguel(a)gmail.com Regression: No Created attachment 282571 --> https://bugzilla.kernel.org/attachment.cgi?id=282571&action=edit log Ever since 5.x reached stable (haven't tested rc's and such), I get a blank screen every time my laptop returns from suspension. From what I've seen in the logs, it seems the GPU can't get back up. The full log is attached. Here is a short info about my system: System: Host: sagan Kernel: 5.0.10-lqx1-1-lqx x86_64 bits: 64 Desktop: KDE Plasma 5.15.4 Distro: Manjaro Linux Machine: Type: Laptop System: LENOVO product: 80XV v: Lenovo ideapad 320-15AST serial: <root required> Mobo: LENOVO model: LNVNB161216 v: SDK0J40700WIN serial: <root required> UEFI: LENOVO v: 5PCN19WW date: 11/29/2017 Battery: ID-1: BAT0 charge: 28.4 Wh condition: 29.9/30.0 Wh (100%) CPU: Dual Core: AMD A9-9420 RADEON R5 5 COMPUTE CORES 2C+3G type: MCP speed: 1397 MHz min/max: 1400/3000 MHz Graphics: Device-1: Advanced Micro Devices [AMD/ATI] Stoney [Radeon R2/R3/R4/R5 Graphics] driver: amdgpu v: kernel Device-2: AMD Topaz XT [Radeon R7 M260/M265 / M340/M360 / M440/M445] driver: amdgpu v: kernel Display: x11 server: X.Org 1.20.4 driver: amdgpu FAILED: ati unloaded: modesetting resolution: 1366x768~60Hz OpenGL: renderer: AMD ICELAND (DRM 3.27.0 5.0.10-lqx1-1-lqx LLVM 8.0.0) v: 4.5 Mesa 19.0.3 Network: Device-1: Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter driver: ath10k_pci Device-2: Realtek RTL810xE PCI Express Fast Ethernet driver: r8169 Device-3: Qualcomm Atheros type: USB driver: btusb Drives: Local Storage: total: 111.79 GiB used: 70.03 GiB (62.6%) Info: Processes: 228 Uptime: 5h 19m Memory: 7.18 GiB used: 2.19 GiB (30.5%) Shell: bash inxi: 3.0.33 -- You are receiving this mail because: You are watching the assignee of the bug.

1 1

[PATCH v13 00/20] arm64: untag user pointers passed to the kernel
by Andrey Konovalov 01 May '19

01 May '19

=== Overview arm64 has a feature called Top Byte Ignore, which allows to embed pointer tags into the top byte of each pointer. Userspace programs (such as HWASan, a memory debugging tool [1]) might use this feature and pass tagged user pointers to the kernel through syscalls or other interfaces. Right now the kernel is already able to handle user faults with tagged pointers, due to these patches: 1. 81cddd65 ("arm64: traps: fix userspace cache maintenance emulation on a tagged pointer") 2. 7dcd9dd8 ("arm64: hw_breakpoint: fix watchpoint matching for tagged pointers") 3. 276e9327 ("arm64: entry: improve data abort handling of tagged pointers") This patchset extends tagged pointer support to syscall arguments. As per the proposed ABI change [3], tagged pointers are only allowed to be passed to syscalls when they point to memory ranges obtained by anonymous mmap() or sbrk() (see the patchset [3] for more details). For non-memory syscalls this is done by untaging user pointers when the kernel performs pointer checking to find out whether the pointer comes from userspace (most notably in access_ok). The untagging is done only when the pointer is being checked, the tag is preserved as the pointer makes its way through the kernel and stays tagged when the kernel dereferences the pointer when perfoming user memory accesses. Memory syscalls (mmap, mprotect, etc.) don't do user memory accesses but rather deal with memory ranges, and untagged pointers are better suited to describe memory ranges internally. Thus for memory syscalls we untag pointers completely when they enter the kernel. === Other approaches One of the alternative approaches to untagging that was considered is to completely strip the pointer tag as the pointer enters the kernel with some kind of a syscall wrapper, but that won't work with the countless number of different ioctl calls. With this approach we would need a custom wrapper for each ioctl variation, which doesn't seem practical. An alternative approach to untagging pointers in memory syscalls prologues is to inspead allow tagged pointers to be passed to find_vma() (and other vma related functions) and untag them there. Unfortunately, a lot of find_vma() callers then compare or subtract the returned vma start and end fields against the pointer that was being searched. Thus this approach would still require changing all find_vma() callers. === Testing The following testing approaches has been taken to find potential issues with user pointer untagging: 1. Static testing (with sparse [2] and separately with a custom static analyzer based on Clang) to track casts of __user pointers to integer types to find places where untagging needs to be done. 2. Static testing with grep to find parts of the kernel that call find_vma() (and other similar functions) or directly compare against vm_start/vm_end fields of vma. 3. Static testing with grep to find parts of the kernel that compare user pointers with TASK_SIZE or other similar consts and macros. 4. Dynamic testing: adding BUG_ON(has_tag(addr)) to find_vma() and running a modified syzkaller version that passes tagged pointers to the kernel. Based on the results of the testing the requried patches have been added to the patchset. === Notes This patchset is meant to be merged together with "arm64 relaxed ABI" [3]. This patchset is a prerequisite for ARM's memory tagging hardware feature support [4]. This patchset has been merged into the Pixel 2 kernel tree and is now being used to enable testing of Pixel 2 phones with HWASan. Thanks! [1] http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html [2] https://github.com/lucvoo/sparse-dev/commit/5f960cb10f56ec2017c128ef9d16060… [3] https://lkml.org/lkml/2019/3/18/819 [4] https://community.arm.com/processors/b/blog/posts/arm-a-profile-architectur… Changes in v13: - Simplified untagging in tcp_zerocopy_receive(). - Looked at find_vma() callers in drivers/, which allowed to identify a few other places where untagging is needed. - Added patch "mm, arm64: untag user pointers in get_vaddr_frames". - Added patch "drm/amdgpu, arm64: untag user pointers in amdgpu_ttm_tt_get_user_pages". - Added patch "drm/radeon, arm64: untag user pointers in radeon_ttm_tt_pin_userptr". - Added patch "IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr". - Added patch "media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get". - Added patch "tee/optee, arm64: untag user pointers in check_mem_type". - Added patch "vfio/type1, arm64: untag user pointers". Changes in v12: - Changed untagging in tcp_zerocopy_receive() to also untag zc->address. - Fixed untagging in prctl_set_mm* to only untag pointers for vma lookups and validity checks, but leave them as is for actual user space accesses. - Updated the link to the v2 of the "arm64 relaxed ABI" patchset [3]. - Dropped the documentation patch, as the "arm64 relaxed ABI" patchset [3] handles that. Changes in v11: - Added "uprobes, arm64: untag user pointers in find_active_uprobe" patch. - Added "bpf, arm64: untag user pointers in stack_map_get_build_id_offset" patch. - Fixed "tracing, arm64: untag user pointers in seq_print_user_ip" to correctly perform subtration with a tagged addr. - Moved untagged_addr() from SYSCALL_DEFINE3(mprotect) and SYSCALL_DEFINE4(pkey_mprotect) to do_mprotect_pkey(). - Moved untagged_addr() definition for other arches from include/linux/memory.h to include/linux/mm.h. - Changed untagging in strn*_user() to perform userspace accesses through tagged pointers. - Updated the documentation to mention that passing tagged pointers to memory syscalls is allowed. - Updated the test to use malloc'ed memory instead of stack memory. Changes in v10: - Added "mm, arm64: untag user pointers passed to memory syscalls" back. - New patch "fs, arm64: untag user pointers in fs/userfaultfd.c". - New patch "net, arm64: untag user pointers in tcp_zerocopy_receive". - New patch "kernel, arm64: untag user pointers in prctl_set_mm*". - New patch "tracing, arm64: untag user pointers in seq_print_user_ip". Changes in v9: - Rebased onto 4.20-rc6. - Used u64 instead of __u64 in type casts in the untagged_addr macro for arm64. - Added braces around (addr) in the untagged_addr macro for other arches. Changes in v8: - Rebased onto 65102238 (4.20-rc1). - Added a note to the cover letter on why syscall wrappers/shims that untag user pointers won't work. - Added a note to the cover letter that this patchset has been merged into the Pixel 2 kernel tree. - Documentation fixes, in particular added a list of syscalls that don't support tagged user pointers. Changes in v7: - Rebased onto 17b57b18 (4.19-rc6). - Dropped the "arm64: untag user address in __do_user_fault" patch, since the existing patches already handle user faults properly. - Dropped the "usb, arm64: untag user addresses in devio" patch, since the passed pointer must come from a vma and therefore be untagged. - Dropped the "arm64: annotate user pointers casts detected by sparse" patch (see the discussion to the replies of the v6 of this patchset). - Added more context to the cover letter. - Updated Documentation/arm64/tagged-pointers.txt. Changes in v6: - Added annotations for user pointer casts found by sparse. - Rebased onto 050cdc6c (4.19-rc1+). Changes in v5: - Added 3 new patches that add untagging to places found with static analysis. - Rebased onto 44c929e1 (4.18-rc8). Changes in v4: - Added a selftest for checking that passing tagged pointers to the kernel succeeds. - Rebased onto 81e97f013 (4.18-rc1+). Changes in v3: - Rebased onto e5c51f30 (4.17-rc6+). - Added linux-arch@ to the list of recipients. Changes in v2: - Rebased onto 2d618bdf (4.17-rc3+). - Removed excessive untagging in gup.c. - Removed untagging pointers returned from __uaccess_mask_ptr. Changes in v1: - Rebased onto 4.17-rc1. Changes in RFC v2: - Added "#ifndef untagged_addr..." fallback in linux/uaccess.h instead of defining it for each arch individually. - Updated Documentation/arm64/tagged-pointers.txt. - Dropped "mm, arm64: untag user addresses in memory syscalls". - Rebased onto 3eb2ce82 (4.16-rc7). Signed-off-by: Andrey Konovalov <andreyknvl(a)google.com> Andrey Konovalov (20): uaccess: add untagged_addr definition for other arches arm64: untag user pointers in access_ok and __uaccess_mask_ptr lib, arm64: untag user pointers in strn*_user mm, arm64: untag user pointers passed to memory syscalls mm, arm64: untag user pointers in mm/gup.c mm, arm64: untag user pointers in get_vaddr_frames fs, arm64: untag user pointers in copy_mount_options fs, arm64: untag user pointers in fs/userfaultfd.c net, arm64: untag user pointers in tcp_zerocopy_receive kernel, arm64: untag user pointers in prctl_set_mm* tracing, arm64: untag user pointers in seq_print_user_ip uprobes, arm64: untag user pointers in find_active_uprobe bpf, arm64: untag user pointers in stack_map_get_build_id_offset drm/amdgpu, arm64: untag user pointers in amdgpu_ttm_tt_get_user_pages drm/radeon, arm64: untag user pointers in radeon_ttm_tt_pin_userptr IB/mlx4, arm64: untag user pointers in mlx4_get_umem_mr media/v4l2-core, arm64: untag user pointers in videobuf_dma_contig_user_get tee/optee, arm64: untag user pointers in check_mem_type vfio/type1, arm64: untag user pointers in vaddr_get_pfn selftests, arm64: add a selftest for passing tagged pointers to kernel arch/arm64/include/asm/uaccess.h | 10 +++-- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 5 ++- drivers/gpu/drm/radeon/radeon_ttm.c | 5 ++- drivers/infiniband/hw/mlx4/mr.c | 7 +-- drivers/media/v4l2-core/videobuf-dma-contig.c | 9 ++-- drivers/tee/optee/call.c | 1 + drivers/vfio/vfio_iommu_type1.c | 2 + fs/namespace.c | 2 +- fs/userfaultfd.c | 5 +++ include/linux/mm.h | 4 ++ ipc/shm.c | 2 + kernel/bpf/stackmap.c | 6 ++- kernel/events/uprobes.c | 2 + kernel/sys.c | 44 +++++++++++++------ kernel/trace/trace_output.c | 5 ++- lib/strncpy_from_user.c | 3 +- lib/strnlen_user.c | 3 +- mm/frame_vector.c | 2 + mm/gup.c | 4 ++ mm/madvise.c | 2 + mm/mempolicy.c | 5 +++ mm/migrate.c | 1 + mm/mincore.c | 2 + mm/mlock.c | 5 +++ mm/mmap.c | 7 +++ mm/mprotect.c | 1 + mm/mremap.c | 2 + mm/msync.c | 2 + net/ipv4/tcp.c | 2 + tools/testing/selftests/arm64/.gitignore | 1 + tools/testing/selftests/arm64/Makefile | 11 +++++ .../testing/selftests/arm64/run_tags_test.sh | 12 +++++ tools/testing/selftests/arm64/tags_test.c | 21 +++++++++ 33 files changed, 159 insertions(+), 36 deletions(-) create mode 100644 tools/testing/selftests/arm64/.gitignore create mode 100644 tools/testing/selftests/arm64/Makefile create mode 100755 tools/testing/selftests/arm64/run_tags_test.sh create mode 100644 tools/testing/selftests/arm64/tags_test.c -- 2.21.0.225.g810b269d1ac-goog

7 51

[RFC 0/4] Add support for drm/rockchip to dynamically control the DDR frequency within vblank for gru chromebooks.
by Gaël PORTAY 01 May '19

01 May '19

Dear all, The purpose of that RFC is to enable de DMC device for the Rockchip based GRU Chromebooks, and to add a mean of synchronization between the Rockchip DRM driver and that DMC devfreq driver. The DMC device is responsible for updating the DDR frequency according to the load of the DDR memory. Changing that clock rate within the display scanout leads to glitches. Thus, the devfreq framework needs a mean to synchronize the rate change with other devices. In that case, the DRM driver display has to synchronize a change rate within the VBLANK. The first patch adds a locking API to the devfreq framework. The users of a devfreq device can control the frequency change by locking and unlocking the devfreq device whenever they want. When a change rate is requested, and the device is locked, the drivers that hold a lock are called back, and the change will be applied as soon as the device is unlocked. The second patch adds the devfreq support in the Rockchip DRM drivers and uses the devfreq lock API to defer the change of the DDR frequency within the next VBLANK. The DRM driver locks the devfreq device and gets notified when a change is wanted then. Next, it enables the VBLANK interrupt, releases the lock on interrupt and starts a timer that relocks the devfreq device at the end of the vertical blanking interval. Also, the DRM driver disables the devfreq device if more than one CRTC becomes active. The third patch merges the Rockchip DDR clock code to the Rockchip DMC devfreq driver. These drivers both perform SMC calls to the Trusted-Firmware A to run SiP services that are related to the DDR memory. This merge puts the code at the same place. It avoids the contention in the Common Clock Framework that may cause to miss the deadline during which the rate can be changing without making glitches. The fourth patch tells display-subsystem to use the DMC devfreq device. I am waiting for your feedback. Note: This RFC needs patchset[1]. Its purpose is to addresses the review that was made in v1[2]. I dropped some patches in v2 to address things separately (in that RFC). [1]: https://patchwork.kernel.org/cover/10901577/ [2]: https://lkml.org/lkml/fancy/2018/8/2/7 Best regards, Gaël PORTAY (3): PM / devfreq: add devfreq_lock/unlock() functions drm: rockchip: Add DDR devfreq support. clk: rockchip: merge clk-ddr in dmc devfreq driver arm64: dts: rockchip: Set the display-subsystem devfreq arch/arm64/boot/dts/rockchip/rk3399-gru.dtsi | 4 + arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 +- drivers/clk/rockchip/Makefile | 1 - drivers/clk/rockchip/clk-ddr.c | 147 -------------- drivers/clk/rockchip/clk-rk3399.c | 2 - drivers/clk/rockchip/clk.c | 9 - drivers/clk/rockchip/clk.h | 33 --- drivers/devfreq/devfreq.c | 200 ++++++++++++++++++- drivers/devfreq/rk3399_dmc.c | 42 ++-- drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 51 ++++- drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 6 + drivers/gpu/drm/rockchip/rockchip_drm_fb.c | 177 +++++++++++++++- drivers/gpu/drm/rockchip/rockchip_drm_fb.h | 3 +- drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 82 ++++++++ include/linux/devfreq.h | 64 ++++++ 15 files changed, 611 insertions(+), 212 deletions(-) delete mode 100644 drivers/clk/rockchip/clk-ddr.c -- 2.21.0

1 5

[PATCH v3 0/3] backlight: lm3630a: bug fix and fwnode support
by Brian Masney 01 May '19

01 May '19

Here is a patch series that fixes a single bug and adds fwnode support to the lm3630a driver. This work was tested on a LG Nexus 5 (hammerhead) phone. My status page at https://masneyb.github.io/nexus-5-upstream/ describes what is working so far with the upstream kernel. See the individual patches for the changelog. Brian Masney (3): backlight: lm3630a: return 0 on success in update_status functions dt-bindings: backlight: add lm3630a bindings backlight: lm3630a: add firmware node support .../leds/backlight/lm3630a-backlight.yaml | 124 ++++++++++++++++ drivers/video/backlight/lm3630a_bl.c | 132 +++++++++++++++++- 2 files changed, 252 insertions(+), 4 deletions(-) create mode 100644 Documentation/devicetree/bindings/leds/backlight/lm3630a-backlight.yaml -- 2.20.1

3 8

Re: [PATCH v2] drm: introduce a capability flag for syncobj timeline support
by Koenig, Christian 01 May '19

01 May '19

Am 01.05.2019 11:00 schrieb Lionel Landwerlin <lionel.g.landwerlin(a)intel.com>: [CAUTION: External Email] On 16/04/2019 20:53, Dave Airlie wrote: > On Tue, 16 Apr 2019 at 22:58, Lionel Landwerlin > <lionel.g.landwerlin(a)intel.com> wrote: >> Unfortunately userspace users of this API cannot be publicly disclosed >> yet. >> >> This commit effectively disables timeline syncobj ioctls for all >> drivers. Each driver wishing to support this feature will need to >> expose DRIVER_SYNCOBJ_TIMELINE. >> >> v2: Add uAPI capability check (Christian) >> >> Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com> >> Reviewed-by: Christian König <christian.koenig(a)amd.com> (v1) >> Cc: Dave Airlie <airlied(a)redhat.com> >> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> >> Cc: Christian König <christian.koenig(a)amd.com> >> Cc: Chunming Zhou <david1.zhou(a)amd.com> > LGTM, > > Reviewed-by: Dave Airlie <airlied(a)redhat.com> > > Not sure if I'm due anymore misc-next pulls, if so would be good to > have it go that way, but otherwise I can pull it into -next when I get > some time. > > Dave. > Christian, Dave, Who should pull these patches in? I was assuming Dave does this. I could do it tomorrow, but today is a holiday here and I am not even close to my laptop. Christian. Thanks, -Lionel

2 1

[PATCH 1/2] drm: report consistent errors when checking syncobj capibility
by Lionel Landwerlin 01 May '19

01 May '19

We've been somewhat inconsistent when adding the new ioctl and returned ENODEV instead of EOPNOTSUPPORTED upon failing the syncobj capibility. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin(a)intel.com> Fixes: ea569910cbab98 ("drm/syncobj: add transition iotcls between binary and timeline v2") Fixes: 01d6c357837918 ("drm/syncobj: add support for timeline point wait v8") Cc: Dave Airlie <airlied(a)redhat.com> Cc: Christian König <christian.koenig(a)amd.com> Cc: Chunming Zhou <david1.zhou(a)amd.com> --- drivers/gpu/drm/drm_syncobj.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index c534c5d46f1e..fb65f13d25cf 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -756,7 +756,7 @@ drm_syncobj_transfer_ioctl(struct drm_device *dev, void *data, int ret; if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ)) - return -ENODEV; + return -EOPNOTSUPP; if (args->pad) return -EINVAL; @@ -1107,7 +1107,7 @@ drm_syncobj_timeline_wait_ioctl(struct drm_device *dev, void *data, int ret = 0; if (!drm_core_check_feature(dev, DRIVER_SYNCOBJ)) - return -ENODEV; + return -EOPNOTSUPP; if (args->flags & ~(DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL | DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT | -- 2.21.0.392.gf8f6787159e

6 10

nouveau-next 5.2
by Ben Skeggs 01 May '19

01 May '19

Hey Dave, No major changes ready for this round, but a few misc fixes instead. Ben. The following changes since commit 7c13e5cc2391950541f41fc9ab0336aae77c7f63: Merge tag 'drm-intel-next-fixes-2019-04-25' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2019-04-26 11:35:59 +1000) are available in the Git repository at: git://github.com/skeggsb/linux linux-5.2 for you to fetch changes up to 30df16b93b25fe345e4c5d4e9c789d3f4f337b72: drm/nouveau/nouveau: forward error generated while resuming objects tree (2019-05-01 11:08:39 +1000) ---------------------------------------------------------------- Bjorn Helgaas (1): drm/nouveau: Remove duplicate ACPI_VIDEO_NOTIFY_PROBE definition Colin Ian King (1): drm/nouveau/fb/ramgk104: fix spelling mistake "sucessfully" -> "successfully" Jon Derrick (4): drm/nouveau/bar/nv50: check bar1 vmm return value drm/nouveau/bar/nv50: ensure BAR is mapped drm/nouveau/bar/gf100: ensure BAR is mapped drm/nouveau/mmu: qualify vmm during dtor Lyude Paul (1): drm/nouveau/i2c: Disable i2c bus access after ->fini() Tobias Klausmann (1): drm/nouveau/nouveau: forward error generated while resuming objects tree drivers/gpu/drm/nouveau/include/nvkm/subdev/i2c.h | 2 ++ drivers/gpu/drm/nouveau/nouveau_display.c | 9 -------- drivers/gpu/drm/nouveau/nouveau_drm.c | 12 ++++++++++- drivers/gpu/drm/nouveau/nvkm/subdev/bar/gf100.c | 2 ++ drivers/gpu/drm/nouveau/nvkm/subdev/bar/nv50.c | 14 +++++++++--- drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgk104.c | 2 +- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.c | 26 ++++++++++++++++++++++- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/aux.h | 2 ++ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/base.c | 15 +++++++++++++ drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.c | 21 +++++++++++++++++- drivers/gpu/drm/nouveau/nvkm/subdev/i2c/bus.h | 1 + drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +- 12 files changed, 91 insertions(+), 17 deletions(-)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2019