aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-07-24drm/i915: use direct alias for i915 in requestsAndrzej Hajda18-42/+43
i915_request contains direct alias to i915, there is no point to go via rq->engine->i915. v2: added missing rq.i915 initialization in measure_breadcrumb_dw. Signed-off-by: Andrzej Hajda <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Acked-by: Nirmoy Das <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev: Document that framebuffer_alloc() returns zero'ed dataThomas Zimmermann1-1/+2
Most fbdev drivers depend on framebuffer_alloc() to initialize the allocated memory to 0. Document this guarantee. v3: * slightly reword the sentence (Miguel) Suggested-by: Miguel Ojeda <[email protected]> Signed-off-by: Thomas Zimmermann <[email protected]> Reviewed-by: Miguel Ojeda <[email protected]> Reviewed-by: Sui Jingfeng <[email protected]> Cc: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev: Remove FBINFO_DEFAULT and FBINFO_FLAG_DEFAULTThomas Zimmermann1-3/+0
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No functional changes. Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev/pxafb: Remove flag FBINFO_FLAG_DEFAULTThomas Zimmermann1-1/+0
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev/atafb: Remove flag FBINFO_FLAG_DEFAULTThomas Zimmermann1-1/+0
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by a static declaration. So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev: Remove FBINFO_FLAG_DEFAULT from framebuffer_alloc()'ed structsThomas Zimmermann24-29/+10
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Jaya Kumar <[email protected]> Cc: Helge Deller <[email protected]> Cc: Peter Jones <[email protected]> Cc: Sascha Hauer <[email protected]> Cc: Pengutronix Kernel Team <[email protected]> Cc: Shawn Guo <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: NXP Linux Team <[email protected]> Cc: Maik Broemme <[email protected]> Cc: Jingoo Han <[email protected]> Cc: Sudip Mukherjee <[email protected]> Cc: Teddy Wang <[email protected]> Cc: Michal Januszewski <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev: Remove FBINFO_FLAG_DEFAULT from kzalloc()'ed structsThomas Zimmermann2-4/+2
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24staging: Remove flag FBINFO_FLAG_DEFAULT from fbdev driversThomas Zimmermann2-2/+1
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Sudip Mukherjee <[email protected]> Cc: Teddy Wang <[email protected]> Acked-by: Greg Kroah-Hartman <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24media: Remove flag FBINFO_FLAG_DEFAULT from fbdev driversThomas Zimmermann2-2/+0
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Andy Walls <[email protected]> Cc: Mauro Carvalho Chehab <[email protected]> Cc: Hans Verkuil <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24hid/picolcd: Remove flag FBINFO_FLAG_DEFAULT from fbdev driverThomas Zimmermann1-1/+0
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Benjamin Tissoires <[email protected]> Acked-by: Bruno Prémont <[email protected]> Cc: "Bruno Prémont" <[email protected]> Cc: Jiri Kosina <[email protected]> Cc: Benjamin Tissoires <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24auxdisplay: Remove flag FBINFO_FLAG_DEFAULT from fbdev driversThomas Zimmermann2-2/+0
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: Miguel Ojeda <[email protected]> Cc: Miguel Ojeda <[email protected]> Cc: Robin van der Gracht <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24sh: mach-sh7763rdp: Assign FB_MODE_IS_UNKNOWN to struct fb_videomode.flagThomas Zimmermann1-1/+1
Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change. FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info. Flags for videomodes are prefixed with FB_MODE_. v3: * include board name in commit message (Adrian) v2: * assign FB_MODE_IS_UNKNOWN (Adrian) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Acked-by: John Paul Adrian Glaubitz <[email protected]> Cc: Yoshinori Sato <[email protected]> Cc: Rich Felker <[email protected]> Cc: John Paul Adrian Glaubitz <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24vfio-mdev: Remove flag FBINFO_DEFAULT from fbdev sample driverThomas Zimmermann1-1/+0
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Kirti Wankhede <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev/fsl-diu-fb: Remove flag FBINFO_DEFAULTThomas Zimmermann1-1/+1
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by dmam_alloc_coherent(__GFP_ZERO). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Timur Tabi <[email protected]> Cc: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev: Remove FBINFO_DEFAULT from framebuffer_alloc()'ed structsThomas Zimmermann64-81/+41
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Helge Deller <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: Benjamin Herrenschmidt <[email protected]> Cc: Ferenc Bakonyi <[email protected]> Cc: "K. Y. Srinivasan" <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Wei Liu <[email protected]> Cc: Dexuan Cui <[email protected]> Cc: Antonino Daplas <[email protected]> Cc: Maik Broemme <[email protected]> Cc: Michael Ellerman <[email protected]> Cc: Nicholas Piggin <[email protected]> Cc: Christophe Leroy <[email protected]> Cc: Kristoffer Ericson <[email protected]> Cc: Hans de Goede <[email protected]> Cc: Steve Glendinning <[email protected]> Cc: Bernie Thompson <[email protected]> Cc: Florian Tobias Schandinat <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev: Remove FBINFO_DEFAULT from devm_kzalloc()'ed structsThomas Zimmermann4-5/+1
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev: Remove FBINFO_DEFAULT from kzalloc()'ed structsThomas Zimmermann5-6/+4
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by kzalloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Helge Deller <[email protected]> Cc: Russell King <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24fbdev: Remove FBINFO_DEFAULT from static structsThomas Zimmermann6-6/+3
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by a static declaration. So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v4: * clarify commit message (Geert, Dan) v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24drm: Remove flag FBINFO_DEFAULT from fbdev emulationThomas Zimmermann4-4/+2
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do not set it. Flags should signal differences from the default values. After cleaning up all occurrences of FBINFO_DEFAULT, the token will be removed. v2: * fix commit message (Miguel) Signed-off-by: Thomas Zimmermann <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Cc: Patrik Jakobsson <[email protected]> Cc: Alex Deucher <[email protected]> Cc: "Christian König" <[email protected]> Cc: "Pan, Xinhui" <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24Merge drm/drm-next into drm-misc-nextThomas Zimmermann13117-147012/+446556
Backmerging to get v6.5-rc2. Signed-off-by: Thomas Zimmermann <[email protected]>
2023-07-24drm/managed: Clean up GFP_ flag usage in drmm_kmalloc()Dan Carpenter1-1/+1
This code is not using the correct gfp flags which were passed in. However, this does not affect runtime because kstrdup_const() is a no-op in this context. (It just returns the "kmalloc" string literal without doing an allocation.) Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24drm/bridge: Remove redundant i2c_client in anx7625/it6505Pin-yen Lin3-114/+114
These two drivers embed a i2c_client in their private driver data, but only strict device is actually needed. Replace the i2c_client reference with a struct device one. Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: Andy Shevchenko <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24drm/bridge: it6505: Fix Kconfig indentationPin-yen Lin1-10/+10
Replace the spaces with tab characters in the Kconfig file. Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-24drm/bridge: anx7625: Drop device lock before drm_helper_hpd_irq_event()Chen-Yu Tsai1-6/+8
The device lock is used to serialize the low level power sequencing operations. Since drm_helper_hpd_irq_event() could end up calling .atomic_enable, which also calls power sequencing functions through runtime PM, this results in a real deadlock. This was observed on an MT8192-based Chromebook's external display (with appropriate patches [1] and DT changes applied). Move the drm_helper_hpd_irq_event() call outside of the lock range. The lock only needs to be held so that the device status can be read back. This is the bare minimum change to avoid the deadlock. The lock could be dropped completely and have pm_runtime_get_if_in_use() increase the reference count, but this is not the same as pm_runtime_suspended(). Dropping the lock completely also causes the internal display of the same device to not function correctly if the internal bridge's interrupt line is added in the device tree. Both the internal and external display of said device each use one anx7625 bridge. [1] https://lore.kernel.org/dri-devel/[email protected]/ Fixes: 60487584a79a ("drm/bridge: anx7625: refactor power control to use runtime PM framework") Signed-off-by: Chen-Yu Tsai <[email protected]> Reviewed-by: Robert Foss <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-22drm: Make FB_CORE to be selected if DRM fbdev emulation is enabledJavier Martinez Canillas1-3/+4
Now that fbdev core has been split in FB_CORE and FB, make the DRM symbol to select the FB_CORE option if the DRM fbdev emulation layer is enabled. This allows to disable the CONFIG_FB option if is not needed, which will avoid the need to explicitly disable each of the legacy fbdev drivers. Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Tested-by: Arnd Bergmann <[email protected]> Acked-by: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-22fbdev: Split frame buffer support in FB and FB_CORE symbolsJavier Martinez Canillas7-25/+37
Currently the CONFIG_FB option has to be enabled even if no legacy fbdev drivers are needed (e.g: only to have support for framebuffer consoles). The DRM subsystem has a fbdev emulation layer, but depends on CONFIG_FB and so it can only be enabled if that dependency is enabled as well. That means fbdev drivers have to be explicitly disabled if users want to enable CONFIG_FB, only to use fbcon and/or the DRM fbdev emulation layer. This patch introduces a non-visible CONFIG_FB_CORE symbol that could be enabled just to have core support needed for CONFIG_DRM_FBDEV_EMULATION, allowing CONFIG_FB to be disabled (and automatically disabling all the fbdev drivers). Nothing from fb_backlight.o and fbmon.o is used by the DRM fbdev emulation layer so these two objects can be compiled out when CONFIG_FB is disabled. Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Tested-by: Arnd Bergmann <[email protected]> Acked-by: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-22fbdev: Move core fbdev symbols to a separate Kconfig fileJavier Martinez Canillas2-185/+188
The drivers/video/fbdev/Kconfig defines both symbols for fbdev drivers and core fbdev symbols, that can be enabled independently of the fbdev drivers. Split the Kconfig in two, one that only has the symbols for fbdev drivers and another one that contains the fbdev core symbols. Suggested-by: Arnd Bergmann <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Tested-by: Arnd Bergmann <[email protected]> Acked-by: Helge Deller <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-22video: Add auxiliary display drivers to Graphics support menuJavier Martinez Canillas2-2/+2
The drivers in this subsystem are for either character-based or monochrome LCD controllers. Which can fall into the same category of the DRM/KMS and fbdev drivers, that are located under the "Graphics support" menu. Add the auxdisplay drivers there as well to have all display drivers under the same menu. Suggested-by: Thomas Zimmermann <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Arnd Bergmann <[email protected]> Tested-by: Arnd Bergmann <[email protected]> Acked-by: Helge Deller <[email protected]> Acked-by: Miguel Ojeda <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-22drm/ssd130x: Fix pitch calculation in ssd130x_fb_blit_rect()Geert Uytterhoeven1-1/+1
The page height must be taken into account only for vertical coordinates and heights, not for horizontal coordinates and widths. Fixes: 179a790aaf2a ("drm/ssd130x: Set the page height value in the device info data") Signed-off-by: Geert Uytterhoeven <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/54deec2ec533e90544faa8c60a0c2518c58f3e9c.1689252746.git.geert@linux-m68k.org
2023-07-21drm/amdgpu: Fix one kernel-doc commentYang Li1-1/+1
Use colon to separate parameter name from their specific meaning. silence the warning: drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c:793: warning: Function parameter or member 'adev' not described in 'amdgpu_vm_pte_update_noretry_flags' Reviewed-by: Randy Dunlap <[email protected]> Signed-off-by: Yang Li <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/amd: Fix an error handling mistake in psp_sw_init()Mario Limonciello1-3/+3
If the second call to amdgpu_bo_create_kernel() fails, the memory allocated from the first call should be cleared. If the third call fails, the memory from the second call should be cleared. Fixes: b95b5391684b ("drm/amdgpu/psp: move PSP memory alloc from hw_init to sw_init") Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Lijo Lazar <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/amdgpu: Fix infinite loop in gfxhub_v1_2_xcc_gart_enable (v2)Victor Lu1-4/+1
An instance of for_each_inst() was not changed to match its new behaviour and is causing a loop. v2: remove tmp_mask variable Fixes: b579ea632fca ("drm/amdgpu: Modify for_each_inst macro") Signed-off-by: Victor Lu <[email protected]> Acked-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/amdgpu: Program xcp_ctl registers as neededLijo Lazar1-11/+12
XCP_CTL register is expected to be programmed by firmware. Under certain conditions FW may not have programmed it correctly. As a workaround, program it when FW has not programmed the right values. Signed-off-by: Lijo Lazar <[email protected]> Reviewed-by: Hawking Zhang <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/amdkfd: fix trap handling work around for debuggingJonathan Kim3-7/+10
Update the list of devices that require the cwsr trap handling workaround for debugging use cases. Signed-off-by: Jonathan Kim <[email protected]> Acked-by: Ruili Ji <[email protected]> Reviewed-by: Felix Kuehling <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/amd/display: Allow building DC with clang on RISC-VSamuel Holland1-1/+1
clang on RISC-V appears to be unaffected by the bug causing excessive stack usage in calculate_bandwidth(). clang 16 with -fstack-usage reports a 304 byte stack frame size with CONFIG_ARCH_RV32I, and 512 bytes with CONFIG_ARCH_RV64I. Reviewed-by: Nathan Chancellor <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Signed-off-by: Samuel Holland <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/amd/display: remove an unused fileAurabindo Pillai2-185/+0
[Why&How] Internal subvp state is not referenced in driver code, so it can be removed. Signed-off-by: Aurabindo Pillai <[email protected]> Reviewed-by: Rodrigo Siqueira <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/radeon: Prefer pr_err/_info over printkSrinivasan Shanmugam1-6/+6
Fixes the following checkpatch.pl: WARNING: printk() should include KERN_<LEVEL> facility level Cc: Christian König <[email protected]> Cc: Alex Deucher <[email protected]> Signed-off-by: Srinivasan Shanmugam <[email protected]> Reviewed-by: Guchun Chen <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/amdgpu: allow secure submission on VCN4 ringsguttula1-2/+6
This patch will enable secure decode playback on VCN4_0_2 Signed-off-by: sguttula <[email protected]> Reviewed-by: Leo Liu <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/amd: Avoid reading the VBIOS part number twiceMario Limonciello7-34/+22
The VBIOS part number is read both in amdgpu_atom_parse() as well as in atom_get_vbios_pn() and stored twice in the `struct atom_context` structure. Remove the first unnecessary read and move the `pr_info` line from that read into the second. v2: squash in unused variable removal Signed-off-by: Mario Limonciello <[email protected]> Reviewed-by: Alex Deucher <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2023-07-21drm/bridge: tc358767: give VSDELAY some positive valueDavid Jander1-1/+1
The documentation is not clear about how this delay works. Empirical tests have shown that with a VSDELAY of 0, the first scanline is not properly formatted in the output stream when DSI->DP mode is used. The calculation spreadsheets from Toshiba seem to always make this value equal to the HFP + 10 for DSI->DP use-case. For DSI->DPI this value should be > 2 and for DPI->DP it seems to always be 0x64. Signed-off-by: David Jander <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Tested-by: Marek Vasut <[email protected]> # TC9595 Reviewed-by: Marek Vasut <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-21drm/bridge: tc358767: increase PLL lock time delayDavid Jander1-2/+2
The PLL often fails to lock with this delay. The new value was determined by trial and error increasing the delay bit by bit until the error did not occurr anymore even after several tries. Then double that value was taken as the minimum delay to be safe. Signed-off-by: David Jander <[email protected]> Signed-off-by: Lucas Stach <[email protected]> Reviewed-by: Marek Vasut <[email protected]> Tested-by: Marek Vasut <[email protected]> # TC9595 Reviewed-by: Marek Vasut <[email protected]> Signed-off-by: Marek Vasut <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-21drm/i915/dpt: Use shmem for dpt objectsRadhakrishna Sripada1-1/+3
Dpt objects that are created from internal get evicted when there is memory pressure and do not get restored when pinned during scanout. The pinned page table entries look corrupted and programming the display engine with the incorrect pte's result in DE throwing pipe faults. Create DPT objects from shmem and mark the object as dirty when pinning so that the object is restored when shrinker evicts an unpinned buffer object. v2: Unconditionally mark the dpt objects dirty during pinning(Chris). Fixes: 0dc987b699ce ("drm/i915/display: Add smem fallback allocation for dpt") Cc: <[email protected]> # v6.0+ Cc: Ville Syrjälä <[email protected]> Cc: Tvrtko Ursulin <[email protected]> Suggested-by: Chris Wilson <[email protected]> Signed-off-by: Fei Yang <[email protected]> Signed-off-by: Radhakrishna Sripada <[email protected]> Reviewed-by: Tvrtko Ursulin <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-21drm/arm/komeda: Remove component framework and add a simple encoderFaiz Abbas4-62/+29
The Komeda driver always expects the remote connector node to initialize an encoder. It uses the component aggregator framework which consists of component->bind() calls used to initialize the remote encoder and attach it to the crtc. This makes it incompatible with connector drivers which implement drm_bridge APIs. Remove all component framework calls from the komeda driver and declare and attach an encoder inside komeda_crtc_add(). The remote connector driver has to implement the DRM bridge APIs which can be used to glue the encoder to the remote connector. Since we usually pair this with a component encoder that also implements a drm_bridge, dropping support is not expected to affect users of this driver. Signed-off-by: Faiz Abbas <[email protected]> Message-ID: <[email protected]> [small white space fixes flagged by checkpatch.pl] Signed-off-by: Liviu Dudau <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-21drm: adv7511: Fix low refresh rate register for ADV7533/5Bogdan Togorean1-2/+7
For ADV7533 and ADV7535 low refresh rate is selected using bits [3:2] of 0x4a main register. So depending on ADV model write 0xfb or 0x4a register. Fixes: 2437e7cd88e8 ("drm/bridge: adv7533: Initial support for ADV7533") Reviewed-by: Robert Foss <[email protected]> Reviewed-by: Nuno Sa <[email protected]> Signed-off-by: Bogdan Togorean <[email protected]> Signed-off-by: Alexandru Ardelean <[email protected]> Reviewed-by: Frieder Schrempf <[email protected]> Signed-off-by: Robert Foss <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-21drm: Explicitly include correct DT includesRob Herring148-156/+152
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <[email protected]> Acked-by: Sam Ravnborg <[email protected]> Reviewed-by: Steven Price <[email protected]> Acked-by: Liviu Dudau <[email protected]> Reviewed-by: Kieran Bingham <[email protected]> Acked-by: Robert Foss <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-21gpu/host1x: Explicitly include correct DT includesRob Herring2-2/+3
The DT of_device.h and of_platform.h date back to the separate of_platform_bus_type before it as merged into the regular platform bus. As part of that merge prepping Arm DT support 13 years ago, they "temporarily" include each other. They also include platform_device.h and of.h. As a result, there's a pretty much random mix of those include files used throughout the tree. In order to detangle these headers and replace the implicit includes with struct declarations, users need to explicitly include the correct includes. Signed-off-by: Rob Herring <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-21gpu: host1x: Stop open-coding of_device_uevent()Miquel Raynal1-23/+6
There is apparently no reasons to open-code of_device_uevent() besides: - The helper receives a struct device while we want to use the of_node member of the struct device *parent*. - of_device_uevent() could not be called by modules because of a missing EXPORT_SYMBOL*(). In practice, the former point is not very constraining, just calling of_device_uevent(dev->parent, ...) would have made the trick. The latter point is more an observation rather than a real blocking point because nothing prevented of_uevent() (called by the inline function of_device_uevent()) to be exported to modules. In practice, this helper is now exported, so nothing prevent us from using of_device_uevent() anymore. Let's use the core helper directly instead of open-coding it. Cc: Thierry Reding <[email protected]> Cc: David Airlie <[email protected]> Cc: Daniel Vetter <[email protected]> Cc: Mikko Perttunen <[email protected]> Cc: Rob Herring <[email protected]> Cc: Frank Rowand <[email protected]> Signed-off-by: Miquel Raynal <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-21of: module: Export of_device_uevent()Miquel Raynal1-0/+1
The content of of_device_uevent() is currently hardcoded in a driver that can be compiled as a module. Nothing prevents of_device_uevent() to be exported to modules, most of the other helpers in of/device.c actually are. The reason why this helper was not exported is because it has been so far only useful in drivers/base, which is built-in anyway. With the idea of getting rid of the hardcoded implementation of of_device_uevent() in other places in the kernel, let's export it to GPL modules (very much like its cousins in the same file). Signed-off-by: Miquel Raynal <[email protected]> Acked-by: Rob Herring <[email protected]> Signed-off-by: Thierry Reding <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-20drm: debugfs: Silence warning from castSteven Price1-1/+1
Casting a pointer to an integer of a different size generates a warning from the compiler. First cast the pointer to a pointer-sized type to keep the compiler happy. Fixes: 4f66feeab173 ("drm: debugfs: provide infrastructure to dump a DRM GPU VA space") Reviewed-by: Danilo Krummrich <[email protected]> Signed-off-by: Steven Price <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-07-20drm: manager: Fix printk format for size_tSteven Price1-1/+1
sizeof() returns a size_t which may be different to an unsigned long. Use the correct format specifier of '%zu' to prevent compiler warnings. Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings") Reviewed-by: Danilo Krummrich <[email protected]> Signed-off-by: Steven Price <[email protected]> Signed-off-by: Danilo Krummrich <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Powered by cgit, Gruvboxed by Blaster4385.