dri-devel June 2020

dri-devel@lists.freedesktop.org

315 participants
731 discussions

[PATCH 1/3] drm/dp_mst: Fix the DDC I2C device unregistration of an MST port
by Imre Deak 10 Jun '20

10 Jun '20

The WARN below triggers during the removal of an MST port. The problem is that the parent device's (the connector's kdev) sysfs directory is removed recursively when the connector is unregistered (even though the I2C device holds a reference on the parent device). To fix this set first the Peer Device Type to none which will remove the I2C device. Note that atm, inconsistently, the parent of the I2C device is initially set to the DRM kdev and after a Connection Status Notification the parent may be reset to be the connector's kdev. This problem is addressed by the next patch. [ 4462.989299] ------------[ cut here ]------------ [ 4463.014940] sysfs group 'power' not found for kobject 'i2c-24' [ 4463.034664] WARNING: CPU: 0 PID: 970 at fs/sysfs/group.c:281 sysfs_remove_group+0x71/0x80 [ 4463.044357] Modules linked in: snd_hda_intel i915 drm_kms_helper(O) drm netconsole snd_hda_codec_hdmi mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul snd_intel_dspcf g crc32_pclmul snd_hda_codec snd_hwdep ghash_clmulni_intel snd_hda_core asix usbnet kvm_intel mii i2c_algo_bit snd_pcm syscopyarea sysfillrect e1000e sysimgblt fb_sys_fops prim e_numbers ptp pps_core i2c_i801 r8169 mei_me realtek mei [last unloaded: drm] [ 4463.044399] CPU: 0 PID: 970 Comm: kworker/0:2 Tainted: G O 5.7.0+ #172 [ 4463.044402] Hardware name: Intel Corporation Tiger Lake Client Platform/TigerLake U DDR4 SODIMM RVP [ 4463.044423] Workqueue: events drm_dp_delayed_destroy_work [drm_kms_helper] [ 4463.044428] RIP: 0010:sysfs_remove_group+0x71/0x80 [ 4463.044431] Code: 48 89 df 5b 5d 41 5c e9 cd b6 ff ff 48 89 df e8 95 b4 ff ff eb cb 49 8b 14 24 48 8b 75 00 48 c7 c7 20 0f 3f 82 e8 9f c5 d7 ff <0f> 0b 5b 5d 41 5c c3 0f 1f 84 00 00 00 00 00 48 85 f6 74 31 41 54 [ 4463.044433] RSP: 0018:ffffc900018bfbf0 EFLAGS: 00010282 [ 4463.044436] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001 [ 4463.044439] RDX: 0000000080000001 RSI: ffff88849e828f38 RDI: 00000000ffffffff [ 4463.052970] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:100:plane 2B] 00000000c2160caa state to 00000000d172564a [ 4463.070533] RBP: ffffffff820cea20 R08: ffff88847f4b8958 R09: 0000000000000000 [ 4463.070535] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88848a725018 [ 4463.070537] R13: 0000000000000000 R14: ffffffff827090e0 R15: 0000000000000002 [ 4463.070539] FS: 0000000000000000(0000) GS:ffff88849e800000(0000) knlGS:0000000000000000 [ 4463.070541] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 4463.070543] CR2: 00007fdf8a756538 CR3: 0000000489684001 CR4: 0000000000760ef0 [ 4463.070545] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 4463.070547] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 4463.070549] PKRU: 55555554 [ 4463.070551] Call Trace: [ 4463.070560] device_del+0x84/0x400 [ 4463.070571] cdev_device_del+0x10/0x30 [ 4463.070578] put_i2c_dev+0x69/0x80 [ 4463.070584] i2cdev_detach_adapter+0x2e/0x60 [ 4463.070591] notifier_call_chain+0x34/0x90 [ 4463.070599] blocking_notifier_call_chain+0x3f/0x60 [ 4463.070606] device_del+0x7c/0x400 [ 4463.087817] ? lockdep_init_map_waits+0x57/0x210 [ 4463.087825] device_unregister+0x11/0x60 [ 4463.087829] i2c_del_adapter+0x249/0x310 [ 4463.087846] drm_dp_port_set_pdt+0x6b/0x2c0 [drm_kms_helper] [ 4463.087862] drm_dp_delayed_destroy_work+0x2af/0x350 [drm_kms_helper] [ 4463.087876] process_one_work+0x268/0x600 [ 4463.105438] ? __schedule+0x30c/0x920 [ 4463.105451] worker_thread+0x37/0x380 [ 4463.105457] ? process_one_work+0x600/0x600 [ 4463.105462] kthread+0x140/0x160 [ 4463.105466] ? kthread_park+0x80/0x80 [ 4463.105474] ret_from_fork+0x24/0x50 Cc: <stable(a)vger.kernel.org> Signed-off-by: Imre Deak <imre.deak(a)intel.com> --- drivers/gpu/drm/drm_dp_mst_topology.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 2a309fb2c4cc..02c800b8199f 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -4669,12 +4669,13 @@ static void drm_dp_tx_work(struct work_struct *work) static inline void drm_dp_delayed_destroy_port(struct drm_dp_mst_port *port) { + drm_dp_port_set_pdt(port, DP_PEER_DEVICE_NONE, port->mcs); + if (port->connector) { drm_connector_unregister(port->connector); drm_connector_put(port->connector); } - drm_dp_port_set_pdt(port, DP_PEER_DEVICE_NONE, port->mcs); drm_dp_mst_put_port_malloc(port); } -- 2.23.1

3 9

[PATCH] dma-buf: Move dma_buf_release() from fops to dentry_ops
by Sumit Semwal 10 Jun '20

10 Jun '20

Charan Teja reported a 'use-after-free' in dmabuffs_dname [1], which happens if the dma_buf_release() is called while the userspace is accessing the dma_buf pseudo fs's dmabuffs_dname() in another process, and dma_buf_release() releases the dmabuf object when the last reference to the struct file goes away. I discussed with Arnd Bergmann, and he suggested that rather than tying the dma_buf_release() to the file_operations' release(), we can tie it to the dentry_operations' d_release(), which will be called when the last ref to the dentry is removed. The path exercised by __fput() calls f_op->release() first, and then calls dput, which eventually calls d_op->d_release(). In the 'normal' case, when no userspace access is happening via dma_buf pseudo fs, there should be exactly one fd, file, dentry and inode, so closing the fd will kill of everything right away. In the presented case, the dentry's d_release() will be called only when the dentry's last ref is released. Therefore, lets move dma_buf_release() from fops->release() to d_ops->d_release(). Many thanks to Arnd for his FS insights :) [1]: https://lore.kernel.org/patchwork/patch/1238278/ Fixes: bb2bb9030425 ("dma-buf: add DMA_BUF_SET_NAME ioctls") Reported-by: syzbot+3643a18836bce555bff6(a)syzkaller.appspotmail.com Cc: <stable(a)vger.kernel.org> [5.3+] Cc: Arnd Bergmann <arnd(a)arndb.de> Reported-by: Charan Teja Reddy <charante(a)codeaurora.org> Signed-off-by: Sumit Semwal <sumit.semwal(a)linaro.org> --- drivers/dma-buf/dma-buf.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 01ce125f8e8d..92ba4b6ef3e7 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -54,8 +54,11 @@ static char *dmabuffs_dname(struct dentry *dentry, char *buffer, int buflen) dentry->d_name.name, ret > 0 ? name : ""); } +static void dma_buf_release(struct dentry *dentry); + static const struct dentry_operations dma_buf_dentry_ops = { .d_dname = dmabuffs_dname, + .d_release = dma_buf_release, }; static struct vfsmount *dma_buf_mnt; @@ -77,14 +80,14 @@ static struct file_system_type dma_buf_fs_type = { .kill_sb = kill_anon_super, }; -static int dma_buf_release(struct inode *inode, struct file *file) +static void dma_buf_release(struct dentry *dentry) { struct dma_buf *dmabuf; - if (!is_dma_buf_file(file)) - return -EINVAL; + if (dentry->d_op != &dma_buf_dentry_ops) + return; - dmabuf = file->private_data; + dmabuf = dentry->d_fsdata; BUG_ON(dmabuf->vmapping_counter); @@ -110,7 +113,6 @@ static int dma_buf_release(struct inode *inode, struct file *file) module_put(dmabuf->owner); kfree(dmabuf->name); kfree(dmabuf); - return 0; } static int dma_buf_mmap_internal(struct file *file, struct vm_area_struct *vma) @@ -412,7 +414,6 @@ static void dma_buf_show_fdinfo(struct seq_file *m, struct file *file) } static const struct file_operations dma_buf_fops = { - .release = dma_buf_release, .mmap = dma_buf_mmap_internal, .llseek = dma_buf_llseek, .poll = dma_buf_poll, -- 2.27.0

2 2

[PATCH 0/6] RFC Support hot device unplug in amdgpu
by Andrey Grodzovsky 10 Jun '20

10 Jun '20

This RFC is a more of a proof of concept then a fully working solution as there are a few unresolved issues we are hopping to get advise on from people on the mailing list. Until now extracting a card either by physical extraction (e.g. eGPU with thunderbold connection or by emulation through syfs -> /sys/bus/pci/devices/device_id/remove) would cause random crashes in user apps. The random crashes in apps were mostly due to the app having mapped a device backed BO into it's adress space was still trying to access the BO while the backing device was gone. To answer this first problem Christian suggested to fix the handling of mapped memory in the clients when the device goes away by forcibly unmap all buffers the user processes has by clearing their respective VMAs mapping the device BOs. Then when the VMAs try to fill in the page tables again we check in the fault handler if the device is removed and if so, return an error. This will generate a SIGBUS to the application which can then cleanly terminate. This indeed was done but this in turn created a problem of kernel OOPs were the OOPSes were due to the fact that while the app was terminating because of the SIGBUS it would trigger use after free in the driver by calling to accesses device structures that were already released from the pci remove sequence. This we handled by introducing a 'flush' seqence during device removal were we wait for drm file reference to drop to 0 meaning all user clients directly using this device terminated. With this I was able to cleanly emulate device unplug with X and glxgears running and later emulate device plug back and restart of X and glxgears. But this use case is only partial and as I see it all the use cases are as follwing and the questions it raises. 1) Application accesses a BO by opening drm file 1.1) BO is mapped into applications address space (BO is CPU visible) - this one we have a solution for by invaldating BO's CPU mapping casuing SIGBUS and termination and waiting for drm file refcound to drop to 0 before releasing the device 1.2) BO is not mapped into applcation address space (BO is CPU invisible) - no solution yet because how we force the application to terminate in this case ? 2) Application accesses a BO by importing a DMA-BUF 2.1) BO is mapped into applications address space (BO is CPU visible) - solution is same as 1.1 but instead of waiting for drm file release we wait for the imported dma-buf's file release 2.2) BO is not mapped into applcation address space (BO is CPU invisible) - our solution is to invalidate GPUVM page tables and destroy backing storage for all exported BOs which will in turn casue VM faults in the importing device and then when the importing driver will try to re-attach the imported BO to update mappings we return -ENODEV in the import hook which hopeffuly will cause the user app to terminate. 3) Applcation opens a drm file or imports a dma-bud and holds a reference but never access any BO or does access but never more after device was unplug - how would we force this applcation to termiante before proceeding with device removal code ? Otherwise the wait in pci remove just hangs for ever. The attached patches adress 1.1, 2.1 and 2.2, for now only 1.1 fully tested and I am still testing the others but I will be happy for any advise on all the described use cases and maybe some alternative and better (more generic) approach to this like maybe obtaining PIDs of relevant processes through some revere mapping from device file and exported dma-buf files and send them SIGKILL - would this make more sense or any other method ? Patches 1-3 address 1.1 Patch 4 addresses 2.1 Pathces 5-6 address 2.2 Reference: https://gitlab.freedesktop.org/drm/amd/-/issues/1081 Andrey Grodzovsky (6): drm/ttm: Add unampping of the entire device address space drm/amdgpu: Force unmap all user VMAs on device removal. drm/amdgpu: Wait for all user clients drm/amdgpu: Wait for all clients importing out dma-bufs. drm/ttm: Add destroy flag in TTM BO eviction interface drm/amdgpu: Use TTM MMs destroy interface drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 2 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 7 +++- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 27 ++++++++++++- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 22 ++++++++-- drivers/gpu/drm/amd/amdgpu/amdgpu_job.c | 9 +++++ drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 4 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 17 +++++++- drivers/gpu/drm/amd/amdgpu/amdgpu_object.h | 1 + drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- drivers/gpu/drm/qxl/qxl_object.c | 4 +- drivers/gpu/drm/radeon/radeon_object.c | 2 +- drivers/gpu/drm/ttm/ttm_bo.c | 63 +++++++++++++++++++++-------- drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 6 +-- include/drm/ttm/ttm_bo_api.h | 2 +- include/drm/ttm/ttm_bo_driver.h | 2 + 16 files changed, 139 insertions(+), 34 deletions(-) -- 2.7.4

9 30

A panic and a hang in the i915 drm driver
by David Howells 10 Jun '20

10 Jun '20

Hi, I'm seeing the attached oops and panic from the i915 drm driver. I've tried bisecting it, but there's a problem in that one of the merged branches causes the machine to hang without output. The oops for commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 looks like: BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.7.0-rc2-fscache+ #883 Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014 RIP: 0010:intel_psr_enabled+0xb/0x6e Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 10 5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6 83 5e 08 00 00 20 75 05 45 31 e4 eb 44 80 RSP: 0000:ffff88840dedfa18 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8884086f9000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8884086f9000 RDI: 0000000000000128 RBP: ffff8884086fb000 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000001 R11: 00000000000000ff R12: ffff888408680000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff8884086fb200 FS: 0000000000000000(0000) GS:ffff88840fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000000440c001 CR4: 00000000001606e0 Call Trace: intel_read_dp_sdp+0x71/0x2c5 hsw_crt_get_config+0x18/0x41 intel_modeset_readout_hw_state+0x24d/0x662 ? do_raw_spin_lock+0x8b/0xcd ? _raw_spin_lock_irqsave+0x10/0x16 intel_modeset_setup_hw_state+0xa8/0xb59 ? __next_node_in+0x39/0x42 ? ww_mutex_lock+0x3d/0x1da ? modeset_lock+0xd4/0x114 ? drm_modeset_lock_all_ctx+0x86/0xcc intel_modeset_init+0x285/0x5bf ? intel_irq_postinstall+0x485/0x4d1 i915_driver_probe+0x1b4/0x49c ? __kernfs_new_node+0x161/0x1b2 ? rpm_resume+0x45e/0x485 i915_pci_probe+0xfd/0x11d ? __pm_runtime_resume+0x51/0x5e local_pci_probe+0x39/0x7a pci_device_probe+0xf5/0x14f ? sysfs_do_create_link_sd.isra.0+0x77/0xa3 really_probe+0x140/0x2a9 driver_probe_device+0x9c/0xd1 device_driver_attach+0x3c/0x55 __driver_attach+0x97/0x9f ? device_driver_attach+0x55/0x55 bus_for_each_dev+0x72/0xa8 bus_add_driver+0x108/0x1b9 driver_register+0x9e/0xd7 ? mipi_dsi_bus_init+0x11/0x11 i915_init+0x58/0x6b do_one_initcall+0x83/0x18a kernel_init_freeable+0x19b/0x1fd ? rest_init+0x9f/0x9f kernel_init+0xa/0xfa ret_from_fork+0x1f/0x30 Modules linked in: CR2: 0000000000000000 ---[ end trace d0c4f561618aeb37 ]--- RIP: 0010:intel_psr_enabled+0xb/0x6e Code: 8b 44 24 08 65 48 33 04 25 28 00 00 00 74 05 e8 7e ff 97 ff 48 83 c4 10 5b 5d 41 5c 41 5d c3 0f 1f 44 00 00 41 55 41 54 55 53 <48> 8b 9f d8 fe ff ff f6 83 5e 08 00 00 20 75 05 45 31 e4 eb 44 80 RSP: 0000:ffff88840dedfa18 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8884086f9000 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff8884086f9000 RDI: 0000000000000128 RBP: ffff8884086fb000 R08: 0000000000000000 R09: 0000000000000001 R10: 0000000000000001 R11: 00000000000000ff R12: ffff888408680000 R13: 0000000000000000 R14: 0000000000000000 R15: ffff8884086fb200 FS: 0000000000000000(0000) GS:ffff88840fb00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000000440c001 CR4: 00000000001606e0 Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 Kernel Offset: disabled ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 ]--- Decoding the RIP gives: RIP: 0010:intel_psr_enabled (/data/fs/linux-fs/build3/../drivers/gpu/drm/i915/display/intel_display_types.h:1595 /data/fs/linux-fs/build3/../drivers/gpu/drm/i915/display/intel_psr.c:1598) Commit c41219fda6e04255c44d37fd2c0d898c1c46abf1 ("Merge tag 'drm-intel-next-fixes-2020-05-20' of git://anongit.freedesktop.org/drm/drm-intel into drm-next") is definitely bad and logs an oops to the console and panics, but it's a merge. On one side is e20bb857dea2f620ff37ae541ed8aee70e3c89f1 ("Merge tag 'exynos-drm-next-for-v5.8' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next"), which hangs. This is also a merge. One side of e20bb is f84e1ba336a4f47ae251e4d2d8a694902571b0df ("drm/exynos-vidi: convert platform driver to use dev_groups") which is good. The other side of c4121 and e20bb derive from the same line of commits, with three patches between. All of these, down to at least 230982d8d8df7f9d9aa216840ea2db1df6ad5d37 ("drm/i915: Update DRIVER_DATE to 20200430") cause the machine to hang without any sort of console output. Commit bfbe1744e4417986419236719922a9a7fda224d1 ("Merge tag 'amd-drm-next-5.8-2020-05-19' of git://people.freedesktop.org/~agd5f/linux into drm-next") is good. Commit 47e51832ae93534d872511ba557115722582d94c ("drm/i915/gvt: use context lrc_reg_state for shadow ppgtt override") is good. I've attached the git log and the config file. David

4 7

[PULL] drm-intel-next-fixes
by Joonas Lahtinen 10 Jun '20

10 Jun '20

Hi Dave & Daniel, Sending this one early for it to hopefully make it in before -rc1. Two important fixes: OOPS fix that was missing "Fixes:" tag and not picked up earlier. Also fix for a use-after-free in cmdparser. Additional fixup to module param types. Regards, Joonas *** drm-intel-next-fixes-2020-06-10: - Avoid use after free in cmdparser - Avoid NULL dereference when probing all display encoders - Fixup to module parameter type The following changes since commit 8d286e2ff4400d313955b4203fc640ca6fd9228b: Merge tag 'drm-intel-next-fixes-2020-06-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-next (2020-06-08 11:59:57 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2020-06-10 for you to fetch changes up to 3680c2e9f4254d1f033bf00f540e47a51f8f996b: drm/i915/display: Only query DP state of a DDI encoder (2020-06-09 14:47:05 +0300) ---------------------------------------------------------------- - Avoid use after free in cmdparser - Avoid NULL dereference when probing all display encoders - Fixup to module parameter type ---------------------------------------------------------------- Chris Wilson (2): drm/i915/gem: Mark the buffer pool as active for the cmdparser drm/i915/display: Only query DP state of a DDI encoder Jani Nikula (1): drm/i915/params: fix i915.reset module param type drivers/gpu/drm/i915/display/intel_dp.c | 3 ++ drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 56 ++++++++++++++++++++++---- drivers/gpu/drm/i915/i915_params.c | 2 +- 3 files changed, 52 insertions(+), 9 deletions(-)

1 1

[PATCH] drm/sun4i: hdmi ddc clk: Fix size of m divider
by Jernej Skrabec 10 Jun '20

10 Jun '20

m divider in DDC clock register is 4 bits wide. Fix that. Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support") Signed-off-by: Jernej Skrabec <jernej.skrabec(a)siol.net> --- drivers/gpu/drm/sun4i/sun4i_hdmi.h | 2 +- drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h b/drivers/gpu/drm/sun4i/sun4i_hdmi.h index 7ad3f06c127e..00ca35f07ba5 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h @@ -148,7 +148,7 @@ #define SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE 3 #define SUN4I_HDMI_DDC_CLK_REG 0x528 -#define SUN4I_HDMI_DDC_CLK_M(m) (((m) & 0x7) << 3) +#define SUN4I_HDMI_DDC_CLK_M(m) (((m) & 0xf) << 3) #define SUN4I_HDMI_DDC_CLK_N(n) ((n) & 0x7) #define SUN4I_HDMI_DDC_LINE_CTRL_REG 0x540 diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c index 2ff780114106..12430b9d4e93 100644 --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_ddc_clk.c @@ -33,7 +33,7 @@ static unsigned long sun4i_ddc_calc_divider(unsigned long rate, unsigned long best_rate = 0; u8 best_m = 0, best_n = 0, _m, _n; - for (_m = 0; _m < 8; _m++) { + for (_m = 0; _m < 16; _m++) { for (_n = 0; _n < 8; _n++) { unsigned long tmp_rate; -- 2.26.0

4 8

[PATCH v1 0/6] drm: add a few simple panels
by Sam Ravnborg 09 Jun '20

09 Jun '20

Push a few patches that has been sitting in my tree for far too long time. Adds a few more panels to panel-simple, including documentation of the compatible. I have added the last few people that added new panels to panel-simple to the cc list, in the hope to speed up the review process a little. Sam Sam Ravnborg (6): dt-bindings: panel: add Seiko 70WVW2T 7" panel drm: panel-simple: add Seiko 70WVW2T 7" simple panel dt-bindings: panel: add Hitachi 3,5" QVGA panel drm: panel-simple: add Hitachi 3.5" QVGA panel dt-bindings: panel: add LOGIC Technologies panels drm: panel-simple: add LOGIC Technologies panels .../bindings/display/panel/panel-simple.yaml | 8 ++ drivers/gpu/drm/panel/panel-simple.c | 127 +++++++++++++++++++++ 2 files changed, 135 insertions(+)

4 15

[PATCH 1/2] dt-bindings: panel-simple: Add koe, tx26d202vm0bwa compatible
by Liu Ying 09 Jun '20

09 Jun '20

Add compatible to panel-simple for Kaohsiung Opto-Electronics Inc. 10.1" WUXGA(1920x1200) TX26D202VM0BWA TFT LCD panel with LVDS interface. Cc: Thierry Reding <thierry.reding(a)gmail.com> Cc: Sam Ravnborg <sam(a)ravnborg.org> Cc: Rob Herring <robh+dt(a)kernel.org> Signed-off-by: Liu Ying <victor.liu(a)nxp.com> --- Documentation/devicetree/bindings/display/panel/panel-simple.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index d6cca14..31e3efc 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -157,6 +157,8 @@ properties: - innolux,zj070na-01p # Kaohsiung Opto-Electronics Inc. 5.7" QVGA (320 x 240) TFT LCD panel - koe,tx14d24vm1bpa + # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel + - koe,tx26d202vm0bwa # Kaohsiung Opto-Electronics. TX31D200VM0BAA 12.3" HSXGA LVDS panel - koe,tx31d200vm0baa # Kyocera Corporation 12.1" XGA (1024x768) TFT LCD panel -- 2.7.4

2 1

[PATCH 1/2] drm/amd: correct trivial kernel-doc inconsistencies
by Colton Lewis 09 Jun '20

09 Jun '20

Silence documentation warnings by correcting kernel-doc comments. ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3388: warning: Excess function parameter 'suspend' description in 'amdgpu_device_suspend' ./drivers/gpu/drm/amd/amdgpu/amdgpu_device.c:3485: warning: Excess function parameter 'resume' description in 'amdgpu_device_resume' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:418: warning: Excess function parameter 'tbo' description in 'amdgpu_vram_mgr_del' ./drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c:418: warning: Excess function parameter 'place' description in 'amdgpu_vram_mgr_del' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:279: warning: Excess function parameter 'tbo' description in 'amdgpu_gtt_mgr_del' ./drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:279: warning: Excess function parameter 'place' description in 'amdgpu_gtt_mgr_del' ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:332: warning: Function parameter or member 'hdcp_workqueue' not described in 'amdgpu_display_manager' ./drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h:332: warning: Function parameter or member 'cached_dc_state' not described in 'amdgpu_display_manager' Signed-off-by: Colton Lewis <colton.w.lewis(a)protonmail.com> --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 2 -- drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 2 -- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h | 2 ++ 4 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c index a027a8f7b281..dd7da7b4b696 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c @@ -3377,7 +3377,6 @@ void amdgpu_device_fini(struct amdgpu_device *adev) * amdgpu_device_suspend - initiate device suspend * * @dev: drm dev pointer - * @suspend: suspend state * @fbcon : notify the fbdev of suspend * * Puts the hw in the suspend state (all asics). @@ -3474,7 +3473,6 @@ int amdgpu_device_suspend(struct drm_device *dev, bool fbcon) * amdgpu_device_resume - initiate device resume * * @dev: drm dev pointer - * @resume: resume state * @fbcon : notify the fbdev of resume * * Bring the hw back to operating state (all asics). diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c index 627104401e84..bc01a06546aa 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c @@ -268,8 +268,6 @@ static int amdgpu_gtt_mgr_new(struct ttm_mem_type_manager *man, * amdgpu_gtt_mgr_del - free ranges * * @man: TTM memory type manager - * @tbo: TTM BO we need this range for - * @place: placement flags and restrictions * @mem: TTM memory object * * Free the allocated GTT again. diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c index d399e5893170..97ad8ffe6c6c 100644 --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c @@ -407,8 +407,6 @@ static int amdgpu_vram_mgr_new(struct ttm_mem_type_manager *man, * amdgpu_vram_mgr_del - free ranges * * @man: TTM memory type manager - * @tbo: TTM BO we need this range for - * @place: placement flags and restrictions * @mem: TTM memory object * * Free the allocated VRAM again. diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h index d61186ff411d..86c132ddc452 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h @@ -139,10 +139,12 @@ struct amdgpu_dm_backlight_caps { * @backlight_link: Link on which to control backlight * @backlight_caps: Capabilities of the backlight device * @freesync_module: Module handling freesync calculations + * @hdcp_workqueue: AMDGPU content protection queue * @fw_dmcu: Reference to DMCU firmware * @dmcu_fw_version: Version of the DMCU firmware * @soc_bounding_box: SOC bounding box values provided by gpu_info FW * @cached_state: Caches device atomic state for suspend/resume + * @cached_dc_state: Cached state of content streams * @compressor: Frame buffer compression buffer. See &struct dm_comressor_info */ struct amdgpu_display_manager { -- 2.26.2

2 1

[PATCH v3 00/39] Introduce memory interconnect for NVIDIA Tegra SoCs
by Dmitry Osipenko 09 Jun '20

09 Jun '20

Hello, This series brings initial support for memory interconnect to Tegra20 and Tegra30 SoCs. For the starter only display controllers are getting interconnect API support, others could be supported later on. The display controllers have the biggest demand for interconnect API right now because dynamic memory frequency scaling can't be done safely without taking into account bandwidth requirement from the displays. Changelog: v3: - Added acks from Rob Herring that were given to some of the v2 patches. - Specified name of the TRM documentation chapter in the patch "dt-bindings: host1x: Document new interconnect properties", which was suggested by Rob Herring in the review comment to v2. - Added patches that allow EMC drivers to be compiled as a loadable kernel modules. This came up during of the v2 review when Georgi Djakov pointed out that interconnect-core could be compiled as a kernel module. Please note that the Tegra124 EMC driver is compile-tested only, I don't have Tegra124 HW. - In the review comment to [1] Stephen Boyd suggested that it will be better not to make changes to clk API, which was needed in order to avoid clashing of the interconnect driver with the devfreq in regards to memory clk-rate rounding. [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200330231617.17079… Stephen Boyd suggested that instead we should provide OPP table via DT. I tried to investigate whether this could be done and turned out it's a bit complicated. Technically it should be doable, but: 1. For now we don't fully support voltage scaling of the CORE regulator and so OPP table in the DT isn't really needed today. We can generate table from the memory timings, which is what Tegra devfreq drivers already do. 2. The OPP table should be defined in the DT for the Memory Controller node and then its usage somehow should be shared by both interconnect and devfreq drivers. It's not obvious what's the best way to do it. So, it will be much better to postpone the DT OPP table addition until these questions are resolved. We can infer OPPs from the memory timings and we could get the memory rates from the memory driver directly, avoiding the problems induced by the clk API usage. This idea is implemented in v3, see these patches: PM / devfreq: tegra20: Use MC timings for building OPP table PM / devfreq: tegra30: Use MC timings for building OPP table v2: - Instead of a single dma-mem interconnect path, the paths are now defined per memory client. - The EMC provider now uses #interconnect-cells=<0>. - Dropped Tegra124 because there is no enough information about how to properly calculate required EMC clock rate for it and I don't have hardware for testing. Somebody else will have to work on it. - Moved interconnect providers code into drivers/memory/tegra/*. - Added "Create tegra20-devfreq device" patch because interconnect is not very usable without the devfreq memory auto-scaling since memory freq will be fixed to the display's requirement. Artur Świgoń (1): interconnect: Relax requirement in of_icc_get_from_provider() Dmitry Osipenko (38): clk: Export clk_hw_reparent() clk: tegra: Remove Memory Controller lock clk: tegra: Export Tegra20 EMC kernel symbols memory: tegra20-emc: Make driver modular memory: tegra30-emc: Make driver modular memory: tegra124-emc: Make driver modular memory: tegra124-emc: Use devm_platform_ioremap_resource soc/tegra: fuse: Export tegra_read_ram_code() memory: tegra20-emc: Initialize MC timings PM / devfreq: tegra20: Silence deferred probe error PM / devfreq: tegra30: Silence deferred probe error PM / devfreq: tegra20: Use MC timings for building OPP table PM / devfreq: tegra30: Use MC timings for building OPP table PM / devfreq: tegra20: Add error messages to tegra_devfreq_target() PM / devfreq: tegra30: Add error messages to tegra_devfreq_target() PM / devfreq: tegra20: Adjust clocks conversion ratio and polling interval PM / devfreq: tegra20: Relax Kconfig dependency dt-bindings: memory: tegra20: mc: Document new interconnect property dt-bindings: memory: tegra20: emc: Document new interconnect property dt-bindings: memory: tegra30: mc: Document new interconnect property dt-bindings: memory: tegra30: emc: Document new interconnect property dt-bindings: host1x: Document new interconnect properties dt-bindings: memory: tegra20: Add memory client IDs dt-bindings: memory: tegra30: Add memory client IDs ARM: tegra: Add interconnect properties to Tegra20 device-tree ARM: tegra: Add interconnect properties to Tegra30 device-tree memory: tegra: Register as interconnect provider memory: tegra20-emc: Use devm_platform_ioremap_resource memory: tegra20-emc: Continue probing if timings are missing in device-tree memory: tegra20-emc: Register as interconnect provider memory: tegra20-emc: Create tegra20-devfreq device memory: tegra30-emc: Continue probing if timings are missing in device-tree memory: tegra30-emc: Register as interconnect provider drm/tegra: dc: Support memory bandwidth management drm/tegra: dc: Tune up high priority request controls for Tegra20 drm/tegra: dc: Extend debug stats with total number of events ARM: tegra: Enable interconnect API in tegra_defconfig ARM: multi_v7_defconfig: Enable interconnect API .../display/tegra/nvidia,tegra20-host1x.txt | 68 +++++ .../memory-controllers/nvidia,tegra20-emc.txt | 2 + .../memory-controllers/nvidia,tegra20-mc.txt | 3 + .../nvidia,tegra30-emc.yaml | 6 + .../memory-controllers/nvidia,tegra30-mc.yaml | 5 + arch/arm/boot/dts/tegra20.dtsi | 22 +- arch/arm/boot/dts/tegra30.dtsi | 23 +- arch/arm/configs/multi_v7_defconfig | 1 + arch/arm/configs/tegra_defconfig | 1 + drivers/clk/clk.c | 1 + drivers/clk/tegra/clk-divider.c | 4 +- drivers/clk/tegra/clk-tegra114.c | 6 +- drivers/clk/tegra/clk-tegra124-emc.c | 63 ++-- drivers/clk/tegra/clk-tegra124.c | 8 +- drivers/clk/tegra/clk-tegra20-emc.c | 3 + drivers/clk/tegra/clk-tegra20.c | 3 +- drivers/clk/tegra/clk-tegra30.c | 3 +- drivers/clk/tegra/clk.h | 14 +- drivers/devfreq/Kconfig | 2 +- drivers/devfreq/tegra20-devfreq.c | 52 ++-- drivers/devfreq/tegra30-devfreq.c | 115 +++++-- drivers/gpu/drm/tegra/dc.c | 289 +++++++++++++++++- drivers/gpu/drm/tegra/dc.h | 13 + drivers/gpu/drm/tegra/drm.c | 19 ++ drivers/gpu/drm/tegra/plane.c | 1 + drivers/gpu/drm/tegra/plane.h | 4 +- drivers/interconnect/core.c | 11 +- drivers/memory/tegra/Kconfig | 6 +- drivers/memory/tegra/mc.c | 121 ++++++++ drivers/memory/tegra/mc.h | 8 + drivers/memory/tegra/tegra124-emc.c | 35 ++- drivers/memory/tegra/tegra20-emc.c | 219 +++++++++++-- drivers/memory/tegra/tegra30-emc.c | 160 ++++++++-- drivers/soc/tegra/fuse/tegra-apbmisc.c | 2 + include/dt-bindings/memory/tegra20-mc.h | 53 ++++ include/dt-bindings/memory/tegra30-mc.h | 67 ++++ include/linux/clk/tegra.h | 11 + include/soc/tegra/emc.h | 16 - include/soc/tegra/mc.h | 3 + 39 files changed, 1245 insertions(+), 198 deletions(-) delete mode 100644 include/soc/tegra/emc.h -- 2.26.0

2 42

← Newer
1
...
56
57
58
59
60
61
62
...
74
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel June 2020