summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2021-07-21drivers/firmware: move x86 Generic System Framebuffers supportJavier Martinez Canillas6-0/+501
The x86 architecture has generic support to register a system framebuffer platform device. It either registers a "simple-framebuffer" if the config option CONFIG_X86_SYSFB is enabled, or a legacy VGA/VBE/EFI FB device. But the code is generic enough to be reused by other architectures and can be moved out of the arch/x86 directory. This will allow to also support the simple{fb,drm} drivers on non-x86 EFI platforms, such as aarch64 where these drivers are only supported with DT. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210625130947.1803678-2-javierm@redhat.com
2021-07-21vgaarb: don't pass a cookie to vga_client_registerChristoph Hellwig6-33/+31
The VGA arbitration is entirely based on pci_dev structures, so just pass that back to the set_vga_decode callback. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-8-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2021-07-21vgaarb: remove the unused irq_set_state argument to vga_client_registerChristoph Hellwig6-27/+6
All callers pass NULL as the irq_set_state argument, so remove it and the ->irq_set_state member in struct vga_device. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-7-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2021-07-21vgaarb: provide a vga_client_unregister wrapperChristoph Hellwig7-9/+8
Add a trivial wrapper for the unregister case that sets all fields to NULL. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-6-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2021-07-21vgaarb: move the kerneldoc for vga_set_legacy_decoding to vgaarb.cChristoph Hellwig1-0/+11
Kerneldoc comments should be at the implementation side, not in the header just declaring the prototype. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-4-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2021-07-21vgaarb: remove vga_conflictsChristoph Hellwig1-6/+0
vga_conflicts only has a single caller and none of the arch overrides mentioned in the comment. Just remove it and the thus dead check in the caller. Signed-off-by: Christoph Hellwig <hch@lst.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716061634.2446357-3-hch@lst.de Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
2021-07-21drm/v3d: Expose performance counters to userspaceJuan A. Suarez Romero7-0/+334
The V3D engine has several hardware performance counters that can of interest for userspace performance analysis tools. This exposes new ioctls to create and destroy performance monitor objects, as well as to query the counter values. Each created performance monitor object has an ID that can be attached to CL/CSD submissions, so the driver enables the requested counters when the job is submitted, and updates the performance monitor values when the job is done. It is up to the user to ensure all the jobs have been finished before getting the performance monitor values. It is also up to the user to properly synchronize BCL jobs when submitting jobs with different performance monitors attached. Cc: Daniel Vetter <daniel@ffwll.ch> Cc: David Airlie <airlied@linux.ie> Cc: Emma Anholt <emma@anholt.net> To: dri-devel@lists.freedesktop.org Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com> Acked-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210608111541.461991-1-jasuarez@igalia.com
2021-07-20drm: protect drm_master pointers in drm_lease.cDesmond Cheong Zhi Xi2-20/+86
drm_file->master pointers should be protected by drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, in drm_lease.c, there are multiple instances where drm_file->master is accessed and dereferenced while neither lock is held. This makes drm_lease.c vulnerable to use-after-free bugs. We address this issue in 2 ways: 1. Add a new drm_file_get_master() function that calls drm_master_get on drm_file->master while holding on to drm_file.master_lookup_lock. Since drm_master_get increments the reference count of master, this prevents master from being freed until we unreference it with drm_master_put. 2. In each case where drm_file->master is directly accessed and eventually dereferenced in drm_lease.c, we wrap the access in a call to the new drm_file_get_master function, then unreference the master pointer once we are done using it. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-6-desmondcheongzx@gmail.com
2021-07-20drm: serialize drm_file.master with a new spinlockDesmond Cheong Zhi Xi2-6/+12
Currently, drm_file.master pointers should be protected by drm_device.master_mutex when being dereferenced. This is because drm_file.master is not invariant for the lifetime of drm_file. If drm_file is not the creator of master, then drm_file.is_master is false, and a call to drm_setmaster_ioctl will invoke drm_new_set_master, which then allocates a new master for drm_file and puts the old master. Thus, without holding drm_device.master_mutex, the old value of drm_file.master could be freed while it is being used by another concurrent process. However, it is not always possible to lock drm_device.master_mutex to dereference drm_file.master. Through the fbdev emulation code, this might occur in a deep nest of other locks. But drm_device.master_mutex is also the outermost lock in the nesting hierarchy, so this leads to potential deadlocks. To address this, we introduce a new spin lock at the bottom of the lock hierarchy that only serializes drm_file.master. With this change, the value of drm_file.master changes only when both drm_device.master_mutex and drm_file.master_lookup_lock are held. Hence, any process holding either of those locks can ensure that the value of drm_file.master will not change concurrently. Since no lock depends on the new drm_file.master_lookup_lock, when drm_file.master is dereferenced, but drm_device.master_mutex cannot be held, we can safely protect the master pointer with drm_file.master_lookup_lock. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-5-desmondcheongzx@gmail.com
2021-07-20drm: add a locked version of drm_is_current_masterDesmond Cheong Zhi Xi1-19/+32
While checking the master status of the DRM file in drm_is_current_master(), the device's master mutex should be held. Without the mutex, the pointer fpriv->master may be freed concurrently by another process calling drm_setmaster_ioctl(). This could lead to use-after-free errors when the pointer is subsequently dereferenced in drm_lease_owner(). The callers of drm_is_current_master() from drm_auth.c hold the device's master mutex, but external callers do not. Hence, we implement drm_is_current_master_locked() to be used within drm_auth.c, and modify drm_is_current_master() to grab the device's master mutex before checking the master status. Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-4-desmondcheongzx@gmail.com
2021-07-20drm: avoid blocking in drm_clients_info's rcu sectionDesmond Cheong Zhi Xi1-1/+2
Inside drm_clients_info, the rcu_read_lock is held to lock pid_task()->comm. However, within this protected section, a call to drm_is_current_master is made, which involves a mutex lock in a future patch. However, this is illegal because the mutex lock might block while in the RCU read-side critical section. Since drm_is_current_master isn't protected by rcu_read_lock, we avoid this by moving it out of the RCU critical section. The following report came from intel-gfx ci's igt@debugfs_test@read_all_entries testcase: ============================= [ BUG: Invalid wait context ] 5.13.0-CI-Patchwork_20515+ #1 Tainted: G W ----------------------------- debugfs_test/1101 is trying to lock: ffff888132d901a8 (&dev->master_mutex){+.+.}-{3:3}, at: drm_is_current_master+0x1e/0x50 other info that might help us debug this: context-{4:4} 3 locks held by debugfs_test/1101: #0: ffff88810fdffc90 (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0x53/0x3b0 #1: ffff888132d90240 (&dev->filelist_mutex){+.+.}-{3:3}, at: drm_clients_info+0x63/0x2a0 #2: ffffffff82734220 (rcu_read_lock){....}-{1:2}, at: drm_clients_info+0x1b1/0x2a0 stack backtrace: CPU: 8 PID: 1101 Comm: debugfs_test Tainted: G W 5.13.0-CI-Patchwork_20515+ #1 Hardware name: Intel Corporation CometLake Client Platform/CometLake S UDIMM (ERB/CRB), BIOS CMLSFWR1.R00.1263.D00.1906260926 06/26/2019 Call Trace: dump_stack+0x7f/0xad __lock_acquire.cold.78+0x2af/0x2ca lock_acquire+0xd3/0x300 ? drm_is_current_master+0x1e/0x50 ? __mutex_lock+0x76/0x970 ? lockdep_hardirqs_on+0xbf/0x130 __mutex_lock+0xab/0x970 ? drm_is_current_master+0x1e/0x50 ? drm_is_current_master+0x1e/0x50 ? drm_is_current_master+0x1e/0x50 drm_is_current_master+0x1e/0x50 drm_clients_info+0x107/0x2a0 seq_read_iter+0x178/0x3b0 seq_read+0x104/0x150 full_proxy_read+0x4e/0x80 vfs_read+0xa5/0x1b0 ksys_read+0x5a/0xd0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-3-desmondcheongzx@gmail.com
2021-07-20drm: avoid circular locks in drm_mode_getconnectorDesmond Cheong Zhi Xi1-1/+4
In preparation for a future patch to take a lock on drm_device.master_mutex inside drm_is_current_master(), we first move the call to drm_is_current_master() in drm_mode_getconnector out from the section locked by &dev->mode_config.mutex. This avoids creating a circular lock dependency. Failing to avoid this lock dependency produces the following lockdep splat: ====================================================== WARNING: possible circular locking dependency detected 5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted ------------------------------------------------------ kms_frontbuffer/1087 is trying to acquire lock: ffff88810dcd01a8 (&dev->master_mutex){+.+.}-{3:3}, at: drm_is_current_master+0x1b/0x40 but task is already holding lock: ffff88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_mode_getconnector+0x1c6/0x4a0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (&dev->mode_config.mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_probe+0x22e/0xca0 __drm_fb_helper_initial_config_and_unlock+0x42/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #1 (&client->modeset_mutex){+.+.}-{3:3}: __mutex_lock+0xab/0x970 drm_client_modeset_commit_locked+0x1c/0x180 drm_client_modeset_commit+0x1c/0x40 __drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0 drm_fb_helper_set_par+0x34/0x40 intel_fbdev_set_par+0x11/0x40 [i915] fbcon_init+0x270/0x4f0 visual_init+0xc6/0x130 do_bind_con_driver+0x1e5/0x2d0 do_take_over_console+0x10e/0x180 do_fbcon_takeover+0x53/0xb0 register_framebuffer+0x22d/0x310 __drm_fb_helper_initial_config_and_unlock+0x36c/0x540 intel_fbdev_initial_config+0xf/0x20 [i915] async_run_entry_fn+0x28/0x130 process_one_work+0x26d/0x5c0 worker_thread+0x37/0x380 kthread+0x144/0x170 ret_from_fork+0x1f/0x30 -> #0 (&dev->master_mutex){+.+.}-{3:3}: __lock_acquire+0x151e/0x2590 lock_acquire+0xd1/0x3d0 __mutex_lock+0xab/0x970 drm_is_current_master+0x1b/0x40 drm_mode_getconnector+0x37e/0x4a0 drm_ioctl_kernel+0xa8/0xf0 drm_ioctl+0x1e8/0x390 __x64_sys_ioctl+0x6a/0xa0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &dev->master_mutex --> &client->modeset_mutex --> &dev->mode_config.mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&dev->mode_config.mutex); lock(&client->modeset_mutex); lock(&dev->mode_config.mutex); lock(&dev->master_mutex); *** DEADLOCK *** 1 lock held by kms_frontbuffer/1087: #0: ffff88810dcd0488 (&dev->mode_config.mutex){+.+.}-{3:3}, at: drm_mode_getconnector+0x1c6/0x4a0 stack backtrace: CPU: 7 PID: 1087 Comm: kms_frontbuffer Not tainted 5.13.0-rc7-CI-CI_DRM_10254+ #1 Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019 Call Trace: dump_stack+0x7f/0xad check_noncircular+0x12e/0x150 __lock_acquire+0x151e/0x2590 lock_acquire+0xd1/0x3d0 __mutex_lock+0xab/0x970 drm_is_current_master+0x1b/0x40 drm_mode_getconnector+0x37e/0x4a0 drm_ioctl_kernel+0xa8/0xf0 drm_ioctl+0x1e8/0x390 __x64_sys_ioctl+0x6a/0xa0 do_syscall_64+0x39/0xb0 entry_SYSCALL_64_after_hwframe+0x44/0xae Reported-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210712043508.11584-2-desmondcheongzx@gmail.com
2021-07-20dma_buf: remove dmabuf sysfs teardown before releaseGuangming Cao1-1/+1
Dmabuf sysfs stat is used for dmabuf info track. But these file maybe still in use after buffer released, should clear it before buffer release. Signed-off-by: Guangming Cao <Guangming.Cao@mediatek.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210720103158.83439-1-guangming.cao@mediatek.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-07-20drm/bochs: Fix missing pci_disable_device() on error in bochs_pci_probe()Yang Yingliang1-1/+1
Replace pci_enable_device() with pcim_enable_device(), pci_disable_device() will be called in release automatically. v3: reformat commit message update for move to tiny/ v2: use pcim_enable_device() Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reported-by: Hulk Robot <hulkci@huawei.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210715132845.2415619-1-yangyingliang@huawei.com
2021-07-20drm/ast: Disable fast reset after DRAM initialKuoHsiang Chou3-26/+76
[Bug][AST2500] V1: When AST2500 acts as stand-alone VGA so that DRAM and DVO initialization have to be achieved by VGA driver with P2A (PCI to AHB) enabling. However, HW suggests disable Fast reset mode after DRAM initializaton, because fast reset mode is mainly designed for ARM ICE debugger. Once Fast reset is checked as enabling, WDT (Watch Dog Timer) should be first enabled to avoid system deadlock before disable fast reset mode. V2: Use to_pci_dev() to get revision of PCI configuration. V3: If SCU00 is not unlocked, just enter its password again. It is unnecessary to clear AHB lock condition and restore WDT default setting again, before Fast-reset clearing. V4: repatch after "error : could not build fake ancestor" resolved. V5: Since CVE_2019_6260 item3, Most of AST2500 have disabled P2A(PCIe to AMBA). However, for backward compatibility, some patches about P2A, such as items of v5.2 and v5.3, are considered to be upstreamed with comments. 1. Add define macro to improve source readability. ast_drv.h, ast_main.c, ast_post.c 2. Add comment about "Fast restet" is enabled for ARM-ICE debugger ast_post.c 3. Add comment about Reset USB port to patch USB unknown device issue ast_post.c Signed-off-by: KuoHsiang Chou <kuohsiang_chou@aspeedtech.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210709080900.4056-1-kuohsiang_chou@aspeedtech.com
2021-07-20drm/ast: Zero is missing in detect functionAinux.Wang1-1/+1
The function ast_get_modes() will also return 0, when it try to get the edid, but it also do not get the edid. Signed-off-by: Ainux.Wang <ainux.wang@gmail.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210716015615.9150-1-ainux.wang@gmail.com
2021-07-20dma-buf: Delete the DMA-BUF attachment sysfs statisticsHridya Valsaraju3-179/+4
The DMA-BUF attachment statistics form a subset of the DMA-BUF sysfs statistics that recently merged to the drm-misc tree. They are not UABI yet since they have not merged to the upstream Linux kernel. Since there has been a reported a performance regression due to the overhead of sysfs directory creation/teardown during dma_buf_attach()/dma_buf_detach(), this patch deletes the DMA-BUF attachment statistics from sysfs. Fixes: bdb8d06dfefd ("dmabuf: Add the capability to expose DMA-BUF stats in sysfs") Signed-off-by: Hridya Valsaraju <hridya@google.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210713040742.2680135-1-hridya@google.com Signed-off-by: Christian König <christian.koenig@amd.com>
2021-07-19drm/ingenic: Convert to Linux IRQ interfacesThomas Zimmermann1-4/+1
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. This patch also fixes a bug where the driver didn't release the IRQ. v2: * automatically release IRQ via devm_request_irq() (Paul) * mention the bugfix (Sam) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Link: https://patchwork.freedesktop.org/patch/msgid/20210715100258.6638-1-tzimmermann@suse.de
2021-07-19fbmem: Convert from atomic_t to refcount_t on fb_info->countXiyu Yang1-3/+3
refcount_t type and corresponding API can protect refcounters from accidental underflow and overflow and further use-after-free situations. Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn> Signed-off-by: Xin Tan <tanxin.ctf@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1626674392-55857-1-git-send-email-xiyuyang19@fudan.edu.cn
2021-07-19video: fbdev: kyro: fix a DoS bug by restricting user inputZheyu Ma1-0/+5
The user can pass in any value to the driver through the 'ioctl' interface. The driver dost not check, which may cause DoS bugs. The following log reveals it: divide error: 0000 [#1] PREEMPT SMP KASAN PTI RIP: 0010:SetOverlayViewPort+0x133/0x5f0 drivers/video/fbdev/kyro/STG4000OverlayDevice.c:476 Call Trace: kyro_dev_overlay_viewport_set drivers/video/fbdev/kyro/fbdev.c:378 [inline] kyrofb_ioctl+0x2eb/0x330 drivers/video/fbdev/kyro/fbdev.c:603 do_fb_ioctl+0x1f3/0x700 drivers/video/fbdev/core/fbmem.c:1171 fb_ioctl+0xeb/0x130 drivers/video/fbdev/core/fbmem.c:1185 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x19b/0x220 fs/ioctl.c:739 do_syscall_64+0x32/0x80 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae Signed-off-by: Zheyu Ma <zheyuma97@gmail.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/1626235762-2590-1-git-send-email-zheyuma97@gmail.com
2021-07-19drm/stm: dsi: compute the transition time from LP to HS and backAntonio Borneo1-4/+13
The driver uses a conservative set of hardcoded values for the maximum time delay of the transitions between LP and HS, either for data and clock lanes. By using the info in STM32MP157 datasheet, valid also for other ST devices, compute the actual delay from the lane's bps. Signed-off-by: Antonio Borneo <antonio.borneo@foss.st.com> Reviewed-by: Philippe Cornu <philippe.cornu@foss.st.com> Acked-by: Philippe Cornu <philippe.cornu@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713144941.3599-1-antonio.borneo@foss.st.com
2021-07-19drm/stm: ltdc: Silence -EPROBE_DEFER till bridge attachedJagan Teki1-3/+5
As dw-mipi-dsi supported all possible ways to find the DSI devices. It can take multiple iterations for ltdc to find all components attached to the DSI bridge. The current ltdc driver failed to find the endpoint as it returned -EINVAL for the first iteration itself. This leads to following error: [    3.099289] [drm:ltdc_load] *ERROR* init encoder endpoint 0 So, check the return value and cleanup the encoder only if it's not -EPROBE_DEFER. This make all components in the attached DSI bridge found properly. Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Tested-by: Yannick Fertre <yannick.fertre@foss.st.com> Acked-by: Philippe Cornu <philippe.cornu@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210704135914.268308-1-jagan@amarulasolutions.com
2021-07-17drm/panel: ws2401: Add driver for WideChips WS2401Linus Walleij3-0/+452
This adds a driver for panels based on the WideChips WS2401 display controller. This display controller is used in the Samsung LMS380KF01 display found in the Samsung GT-I8160 (Codina) mobile phone and possibly others. As is common with Samsung displays manufacturer commands are necessary to configure the display to a working state. The display optionally supports internal backlight control, but can also use an external backlight. This driver re-uses the DBI infrastructure to communicate with the display. Cc: phone-devel@vger.kernel.org Cc: Douglas Anderson <dianders@chromium.org> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210714225002.1065107-2-linus.walleij@linaro.org
2021-07-15drm/dp: For drm_panel_dp_aux_backlight(), init backlight as disabledDouglas Anderson1-0/+2
Even after the DP AUX backlight on my board worked OK after applying the patch ("drm/panel-simple: Power the panel when probing DP AUX backlight") [1], I still noticed some strange timeouts being reported by ti_sn_aux_transfer(). Digging, I realized the problem was this: * Even though `enabled` in `struct dp_aux_backlight` was false, the base backlight structure (`base` in that structure) thought that the backlight was powered on. * If userspace wrote to sysfs in this state then we'd try to enable the backlight. * Unfortunatley, enabling the backlight didn't work because the panel itself wasn't powered. We can only use the backlight if the panel is on and the panel is not officially on when we probe (it's temporarily just on enough for us to talk to it). The important thing we want here is to get `BL_CORE_FBBLANK` set since userspace can't mess with that. This will keep us disabled until drm_panel enables us, which means that the panel is enabled first. Ideally we'd just set this in our `props` before calling devm_backlight_device_register() but the comments in the header file are pretty explicit that we're not supposed to much with the `state` ourselves. Because of this, there may be a small window where the backlight device is registered and someone could try to tweak with the backlight. This isn't likely to happen and even if it did, I don't believe this causes any huge problem. [1] https://lore.kernel.org/lkml/20210714093334.1.Idb41f87e5abae4aee0705db7458b0097fc50e7ab@changeid/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210714101744.1.Ifc22696b27930749915e383f0108b7bcdc015a6e@changeid
2021-07-15drm/panel-simple: Power the panel when probing DP AUX backlightDouglas Anderson1-0/+3
When I tried booting up a device that needed the DP AUX backlight, I found an error in the logs: panel-simple-dp-aux: probe of aux-ti_sn65dsi86.aux.0 failed with error -110 The aux transfers were failing because the panel wasn't powered. Just like when reading the EDID we need to power the panel when trying to talk to it. Add the needed pm_runtime calls. After I do this I can successfully probe the panel and adjust the backlight on my board. Fixes: bfd451403d70 ("drm/panel-simple: Support DP AUX backlight") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210714093334.1.Idb41f87e5abae4aee0705db7458b0097fc50e7ab@changeid
2021-07-15drm/of: free the iterator object on failureSteven Price1-1/+3
When bailing out due to the sanity check the iterator value needs to be freed because the early return prevents for_each_child_of_node() from doing the dereference itself. Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order") Signed-off-by: Steven Price <steven.price@arm.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210714143300.20632-1-steven.price@arm.com
2021-07-15drm/omapdrm: Remove outdated commentThomas Zimmermann1-7/+0
The comment refers to drm_irq_install() et al, which are not used by omapdrm. The functions are part of the DRM IRQ midlayer and shouldn't be used any longer. Remove the comment. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210706073125.7689-1-tzimmermann@suse.de
2021-07-15drm/vbox: Convert to Linux IRQ interfacesThomas Zimmermann3-7/+11
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210706075011.9009-1-tzimmermann@suse.de
2021-07-15drm/qxl: Convert to Linux IRQ interfacesThomas Zimmermann3-6/+5
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210706074735.8849-1-tzimmermann@suse.de
2021-07-15drm/vc4: hdmi: Remove drm_encoder->crtc usageMaxime Ripard1-13/+27
The drm_encoder crtc pointer isn't really fit for an atomic driver, let's rely on the connector state instead. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20210707141930.1811128-1-maxime@cerno.tech
2021-07-15drm/vc4: hdmi: Only call into DRM framework if registeredMaxime Ripard1-1/+1
Our hotplug handler will currently call the drm_kms_helper_hotplug_event every time a hotplug interrupt is called. However, since the device is registered after all the drivers have finished their bind callback, we have a window between when we install our interrupt handler and when drm_dev_register() is eventually called where our handler can run and call drm_kms_helper_hotplug_event but the device hasn't been registered yet, causing a null pointer dereference. Fix this by making sure we only call drm_kms_helper_hotplug_event if our device has been properly registered. Fixes: f4790083c7c2 ("drm/vc4: hdmi: Rely on interrupts to handle hotplug") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210707095112.1469670-4-maxime@cerno.tech
2021-07-15drm/vc4: hdmi: Drop devm interrupt handler for hotplug interruptsMaxime Ripard1-13/+28
The hotplugs interrupt handlers are registered through the devm_request_threaded_irq function. However, while free_irq is indeed called properly when the device is unbound or bind fails, it's called after unbind or bind is done. In our particular case, it means that on failure it creates a window where our interrupt handler can be called, but we're freeing every resource (CEC adapter, DRM objects, etc.) it might need. In order to address this, let's switch to the non-devm variant to control better when the handler will be unregistered and allow us to make it safe. Fixes: f4790083c7c2 ("drm/vc4: hdmi: Rely on interrupts to handle hotplug") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210707095112.1469670-3-maxime@cerno.tech
2021-07-14drm/panel: Add Innolux EJ030NA 3.0" 320x480 panelChristophe Branchereau3-0/+299
Add support for the Innolux/Chimei EJ030NA 3.0" 320x480 TFT panel. This panel can be found in the LDKs, RS97 V2.1 and RG300 (non IPS) handheld gaming consoles. While being 320x480, it is actually a horizontal 4:3 panel with non-square pixels in delta arrangement. Signed-off-by: Christophe Branchereau <cbranchereau@gmail.com> Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210625121045.81711-2-paul@crapouillou.net
2021-07-13drm/shmem-helper: Align to page size in dumb_createDaniel Vetter1-2/+2
shmem helpers seem a bit sloppy here by automatically rounding up when actually creating the buffer, which results in under-reporting of what we actually have. Caught by igt/vgem_basic tests. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210603164113.1433476-4-daniel.vetter@ffwll.ch
2021-07-13drm/dp: Move panel DP AUX backlight support to drm_dp_helperDouglas Anderson2-108/+113
We were getting a depmod error: depmod: ERROR: Cycle detected: drm_kms_helper -> drm -> drm_kms_helper It looks like the rule is that drm_kms_helper can call into drm, but drm can't call into drm_kms_helper. That means we've got to move the DP AUX backlight support into drm_dp_helper. NOTE: as part of this, I didn't try to do any renames of the main registration function. Even though it's in the drm_dp_helper, it still feels very parallel to drm_panel_of_backlight(). Fixes: 10f7b40e4f30 ("drm/panel: add basic DP AUX backlight support") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Rajeev Nandan <rajeevny@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210712075933.v2.1.I23eb4cc5a680341e7b3e791632a635566fa5806a@changeid
2021-07-13drm/vkms: Use dma-buf mapping from shadow-plane state for composingThomas Zimmermann3-13/+15
Store the shadow-buffer mapping's address in struct vkms_composer and use the value when composing the output. It's the same value as stored in the GEM SHMEM BO, but frees the composer code from its dependency on GEM SHMEM. Using struct dma_buf_map is how framebuffer access is supposed to be. The long-term plan is to perform all framebuffer access via struct dma_buf_map and avoid the details of accessing I/O and system memory. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210705074633.9425-5-tzimmermann@suse.de
2021-07-13drm/vkms: Let shadow-plane helpers prepare the plane's FBThomas Zimmermann1-37/+1
Replace vkms' prepare_fb and cleanup_fb functions with the generic code for shadow-buffered planes. No functional changes. This change also fixes a problem where IGT kms_flip tests would create a segmentation fault within vkms. The driver's prepare_fb function did not report an error if a BO's vmap operation failed. The kernel later tried to operate on the non-mapped memory areas. The shared shadow-plane helpers handle errors correctly, so that the driver now avoids the segmantation fault. v2: * include paragraph about IGT tests in commit message (Melissa) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210705074633.9425-4-tzimmermann@suse.de
2021-07-13drm/vkms: Inherit plane state from struct drm_shadow_plane_stateThomas Zimmermann3-11/+12
Subclass struct drm_shadow_plane_state for VKMS planes and update all plane-state callbacks accordingly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210705074633.9425-3-tzimmermann@suse.de
2021-07-13drm/gem: Export implementation of shadow-plane helpersThomas Zimmermann1-3/+52
Export the implementation of duplicate, destroy and reset helpers for shadow-buffered plane state. Useful for drivers that subclass struct drm_shadow_plane_state. The exported functions are wrappers around plane-state implementation, but using them is the correct thing to do for drivers. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210705074633.9425-2-tzimmermann@suse.de
2021-07-13Revert "drm/vgem: Implement mmap as GEM object function"Thomas Zimmermann1-5/+41
Commit 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function") broke several IGT tests in vgem_basic. [1] Attempts to fix the issue have not worked out so far. [2][3] Revert the change for now. Note that there is a patch that converts vgem to shmem helpers. [4] Merging this change would be preferable to modifying vgem's mmap code. v2: * fix spelling error in commit message (Daniel) [1] https://intel-gfx-ci.01.org/tree/drm-tip/igt@vgem_basic@unload.html [2] https://lore.kernel.org/intel-gfx/20210709154256.12005-1-tzimmermann@suse.de/ [3] https://lore.kernel.org/intel-gfx/20210712123321.3658-1-tzimmermann@suse.de/ [4] https://patchwork.freedesktop.org/series/90671/ Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 375cca1cfeb5 ("drm/vgem: Implement mmap as GEM object function") Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Christian König <christian.koenig@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: "Christian König" <christian.koenig@amd.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Melissa Wen <melissa.srw@gmail.com> Cc: Qinglang Miao <miaoqinglang@huawei.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210713090235.26372-1-tzimmermann@suse.de
2021-07-12drm/of: free the right objectJulia Lawall1-1/+1
There is no need to free a NULL value. Instead, free the object that is leaking due to the iterator. The semantic patch that finds this problem is as follows: // <smpl> @@ expression x,e; identifier f; @@ x = f(...); if (x == NULL) { ... when any when != x = e * of_node_put(x); ... } // </smpl> Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order") Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210709200717.3676376-1-Julia.Lawall@inria.fr
2021-07-12drm/panfrost:fix the exception name always "UNKNOWN"ChunyouTang1-1/+1
The exception_code in register is only 8 bits,So if fault_status in panfrost_gpu_irq_handler() don't (& 0xFF),it can't get correct exception reason. and it's better to show all of the register value to custom,so it's better fault_status don't (& 0xFF). Signed-off-by: ChunyouTang <tangchunyou@icubecorp.cn> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210708073407.2015-1-tangchunyou@163.com
2021-07-10drm: bridge: nwl-dsi: Drop unused nwl_dsi_plat_clk_configJagan Teki1-6/+0
nwl_dsi_plat_clk_config structure added in below commit but not used anywhere in the driver. commit <44cfc6233447c> ("drm/bridge: Add NWL MIPI DSI host controller support") Drop it. Cc: Guido Günther <agx@sigxcpu.org> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Guido Günther <agx@sigxcpu.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210704093433.27717-1-jagan@amarulasolutions.com
2021-07-09drm/panel: simple: Add support for EDT ETM0350G0DH6 panelStefan Riedmueller1-0/+29
This patch adds support for the EDT ETM0350G0DH6 3.5" (320x240) lcd panel to DRM simple panel driver. Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de> Signed-off-by: Yunus Bas <y.bas@phytec.de> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210709200349.2665205-2-y.bas@phytec.de
2021-07-09drm/panel: simple: Add support for EDT ETMV570G2DHU panelStefan Riedmueller1-0/+29
This patch adds support for the EDT ETMV570G2DHU 5.7" (640x480) lcd panel to DRM simple panel driver. Signed-off-by: Stefan Riedmueller <s.riedmueller@phytec.de> Signed-off-by: Yunus Bas <y.bas@phytec.de> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210709200349.2665205-1-y.bas@phytec.de
2021-07-09drm/gma500: Add the missed drm_gem_object_put() in psb_user_framebuffer_create()Jing Xiangfeng1-1/+6
psb_user_framebuffer_create() misses to call drm_gem_object_put() in an error path. Add the missed function call to fix it. Signed-off-by: Jing Xiangfeng <jingxiangfeng@huawei.com> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210629115956.15160-1-jingxiangfeng@huawei.com
2021-07-09drm/panel-simple: Add Samsung ATNA33XC20Rajeev Nandan1-0/+33
Add Samsung 13.3" FHD eDP AMOLED panel. Signed-off-by: Rajeev Nandan <rajeevny@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1624726268-14869-7-git-send-email-rajeevny@codeaurora.org
2021-07-09drm/panel-simple: Update validation warnings for eDP panel descriptionRajeev Nandan1-4/+2
Do not give a warning for the eDP panels if the "bus_format" is not specified, since most eDP panels can support more than one bus formats and this can be auto-detected. Also, update the check to include bpc=10 for the eDP panel. Signed-off-by: Rajeev Nandan <rajeevny@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1624726268-14869-5-git-send-email-rajeevny@codeaurora.org
2021-07-09drm/panel-simple: Support for delays between GPIO & regulatorRajeev Nandan1-0/+28
Some panels datasheets may specify a delay between the enable GPIO and the regulator. Support this in panel-simple. Signed-off-by: Rajeev Nandan <rajeevny@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1624726268-14869-4-git-send-email-rajeevny@codeaurora.org
2021-07-09drm/panel-simple: Support DP AUX backlightRajeev Nandan1-0/+6
If there is no backlight specified in the device tree and the panel has access to the DP AUX channel then create a DP AUX backlight if supported by the panel. Signed-off-by: Rajeev Nandan <rajeevny@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/1624726268-14869-3-git-send-email-rajeevny@codeaurora.org
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-17 12:42:54 +0000