aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/vc4
Commit message (Collapse)AuthorAgeFilesLines
* drm/vc4: use new debugfs device-centered functionsMaíra Canal2022-12-2211-116/+37
| | | | | | | | | | | | | | | | | | | | Currently, vc4 has its own debugfs infrastructure that adds the debugfs files on drm_dev_register(). With the introduction of the new debugfs, functions, replace the vc4 debugfs structure with the DRM debugfs device-centered function, drm_debugfs_add_file(). Moreover, remove the explicit error handling of debugfs related functions, considering that the only failure mode is -ENOMEM and also that error handling is not recommended for debugfs functions, as pointed out in [1]. [1] https://lore.kernel.org/all/YWAmZdRwnAt6wh9B@kroah.com/ Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Melissa Wen <mwen@igalia.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20221219120621.15086-5-mcanal@igalia.com
* drm/vc4: dsi: Remove entry to ULPS from vc4_dsi post_disableDave Stevenson2022-12-151-2/+0
| | | | | | | | | | | | | | | | Post_disable was sending the D-PHY sequence to put any device into ULPS suspend mode, and then cutting power to the DSI block. The power-on reset state of the DSI block is for DSI to be in an operational state, not ULPS, so it then never sent the sequence for exiting ULPS. Any attached device that didn't have an external reset therefore remained in ULPS / standby, and didn't function. Use of ULPS isn't well specified in DRM, therefore remove entering it to avoid the above situation. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-dsi-bridge-v1-6-8f68ee0b0adb@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dsi: Convert to using a bridge instead of encoderDave Stevenson2022-12-151-31/+90
| | | | | | | | | | | | | | | | | Remove the encoder functions, and create a bridge attached to this dumb encoder which implements the same functionality. As a bridge has state which an encoder doesn't, we need to add the state management functions as well. As there is no bridge atomic_mode_set, move the initialisation code that was in mode_set into _pre_enable. The code to actually enable and disable sending video are split from the general control into _enable and _disable. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-dsi-bridge-v1-5-8f68ee0b0adb@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dsi: Convert to use atomic operationsDave Stevenson2022-12-151-8/+15
| | | | | | | | | | The atomic calls are preferred as the non-atomic ones are deprecated. In preparation for conversion to a bridge, switch to the atomic calls. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-dsi-bridge-v1-4-8f68ee0b0adb@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dsi: Remove splitting the bridge chain from the driverDave Stevenson2022-12-151-47/+0
| | | | | | | | | | | | | Splitting the bridge chain fails for atomic bridges as the framework can't add the relevant state in drm_atomic_add_encoder_bridges. The chain was split because we needed to power up before calling pre_enable, but that is now done in mode_set, and will move into the framework. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-dsi-bridge-v1-3-8f68ee0b0adb@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dsi: Move initialisation to encoder_mode_setDave Stevenson2022-12-151-4/+12
| | | | | | | | | | | | Breaking the bridge chain does not work for atomic bridges/panels and generally causes issues. We need to initialise the DSI host before the bridge pre_enables are called, so move that to encoder_mode_set in the same way that dw-mipi-dsi does. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-dsi-bridge-v1-2-8f68ee0b0adb@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dsi: Rename bridge to out_bridgeDave Stevenson2022-12-151-6/+6
| | | | | | | | | | In preparation for converting the encoder to being a bridge, rename the variable holding the next bridge in the chain to out_bridge, so that our bridge can be called bridge. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221207-rpi-dsi-bridge-v1-1-8f68ee0b0adb@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: tests: Add unit test suite for the PV muxingMaxime Ripard2022-12-084-9/+1091
| | | | | | | | | | | | | The HVS to PixelValve muxing code is fairly error prone and has a bunch of arbitrary constraints due to the hardware setup. Let's create a test suite that makes sure that the possible combinations work and the invalid ones don't. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-19-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: tests: Fail the current test if we access a registerMaxime Ripard2022-12-087-13/+81
| | | | | | | | | | | | Accessing a register when running under kunit is a bad idea since our device is completely mocked. Fail the current test if we ever access any of our hardware registers. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-18-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: tests: Introduce a mocking infrastructureMaxime Ripard2022-12-0812-13/+511
| | | | | | | | | | | | | | | In order to test the current atomic_check hooks we need to have a DRM device that has roughly the same capabilities and layout that the actual hardware. We'll also need a bunch of functions to create arbitrary atomic states. Let's create some helpers to create a device that behaves like the real one, and some helpers to maintain the atomic state we want to check. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-17-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: hvs: Provide a function to initialize the HVS structureMaxime Ripard2022-12-082-30/+44
| | | | | | | | | | | We'll need to initialize the HVS structure without a backing device to create a mock we'll use for testing. Split the structure initialization part into a separate function. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-16-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: crtc: Make encoder lookup helper publicMaxime Ripard2022-12-082-16/+17
| | | | | | | | | | | We'll need a function that looks up an encoder by its vc4_encoder_type. Such a function is already present in the CRTC code, so let's make it public so that we can reuse it in the unit tests. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-15-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: crtc: Introduce a lower-level crtc init helperMaxime Ripard2022-12-082-19/+57
| | | | | | | | | | | | | | The current vc4_crtc_init() helper assumes that we will be using hardware planes and calls vc4_plane_init(). While it's a reasonable assumption, we'll want to mock the plane and thus provide our own. Let's create a helper that will take the plane as an argument. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-14-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: Move HVS state to main headerMaxime Ripard2022-12-082-22/+26
| | | | | | | | | | | | | In order to introduce unit tests for the HVS state computation, we'll need access to the vc4_hvs_state struct definition and its associated helpers. Let's move them in our driver header. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-13-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dpi: Fix format mapping for RGB565Dave Stevenson2022-12-011-1/+1
| | | | | | | | | | | The mapping is incorrect for RGB565_1X16 as it should be DPI_FORMAT_18BIT_666_RGB_1 instead of DPI_FORMAT_18BIT_666_RGB_3. Fixes: 08302c35b59d ("drm/vc4: Add DPI driver") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-7-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dpi: Change the default DPI format to being 18bpp, not 24.Dave Stevenson2022-12-011-2/+2
| | | | | | | | | | | | | | | | | DPI hasn't really been used up until now, so the default has been meaningless. In theory we should be able to pass the desired format for the adjacent bridge chip through, but framework seems to be missing for that. As the main device to use DPI is the VGA666 or Adafruit Kippah, both of which use RGB666, change the default to being RGB666 instead of RGB888. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-6-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dpi: Support BGR666 formatsJoerg Quinten2022-12-011-0/+6
| | | | | | | | | | The VC4 DPI output can support multiple BGR666 variants, but they were never added to the driver. Let's add the the support for those formats. Signed-off-by: Joerg Quinten <aBUGSworstnightmare@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-5-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dpi: Support RGB565 formatChris Morgan2022-12-011-0/+4
| | | | | | | | | | | | | The RGB565 format with padding over 24 bits (MEDIA_BUS_FMT_RGB565_1X24_CPADHI) is supported by the vc4 DPI controller. This is what the Geekworm MZP280 DPI display uses, so let's add support for it in the DPI controller driver. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-4-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: vec: Use pm_runtime_resume_and_get() in vc4_vec_encoder_enable()Shang XiaoJing2022-11-281-1/+1
| | | | | | | | | | | | | | Commit f0601ef8631c ("drm/vc4: vec: Protect device resources after removal") add fail path for vc4_vec_encoder_enable(), and will put usage_counter only when pm_runtime_get_sync() succeeds. However, pm_runtime_get_sync() will increment usage_counter even it failed. Fix it by replacing it with pm_runtime_resume_and_get() to keep usage counter balanced. Fixes: e4b81f8c74c8 ("drm/vc4: Add support for the VEC (Video Encoder) IP") Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Link: https://lore.kernel.org/r/20221124015113.18540-1-shangxiaojing@huawei.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: crtc: Provide a CRTC nameMaxime Ripard2022-11-283-1/+12
| | | | | | | | | | | | It's fairly hard to figure out the instance of the CRTC affected by an atomic change using the default name. Since we can provide our own to the CRTC initialization functions, let's do so to make the debugging sessions easier. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-20-051a0bb60a16@cerno.tech
* drm/vc4: crtc: Pass the device and data in vc4_crtc_initMaxime Ripard2022-11-283-13/+17
| | | | | | | | | | Both users of vc4_crtc_init need the same extra initialization to set the pointer to the platform_device and the CRTC data. Since it's mandatory, let's make them both arguments of vc4_crtc_init(). Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-17-051a0bb60a16@cerno.tech
* drm/vc4: txp: Initialise the CRTC before the encoder and connectorMaxime Ripard2022-11-281-5/+5
| | | | | | | | | It makes more sense to register the CRTC before the encoder and connectors, so let's move our call around. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-16-051a0bb60a16@cerno.tech
* drm/vc4: Add TXP encoder typeMaxime Ripard2022-11-282-10/+21
| | | | | | | | | | | | The TXP is integrated as a separate CRTC/Encoder/Connector combo, but for some reason doesn't rely on the vc4_encoder type and it's associated type. Let's create a type to make it consistent with the other encoders. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-15-051a0bb60a16@cerno.tech
* drm/vc4: txp: Reorder the variable assignmentsMaxime Ripard2022-11-281-9/+6
| | | | | | | | | The current order of variable assignments is unneccessarily complex, let's make it simpler. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-14-051a0bb60a16@cerno.tech
* drm/vc4: kms: Sort the CRTCs by output before assigning themMaxime Ripard2022-11-281-33/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the vc4 devices (and later), the blending is done by a single device called the HVS. The HVS has three FIFO that can operate in parallel, and route their output to 6 CRTCs and 7 encoders on the BCM2711. Each of these CRTCs and encoders have some constraints on which FIFO they can feed from, so we need some code to take all those constraints into account and assign FIFOs to CRTCs. The problem can be simplified by assigning those FIFOs to CRTCs by ascending output index number. We had a comment mentioning it already, but we were never actually enforcing it. It was working still in most situations because the probe order is roughly equivalent, except for the (optional, and fairly rarely used on the Pi4) VEC which was last in the probe order sequence, but one of the earliest device to assign. This resulted in configurations that were rejected by our code but were still valid with a different assignment. We can fix this by making sure we assign CRTCs to FIFOs by ordering them by ascending HVS output index. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-10-051a0bb60a16@cerno.tech
* drm/vc4: kms: Constify the HVS old/new state helpersMaxime Ripard2022-11-281-2/+2
| | | | | | | | | The vc4_hvs_get_(old|new)_global_state functions don't modify the drm_atomic_state passed as an argument, so let's make it const. Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v1-13-051a0bb60a16@cerno.tech Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: Constify container_of wrappersMaxime Ripard2022-11-281-8/+8
| | | | | | | | | | | None of our wrappers around container_of to access our objects from the DRM object pointer actually modify the latter. Let's make them const. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-11-051a0bb60a16@cerno.tech
* drm/vc4: vec: Add support for more analog TV standardsMateusz Kwiatkowski2022-11-241-4/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the following composite output modes (all of them are somewhat more obscure than the previously defined ones): - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to 4.43361875 MHz (the PAL subcarrier frequency). Never used for broadcasting, but sometimes used as a hack to play NTSC content in PAL regions (e.g. on VCRs). - PAL_N - PAL with alternative chroma subcarrier frequency, 3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay and Uruguay to fit 576i50 with colour in 6 MHz channel raster. - PAL60 - 480i60 signal with PAL-style color at normal European PAL frequency. Another non-standard, non-broadcast mode, used in similar contexts as NTSC_443. Some displays support one but not the other. - SECAM - French frequency-modulated analog color standard; also have been broadcast in Eastern Europe and various parts of Africa and Asia. Uses the same 576i50 timings as PAL. Also added some comments explaining color subcarrier frequency registers. Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-18-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: vec: Convert to the new TV mode propertyMaxime Ripard2022-11-241-53/+131
| | | | | | | | | | | | | | | | Now that the core can deal fine with analog TV modes, let's convert the vc4 VEC driver to leverage those new features. We've added some backward compatibility to support the old TV mode property and translate it into the new TV norm property. We're also making use of the new analog TV atomic_check helper to make sure we trigger a modeset whenever the TV mode is updated. Acked-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-17-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: vec: Check for VEC output constraintsMateusz Kwiatkowski2022-11-241-0/+50
| | | | | | | | | | | | | | | The VEC can accept pretty much any relatively reasonable mode, but still has a bunch of constraints to meet. Let's create an atomic_check() implementation that will make sure we don't end up accepting a non-functional mode. Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-16-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: vec: Use TV Reset implementationMaxime Ripard2022-11-241-1/+7
| | | | | | | | | | | | The analog TV properties created by the drm_mode_create_tv_properties() are not properly initialised at reset. Let's switch our implementation to call drm_atomic_helper_connector_tv_reset(). Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-15-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/connector: Rename drm_mode_create_tv_propertiesMaxime Ripard2022-11-241-2/+3
| | | | | | | | | | | | | | | | | drm_mode_create_tv_properties(), among other things, will create the "mode" property that stores the analog TV mode that connector is supposed to output. However, that property is getting deprecated, so let's rename that function to mention it's deprecated. We'll introduce a new variant of that function creating the property superseeding it in a later patch. Reviewed-by: Lyude Paul <lyude@redhat.com> # nouveau Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-4-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/connector: Rename legacy TV propertyMaxime Ripard2022-11-241-4/+4
| | | | | | | | | | | | | | | | | The current tv_mode has driver-specific values that don't allow to easily share code using it, either at the userspace or kernel level. Since we're going to introduce a new, generic, property that fit the same purpose, let's rename this one to legacy_tv_mode to make it obvious we should move away from it. Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Lyude Paul <lyude@redhat.com> # nouveau Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-2-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* Backmerge tag 'v6.1-rc6' into drm-nextDave Airlie2022-11-244-16/+47
|\ | | | | | | | | | | | | | | Linux 6.1-rc6 This is needed for drm-misc-next and tegra. Signed-off-by: Dave Airlie <airlied@redhat.com>
| * drm/vc4: kms: Fix IS_ERR() vs NULL check for vc4_kmsGaosheng Cui2022-11-101-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The drm_atomic_get_new_private_obj_state() function returns NULL on error path, drm_atomic_get_old_private_obj_state() function returns NULL on error path, too, they does not return error pointers. By the way, vc4_hvs_get_new/old_global_state() should return ERR_PTR(-EINVAL), otherwise there will be null-ptr-defer issue, such as follows: In function vc4_atomic_commit_tail(): |-- old_hvs_state = vc4_hvs_get_old_global_state(state); <-- return NULL |-- if (WARN_ON(IS_ERR(old_hvs_state))) <-- no return |-- unsigned long state_rate = max(old_hvs_state->core_clock_rate, new_hvs_state->core_clock_rate); <-- null-ptr-defer Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221110094445.2930509-6-cuigaosheng1@huawei.com
| * drm/vc4: Fix missing platform_unregister_drivers() call in vc4_drm_register()Yuan Can2022-11-071-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A problem about modprobe vc4 failed is triggered with the following log given: [ 420.327987] Error: Driver 'vc4_hvs' is already registered, aborting... [ 420.333904] failed to register platform driver vc4_hvs_driver [vc4]: -16 modprobe: ERROR: could not insert 'vc4': Device or resource busy The reason is that vc4_drm_register() returns platform_driver_register() directly without checking its return value, if platform_driver_register() fails, it returns without unregistering all the vc4 drivers, resulting the vc4 can never be installed later. A simple call graph is shown as below: vc4_drm_register() platform_register_drivers() # all vc4 drivers are registered platform_driver_register() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without unregister drivers Fixing this problem by checking the return value of platform_driver_register() and do platform_unregister_drivers() if error happened. Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.") Signed-off-by: Yuan Can <yuancan@huawei.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221103014705.109322-1-yuancan@huawei.com
| * drm/vc4: hdmi: Fix HSM clock too low on Pi4maxime@cerno.tech2022-11-032-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at runtime_resume") reintroduced the call to clk_set_min_rate in an attempt to fix the boot without a monitor connected on the RaspberryPi3. However, that introduced a regression breaking the display output entirely (black screen but no vblank timeout) on the Pi4. This is due to the fact that we now have in a typical modeset at boot, in vc4_hdmi_encoder_pre_crtc_configure(), we have a first call to clk_set_min_rate() asking for the minimum rate of the HSM clock for our given resolution, and then a call to pm_runtime_resume_and_get(). We will thus execute vc4_hdmi_runtime_resume() which, since the commit mentioned above, will call clk_set_min_rate() a second time with the absolute minimum rate we want to enforce on the HSM clock. We're thus effectively erasing the minimum mandated by the mode we're trying to set. The fact that only the Pi4 is affected is due to the fact that it uses a different clock driver that tries to minimize the HSM clock at all time. It will thus lower the HSM clock rate to 120MHz on the second clk_set_min_rate() call. The Pi3 doesn't use the same driver and will not change the frequency on the second clk_set_min_rate() call since it's still within the new boundaries and it doesn't have the code to minimize the clock rate as needed. So even though the boundaries are still off, the clock rate is still the right one for our given mode, so everything works. There is a lot of moving parts, so I couldn't find any obvious solution: - Reverting the original is not an option, as that would break the Pi3 again. - We can't move the clk_set_min_rate() call in _pre_crtc_configure() since because, on the Pi3, the HSM clock has the CLK_SET_RATE_GATE flag which prevents the clock rate from being changed after it's been enabled. Our calls to clk_set_min_rate() can change it, so they need to be done before clk_prepare_enable(). - We can't remove the call to clk_prepare_enable() from the runtime_resume hook to put it into _pre_crtc_configure() either, since we need that clock to be enabled to access the registers, and we can't count on the fact that the display will be active in all situations (doing any CEC operation, or listing the modes while inactive are valid for example()). - We can't drop the call to clk_set_min_rate() in _pre_crtc_configure() since we would need to still enforce the minimum rate for a given resolution, and runtime_resume doesn't have access to the current mode, if there's any. - We can't copy the TMDS character rate into vc4_hdmi and reuse it since, because it's part of the KMS atomic state, it needs to be protected by a mutex. Unfortunately, some functions (CEC operations, mostly) can be reentrant (through the CEC framework) and still need a pm_runtime_get. However, we can work around this issue by leveraging the fact that the clk_set_min_rate() calls set boundaries for its given struct clk, and that each different clk_get() call will return a different instance of struct clk. The clock framework will then aggregate the boundaries for each struct clk instances linked to a given clock, plus its hardware boundaries, and will use that. We can thus get an extra HSM clock user for runtime_pm use only, and use our different clock instances depending on the context: runtime_pm will use its own to set the absolute minimum clock setup so that we never lock the CPU waiting for a register access, and the modeset part will set its requirement for the current resolution. And we let the CCF do the coordination. It's not an ideal solution, but it's fairly unintrusive and doesn't really change any part of the logic so it looks like a rather safe fix. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2136234 Fixes: ae71ab585c81 ("drm/vc4: hdmi: Enforce the minimum rate at runtime_resume") Reported-by: Peter Robinson <pbrobinson@gmail.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Link: https://lore.kernel.org/r/20221021131339.2203291-1-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
| * drm/vc4: hdmi: Fix outdated function name in commentmaxime@cerno.tech2022-11-031-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | A comment introduced by commit 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") mentions a drm_atomic_helper_connector_hdmi_reset_link() function that was part of the earlier versions but got moved internally and is now named vc4_hdmi_reset_link(). Let's fix the function name. Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221024093634.118190-2-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
| * drm/vc4: hdmi: Take our lock to reset the linkmaxime@cerno.tech2022-11-031-4/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We access some fields protected by our internal mutex in vc4_hdmi_reset_link() (saved_adjusted_mode, output_bpc, output_format) and are calling functions that need to have that lock taken (vc4_hdmi_supports_scrambling()). However, the current code doesn't lock that mutex. Let's make sure it does. Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221024093634.118190-1-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
| * Merge drm/drm-fixes into drm-misc-fixesThomas Zimmermann2022-10-2022-853/+1513
| |\ | | | | | | | | | | | | | | | Backmerging to get v6.1-rc1. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
* | | drm/vc4: hdmi: Fix pointer dereference before checkJosé Expósito2022-11-151-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") introduced the vc4_hdmi_reset_link() function. This function dereferences the "connector" pointer before checking whether it is NULL or not. Rework variable assignment to avoid this issue. Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20221110134752.238820-3-jose.exposito89@gmail.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* | | drm/vc4: hdmi: Pass vc4_hdmi to vc4_hdmi_supports_scrambling()José Expósito2022-11-151-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Simplify vc4_hdmi_supports_scrambling() by changing its first parameter from struct drm_encoder to struct vc4_hdmi. Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://lore.kernel.org/r/20221110134752.238820-2-jose.exposito89@gmail.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* | | drm/fb-helper: Move generic fbdev emulation into separate source fileThomas Zimmermann2022-11-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | Merge tag 'drm-misc-next-2022-11-03' of ↵Dave Airlie2022-11-045-25/+63
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 6.2: UAPI Changes: Cross-subsystem Changes: - dma-buf: locking improvements - firmware: New API in the RaspberryPi firmware driver used by vc4 Core Changes: - client: Null pointer dereference fix in drm_client_buffer_delete() - mm/buddy: Add back random seed log - ttm: Convert ttm_resource to use size_t for its size, fix for an undefined behaviour Driver Changes: - bridge: - adv7511: use dev_err_probe - it6505: Fix return value check of pm_runtime_get_sync - panel: - sitronix: Fixes and clean-ups - lcdif: Increase DMA burst size - rockchip: runtime_pm improvements - vc4: Fix for a regression preventing the use of 4k @ 60Hz, and further HDMI rate constraints check. - vmwgfx: Cursor improvements Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221103083437.ksrh3hcdvxaof62l@houat
| * | | drm/vc4: Make sure we don't end up with a core clock too highMaxime Ripard2022-10-281-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Following the clock rate range improvements to the clock framework, trying to set a disjoint range on a clock will now result in an error. Thus, we can't set a minimum rate higher than the maximum reported by the firmware, or clk_set_min_rate() will fail. Thus we need to clamp the rate we are about to ask for to the maximum rate possible on that clock. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220815-rpi-fix-4k-60-v5-7-fe9e7ac8b111@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
| * | | drm/vc4: hdmi: Add more checks for 4k resolutionsDom Cobley2022-10-283-2/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At least the 4096x2160@60Hz mode requires some overclocking that isn't available by default, even if hdmi_enable_4kp60 is enabled. Let's add some logic to detect whether we can satisfy the core clock requirements for that mode, and prevent it from being used otherwise. Signed-off-by: Dom Cobley <popcornmix@gmail.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220815-rpi-fix-4k-60-v5-6-fe9e7ac8b111@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
| * | | drm/vc4: hdmi: Rework hdmi_enable_4kp60 detection codeMaxime Ripard2022-10-284-19/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to support higher HDMI frequencies, users have to set the hdmi_enable_4kp60 parameter in their config.txt file. This will have the side-effect of raising the maximum of the core clock, tied to the HVS, and managed by the HVS driver. However, we are querying this in the HDMI driver by poking into the HVS structure to get our struct clk handle. Let's make this part of the HVS bind implementation to have all the core clock related setup in the same place. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220815-rpi-fix-4k-60-v5-5-fe9e7ac8b111@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
| * | | drm/vc4: hdmi: Fix hdmi_enable_4kp60 detectionMaxime Ripard2022-10-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In order to support higher HDMI frequencies, users have to set the hdmi_enable_4kp60 parameter in their config.txt file. We were detecting this so far by calling clk_round_rate() on the core clock with the frequency we're supposed to run at when one of those modes is enabled. Whether or not the parameter was enabled could then be inferred by the returned rate since the maximum clock rate reported by the firmware was one of the side effect of setting that parameter. However, the recent clock rework we did changed what clk_round_rate() was returning to always return the minimum allowed, and thus this test wasn't reliable anymore. Let's use the new clk_get_max_rate() function to reliably determine the maximum rate allowed on that clock and fix the 4k@60Hz output. Fixes: e9d6cea2af1c ("clk: bcm: rpi: Run some clocks at the minimum rate allowed") Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220815-rpi-fix-4k-60-v5-4-fe9e7ac8b111@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* | | | Merge tag 'drm-misc-next-2022-10-27' of ↵Dave Airlie2022-10-281-2/+2
|\| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm/drm-misc into drm-next drm-misc-next for 6.2: UAPI Changes: Cross-subsystem Changes: Core Changes: - connector: Send hotplug event on cleanup - edid: logging/debug improvements - plane_helper: Improve tests Driver Changes: - bridge: - it6505: Synchronization improvements - panel: - panel-edp: Add INX N116BGE-EA2 C2 and C4 support. - nouveau: Fix page-fault handling - vmwgfx: fb and cursor refactoring, convert to generic hashtable Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221027073407.c2tlaczvzjrnzazi@houat
| * | | drm/vc4: Fix spelling mistake "mmaping" -> "mmapping"Colin Ian King2022-10-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are a couple of spelling mistakes in DRM_DEBUG messages. Fix them. Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221021084035.65367-1-colin.i.king@gmail.com
generated by cgit (git 2.34.1) at 2025-02-24 00:38:50 +0000