summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vc4
AgeCommit message (Collapse)AuthorFilesLines
2025-04-05treewide: Switch/rename to timer_delete[_sync]()Thomas Gleixner1-1/+1
timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree over and remove the historical wrapper inlines. Conversion was done with coccinelle plus manual fixups where necessary. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2025-03-03drm/vc4: hdmi: Fix some NULL vs IS_ERR() bugsDan Carpenter1-14/+14
The devm_platform_ioremap_resource_byname() function doesn't return NULL, it returns error pointers. Update the checking to match. Fixes: b93f07cf090a ("drm/vc4: move to devm_platform_ioremap_resource() usage") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/a952e2b4-d4b8-49ac-abd9-9967c50f4a80@stanley.mountain Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-03-03drm/tests: Drop drm_kunit_helper_acquire_ctx_alloc()Maxime Ripard1-19/+27
lockdep complains when a lock is released in a separate thread the lock is taken in, and it turns out that kunit does run its actions in a separate thread than the test ran in. This means that drm_kunit_helper_acquire_ctx_alloc() just cannot work as it's supposed to, so let's just get rid of it. Suggested-by: Simona Vetter <simona.vetter@ffwll.ch> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250220132537.2834168-1-mripard@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-26drm/vc4: move to devm_platform_ioremap_resource() usageAnusha Srivatsa1-35/+18
Replace platform_get_resource_byname + devm_ioremap_resource with just devm_platform_ioremap_resource() Used Coccinelle to do this change. SmPl patch: //rule s/(devm_)platform_get_resource_byname + //(devm_)ioremap/devm_platform_ioremap_resource. @rule_3@ identifier res; expression ioremap; identifier pdev; constant mem; expression name; @@ -struct resource *res; <+... -res = platform_get_resource_byname(pdev,mem,name); <... -if (!res) { -... -} ...> -ioremap = devm_ioremap(...); +ioremap = devm_platform_ioremap_resource_byname(pdev,name); ...+> v2: Change the SmPl patch to work on multiple occurences of the pattern. This also fixes the compilation error. v3: Do not convert "hd" resource to follow the rest of the refactor. (Maxime) v4: fix compiler error Cc: Maxime Ripard <mripard@kernel.org> Cc: Dave Stevenson <dave.stevenson@raspberrypi.com> Cc: Maíra Canal <mcanal@igalia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Anusha Srivatsa <asrivats@redhat.com> Link: https://lore.kernel.org/r/20250225-memory-drm-misc-next-v1-11-9d0e8761107a@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-19drm/bridge: Pass full state to atomic_post_disableMaxime Ripard1-1/+1
It's pretty inconvenient to access the full atomic state from drm_bridges, so let's change the atomic_post_disable hook prototype to pass it directly. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-5-e71598f49c8f@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-19drm/bridge: Pass full state to atomic_disableMaxime Ripard1-1/+1
It's pretty inconvenient to access the full atomic state from drm_bridges, so let's change the atomic_disable hook prototype to pass it directly. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-4-e71598f49c8f@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-19drm/bridge: Pass full state to atomic_enableMaxime Ripard1-1/+1
It's pretty inconvenient to access the full atomic state from drm_bridges, so let's change the atomic_enable hook prototype to pass it directly. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-3-e71598f49c8f@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-19drm/bridge: Pass full state to atomic_pre_enableMaxime Ripard1-2/+1
It's pretty inconvenient to access the full atomic state from drm_bridges, so let's change the atomic_pre_enable hook prototype to pass it directly. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Tested-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20250213-bridge-connector-v3-2-e71598f49c8f@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-02-14drm/atomic: Let drivers decide which planes to async flipAndré Almeida1-1/+1
Currently, DRM atomic uAPI allows only primary planes to be flipped asynchronously. However, each driver might be able to perform async flips in other different plane types. To enable drivers to set their own restrictions on which type of plane they can or cannot flip, use the existing atomic_async_check() from struct drm_plane_helper_funcs to enhance this flexibility, thus allowing different plane types to be able to do async flips as well. Create a new parameter for the atomic_async_check(), `bool flip`. This parameter is used to distinguish when this function is being called from a plane update from a full page flip. In order to prevent regressions and such, we keep the current policy: we skip the driver check for the primary plane, because it is always allowed to do async flips on it. Signed-off-by: André Almeida <andrealmeid@igalia.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Christopher Snowhill <chris@kode54.net> Tested-by: Christopher Snowhill <chris@kode54.net> Link: https://patchwork.freedesktop.org/patch/msgid/20250127-tonyk-async_flip-v12-1-0f7f8a8610d3@igalia.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-02-13drm/vc4: hdmi: Use drm_atomic_helper_reset_crtc()Herve Codina1-29/+1
The current code uses a the reset_pipe() local function to reset the CRTC outputs. drm_atomic_helper_reset_crtc() has been introduced recently and it performs exact same operations. In order to avoid code duplication, use the new helper instead of the local function. Signed-off-by: Herve Codina <herve.codina@bootlin.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20250210132620.42263-4-herve.codina@bootlin.com Signed-off-by: Maxime Ripard <mripard@kernel.org>
2025-01-19drm/vc4: Remove BOs seqnosMaíra Canal4-113/+17
`bo->seqno`, `bo->write_seqno`, and `exec->bin_dep_seqno` are leftovers from a time when VC4 didn't support DMA Reservation Objects. Before DMA Resv was introduced, tracking the correspondence between BOs and jobs through the job's seqno made sense. However, this is no longer needed, as VC4 now supports DMA Reservation Objects and attaches the "job done" fence to the BOs. Therefore, remove the BOs seqnos in favor of using DMA Resv Objects. Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Melissa Wen <mwen@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241220134204.634577-4-mcanal@igalia.com
2025-01-19drm/vc4: Use DMA Resv to implement VC4 wait BO IOCTLMaíra Canal1-11/+14
Since the BOs used by VC4 have DMA Reservation Objects attached to them, waiting for seqnos to check BO availability is unnecessary. Instead, `drm_gem_dma_resv_wait()` can be used. Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241220134204.634577-3-mcanal@igalia.com
2025-01-19drm/vc4: Use DRM Execution ContextsMaíra Canal2-78/+22
VC4 has internal copies of `drm_gem_lock_reservations()` and `drm_gem_unlock_reservations()` within the driver. Ideally, these hard-coded functions should be replaced with the generic functions provided by DRM common code. However, instead of using the DRM GEM functions to (un)lock reservations, transition to the new DRM Execution Contexts API. Signed-off-by: Maíra Canal <mcanal@igalia.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241220134204.634577-2-mcanal@igalia.com
2025-01-07drm/connector: make mode_valid take a const struct drm_display_modeDmitry Baryshkov1-1/+1
The mode_valid() callbacks of drm_encoder, drm_crtc and drm_bridge take a const struct drm_display_mode argument. Change the mode_valid callback of drm_connector to also take a const argument. Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Liviu Dudau <liviu.dudau@arm.com> Reviewed-by: Raphael Gallais-Pou <rgallaispou@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241214-drm-connector-mode-valid-const-v2-5-4f9498a4c822@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-04drm/vc4: hdmi: use drm_atomic_helper_connector_hdmi_hotplug()Dmitry Baryshkov1-6/+3
Use the helper function to update the connector's information. This makes sure that HDMI-related events are handled in a generic way. Currently it is limited to the HDMI state reporting to the sound system. Acked-by: Maxime Ripard <mripard@kernel.org> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241224-drm-bridge-hdmi-connector-v10-10-dc89577cd438@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-04drm/vc4: hdmi: stop rereading EDID in get_modes()Dmitry Baryshkov1-21/+0
The vc4_hdmi_connector_detect_ctx() via vc4_hdmi_handle_hotplug() already reads EDID and propagates it to the drm_connector. Stop rereading EDID as a part of the .get_modes() callback and just update the list of modes. This matches the behaviour of the i915 driver. Acked-by: Maxime Ripard <mripard@kernel.org> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241224-drm-bridge-hdmi-connector-v10-9-dc89577cd438@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2025-01-04drm/vc4: hdmi: switch to using generic HDMI Codec infrastructureDmitry Baryshkov3-57/+20
Drop driver-specific implementation and use the generic HDMI Codec framework in order to implement the HDMI audio support. Acked-by: Maxime Ripard <mripard@kernel.org> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241224-drm-bridge-hdmi-connector-v10-8-dc89577cd438@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-12-16drm/vc4: hdmi: use eld_mutex to protect access to connector->eldDmitry Baryshkov1-2/+2
Reading access to connector->eld can happen at the same time the drm_edid_to_eld() updates the data. Take the newly added eld_mutex in order to protect connector->eld from concurrent access. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241206-drm-connector-eld-mutex-v2-10-c9bce1ee8bea@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-12-12drm/vc4: unlock on error in vc4_hvs_get_fifo_frame_count()Dan Carpenter1-1/+1
The default statement is never used in real life. However, if it were used for some reason then call drm_dev_exit() before returning. Fixes: 8f2fc64773be ("drm/vc4: Fix reading of frame count on GEN5 / Pi4") Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/b61a81b2-0101-43bd-a4f6-09cf3a016484@stanley.mountain Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-12-11drm/vc4: plane: Remove WARN on state being set in plane_resetDave Stevenson1-1/+4
It is permitted on situations such as system resume for plane->state to be non-NULL, and that should be handled by freeing it. Do so. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Stefan Wahren <wahrenst@gmx.net> Reviewed-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241202120343.33726-1-wahrenst@gmx.net
2024-12-09Merge remote-tracking branch 'drm/drm-next' into drm-misc-nextMaarten Lankhorst9-9/+9
The v6.13-rc2 release included a bunch of breaking changes, specifically the MODULE_IMPORT_NS commit. Backmerge in order to fix them before the next pull-request. Include the fix from Stephen Roswell. Caused by commit 25c3fd1183c0 ("drm/virtio: Add a helper to map and note the dma addrs and lengths") Interacting with commit cdd30ebb1b9f ("module: Convert symbol namespace to string literal") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Link: https://patchwork.freedesktop.org/patch/msgid/20241209121717.2abe8026@canb.auug.org.au Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
2024-12-05drm/vc4: use drm_hdmi_connector_mode_valid()Dmitry Baryshkov1-3/+2
Use new drm_hdmi_connector_mode_valid() helper instead of a module-specific copy. Reviewed-by: Chen-Yu Tsai <wens@csie.org> Acked-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241130-hdmi-mode-valid-v5-6-742644ec3b1f@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
2024-12-05drm: remove driver date from struct drm_driver and all driversJani Nikula1-3/+0
We stopped using the driver initialized date in commit 7fb8af6798e8 ("drm: deprecate driver date") and (eventually) started returning "0" for drm_version ioctl instead. Finish the job, and remove the unused date member from struct drm_driver, its initialization from drivers, along with the common DRIVER_DATE macros. v2: Also update drivers/accel (kernel test robot) Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Simon Ser <contact@emersion.fr> Acked-by: Jeffrey Hugo <quic_jhugo@quicinc.com> Acked-by: Lucas De Marchi <lucas.demarchi@intel.com> Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # msm Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1f2bf2543aed270a06f6c707fd6ed1b78bf16712.1733322525.git.jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2024-12-02Get rid of 'remove_new' relic from platform driver structLinus Torvalds9-9/+9
The continual trickle of small conversion patches is grating on me, and is really not helping. Just get rid of the 'remove_new' member function, which is just an alias for the plain 'remove', and had a comment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */ This was just a tree-wide 'sed' script that replaced '.remove_new' with '.remove', with some care taken to turn a subsequent tab into two tabs to make things line up. I did do some minimal manual whitespace adjustment for places that used spaces to line things up. Then I just removed the old (sic) .remove_new member function, and this is the end result. No more unnecessary conversion noise. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-11-27drm/vc4: Drop planes that are completely off-screen or 0 crtc sizeDave Stevenson1-0/+20
It is permitted for a plane to be configured such that none of it is on-screen via either negative dest rectangle X,Y offset, or an offset that is greater than the crtc dimensions. These planes were resized via drm_atomic_helper_check_plane_state such that the source rectangle had a zero width or height, but they still created a dlist entry even though they contributed no pixels. In the case of vc6_plane_mode_set, that it could result in negative values being written into registers, which caused incorrect behaviour. Drop planes that result in a source width or height of 0 pixels or an on-screen size of 0 pixels to avoid the incorrect rendering. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-28-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: Enable bg_fill if there are no planes enabledDave Stevenson1-1/+1
The default was to have enable_bg_fill disabled and the first plane set it if it wasn't opaque and covering the whole screen. However that meant that if no planes were enabled, then the background fill wasn't enabled, and would give a striped output from the uninitialised output buffer. Initialise it to enabled to avoid this. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-27-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: Add additional warn_on for incorrect revisionsMaxime Ripard3-2/+51
Some code path in vc4 are conditional to a generation and cannot be executed on others. Let's put a WARN_ON if that ever happens. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-26-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: hdmi: Support 2712 D-step register mapDave Stevenson2-2/+26
The D-step has increased FIFO sizes of the MAI_THR blocks, resulting in changes to the register masking. Add support for it. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-25-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: plane: Add support for 2712 D-step.Dave Stevenson2-21/+60
There are a few minor changes in the display list generation for the D-step of the chip, so add them. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-24-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: hvs: Add in support for 2712 D-step.Dave Stevenson4-46/+234
The registers have been moved around, and a couple of minor changes made, so adapt for this. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-23-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: drv: Add support for 2712 D-stepDave Stevenson4-0/+9
Add in the compatible string and VC4_GEN_ enum for the D-step Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-22-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: txp: Add BCM2712 MOPLET supportMaxime Ripard1-0/+14
The BCM2712 features a simpler TXP called MOPLET. Let's add support for it. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-21-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: txp: Add support for BCM2712 MOPMaxime Ripard1-1/+18
The BCM2712 has an evolution of what used to be called TXP in the earlier SoCs, but is now called MOP. There's a few differences still, so we can add a new compatible to deal with them easily. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-20-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: txp: Add a new TXP encoder typeMaxime Ripard5-58/+59
Starting with BCM2712, we'll have a two TXP. Let's follow the HDMI example and add two encoder types for TXP: TXP0 and TXP1. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-19-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: txp: Move the encoder type in the variant structureMaxime Ripard2-1/+3
We'll have multiple TXP instances in the BCM2712, so we can't use a single encoder type anymore. Let's tie the encoder type to the compatible. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-18-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: txp: Handle 40-bits DMA AddressesMaxime Ripard2-1/+13
The BCM2712 MOP and MOPLET can handle addresses larger than 32bits through an extra register. We can easily support it and make it conditional based on the compatible through a boolean in our variant structure. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-17-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: txp: Add horizontal and vertical size offset toggle bitMaxime Ripard2-2/+13
The new writeback controllers that can be found on the BCM2712 require to have their horizontal and vertical size reduced by one. Let's tie that behaviour to the compatible so we can support both the new and old controllers. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-16-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: txp: Add byte enable toggle bitMaxime Ripard2-1/+6
The MOPLET doesn't have the BYTE_ENABLE field to set, but the TXP and MOP do, so let's add a boolean to control whether or not we need to set it. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-15-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: txp: Rename TXP data structureMaxime Ripard3-5/+5
The TXP data structure has a name too generic for the multiple variants we'll have to support. Let's rename it to mention the SoC it applies to. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-14-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: txp: Introduce structure to deal with revision differencesMaxime Ripard3-10/+23
The BCM2712 will have several TXP with small differences. Let's add a structure tied to the compatible to deal with those differences. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-13-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: hdmi: Add support for BCM2712 HDMI controllersMaxime Ripard4-6/+943
The HDMI controllers found in the BCM2712 are largely the ones found in the BCM2711 with a different PHY. There's some difference with how timings are split between registers, and HDMI1 is now able to run at 4k/60Hz. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-12-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: crtc: Add support for BCM2712 PixelValvesMaxime Ripard3-2/+55
The PixelValves found on the BCM2712 are similar to the ones found in the previous generation. Compared to BCM2711: - the pixelvalves only drive one HDMI controller each - HDMI1 PixelValve has a FIFO long enough to support 4k at 60Hz - support has been added for odd horizontal timings whilst at 2pixels/clock Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-11-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: hvs: Add support for BCM2712 HVSMaxime Ripard7-77/+1616
The HVS found in the BCM2712, while having a similar role, is very different from the one found in the previous SoCs. Indeed, the register layout is fairly different, and the DLIST format is new as well. Let's introduce the needed functions to support the new HVS. This commit adds the C-step register layout. The D-step will be added later. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-10-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: drv: Support BCM2712Maxime Ripard2-0/+2
The BCM2712 has an improved display pipeline, most notably with a different HVS and only HDMI and writeback outputs. Let's introduce it as a new VideoCore generation and compatible. Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-9-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: Fix reading of frame count on GEN5 / Pi4Dave Stevenson2-11/+40
The frame count values moved within registers DISPSTAT1 and DISPSTAT2 with GEN5, so update the accessor function to accommodate that. Fixes: b51cd7ad143d ("drm/vc4: hvs: Fix frame count register readout") Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-2-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-27drm/vc4: Use of_device_get_match_data to set generationDave Stevenson1-7/+4
Use of_device_get_match_data to retrieve the generation value as set in the struct of_device_id, rather than manually comparing compatible strings. Reviewed-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20241025-drm-vc4-2712-support-v2-1-35efa83c8fc0@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
2024-11-15drm/client: Move public client header to clients/ subdirectoryThomas Zimmermann1-1/+1
Move the public header file drm_client_setup.h to the clients/ subdirectory and update all drivers. No functional changes. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241108154600.126162-3-tzimmermann@suse.de
2024-11-04Backmerge v6.12-rc6 of ↵Dave Airlie1-1/+6
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux into drm-next Backmerge Linus tree for some drm-fixes needed for msm and xe merges. Signed-off-by: Dave Airlie <airlied@redhat.com>
2024-10-14drm/vc4: Use video aperture helpersThomas Zimmermann1-2/+2
DRM's aperture functions have long been implemented as helpers under drivers/video/ for use with fbdev. Avoid the DRM wrappers by calling the video functions directly. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: Maxime Ripard <mripard@kernel.org> Cc: Dave Stevenson <dave.stevenson@raspberrypi.com> Cc: Raspberry Pi Kernel Maintenance <kernel-list@raspberrypi.com> Acked-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240930130921.689876-25-tzimmermann@suse.de
2024-10-09drm/vc4: Correct generation check in vc4_hvs_lut_loadDave Stevenson1-1/+1
Commit 24c5ed3ddf27 ("drm/vc4: Introduce generation number enum") incorrectly swapped a check of hvs->vc4->is_vc5 to hvs->vc4->gen == VC4_GEN_4 in vc4_hvs_lut_load, hence breaking loading the gamma look up table on Pi0-3. Correct that conditional. Fixes: 24c5ed3ddf27 ("drm/vc4: Introduce generation number enum") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/dri-devel/37051126-3921-4afe-a936-5f828bff5752@samsung.com/ Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241008-drm-vc4-fixes-v1-3-9d0396ca9f42@raspberrypi.com Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-05-11 13:07:15 +0300