- Sep 24, 2024
-
-
Replace the open-coded v3d_perfmon_find() with the real thing. Signed-off-by:
Christian Gmeiner <cgmeiner@igalia.com> Reviewed-by:
Maíra Canal <mcanal@igalia.com> Signed-off-by:
Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240923152000.185980-1-christian.gmeiner@gmail.com
-
Add support for the drm_panic module for DU variants not using the VSP-compositor, to display a message on the screen when a kernel panic occurs. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Jocelyn Falempe <jfalempe@redhat.com> Acked-by:
Sui Jingfeng <sui.jingfeng@linux.dev> Link: https://patchwork.freedesktop.org/patch/msgid/b633568d2e3f405b21debdd60854fe39780254d6.1716816897.git.geert+renesas@glider.be Signed-off-by:
Maxime Ripard <mripard@kernel.org>
-
Add support for the drm_panic module, which displays a message on the screen when a kernel panic occurs. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Jocelyn Falempe <jfalempe@redhat.com> Acked-by:
Sui Jingfeng <sui.jingfeng@linux.dev> Link: https://patchwork.freedesktop.org/patch/msgid/292638fde9aef8b00e984245f43dc02a818cf322.1716816827.git.geert+renesas@glider.be Signed-off-by:
Maxime Ripard <mripard@kernel.org>
-
Without the locking amdgpu currently can race between amdgpu_ctx_set_entity_priority() (via drm_sched_entity_modify_sched()) and drm_sched_job_arm(), leading to the latter accesing potentially inconsitent entity->sched_list and entity->num_sched_list pair. v2: * Improve commit message. (Philipp) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@igalia.com> Fixes: b37aced3 ("drm/scheduler: implement a function to modify sched list") Cc: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Luben Tuikov <ltuikov89@gmail.com> Cc: Matthew Brost <matthew.brost@intel.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Philipp Stanner <pstanner@redhat.com> Cc: <stable@vger.kernel.org> # v5.7+ Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240924101914.2713-2-tursulin@igalia.com Signed-off-by:
Christian König <christian.koenig@amd.com>
-
Uprev mesa, IGT to the latest version and deqp-runner to v0.20.0. Also update expectation files. Acked-by:
Helen Koike <helen.koike@collabora.com> Reviewed-by:
Daniel Stone <daniels@collabora.com> Signed-off-by:
Vignesh Raman <vignesh.raman@collabora.com> Signed-off-by:
Helen Koike <helen.koike@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240910131927.161883-1-vignesh.raman@collabora.com
-
Function drm_sched_entity_push_job() doesn't have a return value, remove the return value description for it. Correct several other typo errors. v2 (Philipp): - more correction with related comments. Signed-off-by:
Shuicheng Lin <shuicheng.lin@intel.com> Reviewed-by:
Philipp Stanner <pstanner@redhat.com> Signed-off-by:
Simona Vetter <simona.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20240917144732.2758572-1-shuicheng.lin@intel.com
-
Fix a typo in comments. Reported-by:
Matthew Wilcox <willy@infradead.org> Signed-off-by:
Andrew Kreimer <algonell@gmail.com> Signed-off-by:
Simona Vetter <simona.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20240909135655.45938-1-algonell@gmail.com
-
Thomas Zimmermann authored
Several places in drm.ko use struct drm_rect and its helpers. This only works as the called interfaces are declared as static inline in the header file. Fix the issue by linking drm_rect.o into drm.ko. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240919185436.86790-1-tzimmermann@suse.de
-
- Sep 23, 2024
-
-
The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Cc: stable@vger.kernel.org Fixes: dd86dc2f ("drm/sti: implement atomic_check for the planes") Signed-off-by:
Ma Ke <make24@iscas.ac.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20240913090412.2022848-1-make24@iscas.ac.cn Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com>
-
The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Cc: stable@vger.kernel.org Fixes: dd86dc2f ("drm/sti: implement atomic_check for the planes") Signed-off-by:
Ma Ke <make24@iscas.ac.cn> Acked-by:
Alain Volmat <alain.volmat@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240909063359.1197065-1-make24@iscas.ac.cn Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com>
-
The return value of drm_atomic_get_crtc_state() needs to be checked. To avoid use of error pointer 'crtc_state' in case of the failure. Cc: stable@vger.kernel.org Fixes: dd86dc2f ("drm/sti: implement atomic_check for the planes") Signed-off-by:
Ma Ke <make24@iscas.ac.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20240913090926.2023716-1-make24@iscas.ac.cn Signed-off-by:
Alain Volmat <alain.volmat@foss.st.com>
-
This patch tries to improve the display of the code listing on The Linux Kernel documentation website for dma-buf [1] . Originally, it appears that it was attempting to escape the '*' character, but looks like it's not necessary (now), so we are seeing something like '\*' on the webite. This patch removes these unnecessary backslashes and adds syntax highlighting to improve the readability of the code listing. [1] https://docs.kernel.org/driver-api/dma-buf.html Signed-off-by:
Tommy Chiang <ototot@chromium.org> Reviewed-by:
T.J. Mercier <tjmercier@google.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240119033126.1802711-1-ototot@chromium.org Signed-off-by:
Christian König <christian.koenig@amd.com>
-
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from of_device_id table. Signed-off-by:
Liao Chen <liaochen4@huawei.com> Reviewed-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240902113320.903147-4-liaochen4@huawei.com Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded based on the alias from of_device_id table. Signed-off-by:
Liao Chen <liaochen4@huawei.com> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240902113320.903147-2-liaochen4@huawei.com Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
i.MX28 has an RX DMA channel associated with the LCDIF controller. Document the 'dmas' and 'dma-names' properties to fix the following dt-schema warnings: lcdif@80030000: 'dma-names', 'dmas' do not match any of the regexes: 'pinctrl-[0-9]+' Signed-off-by:
Fabio Estevam <festevam@denx.de> Reviewed-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240903162729.1151134-1-festevam@gmail.com [DB: added extra empty line, requested by Krzysztof] Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
- Sep 22, 2024
-
-
Linus Walleij authored
The commit introducing the Frida display started to write the SETVCMOFF registers unconditionally, and some (not all!) Hydis display seem to be affected by ghosting after the commit. Make SETVCMOFF optional and only send these commands on the Frida display for now. Reported-by:
Stefan Hansson <newbyte@postmarketos.org> Fixes: 219a1f49 ("drm/panel: nt35510: support FRIDA FRD400B25025-A-CTK") Acked-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Tested-by:
Stefan Hansson <newbyte@postmarketos.org> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240908-fix-nt35510-v2-1-d4834b9cdb9b@linaro.org
-
When drm/bridge-connector was moved to DRM_DISPLAY_HELPER not all users were updated. Add missing Kconfig selections. Fixes: 9da7ec9b ("drm/bridge-connector: move to DRM_DISPLAY_HELPER module") Signed-off-by:
Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by:
Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240906063857.2223442-1-alexander.stein@ew.tq-group.com Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Add quirk orientation for AYA NEO GEEK. The name appears without spaces in DMI strings. The board name is completely different to the previous models making it difficult to reuse their quirks despite being the same resolution and using the same orientation. Tested by the JELOS team that has been patching their own kernel for a while now and confirmed by users in the AYA NEO and ChimeraOS discord servers. Signed-off-by:
Joaquín Ignacio Aramendía <samsagax@gmail.com> Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/40350b0d63fe2b54e7cba1e14be50917203f0079.1726492131.git.tjakobi@math.uni-bielefeld.de Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Add quirk orientation for AYA NEO Founder. The name appears with spaces in DMI strings as other devices of the brand. The panel is the same as the NEXT and 2021 models. Those could not be reused as the former has VENDOR name as "AYANEO" without spaces and the latter has "AYADEVICE". Tested by the JELOS team that has been patching their own kernel for a while now and confirmed by users in the AYA NEO and ChimeraOS discord servers. Signed-off-by:
Joaquín Ignacio Aramendía <samsagax@gmail.com> Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/f71889a0b39f13f4b78481bd030377ca15035680.1726492131.git.tjakobi@math.uni-bielefeld.de Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Add quirk orientation for AYA NEO 2. The name appears without spaces in DMI strings. That made it difficult to reuse the 2021 match. Also the display is larger in resolution. Tested by the JELOS team that has been patching their own kernel for a while now and confirmed by users in the AYA NEO and ChimeraOS discord servers. Signed-off-by:
Joaquín Ignacio Aramendía <samsagax@gmail.com> Signed-off-by:
Tobias Jakobi <tjakobi@math.uni-bielefeld.de> Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/2b35545b77a9fd8c9699b751ca282226dcecb1dd.1726492131.git.tjakobi@math.uni-bielefeld.de Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
- Sep 21, 2024
-
-
disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 47b1be5c ("staging: imx/drm: request irq only after adding the crtc") Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by:
Philipp Zabel <p.zabel@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-4-ruanjinjie@huawei.com Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 9021c317 ("drm/imx: Add initial support for DCSS on iMX8MQ") Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by:
Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by:
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-3-ruanjinjie@huawei.com Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
disable_irq() after request_irq() still has a time gap in which interrupts can come. request_irq() with IRQF_NO_AUTOEN flag will disable IRQ auto-enable when request IRQ. Fixes: 9021c317 ("drm/imx: Add initial support for DCSS on iMX8MQ") Signed-off-by:
Jinjie Ruan <ruanjinjie@huawei.com> Reviewed-by:
Laurentiu Palcu <laurentiu.palcu@oss.nxp.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240912083020.3720233-2-ruanjinjie@huawei.com [DB: fixed the subject] Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
- Sep 20, 2024
-
-
When invoke memfd_pin_folios, we need offer an array to save each folio which we pinned. The current way is dynamic alloc an array(use kvmalloc), get folios, save into udmabuf and then free. Depend on the size, kvmalloc can do something different: Below PAGE_SIZE, slab allocator will be used, which have good alloc performance, due to it cached page. PAGE_SIZE - PCP Order, PCP(per-cpu-pageset) also given buddy page a cache in each CPU, so different CPU no need to hold some lock(zone or some) to get the locally page. If PCP cached page, the access also fast. PAGE_SIZE - BUDDY_MAX, try to get page from buddy, due to kvmalloc adjusted the gfp flags, if zone freelist can't alloc page(fast path), we will not enter slowpath to reclaim memory. Due to need hold lock and check, may slow, but still fast than vmalloc. Anything wrong will fallback into vmalloc to alloc memory, it obtains contiguous virtual addresses by loop alloc order 0 page(PAGE_SIZE), and then map it into vmalloc area. If necessary, page alloc may enter slowpath to reclaim memory. Hence, if fallback into vmalloc, it's slow. When create, we need to iter each udmabuf item, then pin it's range folios, if each item's range folio's count is large, we may fallback each into vmalloc. This patch find the largest range folio in items, then alloc this size's folio array. When pin range folios, reuse this array. Signed-off-by:
Huan Yang <link@vivo.com> Acked-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-8-link@vivo.com
-
Currently, udmabuf handles folio by create an unpin list to record each folio obtained from the list and unpinning them when released. To maintain this, many struct have been established. However, maintain this requires a significant amount of memory and iter the list is a substantial overhead, which is not friendly to the CPU cache. When create, we arranged the folio array in the order of pin and set the offset according to pgcnt. So, if record each pinned folio when create, then can easy unpin it. Compare to use list to record it, an array also can do this. Hence, this patch setup a pinned_folios array(size is the pgcnt) to instead of udmabuf_folio struct, it record each folio which pinned when invoke memfd_pin_folios, then unpin folio by iter pinned_folios. Note that, since a folio may be pinned multiple times, each folio can be added to pinned_folios multiple times, depend on how many times the folio has been pinned when create. Compare to udmabuf_folio(24 byte size), a folio pointer is 8 byte, if no large folio - each folio is PAGE_SIZE - and need to unpin when release. So need to record each folio, by this patch, each folio can save 16 byte. But if large folio used, depend on the large folio's number, the pinned_folios array may take more memory, but it still can makes unpin access more cache-friendly. Signed-off-by:
Huan Yang <link@vivo.com> Acked-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-7-link@vivo.com
-
After udmabuf is allocated, its resources need to be initialized, including various array structures. The current array structure has already been greatly expanded. Also, before udmabuf needs to be kfree, the occupied resources need to be released. This part is repetitive and maybe overlooked. This patch give a helper function when init and deinit, by this, reduce duplicate code. Signed-off-by:
Huan Yang <link@vivo.com> Acked-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-6-link@vivo.com
-
This patch aim to simplify the memfd folio pin during the udmabuf create. No functional changes. This patch create a udmabuf_pin_folios function, in this, do the memfd pin folio and then record each pinned folio, offset. This patch simplify the pinned folio record, iter by each pinned folio, and then record each offset in it. Compare to iter by pgcnt, more readable. Suggested-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Huan Yang <link@vivo.com> Acked-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-5-link@vivo.com
-
Currently vmap_udmabuf set page's array by each folio. But, ubuf->folios is only contain's the folio's head page. That mean we repeatedly mapped the folio head page to the vmalloc area. Due to udmabuf can use hugetlb, if HVO enabled, tail page may not exist, so, we can't use page array to map, instead, use pfn array. By this, we removed page usage in udmabuf totally. Fixes: 5e72b2b4 ("udmabuf: convert udmabuf driver to use folios") Suggested-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Huan Yang <link@vivo.com> Acked-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-4-link@vivo.com
-
When PAGE_SIZE 4096, MAX_PAGE_ORDER 10, 64bit machine, page_alloc only support 4MB. If above this, trigger this warn and return NULL. udmabuf can change size limit, if change it to 3072(3GB), and then alloc 3GB udmabuf, will fail create. [ 4080.876581] ------------[ cut here ]------------ [ 4080.876843] WARNING: CPU: 3 PID: 2015 at mm/page_alloc.c:4556 __alloc_pages+0x2c8/0x350 [ 4080.878839] RIP: 0010:__alloc_pages+0x2c8/0x350 [ 4080.879470] Call Trace: [ 4080.879473] <TASK> [ 4080.879473] ? __alloc_pages+0x2c8/0x350 [ 4080.879475] ? __warn.cold+0x8e/0xe8 [ 4080.880647] ? __alloc_pages+0x2c8/0x350 [ 4080.880909] ? report_bug+0xff/0x140 [ 4080.881175] ? handle_bug+0x3c/0x80 [ 4080.881556] ? exc_invalid_op+0x17/0x70 [ 4080.881559] ? asm_exc_invalid_op+0x1a/0x20 [ 4080.882077] ? udmabuf_create+0x131/0x400 Because MAX_PAGE_ORDER, kmalloc can max alloc 4096 * (1 << 10), 4MB memory, each array entry is pointer(8byte), so can save 524288 pages(2GB). Further more, costly order(order 3) may not be guaranteed that it can be applied for, due to fragmentation. This patch change udmabuf array use kvmalloc_array, this can fallback alloc into vmalloc, which can guarantee allocation for any size and does not affect the performance of kmalloc allocations. Signed-off-by:
Huan Yang <link@vivo.com> Acked-by:
Christian König <christian.koenig@amd.com> Acked-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-3-link@vivo.com
-
The current udmabuf mmap only fills the physical memory to the corresponding virtual address when the user actually accesses the virtual address. However, the current udmabuf has already obtained and pinned the folio upon completion of the creation.This means that the physical memory has already been acquired, rather than being accessed dynamically. As a result, the page fault has lost its purpose as a demanding page. Due to the fact that page fault requires trapping into kernel mode and filling in when accessing the corresponding virtual address in mmap, when creating a large size udmabuf, this represents a considerable overhead. This patch fill the pfn into page table, and then pre-fault each pfn into vma, when first access. Notice, if anything wrong , we do not return an error during this pre-fault step. However, an error will be returned if the failure occurs when the addr is truly accessed Suggested-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Huan Yang <link@vivo.com> Acked-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240918025238.2957823-2-link@vivo.com
-
Vivek Kasireddy authored
I would like to help maintain the udmabuf driver, in light of the recent changes that converted the driver to use folios instead of pages. Furthermore, I also contribute to Qemu's virtio-gpu module (and UI modules), that are primary users of udmabuf driver. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Gerd Hoffmann <kraxel@redhat.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240822045806.3563883-1-vivek.kasireddy@intel.com
-
Thomas Hellström authored
Condsider the following call sequence: /* Upper layer */ dma_fence_begin_signalling(); lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); ... The driver might here use a utility that is annotated as intended for the dma-fence signalling critical path. Now if the upper layer isn't correctly annotated yet for whatever reason, resulting in /* Upper layer */ lock(tainted_shared_lock); /* Driver callback */ dma_fence_begin_signalling(); We will receive a false lockdep locking order violation notification from dma_fence_begin_signalling(). However entering a dma-fence signalling critical section itself doesn't block and could not cause a deadlock. So use a successful read_trylock() annotation instead for dma_fence_begin_signalling(). That will make sure that the locking order is correctly registered in the first case, and doesn't register any locking order in the second case. The alternative is of course to make sure that the "Upper layer" is always correctly annotated. But experience shows that's not easily achievable in all cases. Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230428125233.228353-1-thomas.hellstrom@linux.intel.com
-
- Sep 19, 2024
-
-
On RK3399 the VOPL is loaded before VOPB and get registered as crtc-0. However, on RK3288 and PX30 VOPB is gets registered as crtc-0 instead of VOPL. With VOPL registered as crtc-0 the kernel kms client is not able to enable 4K display modes for console use on RK3399. Load VOPB before VOPL to help kernel kms client make use of 4K display modes for console use on RK3399. Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-8-jonas@kwiboo.se
-
Use a maximum TMDS clock rate limit of 594MHz to enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3399 and RK3568. Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Tested-by: Diederik de Haas <didi.debian@cknow.org> # Quartz64 Model B Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-7-jonas@kwiboo.se
-
The previous tables for mpll_cfg and curr_ctrl were created using the 20-pages of example settings provided by the PHY vendor. Those example settings weren't particularly dense, so there were places where we were guessing what the settings would be for 10-bit and 12-bit (not that we use those anyway). It was also always a lot of extra work every time we wanted to add a new clock rate since we had to cross-reference several tables. In <https://crrev.com/c/285855 > I've gone through the work to figure out how to generate this table automatically. Let's now use the automatically generated table and then we'll never need to look at it again. We only support 8-bit mode right now and only support a small number of clock rates and I've verified that the only 8-bit rate that was affected was 148.5. That mode appears to have been wrong in the old table. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Yakir Yang <ykk@rock-chips.com> Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-6-jonas@kwiboo.se
-
Jitter was improved by lowering the MPLL bandwidth to account for high frequency noise in the rk3288 PLL. In each case MPLL bandwidth was lowered only enough to get us a comfortable margin. We believe that lowering the bandwidth like this is safe given sufficient testing. Signed-off-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
Yakir Yang <ykk@rock-chips.com> Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-5-jonas@kwiboo.se
-
Add phy_config for 594Mhz pixel clock used for HDMI2.0 display modes. Signed-off-by:
Nickey Yang <nickey.yang@rock-chips.com> Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-4-jonas@kwiboo.se
-
Dut to the high HDMI signal voltage driver, Mickey have meet a serious RF/EMI problem, so we decided to reduce HDMI signal voltage to a proper value. The default params for phy is cklvl = 20 & txlvl = 13 (RF/EMI failed) ck: lvl = 13, term=100, vlo = 2.71, vhi=3.14, vswing = 0.43 tx: lvl = 20, term=100, vlo = 2.81, vhi=3.16, vswing = 0.35 1. We decided to reduce voltage value to lower, but VSwing still keep high, RF/EMI have been improved but still failed. ck: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50 tx: lvl = 6, term=100, vlo = 2.61, vhi=3.11, vswing = 0.50 2. We try to keep voltage value and vswing both lower, then RF/EMI test all passed ;) ck: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40 tx: lvl = 11, term= 66, vlo = 2.68, vhi=3.09, vswing = 0.40 When we back to run HDMI different test and single-end test, we see different test passed, but signle-end test failed. The oscilloscope show that simgle-end clock's VL value is 1.78v (which remind LowLimit should not lower then 2.6v). 3. That's to say there are some different between PHY document and measure value. And according to experiment 2 results, we need to higher clock voltage and lower data voltage, then we can keep RF/EMI satisfied and single-end & differen test passed. ck: lvl = 9, term=100, vlo = 2.65, vhi=3.12, vswing = 0.47 tx: lvl = 16, term=100, vlo = 2.75, vhi=3.15, vswing = 0.39 Signed-off-by:
Yakir Yang <ykk@rock-chips.com> Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-3-jonas@kwiboo.se
-
RK3228 and RK3328 clock rate is being validated against a mpll config table intended for a Synopsys phy, and not the used inno-hdmi-phy. Instead get a reference to the hdmiphy clk and validate rates against it to enable use of HDMI2.0 modes, e.g. 4K@60Hz, on RK3228 and RK3328. For Synopsis phy the max_tmds_clock validation is sufficient. Signed-off-by:
Jonas Karlman <jonas@kwiboo.se> Tested-by: Diederik de Haas <didi.debian@cknow.org> # Rock64 Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240908145511.3331451-2-jonas@kwiboo.se
-
Fix a typo in comments. Reported-by:
Matthew Wilcox <willy@infradead.org> Signed-off-by:
Andrew Kreimer <algonell@gmail.com> Acked-by:
Andy <Yan<andyshrk@163.com> Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240915123943.105118-1-algonell@gmail.com
-