- 05 May, 2022 19 commits
-
-
Jani Nikula authored
Use the cea db iterator for speaker allocation. We'll still stop at the first speaker data block, but not at the first CTA extension if that doesn't have the info. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/0b9e7f136854055a14b826097160fe0b43b9f3d1.1651569697.git.jani.nikula@intel.com
-
Jani Nikula authored
Iterate through all CTA EDID extension blocks and DisplayID CTA data blocks to add CEA modes. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Abstract helpers for matching vendor data blocks and extended tags, and use them to simplify all the cea_db_is_*() functions. Take void pointer as parameter to allow transitional use for both u8 * and struct cea_db *. v2: Remove superfluous parens (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Add an iterator for CTA Data Blocks across EDID CTA Extensions and DisplayID CTA Data Blocks. v2: Update references, note why we can trust displayid ranges (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Add an iterator abstraction for going through all the EDID blocks. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
Add prefixed names, group, sort, add references. v2: - Updated references to CTA-861-H - s/CEA/CTA/ in data block macros Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Jani Nikula authored
The HDMI spec talks about SCDS, Sink Capability Data Structure, exposed via HF-VSDB or HF-SCDB. Rename VSDB to SCDS. Suggested-by:
-
Lee Shawn C authored
Find HF-SCDB information in CEA extensions block. And retrieve Max_TMDS_Character_Rate that support by sink device. v2: HF-SCDB and HF-VSDBS carry the same SCDS data. Reuse drm_parse_hdmi_forum_vsdb() to parse this packet. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: intel-gfx <intel-gfx@lists.freedesktop.org> Signed-off-by:Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
-
Jani Nikula authored
If a NULL edid gets passed to drm_add_edid_modes(), we should probably also reset the display info. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Christian König authored
We could need to wait for the pin to complete here. Signed-off-by:
Christian König <christian.koenig@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: virtualization@lists.linux-foundation.org Cc: spice-devel@lists.freedesktop.org Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220429134230.24334-4-christian.koenig@amd.com
-
Javier Martinez Canillas authored
The Kernel Unit Testing (KUnit) framework provides a common framework for unit tests within the Linux kernel. Having a test suite would allow to identify regressions earlier. Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Acked-by:
Maxime Ripard <maxime@cerno.tech> Acked-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220504080212.713275-1-javierm@redhat.com
-
Minghao Chi authored
Simplify the return expression. Reported-by:
Zeal Robot <zealci@zte.com.cn> Signed-off-by:
Minghao Chi <chi.minghao@zte.com.cn> Acked-by:
-
Thomas Zimmermann authored
Add a mutex lock to protect concurrent access to I/O registers against each other. This happens between invocation of commit- tail functions and get-mode operations. Both with use the CRTC index registers MGA1064_GEN_IO_DATA and MGA1064_GEN_IO_CTL. Concurrent access can lead to failed mode-setting operations. v2: * fix typo in commit description (Jocelyn) * add comment to explain rmmio_lock Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Acked-by:
-
Thomas Zimmermann authored
Add a mutex lock to protect concurrent access to I/O registers against each other. This happens between invocation of commit- tail functions and get-mode operations. Both with use the CRTC index register AST_IO_CRTC_PORT. Concurrent access can lead to failed mode-setting operations. v2: * fix typo in commit description (Jocelyn) Signed-off-by:
KuoHsiang Chou <kuohsiang_chou@aspeedtech.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220502142514.2174-3-tzimmermann@suse.de
-
Thomas Zimmermann authored
Add drmm_mutex_init(), a helper that provides managed mutex cleanup. The mutex will be destroyed with the final reference of the DRM device. Signed-off-by:
-
Thomas Zimmermann authored
Provide format-independent conversion helpers for system and I/O memory. Implement most existing helpers on top of it. The source and destination formats of each conversion is handled by a per-line helper that is given to the generic implementation. v2: * remove a blank line Signed-off-by:
-
Thomas Zimmermann authored
Give each per-line conversion helper pointers of type void and the number of pixels in the line. Remove the unused swab parameters. Signed-off-by:
-
Thomas Zimmermann authored
Implement per-pixel byte swapping in a separate conversion helper for the single function that requires it. Select the correct helper for each conversion. Signed-off-by:
-
Thomas Zimmermann authored
Replace the inner loop of drm_fb_swab() with helper functions that swap the bytes in each pixel. This will allow to share the outer loop with other conversion helpers. Signed-off-by:
-
- 04 May, 2022 15 commits
-
-
Marek Vasut authored
Per toshiba,tc358767.yaml DT binding document, port@2 the output (e)DP port is optional. In case this port is not described in DT, the bridge driver operates in DPI-to-DP mode. Make sure the driver treats this as a valid mode of operation instead of reporting invalid mode. Fixes: 71f7d9c0 ("drm/bridge: tc358767: Detect bridge mode from connected endpoints in DT") Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Marek Vasut <marex@denx.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Reviewed-by:
Lucas Stach <l.stach@pengutronix.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220429204625.241591-1-marex@denx.de
-
Marek Vasut authored
The LCDIF controller as present in i.MX28/i.MX6SX/i.MX8M Mini/Nano has CRC_STAT register, which contains CRC32 of the frame as it was clocked out of the DPI interface of the LCDIF. This is most likely meant as a functional safety feature. Unfortunately, there is zero documentation on how the CRC32 is calculated, there is no documentation of the polynomial, the init value, nor on which data is the checksum applied. By applying brute-force on 8 pixel / 2 line frame, which is the minimum size LCDIF would work with, it turns out the polynomial is CRC32_POLY_LE 0xedb88320 , init value is 0xffffffff , the input data are bitrev32() of the entire frame and the resulting CRC has to be also bitrev32()ed. Doing this calculation in kernel for each frame is unrealistic due to the CPU demand, so attach the CRC collected from hardware to a frame instead. The DRM subsystem already has an interface for this purpose and the CRC can be accessed e.g. via debugfs: " $ echo auto > /sys/kernel/debug/dri/1/crtc-0/crc/control $ cat /sys/kernel/debug/dri/1/crtc-0/crc/data 0x0000408c 0xa4e5cdd8 0x0000408d 0x72f537b4 " The per-frame CRC can be used by userspace e.g. during automated testing, to verify that whatever buffer was sent to be scanned out was actually scanned out of the LCDIF correctly. Acked-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
-
Christian König authored
Hardware drivers which don't have much difference between emit and init shouldn't use this trace point. Signed-off-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Lyude Paul authored
There's plenty of ways to fudge the GPU when developing on nouveau by mistake, some of which can result in nouveau seriously spamming dmesg with fault errors. This can be somewhat annoying, as it can quickly overrun the message buffer (or your terminal emulator's buffer) and get rid of actually useful feedback from the driver. While working on my new atomic only MST branch, I ran into this issue a couple of times. So, let's fix this by adding nvkm_error_ratelimited(), and using it to ratelimit errors from faults. This should be fine for developers, since it's nearly always only the first few faults that we care about seeing. Plus, you can turn off rate limiting in the kernel if you really need to. Signed-off-by:
Karol Herbst <kherbst@redhat.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20220429195350.85620-1-lyude@redhat.com
-
Guo Zhengkui authored
Fix the following coccicheck warnings: drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gf100.c:71:5-12: Unneeded variable: "disable". Return "0ULL" on line 90. drivers/gpu/drm/nouveau/nvkm/subdev/devinit/gm107.c:35:5-12: Unneeded variable: "disable". Return "0ULL" on line 44. drivers/gpu/drm/nouveau/nvkm/subdev/devinit/g98.c:35:5-12: Unneeded variable: "disable". Return "0ULL" on line 50. Signed-off-by:
Guo Zhengkui <guozhengkui@vivo.com> Reviewed-by:
-
Jagan Teki authored
commit <711c7adc> ("drm: exynos: dsi: Use drm panel_bridge API") added devm_drm_of_get_bridge for looking up if child node has panel or bridge. However commit <b089c0a9> ("Revert "drm: of: Lookup if child node has panel or bridge") has reverted panel or bridge child node lookup from devm_drm_of_get_bridge which eventually failed to find the DSI devices in exynos drm dsi driver. So, use the conventional child panel bridge lookup helpers like it does before. Signed-off-by:
Jagan Teki <jagan@amarulasolutions.com> Tested-by:
Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by:
-
Jagan Teki authored
commit <3d7039e1> ("drm: bridge: mcde_dsi: Switch to devm_drm_of_get_bridge") switched to devm_drm_of_get_bridge for looking up if child node has panel or bridge. However commit <b089c0a9> ("Revert "drm: of: Lookup if child node has panel or bridge") has reverted panel or bridge child node lookup from devm_drm_of_get_bridge as it breaks the non-trivial cases the first child node might not be a panel or bridge. So, revert this commit to switch the previous behavior of looking up child panel or bridge. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jagan Teki authored
commit <3730bc61> ("drm: bridge: mcde_dsi: Drop explicit bridge remove") has removed downstream bridge as it's prior commit <3d7039e1> ("drm: bridge: mcde_dsi: Switch to devm_drm_of_get_bridge") added devm_drm_of_get_bridge for looking up if child node has panel or bridge. However commit <b089c0a9> ("Revert "drm: of: Lookup if child node has panel or bridge") has reverted panel or bridge child node lookup from devm_drm_of_get_bridge as it breaks the non-trivial cases the first child node might not be a panel or bridge. So, revert this commit to switch the previous behavior of looking up child panel or bridge. Link: https://lore.kernel.org/all/20220429085947.1699963-1-jagan@amarulasolutions.com/Signed-off-by:
-
Lucas Stach authored
While the labels may mislead the casual reader, the tail of the function etnaviv_ioctl_gem_submit is always executed, as a lot of the structures set up in this function need to be cleaned up regardless of whether the submit succeeded or failed. An exception is the newly added drm_sched_job_cleanup, which must only be called when the submit failed before handing the job to the scheduler. Fixes: b827c84f ("drm/etnaviv: Use scheduler dependency handling") Reported-by:
Michael Walle <michael@walle.cc> Signed-off-by:
-
Raphael Gallais-Pou authored
Fix typo in a doxygen comment (replaced green by blue) in drm_color_mgmt.c Signed-off-by:
Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by:
-
Andy Yan authored
The VOP2 unit is found on Rockchip SoCs beginning with rk3566/rk3568. It replaces the VOP unit found in the older Rockchip SoCs. This driver has been derived from the downstream Rockchip Kernel and heavily modified: - All nonstandard DRM properties have been removed - dropped struct vop2_plane_state and pass around less data between functions - Dropped all DRM_FORMAT_* not known on upstream - rework register access to get rid of excessively used macros - Drop all waiting for framesyncs The driver is tested with HDMI and MIPI-DSI display on a RK3568-EVB board. Overlay support is tested with the modetest utility. AFBC support on the cluster windows is tested with weston-simple-dmabuf-egl on weston using the (yet to be upstreamed) panfrost driver support. Signed-off-by:
Andy Yan <andy.yan@rock-chips.com> Co-Developed-by:
Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by:
Michael Riesch <michael.riesch@wolfvision.net> [dt-binding-header:] Acked-by:
Rob Herring <robh@kernel.org> [moved dt-binding header from dt-nodes patch to here and made checkpatch --strict happier] Signed-off-by:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-23-s.hauer@pengutronix.de
-
Sascha Hauer authored
With upcoming VOP2 support VOP won't be the only choice anymore, so make the VOP driver optional. This also adds a dependency from ROCKCHIP_ANALOGIX_DP to ROCKCHIP_VOP, because that driver currently only links and works with the VOP driver. Signed-off-by:
-
Sascha Hauer authored
Current port description doesn't cover all possible cases. It currently expects one single port with two endpoints. When the HDMI connector is described in the device tree there can be two ports, first one going to the VOP and the second one going to the connector. Also on SoCs which only have a single VOP there will be only one endpoint instead of two. This patch addresses both issues. With this there can either be a single port ("port") , or two of them ("port@0", "port@1") when the connector is also in the device tree. Also the first or only port can either have one endpoint ("endpoint") for single VOP SoCs or two ("endpoint@0", "endpoint@1") for dual VOP SoCs. Signed-off-by: -
Sascha Hauer authored
The VOP2 is found on newer Rockchip SoCs like the rk3568 or the rk3566. The binding differs slightly from the existing VOP binding, so add a new binding file for it. Signed-off-by:
-
Christian König authored
krealloc_array() ignores attempts to reduce the array size, so the attempt to save memory is completely pointless here. Also move testing for the no fence case into sync_file_set_fence(), this way we don't even touch the fence array when we don't have any fences. Signed-off-by:
-
- 03 May, 2022 6 commits
-
-
Thomas Zimmermann authored
Don't select shadow buffering for the fbdev console explicitly. The fbdev emulation's heuristic will enable it for any framebuffer with .dirty callback. Signed-off-by:
-
Thomas Zimmermann authored
Use pageref->offset instead of page->index for deferred-I/O writeback where appropriate. Distinguishes between file-mapping offset and video- memory offset. While at it, also remove unnecessary references to struct page. Fbdev's deferred-I/O code uses the two related page->index and pageref->offset. The former is the page offset in the mapped file, the latter is the byte offset in the video memory (or fbdev screen buffer). It's the same value for fbdev drivers, but for DRM the values can be different. Because GEM buffer objects are mapped at an offset in the DRM device file, page->index has this offset added to it as well. We currently don't hit this case in DRM, because all affected mappings of GEM memory are performed with an internal, intermediate shadow buffer. The value of page->index is required by page_mkclean(), which we call to reset the mappings during the writeback phase of the deferred I/O. The value of pageref->offset is for conveniently getting an offset into video memory in fb helpers. v4: * fix commit message (Javier) Suggested-by:
-
Thomas Zimmermann authored
Rename various instances of pagelist to pagereflist. The list now stores pageref structures, so the new name is more appropriate. In their write-back helpers, several fbdev drivers refer to the pageref list in struct fb_deferred_io instead of using the one supplied as argument to the function. Convert them over to the supplied one. It's the same instance, so no change of behavior occurs. v4: * fix commit message (Javier) Suggested-by:
Sam Ravnborg <sam@ravnborg.org> Signed-off-by:
-
Thomas Zimmermann authored
Refactor the page-write handler for deferred I/O. Drivers use the function to let fbdev track written pages of mmap'ed framebuffer memory. v3: * keep locking within track-pages function for readability (Sam) v2: * don't export the helper until we have an external caller Signed-off-by:
-
Thomas Zimmermann authored
Store the per-page state for fbdev's deferred I/O in struct fb_deferred_io_pageref. Maintain a list of pagerefs for the pages that have to be written back to video memory. Update all affected drivers. As with pages before, fbdev acquires a pageref when an mmaped page of the framebuffer is being written to. It holds the pageref in a list of all currently written pagerefs until it flushes the written pages to video memory. Writeback occurs periodically. After writeback fbdev releases all pagerefs and builds up a new dirty list until the next writeback occurs. Using pagerefs has a number of benefits. For pages of the framebuffer, the deferred I/O code used struct page.lru as an entry into the list of dirty pages. The lru field is owned by the page cache, which makes deferred I/O incompatible with some memory pages (e.g., most notably DRM's GEM SHMEM allocator). struct fb_deferred_io_pageref now provides an entry into a list of dirty framebuffer pages, freeing lru for use with the page cache. Drivers also assumed that struct page.index is the page offset into the framebuffer. This is not true for DRM buffers, which are located at various offset within a mapped area. struct fb_deferred_io_pageref explicitly stores an offset into the framebuffer. struct page.index is now only the page offset into the mapped area. These changes will allow DRM to use fbdev deferred I/O without an intermediate shadow buffer. v3: * use pageref->offset for sorting * fix grammar in comment v2: * minor fixes in commit message Signed-off-by:
-
Thomas Zimmermann authored
The fbdev mmap function fb_mmap() unconditionally overrides the driver's implementation if deferred I/O has been activated. This makes it hard to implement mmap with anything but a vmalloc()'ed software buffer. That is specifically a problem for DRM, where video memory is maintained by a memory manager. Leave the mmap handling to drivers and expect them to call the helper for deferred I/O by thmeselves. v4: * unlock mm_lock in fb_mmap() error path (Dan) v3: * fix warning if fb_mmap is missing (kernel test robot) v2: * print a helpful error message if the defio setup is incorrect (Javier) Signed-off-by:
-
