An error occurred fetching the project authors.
- 05 Nov, 2022 1 commit
-
-
Thomas Zimmermann authored
Move the generic fbdev implementation into its own source and header file. Adapt drivers. No functional changes, but some of the internal helpers have been renamed to fit into the drm_fbdev_ naming scheme. v3: * rename drm_fbdev.{c,h} to drm_fbdev_generic.{c,h} * rebase onto vmwgfx changes * rebase onto xlnx changes * fix include statements in amdgpu Signed-off-by:Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-22-tzimmermann@suse.de
-
- 13 Oct, 2022 1 commit
-
-
Maxime Ripard authored
The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver will register a device matching the HDMI codec driver, and then register an ASoC card using that codec. However, if vc4 is compiled as a module, chances are that the hdmi-codec driver will be too. In such a case, the module loader will have a very narrow window to load the module between the device registration and the card registration. If it fails to load the module in time, the card registration will fail with EPROBE_DEFER, and we'll abort the audio initialisation, unregistering the HDMI codec device in the process. The next time the bind callback will be run, it's likely that we end up missing that window again, effectively preventing vc4 to probe entirely. In order to prevent this, we can create a soft dependency of the vc4 driver on the HDMI codec one so that we're sure the HDMI codec will be loaded before the VC4 module is, and thus we'll never end up in the previous situation. Fixes: 91e99e11 ("drm/vc4: hdmi: Register HDMI codec") Reviewed-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220902144111.3424560-1-maxime@cerno.tech
-
- 03 Aug, 2022 2 commits
-
-
Danilo Krummrich authored
Rename "GEM CMA" helpers to "GEM DMA" helpers - considering the hierarchy of APIs (mm/cma -> dma -> gem dma) calling them "GEM DMA" seems to be more applicable. Besides that, commit e57924d4 ("drm/doc: Task to rename CMA helpers") requests to rename the CMA helpers and implies that people seem to be confused about the naming. In order to do this renaming the following script was used: ``` #!/bin/bash DIRS="drivers/gpu include/drm Documentation/gpu" REGEX_SYM_UPPER="[0-9A-Z_\-]" REGEX_SYM_LOWER="[0-9a-z_\-]" REGEX_GREP_UPPER="(${REGEX_SYM_UPPER}*)(GEM)_CMA_(${REGEX_SYM_UPPER}*)" REGEX_GREP_LOWER="(${REGEX_SYM_LOWER}*)(gem)_cma_(${REGEX_SYM_LOWER}*)" REGEX_SED_UPPER="s/${REGEX_GREP_UPPER}/\1\2_DMA_\3/g" REGEX_SED_LOWER="s/${REGEX_GREP_LOWER}/\1\2_dma_\3/g" # Find all upper case 'CMA' symbols and replace them with 'DMA'. for ff in $(grep -REHl "${REGEX_GREP_UPPER}" $DIRS) do sed -i -E "$REGEX_SED_UPPER" $ff done # Find all lower case 'cma' symbols and replace them with 'dma'. for ff in $(grep -REHl "${REGEX_GREP_LOWER}" $DIRS) do sed -i -E "$REGEX_SED_LOWER" $ff done # Replace all occurrences of 'CMA' / 'cma' in comments and # documentation files with 'DMA' / 'dma'. for ff in $(grep -RiHl " cma " $DIRS) do sed -i -E "s/ cma / dma /g" $ff sed -i -E "s/ CMA / DMA /g" $ff done # Rename all 'cma_obj's to 'dma_obj'. for ff in $(grep -RiHl "cma_obj" $DIRS) do sed -i -E "s/cma_obj/dma_obj/g" $ff done ``` Only a few more manual modifications were needed, e.g. reverting the following modifications in some DRM Kconfig files - select CMA if HAVE_DMA_CONTIGUOUS + select DMA if HAVE_DMA_CONTIGUOUS as well as manually picking the occurrences of 'CMA'/'cma' in comments and documentation which relate to "GEM CMA", but not "FB CMA". Also drivers/gpu/drm/Makefile was fixed up manually after renaming drm_gem_cma_helper.c to drm_gem_dma_helper.c. This patch is compile-time tested building a x86_64 kernel with `make allyesconfig && make drivers/gpu/drm`. Acked-by:
Sam Ravnborg <sam@ravnborg.org> Acked-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Danilo Krummrich <dakr@redhat.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> #drivers/gpu/drm/arm Signed-off-by:
-
Danilo Krummrich authored
Quite a lot of drivers include the drm_fb_cma_helper.h header file without actually making use of it's provided API, hence remove those includes. Suggested-by:
-
- 13 Jul, 2022 3 commits
-
-
Maxime Ripard authored
mutex_init is supposed to be balanced by a call to mutex_destroy that we were never doing in the vc4 driver. Since a DRM-managed mutex_init variant has been introduced, let's just switch to it. Acked-by:
-
Maxime Ripard authored
When our KMS driver is unbound, the device is no longer there but we might still have users with an opened fd to the KMS device. To avoid any issue in such a situation, every device access needs to be protected by calls to drm_dev_enter() and drm_dev_exit(), and the driver needs to call drm_dev_unplug(). We'll add calls to drm_dev_enter()/drm_dev_exit() in subsequent patches changing the relevant drivers, but let's start by calling drm_dev_unplug(). Acked-by:
-
Maxime Ripard authored
While we were using the component framework to deal with all the DRM subdevices, we were not calling component_unbind_all(). This leads to none of the subdevices freeing up their resources as part of their unbind() or device managed hooks. Fixes: c8b75bca ("drm/vc4: Add KMS support for Raspberry Pi.") Acked-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by:
-
- 30 Jun, 2022 1 commit
-
-
Tom Rix authored
sparse reports drivers/gpu/drm/vc4/vc4_drv.c:270:27: warning: symbol 'vc4_dma_range_matches' was not declared. Should it be static? vc4_dma_range_matches is only used in vc4_drv.c, so it's storage class specifier should be static. Fixes: da8e393e ("drm/vc4: drv: Adopt the dma configuration from the HVS or V3D component") Signed-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
- 28 Jun, 2022 1 commit
-
-
Dave Stevenson authored
vc4_drv isn't necessarily under the /soc node in DT as it is a virtual device, but it is the one that does the allocations. The DMA addresses are consumed by primarily the HVS or V3D, and those require VideoCore cache alias address mapping, and so will be under /soc. During probe find the a suitable device node for HVS or V3D, and adopt the DMA configuration of that node. Cc: <stable@vger.kernel.org> Signed-off-by:
-
- 16 Jun, 2022 6 commits
-
-
Maxime Ripard authored
The BCM2711 has a separate driver for the v3d, and thus we can't call into any of the driver entrypoints that rely on the v3d being there. Let's add a bunch of checks and complain loudly if that ever happen. Reviewed-by:
Melissa Wen <mwen@igalia.com> Signed-off-by:
-
Maxime Ripard authored
On the BCM2711, we currently call the vc4_bo_cache_init() and vc4_gem_init() functions. These functions initialize the BO and GEM backends. However, this code was initially created to accomodate the requirements of the GPU on the older SoCs, while the BCM2711 has a separate driver for it. So let's just skip these calls when we're on a newer hardware. Reviewed-by:
-
Maxime Ripard authored
Prior to the BCM2711/RaspberryPi4, the GPU was a part of the display components of the SoC. It was thus a part of the vc4 driver. However, with the BCM2711, it got split out and thus the v3d driver was created. The vc4 driver now only handles the display part. We didn't properly split out the code when doing the BCM2711 support though, and most of the code around buffer allocations is still involved, even though it doesn't have the backing hardware anymore. Let's start the split out by creating a new drm_driver that only reports and uses what we support on the BCM2711. The ioctl were properly filtered already, but we were still exposing a .gem_create_object hook, as well as having an .open and .postclose hooks which are only relevant on older generations. Reviewed-by:
-
Maxime Ripard authored
The vc4_bo_dumb_create() both fixes up the allocation arguments to match the hardware constraints and actually performs the allocation. Since we're going to introduce a new function that uses a different allocator, let's split the arguments fixup to a separate function we will be able to reuse. Reviewed-by:
-
Maxime Ripard authored
We're going to add a new variant of the dumb BO allocation function, so let's rename vc4_dumb_create() to something a bit more specific. Reviewed-by:
-
Maxime Ripard authored
A new generation of controller has been introduced with the BCM2711/RaspberryPi4. This generation needs a bunch of quirks, and over time we've piled on a number of checks in most parts of the drivers. All these checks are performed several times, and are not always consistent. Let's create a single, global, variable to hold it and use it everywhere. Reviewed-by:
-
- 25 Feb, 2022 1 commit
-
-
Yong Wu authored
Use the common compare helper from component. Cc: Emma Anholt <emma@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by:
Yong Wu <yong.wu@mediatek.com> Link: https://lore.kernel.org/r/20220214060819.7334-18-yong.wu@mediatek.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 11 Jan, 2022 3 commits
-
-
Maxime Ripard authored
Once the call to drm_fb_helper_remove_conflicting_framebuffers() has been made, simplefb has been unregistered and the KMS driver is entirely in charge of the display. Thus, we can notify the firmware it can free whatever resource it was using to maintain simplefb functional. Signed-off-by:
-
Maxime Ripard authored
The bind hooks will modify their controller registers, so simplefb is going to be unusable anyway. Let's avoid any transient state where it could still be in the system but no longer functionnal. Acked-by:
Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by:
-
Maxime Ripard authored
If we have nomodeset on the kernel command line we should have the firmware framebuffer driver kept as is and not try to load the full-blown KMS driver. In this case, let's just register the v3d driver. Signed-off-by:
-
- 01 Sep, 2021 1 commit
-
-
Cai Huoqing authored
Use the devm_platform_ioremap_resource() helper instead of calling platform_get_resource() and devm_ioremap_resource() separately Signed-off-by:
Cai Huoqing <caihuoqing@baidu.com> Signed-off-by:
-
- 10 Aug, 2021 1 commit
-
-
Thomas Zimmermann authored
Drop the DRM IRQ midlayer in favor of Linux IRQ interfaces. DRM's IRQ helpers are mostly useful for UMS drivers. Modern KMS drivers don't benefit from using it. DRM IRQ callbacks are now being called directly or inlined. Calls to platform_get_irq() can fail with a negative errno code. Abort initialization in this case. The DRM IRQ midlayer does not handle this case correctly. Signed-off-by:
-
- 01 Jul, 2021 1 commit
-
-
Thomas Zimmermann authored
Print the name of the DRM driver when taking over fbdev devices. Makes the output to dmesg more consistent. Note that the driver name is only used for printing a string to the kernel log. No UAPI is affected by this change. Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Acked-by: Chen-Yu Tsai <wens@csie.org> # sun4i Acked-by: Neil Armstrong <narmstrong@baylibre.com> # meson Link: https://patchwork.freedesktop.org/patch/msgid/20210629135833.22679-1-tzimmermann@suse.de
-
- 24 May, 2021 1 commit
-
-
Maxime Ripard authored
We'll need to have the HVS binding before the HDMI controllers so that we can check whether the firmware allows to run in 4kp60. Reorder a bit the component list, and document the current constraints we're aware of. Acked-by:
-
- 11 May, 2021 1 commit
-
-
Zhen Lei authored
When devm_ioremap_resource() fails, a clear enough error message will be printed by its subfunction __devm_ioremap_resource(). The error information contains the device name, failure cause, and possibly resource information. Therefore, remove the error printing here to simplify code and reduce the binary size. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhen Lei <thunder.leizhen@huawei.com> Signed-off-by:
-
- 14 Apr, 2021 1 commit
-
-
Thomas Zimmermann authored
Mass-convert all drivers from FB helpers to aperture interfaces. No functional changes besides checking for returned errno codes. Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210412131043.5787-3-tzimmermann@suse.de
-
- 15 Jan, 2021 1 commit
-
-
Thomas Zimmermann authored
The function vc4_prime_import_sg_table() is an otherwise empty wrapper around CMA's drm_gem_cma_prime_import_sg_table(). Removing it in favor of the latter allows to initialize vc4_drm_driver with CMA's initializer macro. Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Acked-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20210114084949.29014-1-tzimmermann@suse.de
-
- 13 Jan, 2021 1 commit
-
-
Thomas Zimmermann authored
Moving vc4's mmap code from vc4_mmap() into a GEM object function allows for the use drm_gem_mmap() and drm_gem_prime_mmap(). The content of vc4_drm_fpos can then be generated by DEFINE_DRM_GEM_FOPS(). The actual mmap implementation is just a check if the BO is a validated shader plus the default CMA mmap code. Signed-off-by:
-
- 03 Nov, 2020 1 commit
-
-
Maxime Ripard authored
The commit dcda7c28 ("drm/vc4: kms: Add functions to create the state objects") removed the last users of the vc4 variable, but didn't remove that variable resulting in a warning. Fixes: dcda7c28 ("drm/vc4: kms: Add functions to create the state objects") Reported-by:
-
- 02 Nov, 2020 5 commits
-
-
Maxime Ripard authored
In order to make the vc4_kms_load code and error path a bit easier to read and extend, add functions to create state objects, and use managed actions to cleanup if needed. Signed-off-by:
-
Maxime Ripard authored
We can simplify a bit the bind code, its error path and unbind by using the managed devm_drm_dev_alloc function. Acked-by:
-
Maxime Ripard authored
The job queue needs to be cleaned up using vc4_gem_destroy, but it's not used consistently (vc4_drv's bind calls it in its error path, but doesn't in unbind), and we can make that automatic through a managed action. Let's remove the requirement to call vc4_gem_destroy. Fixes: d5b1a78a ("drm/vc4: Add support for drawing 3D frames.") Acked-by:
-
Maxime Ripard authored
Using drmm_mode_config_init instead of drm_mode_config_init allows us to cleanup a bit the error path. Signed-off-by:
-
Maxime Ripard authored
The BO cache needs to be cleaned up using vc4_bo_cache_destroy, but it's not used consistently (vc4_drv's bind calls it in its error path, but doesn't in unbind), and we can make that automatic through a managed action. Let's remove the requirement to call vc4_bo_cache_destroy. Fixes: c826a6e1 ("drm/vc4: Add a BO cache.") Acked-by:
-
- 27 Oct, 2020 1 commit
-
-
Hoegeun Kwon authored
There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by:
Hoegeun Kwon <hoegeun.kwon@samsung.com> Signed-off-by:
-
- 25 Sep, 2020 1 commit
-
-
Thomas Zimmermann authored
GEM object functions deprecate several similar callback interfaces in struct drm_driver. This patch replaces the per-driver callbacks with per-instance callbacks in vc4. The only exception is gem_prime_mmap, which is non-trivial to convert. Signed-off-by:
Eric Anholt <eric@anholt.net> Acked-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200923102159.24084-17-tzimmermann@suse.de
-
- 07 Sep, 2020 2 commits
-
-
Maxime Ripard authored
The BCM2711 has a reworked display pipeline, and the load tracker needs some adjustment to operate properly. Let's add a compatible for BCM2711 and disable the load tracker until properly supported. Signed-off-by:
Chanwoo Choi <cw00.choi@samsung.com> Tested-by:
Stefan Wahren <stefan.wahren@i2se.com> Reviewed-by:
-
Maxime Ripard authored
In order to prevent issues during the firmware to KMS transition, we need to make sure the pixelvalve are disabled at boot time so that the DRM state matches the hardware state. Signed-off-by:
-
- 07 Jul, 2020 1 commit
-
-
Maxime Ripard authored
We'll need the HVS to be bound before the TXP for the upcoming reworks, but it needs to happen before the PV are bound so that the code to set the possible_crtcs field works properly on the TXP. Move it right between the two devices. Signed-off-by:
-
- 10 Jun, 2020 1 commit
-
-
Maxime Ripard authored
So far the plane creation was done when each CRTC was bound, and those planes were only tied to the CRTC that was registering them. This causes two main issues: - The planes in the vc4 hardware are actually not tied to any CRTC, but can be used with every combination - More importantly, so far, we allocate 10 planes per CRTC, with 3 CRTCs. However, the next generation of hardware will have 5 CRTCs, putting us well above the maximum of 32 planes currently allowed by DRM. This patch is the first one in a series of patches that will take down both of these issues so that we can support the next generation of hardware while keeping a good amount of planes. We start by changing the way the planes are registered to first registering the primary planes for each CRTC in the CRTC bind function as we used to, but moving the overlay and cursor creation to the main driver bind function, after all the CRTCs have been bound, and make the planes associated to all CRTCs. This will slightly change the ID order of the planes, since the primary planes of all CRTCs will be first, and then a pattern of 8 overlays, 1 cursor plane for each CRTC. This shouldn't cause any trouble since the ordering between the planes is preserved though. Reviewed-by:
-
- 13 Feb, 2020 1 commit
-
-
Thomas Zimmermann authored
VBLANK callbacks in struct drm_driver are deprecated in favor of their equivalents in struct drm_crtc_funcs. Convert vc4 over. Signed-off-by:
-
