summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-07-22drm: Make FB_CORE to be selected if DRM fbdev emulation is enabledJavier Martinez Canillas
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 <javierm@redhat.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230719081544.741051-5-javierm@redhat.com
2023-07-22fbdev: Split frame buffer support in FB and FB_CORE symbolsJavier Martinez Canillas
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 <javierm@redhat.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230719081544.741051-4-javierm@redhat.com
2023-07-22fbdev: Move core fbdev symbols to a separate Kconfig fileJavier Martinez Canillas
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 <arnd@arndb.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230719081544.741051-3-javierm@redhat.com
2023-07-22video: Add auxiliary display drivers to Graphics support menuJavier Martinez Canillas
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 <tzimmermann@suse.de> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Helge Deller <deller@gmx.de> Acked-by: Miguel Ojeda <ojeda@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230719081544.741051-2-javierm@redhat.com
2023-07-22drm/ssd130x: Fix pitch calculation in ssd130x_fb_blit_rect()Geert Uytterhoeven
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 <geert@linux-m68k.org> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/54deec2ec533e90544faa8c60a0c2518c58f3e9c.1689252746.git.geert@linux-m68k.org
2023-07-21drm/bridge: tc358767: give VSDELAY some positive valueDavid Jander
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 <david@protonic.nl> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Marek Vasut <marex@denx.de> # TC9595 Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230721165328.3968759-2-l.stach@pengutronix.de
2023-07-21drm/bridge: tc358767: increase PLL lock time delayDavid Jander
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 <david@protonic.nl> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Marek Vasut <marex@denx.de> Tested-by: Marek Vasut <marex@denx.de> # TC9595 Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230721165328.3968759-1-l.stach@pengutronix.de
2023-07-21drm/arm/komeda: Remove component framework and add a simple encoderFaiz Abbas
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 <faiz.abbas@arm.com> Message-ID: <20230712064937.25192-1-faiz.abbas@arm.com> [small white space fixes flagged by checkpatch.pl] Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230712064937.25192-1-faiz.abbas@arm.com
2023-07-21drm: adv7511: Fix low refresh rate register for ADV7533/5Bogdan Togorean
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 <rfoss@kernel.org> Reviewed-by: Nuno Sa <nuno.sa@analog.com> Signed-off-by: Bogdan Togorean <bogdan.togorean@analog.com> Signed-off-by: Alexandru Ardelean <alex@shruggie.ro> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230719060143.63649-1-alex@shruggie.ro
2023-07-21drm: Explicitly include correct DT includesRob Herring
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 <robh@kernel.org> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Steven Price <steven.price@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Acked-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230714174545.4056287-1-robh@kernel.org
2023-07-21gpu/host1x: Explicitly include correct DT includesRob Herring
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 <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230714174549.4056675-1-robh@kernel.org
2023-07-21gpu: host1x: Stop open-coding of_device_uevent()Miquel Raynal
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 <thierry.reding@gmail.com> Cc: David Airlie <airlied@gmail.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Mikko Perttunen <mperttunen@nvidia.com> Cc: Rob Herring <robh+dt@kernel.org> Cc: Frank Rowand <frowand.list@gmail.com> Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230622213214.3586530-3-miquel.raynal@bootlin.com
2023-07-21of: module: Export of_device_uevent()Miquel Raynal
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 <miquel.raynal@bootlin.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Thierry Reding <treding@nvidia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230622213214.3586530-2-miquel.raynal@bootlin.com
2023-07-20drm: debugfs: Silence warning from castSteven Price
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 <dakr@redhat.com> Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/010b58cd-1225-02f7-33f0-c678e5cd349d@arm.com
2023-07-20drm: manager: Fix printk format for size_tSteven Price
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 <dakr@redhat.com> Signed-off-by: Steven Price <steven.price@arm.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/2bf64010-c40a-8b84-144c-5387412b579e@arm.com
2023-07-20drm/panel: simple: Drop prepared_timeMarek Vasut
This has been superseded by RPM in commit 3235b0f20a0a ("drm/panel: panel-simple: Use runtime pm to avoid excessive unprepare / prepare") and the last user of the non-RPM case has been dropped in commit b6d5ffce11dd ("drm/panel-simple: Non-eDP panels don't need "HPD" handling") whatever is left in this driver is just assigned and never used. Drop the remaining parts. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230709162253.464299-1-marex@denx.de
2023-07-20drm/syncobj: add IOCTL to register an eventfdSimon Ser
Introduce a new DRM_IOCTL_SYNCOBJ_EVENTFD IOCTL which signals an eventfd from a syncobj. This is useful for Wayland compositors to handle wait-before-submit. Wayland clients can send a timeline point to the compositor before the point has materialized yet, then compositors can wait for the point to materialize via this new IOCTL. The existing DRM_IOCTL_SYNCOBJ_TIMELINE_WAIT IOCTL is not suitable because it blocks. Compositors want to integrate the wait with their poll(2)-based event loop. Requirements for new uAPI: - User-space patch: https://gitlab.freedesktop.org/wlroots/wlroots/-/merge_requests/4262 - IGT: https://lists.freedesktop.org/archives/igt-dev/2023-July/057893.html v2: - Wait for fence when flags is zero - Improve documentation (Pekka) - Rename IOCTL (Christian) - Fix typo in drm_syncobj_add_eventfd() (Christian) v3: - Link user-space + IGT patches - Add reference from overview docs v4: fix IOCTL number conflict with GETFB2 (Nicholas Choi, Vitaly Prosyak) Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Pekka Paalanen <pekka.paalanen@collabora.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Cc: Daniel Stone <daniel@fooishbar.org> Cc: James Jones <jajones@nvidia.com> Cc: Austin Shafer <ashafer@nvidia.com> Cc: Vitaly Prosyak <vprosyak@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230714111257.11940-1-contact@emersion.fr
2023-07-20drm: debugfs: provide infrastructure to dump a DRM GPU VA spaceDanilo Krummrich
This commit adds a function to dump a DRM GPU VA space and a macro for drivers to register the struct drm_info_list 'gpuvas' entry. Most likely, most drivers might maintain one DRM GPU VA space per struct drm_file, but there might also be drivers not having a fixed relation between DRM GPU VA spaces and a DRM core infrastructure, hence we need the indirection via the driver iterating it's maintained DRM GPU VA spaces. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230720001443.2380-3-dakr@redhat.com
2023-07-20drm: manager to keep track of GPUs VA mappingsDanilo Krummrich
Add infrastructure to keep track of GPU virtual address (VA) mappings with a decicated VA space manager implementation. New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers start implementing, allow userspace applications to request multiple and arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is intended to serve the following purposes in this context. 1) Provide infrastructure to track GPU VA allocations and mappings, using an interval tree (RB-tree). 2) Generically connect GPU VA mappings to their backing buffers, in particular DRM GEM objects. 3) Provide a common implementation to perform more complex mapping operations on the GPU VA space. In particular splitting and merging of GPU VA mappings, e.g. for intersecting mapping requests or partial unmap requests. Acked-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Acked-by: Matthew Brost <matthew.brost@intel.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Tested-by: Matthew Brost <matthew.brost@intel.com> Tested-by: Donald Robson <donald.robson@imgtec.com> Suggested-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Danilo Krummrich <dakr@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230720001443.2380-2-dakr@redhat.com
2023-07-17drm/bridge: anx7625: Use common macros for HDCP capabilitiesChen-Yu Tsai
The DRM DP code has macros for the DP HDCP capabilities. Use them in the anx7625 driver instead of raw numbers. Fixes: cd1637c7e480 ("drm/bridge: anx7625: add HDCP support") Suggested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230710091203.1874317-1-wenst@chromium.org
2023-07-17drm/bridge: anx7625: Use common macros for DP power sequencing commandsChen-Yu Tsai
The DRM DP code has macros for the DP power sequencing commands. Use them in the anx7625 driver instead of raw numbers. Fixes: 548b512e144f ("drm/bridge: anx7625: send DPCD command to downstream") Fixes: 27f26359de9b ("drm/bridge: anx7625: Set downstream sink into normal status") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230710090929.1873646-1-wenst@chromium.org
2023-07-17drm/file: use explicit values for enum drm_minor_typeSimon Ser
This makes it clearer that the values cannot be changed because they are ABI. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by:James Zhu <James.Zhu@amd.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Christian König <christian.koenig@amd.com> Cc: Marek Olšák <marek.olsak@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230714104557.518457-2-contact@emersion.fr
2023-07-17drm/drv: use enum drm_minor_type when appropriateSimon Ser
This makes it easier to figure out what the "type" variable can be set to when reading the implementation of these functions. Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by:James Zhu <James.Zhu@amd.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Christian König <christian.koenig@amd.com> Cc: Marek Olšák <marek.olsak@amd.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20230714104557.518457-1-contact@emersion.fr
2023-07-14drm/panel: ld9040: Register a backlight devicePaul Cercueil
Register a backlight device to be able to switch between all the gamma levels. v2: Remove .get_brightness() callback, use bl_get_data() and backlight_get_brightness() Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230708084027.18352-3-paul@crapouillou.net
2023-07-14drm/panel: ld9040: Use better magic valuesPaul Cercueil
I have no idea what the prior magic values mean, and I have no idea what my replacement (extracted from [1]) magic values mean. What I do know, is that these new values result in a much better picture, where the blacks are really black (as you would expect on an AMOLED display) instead of grey-ish. [1]: https://github.com/dorimanx/Dorimanx-SG2-I9100-Kernel/blob/master-jelly-bean/arch/arm/mach-exynos/u1-panel.h v2: Remove spurious new line Signed-off-by: Paul Cercueil <paul@crapouillou.net> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230708084027.18352-2-paul@crapouillou.net
2023-07-13drm/ssd130x: Change pixel format used to compute the buffer sizeJavier Martinez Canillas
The commit e254b584dbc0 ("drm/ssd130x: Remove hardcoded bits-per-pixel in ssd130x_buf_alloc()") used a pixel format info rather than a hardcoded bpp to calculate the size of the buffer allocated to store the native pixels. But it wrongly used the DRM_FORMAT_C1 fourcc pixel format. That is for color-indexed frame buffer formats, while the ssd103x controllers don't support different single-channel colors nor a Color Lookup Table (CLUT). So the correct pixel format to use in this case is DRM_FORMAT_R1 instead. Since both formats use a eight pixels/byte, there is no functional change in practice by this patch. Still, the correct pixel format should be used. Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230713085859.907127-1-javierm@redhat.com
2023-07-13drm/loongson: Remove a useless check in cursor_plane_atomic_async_check()Sui Jingfeng
Because smatch warnings: drivers/gpu/drm/loongson/lsdc_plane.c:199 lsdc_cursor_plane_atomic_async_check() warn: variable dereferenced before check 'state' (see line 180) vim +/state +199 drivers/gpu/drm/loongson/lsdc_plane.c 174 static int lsdc_cursor_plane_atomic_async_check(struct drm_plane *plane, 175 struct drm_atomic_state *state) 176 { 177 struct drm_plane_state *new_state; 178 struct drm_crtc_state *crtc_state; 179 180 new_state = drm_atomic_get_new_plane_state(state, plane); ^^^^^ state is dereferenced inside this function 181 182 if (!plane->state || !plane->state->fb) { 183 drm_dbg(plane->dev, "%s: state is NULL\n", plane->name); 184 return -EINVAL; 185 } 186 187 if (new_state->crtc_w != new_state->crtc_h) { 188 drm_dbg(plane->dev, "unsupported cursor size: %ux%u\n", 189 new_state->crtc_w, new_state->crtc_h); 190 return -EINVAL; 191 } 192 193 if (new_state->crtc_w != 64 && new_state->crtc_w != 32) { 194 drm_dbg(plane->dev, "unsupported cursor size: %ux%u\n", 195 new_state->crtc_w, new_state->crtc_h); 196 return -EINVAL; 197 } 198 199 if (state) { ^^^^^ Checked too late! Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/r/202307100423.rV7D05Uq-lkp@intel.com/ Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Sui Jingfeng <sui.jingfeng@linux.dev> Link: https://patchwork.freedesktop.org/patch/msgid/20230710102411.257970-1-suijingfeng@loongson.cn
2023-07-12drm/amdgpu: use the new drm_exec object for CS v3Christian König
Use the new component here as well and remove the old handling. v2: drop dupplicate handling v3: fix memory leak pointed out by Tatsuyuki Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230711133122.3710-7-christian.koenig@amd.com
2023-07-12drm/amdgpu: use drm_exec for MES testingChristian König
Start using the new component here as well. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230711133122.3710-6-christian.koenig@amd.com
2023-07-12drm/amdgpu: use drm_exec for GEM and CSA handling v2Christian König
Start using the new component here as well. v2: ignore duplicates to allow per VM BO mappings Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230711133122.3710-5-christian.koenig@amd.com
2023-07-12drm/amdkfd: switch over to using drm_exec v3Christian König
Avoids quite a bit of logic and kmalloc overhead. v2: fix multiple problems pointed out by Felix v3: two more nit picks from Felix fixed Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230711133122.3710-4-christian.koenig@amd.com
2023-07-12drm: add drm_exec selftests v4Christian König
Exercise at least all driver facing functions of this new component. v2: add array test as well v3: some kunit cleanups v4: more tests and cleanups Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230711133122.3710-3-christian.koenig@amd.com
2023-07-12drm: execution context for GEM buffers v7Christian König
This adds the infrastructure for an execution context for GEM buffers which is similar to the existing TTMs execbuf util and intended to replace it in the long term. The basic functionality is that we abstracts the necessary loop to lock many different GEM buffers with automated deadlock and duplicate handling. v2: drop xarray and use dynamic resized array instead, the locking overhead is unnecessary and measurable. v3: drop duplicate tracking, radeon is really the only one needing that. v4: fixes issues pointed out by Danilo, some typos in comments and a helper for lock arrays of GEM objects. v5: some suggestions by Boris Brezillon, especially just use one retry macro, drop loop in prepare_array, use flags instead of bool v6: minor changes suggested by Thomas, Boris and Danilo v7: minor typos pointed out by checkpatch.pl fixed Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Danilo Krummrich <dakr@redhat.com> Tested-by: Danilo Krummrich <dakr@redhat.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230711133122.3710-2-christian.koenig@amd.com
2023-07-11fbdev/hyperv_fb: Include <linux/screen_info.h>Thomas Zimmermann
Include <linux/screen_info.h> to get the global screen_info state. Fixes the following errors: >> drivers/video/fbdev/hyperv_fb.c:1033:10: error: use of undeclared identifier 'screen_info' 1033 | base = screen_info.lfb_base; | ^ drivers/video/fbdev/hyperv_fb.c:1034:10: error: use of undeclared identifier 'screen_info' 1034 | size = screen_info.lfb_size; | ^ >> drivers/video/fbdev/hyperv_fb.c:1080:3: error: must use 'struct' tag to refer to type 'screen_info' 1080 | screen_info.lfb_size = 0; | ^ | struct >> drivers/video/fbdev/hyperv_fb.c:1080:14: error: expected identifier or '(' 1080 | screen_info.lfb_size = 0; | ^ drivers/video/fbdev/hyperv_fb.c:1081:3: error: must use 'struct' tag to refer to type 'screen_info' 1081 | screen_info.lfb_base = 0; | ^ | struct drivers/video/fbdev/hyperv_fb.c:1081:14: error: expected identifier or '(' 1081 | screen_info.lfb_base = 0; | ^ drivers/video/fbdev/hyperv_fb.c:1082:3: error: must use 'struct' tag to refer to type 'screen_info' 1082 | screen_info.orig_video_isVGA = 0; | ^ | struct drivers/video/fbdev/hyperv_fb.c:1082:14: error: expected identifier or '(' 1082 | screen_info.orig_video_isVGA = 0; | ^ 8 errors generated. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307101042.rqehuauj-lkp@intel.com/ Fixes: 8b0d13545b09 ("efi: Do not include <linux/screen_info.h> from EFI header") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: "K. Y. Srinivasan" <kys@microsoft.com> (supporter:Hyper-V/Azure CORE AND DRIVERS) Cc: Haiyang Zhang <haiyangz@microsoft.com> (supporter:Hyper-V/Azure CORE AND DRIVERS) Cc: Wei Liu <wei.liu@kernel.org> (supporter:Hyper-V/Azure CORE AND DRIVERS) Cc: Dexuan Cui <decui@microsoft.com> (supporter:Hyper-V/Azure CORE AND DRIVERS) Cc: Helge Deller <deller@gmx.de> (maintainer:FRAMEBUFFER LAYER) Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Sui Jingfeng <suijingfeng@loongson.cn> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: linux-efi@vger.kernel.org Cc: linux-hyperv@vger.kernel.org (open list:Hyper-V/Azure CORE AND DRIVERS) Cc: linux-fbdev@vger.kernel.org (open list:FRAMEBUFFER LAYER) Cc: dri-devel@lists.freedesktop.org (open list:FRAMEBUFFER LAYER) Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Link: https://patchwork.freedesktop.org/patch/msgid/20230710075848.23087-1-tzimmermann@suse.de
2023-07-10drm/arm: Make ARM devices menu depend on DRMJavier Martinez Canillas
Otherwise if CONFIG_DRM is disabled, menuconfig will show an empty menu. Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230703230534.997525-4-javierm@redhat.com
2023-07-10drm/ttm: Use init_on_free to delay release TTM BOsRajneesh Bhardwaj
Delay release TTM BOs when the kernel default setting is init_on_free. This offloads the overhead of clearing the system memory to the work item and potentially a different CPU. This could be very beneficial when the application does a lot of malloc/free style allocations of system memory. Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>. Link: https://patchwork.freedesktop.org/patch/msgid/20230708011355.853-1-rajneesh.bhardwaj@amd.com Signed-off-by: Christian König <christian.koenig@amd.com>
2023-07-10drm/bridge: cdns-mhdp8546: Fix the interrupt enable/disableNikhil Devshatwar
When removing the tidss driver, there is a warning reported by kernel about an unhandled interrupt for mhdp driver. [ 43.238895] irq 31: nobody cared (try booting with the "irqpoll" option) ... [snipped backtrace] [ 43.330735] handlers: [ 43.333020] [<000000005367c4f9>] irq_default_primary_handler threaded [<000000007e02b601>] cdns_mhdp_irq_handler [cdns_mhdp8546] [ 43.344607] Disabling IRQ #31 This happens because as part of cdns_mhdp_bridge_hpd_disable, driver tries to disable the interrupts. While disabling the SW_EVENT interrupts, it accidentally enables the MBOX interrupts, which are not handled by the driver. Fix this with a read-modify-write to update only required bits. Use the enable / disable function as required in other places. Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com> Reviewed-by: Swapnil Jakhade <sjakhade@cadence.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-9-a-bhatia1@ti.com
2023-07-10drm/tidss: Update encoder/bridge chain connect modelAradhya Bhatia
With the new encoder/bridge chain model, the display controller driver is required to create a drm_connector entity instead of asking the bridge to do so during drm_bridge_attach. Moreover, the controller driver should create a drm_bridge entity to negotiate bus formats and a 'simple' drm_encoder entity to expose it to userspace. Update the encoder/bridge initialization sequence in tidss as per the new model. Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-8-a-bhatia1@ti.com
2023-07-10drm/bridge: sii902x: Set input_bus_flags in atomic_checkAradhya Bhatia
input_bus_flags are specified in drm_bridge_timings (legacy) as well as drm_bridge_state->input_bus_cfg.flags The flags from the timings will be deprecated. Bridges are supposed to validate and set the bridge state flags from atomic_check. Implement atomic_check hook for the same. Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-7-a-bhatia1@ti.com
2023-07-10drm/bridge: sii902x: Support format negotiation hooksAradhya Bhatia
With new connector model, sii902x will not create the connector, when DRM_BRIDGE_ATTACH_NO_CONNECTOR is set and SoC driver will rely on format negotiation to setup the encoder format. Support format negotiations hooks in the drm_bridge_funcs. Use helper functions for state management. Input format is selected to MEDIA_BUS_FMT_RGB888_1X24 as default, as is the case with older model. Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-6-a-bhatia1@ti.com
2023-07-10drm/bridge: mhdp8546: Set input_bus_flags from atomic_checkNikhil Devshatwar
input_bus_flags are specified in drm_bridge_timings (legacy) as well as drm_bridge_state->input_bus_cfg.flags The flags from the timings will be deprecated. Bridges are supposed to validate and set the bridge state flags from atomic_check. Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com> [a-bhatia1: replace timings in cdns_mhdp_platform_info by input_bus_flags] Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-5-a-bhatia1@ti.com
2023-07-10drm/bridge: mhdp8546: Add minimal format negotiationNikhil Devshatwar
With new connector model, mhdp bridge will not create the connector and SoC driver will rely on format negotiation to setup the encoder format. Support minimal format negotiations hooks in the drm_bridge_funcs. Complete format negotiation can be added based on EDID data. This patch adds the minimal required support to avoid failure after moving to new connector model. Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com> [a-bhatia1: Drop the output_fmt check condition] Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-4-a-bhatia1@ti.com
2023-07-10drm/bridge: tfp410: Set input_bus_flags in atomic_checkNikhil Devshatwar
input_bus_flags are specified in drm_bridge_timings (legacy) as well as drm_bridge_state->input_bus_cfg.flags The flags from the timings will be deprecated. Bridges are supposed to validate and set the bridge state flags from atomic_check. Implement atomic_check hook for the same. Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com> Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-3-a-bhatia1@ti.com
2023-07-10drm/bridge: tfp410: Support format negotiation hooksNikhil Devshatwar
With new connector model, tfp410 will not create the connector and SoC driver will rely on format negotiation to setup the encoder format. Support format negotiations hooks in the drm_bridge_funcs. Use helper functions for state management. Input format is the one selected by the bridge from DT properties. Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com> [a-bhatia1: Removed output fmt condition check] Signed-off-by: Aradhya Bhatia <a-bhatia1@ti.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230606082142.23760-2-a-bhatia1@ti.com
2023-07-10drm/bridge: tc358767: Use devm_clk_get_enabled() helperChristophe JAILLET
The devm_clk_get_enabled() helper: - calls devm_clk_get() - calls clk_prepare_enable() and registers what is needed in order to call clk_disable_unprepare() when needed, as a managed resource. This simplifies the code and avoids the need of a dedicated function used with devm_add_action_or_reset(). Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/208a15ce4e01973daf039ad7bc0f9241f650b3af.1672415956.git.christophe.jaillet@wanadoo.fr
2023-07-10drm/nouveau/disp: use drm_kms_helper_connector_hotplug_event()Simon Ser
This adds more information to the hotplug uevent and lets user-space know that it's about a particular connector only. Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Karol Herbst <kherbst@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230620181547.272476-1-contact@emersion.fr
2023-07-10nouveau/dispnv50: add cursor pitch checkSimon Ser
The hardware needs a FB which is packed. Add checks to make sure this is the case. While at it, add debug logs for the existing checks. This allows user-space to more easily figure out why a configuration is rejected. v2: - Use drm_format_info instead of hardcoding bytes-per-pixel (Ilia) - Remove unnecessary size check (Ilia) v3: - Add missing newlines in debug messages (Lyude) - Use NV_ATOMIC (Lyude) - Add missing debug log for invalid format (Ilia) v4: add plane name in debug messages (Ilia) Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Ilia Mirkin <imirkin@alum.mit.edu> Cc: Ben Skeggs <bskeggs@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210205224140.28174-1-contact@emersion.fr
2023-07-09drm/virtio: Conditionally allocate virtio_gpu_fenceGurchetan Singh
We don't want to create a fence for every command submission. It's only necessary when userspace provides a waitable token for submission. This could be: 1) bo_handles, to be used with VIRTGPU_WAIT 2) out_fence_fd, to be used with dma_fence apis 3) a ring_idx provided with VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK + DRM event API 4) syncobjs in the future The use case for just submitting a command to the host, and expecting no response. For example, gfxstream has GFXSTREAM_CONTEXT_PING that just wakes up the host side worker threads. There's also CROSS_DOMAIN_CMD_SEND which just sends data to the Wayland server. This prevents the need to signal the automatically created virtio_gpu_fence. In addition, VIRTGPU_EXECBUF_RING_IDX is checked when creating a DRM event object. VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is already defined in terms of per-context rings. It was theoretically possible to create a DRM event on the global timeline (ring_idx == 0), if the context enabled DRM event polling. However, that wouldn't work and userspace (Sommelier). Explicitly disallow it for clarity. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # edited coding style Link: https://patchwork.freedesktop.org/patch/msgid/20230707213124.494-1-gurchetansingh@chromium.org
2023-07-09drm/hyperv: Fix a compilation issue because of not including screen_info.hSui Jingfeng
Fixes the following build errors on arm64: drivers/video/fbdev/hyperv_fb.c: In function 'hvfb_getmem': >> drivers/video/fbdev/hyperv_fb.c:1033:24: error: 'screen_info' undeclared (first use in this function) 1033 | base = screen_info.lfb_base; | ^~~~~~~~~~~ drivers/video/fbdev/hyperv_fb.c:1033:24: note: each undeclared identifier is reported only once for each function it appears in >> drivers/gpu/drm/hyperv/hyperv_drm_drv.c:75:54: error: 'screen_info' undeclared (first use in this function) 75 | drm_aperture_remove_conflicting_framebuffers(screen_info.lfb_base, | ^~~~~~~~~~~ drivers/gpu/drm/hyperv/hyperv_drm_drv.c:75:54: note: each undeclared identifier is reported only once for each function it appears in Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202307090823.nxnT8Kk5-lkp@intel.com/ Fixes: 81d2393485f0 ("fbdev/hyperv-fb: Do not set struct fb_info.apertures") Fixes: 8b0d13545b09 ("efi: Do not include <linux/screen_info.h> from EFI header") Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230709100514.703759-1-suijingfeng@loongson.cn
2023-07-08fbdev/xen-fbfront: Generate deferred I/O opsThomas Zimmermann
Use the existing generator macros to create deferred-I/O helpers for xen-fbfront and set them in the fb_ops structure. Functions for damage handling on memory ranges and areas are provided by the driver. Xen-fbfront's implementation of fb_write writes to system memory, so the generated code can use the respective helper internally. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Acked-by: Helge Deller <deller@gmx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230706151432.20674-11-tzimmermann@suse.de
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-01 19:49:37 +0000