aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2022-05-05drm: mxsfb: Implement LCDIF scanout CRC32 supportMarek Vasut4-5/+74
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: Lucas Stach <l.stach@pengutronix.de> Acked-by: Stefan Agner <stefan@agner.ch> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Alexander Stein <alexander.stein@ew.tq-group.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Peng Fan <peng.fan@nxp.com> Cc: Robby Cai <robby.cai@nxp.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Stefan Agner <stefan@agner.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220429212313.305556-1-marex@denx.de
2022-05-04drm/nouveau: remove trace_dma_fence_emitChristian König1-1/+0
Hardware drivers which don't have much difference between emit and init shouldn't use this trace point. Signed-off-by: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: nouveau@lists.freedesktop.org Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220503085935.11023-1-christian.koenig@amd.com
2022-05-04drm/nouveau/subdev/bus: Ratelimit logging for fault errorsLyude Paul4-13/+15
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: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20220429195350.85620-1-lyude@redhat.com
2022-05-04drm/nouveau/devinit: fix returnvar.cocci warningsGuo Zhengkui3-6/+3
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: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220504161003.9245-1-guozhengkui@vivo.com
2022-05-04drm: exynos: dsi: Use child panel or bridge find helpersJagan Teki1-1/+11
commit <711c7adc4687> ("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 <b089c0a9b14c> ("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: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220428094808.782938-1-jagan@amarulasolutions.com
2022-05-04Revert "drm: bridge: mcde_dsi: Switch to devm_drm_of_get_bridge"Jagan Teki1-6/+38
commit <3d7039e1e649> ("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 <b089c0a9b14c> ("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: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220429085947.1699963-2-jagan@amarulasolutions.com
2022-05-04Revert "drm: bridge: mcde_dsi: Drop explicit bridge remove"Jagan Teki1-0/+1
commit <3730bc6147b0> ("drm: bridge: mcde_dsi: Drop explicit bridge remove") has removed downstream bridge as it's prior commit <3d7039e1e649> ("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 <b089c0a9b14c> ("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: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-05-04drm/etnaviv: avoid cleaning up sched_job when submit succeededLucas Stach1-2/+8
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: b827c84f5e84 ("drm/etnaviv: Use scheduler dependency handling") Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220504090229.2506560-1-l.stach@pengutronix.de
2022-05-04drm: fix typo in commentRaphael Gallais-Pou1-1/+1
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: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220426131912.3850354-1-raphael.gallais-pou@foss.st.com
2022-05-04drm/rockchip: Add VOP2 driverAndy Yan10-1/+3507
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: Sascha Hauer <s.hauer@pengutronix.de> Tested-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
2022-05-04drm/rockchip: Make VOP driver optionalSascha Hauer3-2/+11
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 <s.hauer@pengutronix.de> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-22-s.hauer@pengutronix.de
2022-05-04dt-bindings: display: rockchip: dw-hdmi: fix ports descriptionSascha Hauer1-15/+9
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 <s.hauer@pengutronix.de> Reviewed-by: Rob Herring <robh@kernel.org> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-25-s.hauer@pengutronix.de
2022-05-04dt-bindings: display: rockchip: Add binding for VOP2Sascha Hauer1-0/+140
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: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Rob Herring <robh@kernel.org> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-24-s.hauer@pengutronix.de
2022-05-04dma-buf/sync_file: cleanup fence merging a bitChristian König1-14/+7
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: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20220426124637.329764-1-christian.koenig@amd.com
2022-05-03drm/simpledrm: Use fbdev defaults for shadow bufferingThomas Zimmermann1-1/+0
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 <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220303205839.28484-2-tzimmermann@suse.de
2022-05-03fbdev: Use pageref offset for deferred-I/O writebackThomas Zimmermann9-32/+20
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: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-6-tzimmermann@suse.de
2022-05-03fbdev: Rename pagelist to pagereflist for deferred I/OThomas Zimmermann16-70/+53
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 <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-5-tzimmermann@suse.de
2022-05-03fbdev: Refactor implementation of page_mkwriteThomas Zimmermann1-15/+38
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 <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-4-tzimmermann@suse.de
2022-05-03fbdev: Track deferred-I/O pages in pageref structThomas Zimmermann12-74/+145
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 <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-3-tzimmermann@suse.de
2022-05-03fbdev: Put mmap for deferred I/O into driversThomas Zimmermann15-11/+37
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: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429100834.18898-2-tzimmermann@suse.de
2022-05-03drm/ast: Create the driver for ASPEED proprietory Display-PortKuoHsiang Chou6-8/+524
V1: 1. The MCU FW controling ASPEED DP is loaded by BMC boot loader. 2. Driver starts after CR[3:1] == 111b that indicates Tx is ASTDP, and CRD1[5] has been asserted by BMVC boot loader. 3. EDID is prioritized by DP monitor. 4. DP's EDID has high priority to decide resolution supporting. V2: Modules description: 1. ASTDP (ASPEED DisplayPort) is controlled by dedicated AST-MCU (ASPEED propriatary MCU). 2. MCU is looping in charged of HPD, Read EDID, Link Training with DP sink. 3. ASTDP and AST-MUC reside in BMC (Baseboard Management controller) addressing-space. 4. ASPEED DRM driver requests MCU to get HPD and EDID by CR-scratched register. Booting sequence: 1. Check if TX is ASTDP // ast_dp_launch() 2. Check if DP-MCU FW has loaded // ast_dp_launch() 3. Read EDID // ast_dp_read_edid() 4. Resolution switch // ast_dp_SetOutput() V3: 1. Remove unneeded semicolon. 2. Apply to git://anongit.freedesktop.org/drm/drm, instead of git://anongit.freedesktop.org/drm/drm-misc 3. Resolve auto build test WARNINGs on V1 patch. V4: 1. Sync code-base with kernel 5.17_rc6 2. Remove the define of DPControlPower, because DP chips need to be powered on to be used. 3. Remove the switches of PHY and Display from EDID procedure. 4. Revise increaing delay to fixed delay, because this version kernel doesn't detect minitor consistenntly. 5. Create clean-up code used for reset of power state on errors with -EIO manner. 6. Revise the DP detection by TX type and its DP-FW status during booting and resume. 7. Correct the CamelCase Style. 8. Use register reading while needing, and remove to hold full register. 9. Instead of 'u8', revise to 'bool' on swwitch of PHY and video. 10.Correct typo 11.Remove the duplicated copy of TX definition. 12.Use EDID_LENGTH as the constant of 128. Signed-off-by: KuoHsiang Chou <kuohsiang_chou@aspeedtech.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220428075603.20904-1-kuohsiang_chou@aspeedtech.com
2022-05-03dt-bindings: display: rockchip: dw-hdmi: Make unwedge pinctrl optionalSascha Hauer1-0/+1
None of the upstream device tree files has a "unwedge" pinctrl specified. Make it optional. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Rob Herring <robh@kernel.org> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-16-s.hauer@pengutronix.de
2022-05-03drm/rockchip: dw_hdmi: add regulator supportSascha Hauer1-3/+38
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed for the HDMI port. add support for these to the driver for boards which have them supplied by switchable regulators. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-10-s.hauer@pengutronix.de
2022-05-03dt-bindings: display: rockchip: dw-hdmi: Add regulator supportSascha Hauer1-0/+11
The RK3568 has HDMI_TX_AVDD0V9 and HDMI_TX_AVDD_1V8 supply inputs needed for the HDMI port. Add the binding for these supplies. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Rob Herring <robh@kernel.org> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-11-s.hauer@pengutronix.de
2022-05-03drm/rockchip: dw_hdmi: add rk3568 supportSascha Hauer1-0/+31
Add a new dw_hdmi_plat_data struct and new compatible for rk3568. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-8-s.hauer@pengutronix.de
2022-05-03dt-bindings: display: rockchip: dw-hdmi: Add compatible for rk3568 HDMIBenjamin Gaignard1-0/+1
Define a new compatible for rk3568 HDMI. This version of HDMI hardware block needs two new clocks hclk_vio and hclk to provide phy reference clocks. Signed-off-by: Benjamin Gaignard <benjamin.gaignard@collabora.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-9-s.hauer@pengutronix.de
2022-05-03Merge drm/drm-next into drm-misc-nextMaxime Ripard1357-12447/+21604
Christian needs a backmerge to avoid a merge conflict for amdgpu. Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-05-03dt-bindings: display: rockchip: dw-hdmi: use "ref" as clock nameSascha Hauer1-2/+7
"vpll" is a misnomer. A clock input to a device should be named after the usage in the device, not after the clock that drives it. On the rk3568 the same clock is driven by the HPLL. This patch adds "ref" as a new alternative clock name for "vpll" Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Acked-by: Rob Herring <robh@kernel.org> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-6-s.hauer@pengutronix.de
2022-05-03drm/rockchip: dw_hdmi: rename vpll clock to reference clockSascha Hauer1-13/+14
"vpll" is a misnomer. A clock input to a device should be named after the usage in the device, not after the clock that drives it. On the rk3568 the same clock is driven by the HPLL. To fix that, this patch renames the vpll clock to ref clock. The clock name "vpll" is left for compatibility to old device trees. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-5-s.hauer@pengutronix.de
2022-05-03drm/rockchip: Add crtc_endpoint_id to rockchip_encoderSascha Hauer2-1/+36
The VOP2 has an interface mux which decides to which encoder(s) a CRTC is routed to. The encoders and CRTCs are connected via of_graphs in the device tree. When given an encoder the VOP2 driver needs to know to which internal register setting this encoder matches. For this the VOP2 binding offers different endpoints, one for each possible encoder. The endpoint ids of these endpoints are used as a key from an encoders device tree description to the internal register setting. This patch adds the key aka endpoint id to struct rockchip_encoder plus a function to read the endpoint id starting from the encoders device node. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-4-s.hauer@pengutronix.de
2022-05-03drm/rockchip: Embed drm_encoder into rockchip_decoderSascha Hauer9-60/+122
The VOP2 driver needs rockchip specific information for a drm_encoder. This patch creates a struct rockchip_encoder with a struct drm_encoder embedded in it. This is used throughout the rockchip driver instead of struct drm_encoder directly. The information the VOP2 drivers needs is the of_graph endpoint node of the encoder. To ease bisectability this is added here. While at it convert the different encoder-to-driverdata macros to static inline functions in order to gain type safety and readability. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Michael Riesch <michael.riesch@wolfvision.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422072841.2206452-3-s.hauer@pengutronix.de
2022-05-03Backmerge tag 'v5.18-rc5' of ↵Dave Airlie1021-5586/+8212
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Linux 5.18-rc5 There was a build fix for arm I wanted in drm-next, so backmerge rather then cherry-pick. Signed-off-by: Dave Airlie <airlied@redhat.com>
2022-05-03drm/rockchip: Support YUV formats with U/V swappedChen-Yu Tsai3-1/+31
The VOP in Rockchip SoCs that support YUV planes also support swapping of the U and V elements. Supporting the swapped variants, especially NV21, would be beneficial for multimedia applications, as the hardware video decoders only output NV21, and supporting this pixel format in the display pipeline would allow the decoded video frames to be output directly. Add support for this to support the various formats that have U/V swapped. Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220114074038.2633848-1-wenst@chromium.org
2022-05-02drm/rockchip: rk3066_hdmi: Replace drm_detect_hdmi_monitor() with is_hdmiJosé Expósito1-3/+3
Once EDID is parsed, the monitor HDMI support information is available through drm_display_info.is_hdmi. This driver calls drm_detect_hdmi_monitor() to receive the same information and stores its own cached value, which is less efficient. Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi instead and also remove hdmi_data_info.sink_is_hdmi as it is no longer necessary. Signed-off-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220421170725.903361-4-jose.exposito89@gmail.com
2022-05-02drm/rockchip: inno_hdmi: Replace drm_detect_hdmi_monitor() with is_hdmiJosé Expósito1-4/+4
Once EDID is parsed, the monitor HDMI support information is available through drm_display_info.is_hdmi. This driver calls drm_detect_hdmi_monitor() to receive the same information and stores its own cached value, which is less efficient. Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi instead and also remove hdmi_data_info.sink_is_hdmi as it is no longer necessary. Signed-off-by: José Expósito <jose.exposito89@gmail.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220421170725.903361-3-jose.exposito89@gmail.com
2022-05-02drm/rockchip: cdn-dp: change rk3399_cdn_dp from global to staticTom Rix1-1/+1
Smatch reports this issue cdn-dp-core.c:51:20: warning: symbol 'rk3399_cdn_dp' was not declared. Should it be static? rk3399_cdn_dp is only used in cdn-dp-core.c so change its storge-class specifier to static. Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220421144304.586396-1-trix@redhat.com
2022-05-02drm/rockchip: Refactor IOMMU initialisationRobin Murphy3-34/+31
Defer the IOMMU domain setup until after successfully binding components, so we can figure out IOMMU support directly from the VOP devices themselves, rather than manually inferring it from the DT (which also fails to account for whether the IOMMU driver is actually loaded). Although this is somewhat of a logical cleanup, the main motivation is to prepare for a change in the iommu_domain_alloc() interface. Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/94eee7ab434fe11eb0787f691e9f1ab03a2e91be.1649168685.git.robin.murphy@arm.com
2022-05-02drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()Yang Yingliang1-1/+1
It will cause null-ptr-deref in resource_size(), if platform_get_resource() returns NULL, move calling resource_size() after devm_ioremap_resource() that will check 'res' to avoid null-ptr-deref. Fixes: 2048e3286f34 ("drm: rockchip: Add basic drm driver") Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220422032854.2995175-1-yangyingliang@huawei.com
2022-05-02drm/bridge: tfp410: Make tfp410_fini() return voidUwe Kleine-König1-5/+7
tfp410_fini() always returns zero. Make it return no value which makes it easier to see in the callers that there is no error to handle. Also the return value of i2c and platform driver remove callbacks is ignored anyway. This prepares making i2c and platform remove callbacks return void, too. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220428162803.185275-1-u.kleine-koenig@pengutronix.de
2022-05-02drm: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridgeMarek Vasut3-0/+351
The i.MX8MP contains two syscon registers which are responsible for configuring the on-SoC DPI-to-LVDS serializer. Implement a simple bridge driver for this serializer. -- - Add sentinel of_device_table - Add RB from Sam - Rename to fsl-ldb altogether Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Peng Fan <peng.fan@nxp.com> Cc: Robby Cai <robby.cai@nxp.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org V2: - Rename syscon to fsl,syscon V3: - Consistently use MX8MP V4: - Fix MODULE_DESCRIPTION to also use MX8MP Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220426193645.244792-2-marex@denx.de
2022-05-02dt-bindings: display: bridge: ldb: Implement simple Freescale i.MX8MP LDB bridgeMarek Vasut1-0/+92
The i.MX8MP contains two syscon registers which are responsible for configuring the on-SoC DPI-to-LVDS serializer. Add DT binding which represents this serializer as a bridge. Acked-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Marek Vasut <marex@denx.de> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Peng Fan <peng.fan@nxp.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Robby Cai <robby.cai@nxp.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: devicetree@vger.kernel.org To: dri-devel@lists.freedesktop.org Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220426193645.244792-1-marex@denx.de
2022-05-02drm: bridge: adv7511: use non-legacy mode for CEC RXAlvin Šipraga3-32/+106
The ADV7511 family of bridges supports two modes for CEC RX: legacy and non-legacy mode. The only difference is whether the chip uses a single CEC RX buffer, or uses all three available RX buffers. Currently the adv7511 driver uses legacy mode. While debugging a stall in CEC RX on an ADV7535, we reached out to Analog Devices, who suggested to use non-legacy mode instead. According to the programming guide for the ADV7511 [1], and the register control manual of the ADV7535 [2], this is the default behaviour on reset. As previously stated, the adv7511 driver currently overrides this to legacy mode. This patch updates the adv7511 driver to instead use non-legacy mode with all three CEC RX buffers. As a result of this change, we no longer experience any stalling of CEC RX with the ADV7535. It is not known why non-legacy mode solves this particular issue, but besides this, no functional change is to be expected by this patch. Please note that this has only been tested on an ADV7535. What follows is a brief description of the non-legacy mode interrupt handling behaviour. The programming guide in [1] gives a more detailed explanation. With three RX buffers, the interrupt handler checks the CEC_RX_STATUS register (renamed from CEC_RX_ENABLE in this patch), which contains 2-bit psuedo-timestamps for each of the RX buffers. The RX timestamps for each buffer represent the time of arrival for the CEC frame held in a given buffer, with lower timestamp values indicating chronologically older frames. A special value of 0 indicates that the given RX buffer is inactive and should be skipped. The interrupt handler parses these timestamps and then reads the active RX buffers in the prescribed order using the same logic as before. Changes have been made to ensure that the correct RX buffer is cleared after processing. This clearing procesure also sets the timestamp of the given RX buffer to 0 to mark it as inactive. [1] https://www.analog.com/media/en/technical-documentation/user-guides/ADV7511_Programming_Guide.pdf cf. CEC Map, register 0x4A, bit 3, default value 1: 0 = Use only buffer 0 to store CEC frames (Legacy mode) 1 = Use all 3 buffers to stores the CEC frames (Non-legacy mode) [2] The ADV7535 register control manual is under NDA, but trust me when I say that non-legacy CEC RX mode is the default here too. Here the register is offset by 0x70 and has an address of 0xBA in the DSI_CEC regiser map. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220423120854.1503163-3-alvin@pqrs.dk
2022-05-02drm: bridge: adv7511: enable CEC support for ADV7535Alvin Šipraga3-14/+10
Like the ADV7533, the ADV7535 has an offset for the CEC register map, and it is the same value (ADV7533_REG_CEC_OFFSET = 0x70). Rather than testing for numerous chip types in the offset calculations throughout the driver, just compute it during driver probe and put it in the private adv7511 data structure. Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220423120854.1503163-2-alvin@pqrs.dk
2022-05-02drm/bridge: it6505: Send DPCD SET_POWER to downstreamPin-Yen Lin1-11/+18
Send DPCD SET_POWER command to downstream in .atomic_disable to make the downstream monitor enter the power down mode, so the device suspend won't be affected. Fixes: b5c84a9edcd418 ("drm/bridge: add it6505 driver") Signed-off-by: Pin-Yen Lin <treapking@chromium.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220425134424.1150965-1-treapking@chromium.org Reviewed-by: Robert Foss <robert.foss@linaro.org>
2022-05-02drm/panel: panel-simple: Fix proper bpc for AM-1280800N3TZQW-T00HJagan Teki1-1/+1
AM-1280800N3TZQW-T00H panel support 8 bpc not 6 bpc as per recent testing in i.MX8MM platform. Fix it. Fixes: bca684e69c4c ("drm/panel: simple: Add AM-1280800N3TZQW-T00H") Signed-off-by: Jagan Teki <jagan@amarulasolutions.com> Reviewed-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211111094103.494831-1-jagan@amarulasolutions.com
2022-05-02drm/nouveau: use drm_gem_plane_helper_prepare_fbChristian König1-3/+2
Instead of manually adjusting the plane state. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220429134230.24334-3-christian.koenig@amd.com
2022-05-02drm: handle kernel fences in drm_gem_plane_helper_prepare_fb v2Christian König4-64/+62
drm_gem_plane_helper_prepare_fb() was using drm_atomic_set_fence_for_plane() which ignores all implicit fences when an explicit fence is already set. That's rather unfortunate when the fb still has a kernel fence we need to wait for to avoid presenting garbage on the screen. So instead update the fence in the plane state directly. While at it also take care of all potential GEM objects and not just the first one. Also remove the now unused drm_atomic_set_fence_for_plane() function, new drivers should probably use the atomic helpers directly. v2: improve kerneldoc, use local variable and num_planes, WARN_ON_ONCE on missing planes. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1) Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20220429134230.24334-1-christian.koenig@amd.com
2022-05-01Linux 5.18-rc5Linus Torvalds1-1/+1
2022-05-01Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds18-62/+214
Pull kvm fixes from Paolo Bonzini: "ARM: - Take care of faults occuring between the PARange and IPA range by injecting an exception - Fix S2 faults taken from a host EL0 in protected mode - Work around Oops caused by a PMU access from a 32bit guest when PMU has been created. This is a temporary bodge until we fix it for good. x86: - Fix potential races when walking host page table - Fix shadow page table leak when KVM runs nested - Work around bug in userspace when KVM synthesizes leaf 0x80000021 on older (pre-EPYC) or Intel processors Generic (but affects only RISC-V): - Fix bad user ABI for KVM_EXIT_SYSTEM_EVENT" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: KVM: x86: work around QEMU issue with synthetic CPUID leaves Revert "x86/mm: Introduce lookup_address_in_mm()" KVM: x86/mmu: fix potential races when walking host page table KVM: fix bad user ABI for KVM_EXIT_SYSTEM_EVENT KVM: x86/mmu: Do not create SPTEs for GFNs that exceed host.MAXPHYADDR KVM: arm64: Inject exception on out-of-IPA-range translation fault KVM/arm64: Don't emulate a PMU for 32-bit guests if feature not set KVM: arm64: Handle host stage-2 faults from 32-bit EL0
2022-05-01Merge tag 'x86_urgent_for_v5.18_rc5' of ↵Linus Torvalds21-29/+63
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Borislav Petkov: - A fix to disable PCI/MSI[-X] masking for XEN_HVM guests as that is solely controlled by the hypervisor - A build fix to make the function prototype (__warn()) as visible as the definition itself - A bunch of objtool annotation fixes which have accumulated over time - An ORC unwinder fix to handle bad input gracefully - Well, we thought the microcode gets loaded in time in order to restore the microcode-emulated MSRs but we thought wrong. So there's a fix for that to have the ordering done properly - Add new Intel model numbers - A spelling fix * tag 'x86_urgent_for_v5.18_rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/pci/xen: Disable PCI/MSI[-X] masking for XEN_HVM guests bug: Have __warn() prototype defined unconditionally x86/Kconfig: fix the spelling of 'becoming' in X86_KERNEL_IBT config objtool: Use offstr() to print address of missing ENDBR objtool: Print data address for "!ENDBR" data warnings x86/xen: Add ANNOTATE_NOENDBR to startup_xen() x86/uaccess: Add ENDBR to __put_user_nocheck*() x86/retpoline: Add ANNOTATE_NOENDBR for retpolines x86/static_call: Add ANNOTATE_NOENDBR to static call trampoline objtool: Enable unreachable warnings for CLANG LTO x86,objtool: Explicitly mark idtentry_body()s tail REACHABLE x86,objtool: Mark cpu_startup_entry() __noreturn x86,xen,objtool: Add UNWIND hint lib/strn*,objtool: Enforce user_access_begin() rules MAINTAINERS: Add x86 unwinding entry x86/unwind/orc: Recheck address range after stack info was updated x86/cpu: Load microcode during restore_processor_state() x86/cpu: Add new Alderlake and Raptorlake CPU model numbers
Powered by cgit, Gruvboxed by Blaster4385.