aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/vc4
AgeCommit message (Collapse)AuthorFilesLines
2023-01-10drm/vc4: dsi: Drop unused i2c includeUwe Kleine-König1-1/+0
The driver doesn't make use of any symbol provided by <linux/i2c.h>. So drop the include. Signed-off-by: Uwe Kleine-König <[email protected]> Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Javier Martinez Canillas <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2023-01-09drm/vc4: vec: Support progressive modesMateusz Kwiatkowski1-1/+3
The VEC is able to output progressive analog modes, but the driver has never set the proper bit to do so. Signed-off-by: Mateusz Kwiatkowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hdmi: Correct interlaced timings againDave Stevenson1-2/+3
The back porch timings were correct, only the sync offset was wrong. Correct timing is now reported for 1080i and 576i, but the h offset is incorrect for 480i for non-obvious reasons. Fixes: fb10dc451c0f ("drm/vc4: hdmi: Correct HDMI timing registers for interlaced modes") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: crtc: Fix timings for VEC modesMateusz Kwiatkowski1-27/+44
This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards. Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals being generated, respectively. Changes to vc4_crtc.c have also been made, to make the PixelValve vertical timings accurately correspond to the DRM modeline in interlaced modes. The resulting VERTA/VERTB register values have been verified against the reference values set by the Raspberry Pi firmware. Signed-off-by: Mateusz Kwiatkowski <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: Add comments for which HVS_PIXEL_ORDER_xxx defines applyDave Stevenson1-0/+3
The HVS_PIXEL_ORDER_xxx defines apply to specific HVS_PIXEL_FORMAT_xxx modes, so add comments to make this obvious. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: plane: Add 3:3:2 and 4:4:4:4 RGB/RGBX/RGBA formatsDave Stevenson1-0/+70
The hardware supports the 332 8bpp and 4:4:4:4 16bpp formats, but the table of supported formats didn't include them. Add them in. In theory they are supported for T-format as well as linear, but without a way to test them just add them as linear for now. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: plane: Omit pixel_order from the hvs_format for hvs5 only formatsDave Stevenson1-5/+0
pixel_order is used for the earlier versions of the HVS, so is redundant on the 10:10:10:2 and 10bit YUV formats that are only supported on HVS5. Remove the assignment from the table to avoid confusion. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: plane: Allow using 0 as a pixel order valueDave Stevenson1-6/+14
vc4_plane_mode_set for HVS5 was using pixel_order unless pixel_order_hvs5 was non-zero, except 0 is a valid value for the pixel_order. Specify pixel_order_hvs5 for all formats and remove the conditional. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: Ignore atomic_flush if we're disabledMaxime Ripard1-0/+3
atomic_flush will be called for each CRTC even if they aren't enabled. The whole code we have there will thus run without a properly affected channel, which can then result in all sorts of weird behaviour. Reviewed-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: Add DRM 210101010 RGB formatsDave Stevenson1-0/+28
HVS5 supports the 210101010 RGB[A|X] formats, but they were missing from the DRM to HVS mapping list, so weren't available. Add them in. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: Fix colour order for xRGB1555 on HVS5Dave Stevenson1-0/+2
Same as the xRGB8888 formats, HVS5 has managed to swap the colour channels for the xRGB1555 formats as well. Add the relevant config for pixel_order_hvs5. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: Support zpos on all planesDave Stevenson3-18/+48
Adds the zpos property to all planes, and creates the dlist by placing the fragments in the correct order based on zpos. Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: Correct interrupt masking bit assignment for HVS5Dave Stevenson2-18/+44
HVS5 has moved the interrupt enable bits around within the DISPCTRL register, therefore the configuration has to be updated to account for this. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: SCALER_DISPBKGND_AUTOHS is only valid on HVS4Dave Stevenson2-4/+7
The bit used for SCALER_DISPBKGND_AUTOHS in SCALER_DISPBKGNDX has been repurposed on HVS5 to configure whether a display can win back-to-back arbitration wins for the COB. This is not desirable, therefore only select this bit on HVS4, and explicitly clear it on HVS5. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: Set AXI panic modesDave Stevenson2-0/+17
The HVS can change AXI request mode based on how full the COB FIFOs are. Until now the vc4 driver has been relying on the firmware to have set these to sensible values. With HVS channel 2 now being used for live video, change the panic mode for all channels to be explicitly set by the driver, and the same for all channels. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-09drm/vc4: hvs: Configure the HVS COB allocationsDave Stevenson1-1/+55
The HVS Composite Output Buffer (COB) is the memory used to generate the output pixel data. Until now the vc4 driver has been relying on the firmware to have set these to sensible values. In testing triple screen support it has been noted that only 1 line was being assigned to HVS channel 2. Whilst that is fine for the transposer (TXP), and indeed needed as only some pixels have an alpha channel, it is insufficient to run a live display. Split the COB more evenly between the 3 HVS channels. Fixes: c54619b0bfb3 ("drm/vc4: Add support for the BCM2711 HVS5") Signed-off-by: Dave Stevenson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2023-01-02drm/vc4: drop all currently held locks if deadlock happensMaíra Canal1-1/+10
If vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock happened in the locking context. This situation should be addressed by dropping all currently held locks and block until the contended lock becomes available. Currently, vc4 is not dealing with the deadlock properly, producing the following output when PROVE_LOCKING is enabled: [ 825.612809] ------------[ cut here ]------------ [ 825.612852] WARNING: CPU: 1 PID: 116 at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x60/0x68 [drm] [ 825.613458] Modules linked in: 8021q mrp garp stp llc raspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211 btqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec clk_raspberrypi ecdh_generic drm_display_helper ecc rfkill drm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng rng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6 [ 825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: G W 6.1.0-rc6-01399-g941aae326315 #3 [ 825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT) [ 825.613777] Workqueue: events output_poll_execute [drm_kms_helper] [ 825.614038] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm] [ 825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper] [ 825.614829] sp : ffff800008313bf0 [ 825.614844] x29: ffff800008313bf0 x28: ffffcd7778b8b000 x27: 0000000000000000 [ 825.614883] x26: 0000000000000001 x25: 0000000000000001 x24: ffff677cc35c2758 [ 825.614920] x23: ffffcd7707d01430 x22: ffffcd7707c3edc7 x21: 0000000000000001 [ 825.614958] x20: 0000000000000000 x19: ffff800008313c10 x18: 000000000000b6d3 [ 825.614995] x17: ffffcd777835e214 x16: ffffcd7777cef870 x15: fffff81000000000 [ 825.615033] x14: 0000000000000000 x13: 0000000000000099 x12: 0000000000000002 [ 825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 72917988020af800 [ 825.615108] x8 : ffff677cc665e0a8 x7 : d00a8c180000110c x6 : ffffcd77774c0054 [ 825.615145] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 [ 825.615181] x2 : ffff677cc55e1880 x1 : ffffcd7777cef8ec x0 : ffff800008313c10 [ 825.615219] Call trace: [ 825.615232] drm_modeset_drop_locks+0x60/0x68 [drm] [ 825.615773] drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper] [ 825.616003] output_poll_execute+0xe4/0x224 [drm_kms_helper] [ 825.616233] process_one_work+0x2b4/0x618 [ 825.616264] worker_thread+0x24c/0x464 [ 825.616288] kthread+0xec/0x110 [ 825.616310] ret_from_fork+0x10/0x20 [ 825.616335] irq event stamp: 7634 [ 825.616349] hardirqs last enabled at (7633): [<ffffcd777831ee90>] _raw_spin_unlock_irq+0x3c/0x78 [ 825.616384] hardirqs last disabled at (7634): [<ffffcd7778315a78>] __schedule+0x134/0x9f0 [ 825.616411] softirqs last enabled at (7630): [<ffffcd7707aacea0>] local_bh_enable+0x4/0x30 [ipv6] [ 825.617019] softirqs last disabled at (7618): [<ffffcd7707aace70>] local_bh_disable+0x4/0x30 [ipv6] [ 825.617586] ---[ end trace 0000000000000000 ]--- Therefore, deal with the deadlock as suggested by [1], using the function drm_modeset_backoff(). [1] https://docs.kernel.org/gpu/drm-kms.html?highlight=kms#kms-locking Fixes: 6bed2ea3cb38 ("drm/vc4: hdmi: Reset link on hotplug") Reported-by: Stefan Wahren <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Tested-by: Stefan Wahren <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-12-22drm/vc4: use new debugfs device-centered functionsMaíra Canal11-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/[email protected]/ Signed-off-by: Maíra Canal <[email protected]> Reviewed-by: Maxime Ripard <[email protected]> Reviewed-by: Melissa Wen <[email protected]> Acked-by: Daniel Vetter <[email protected]> Signed-off-by: Maíra Canal <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-12-15drm/vc4: dsi: Remove entry to ULPS from vc4_dsi post_disableDave Stevenson1-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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-15drm/vc4: dsi: Convert to using a bridge instead of encoderDave Stevenson1-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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-15drm/vc4: dsi: Convert to use atomic operationsDave Stevenson1-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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-15drm/vc4: dsi: Remove splitting the bridge chain from the driverDave Stevenson1-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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-15drm/vc4: dsi: Move initialisation to encoder_mode_setDave Stevenson1-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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-15drm/vc4: dsi: Rename bridge to out_bridgeDave Stevenson1-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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-08drm/vc4: tests: Add unit test suite for the PV muxingMaxime Ripard4-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 <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-08drm/vc4: tests: Fail the current test if we access a registerMaxime Ripard7-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 <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-08drm/vc4: tests: Introduce a mocking infrastructureMaxime Ripard12-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 <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-08drm/vc4: hvs: Provide a function to initialize the HVS structureMaxime Ripard2-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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-08drm/vc4: crtc: Make encoder lookup helper publicMaxime Ripard2-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 <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-08drm/vc4: crtc: Introduce a lower-level crtc init helperMaxime Ripard2-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 <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-08drm/vc4: Move HVS state to main headerMaxime Ripard2-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 <[email protected]> Reviewed-by: Maíra Canal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-01drm/vc4: dpi: Fix format mapping for RGB565Dave Stevenson1-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 <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-01drm/vc4: dpi: Change the default DPI format to being 18bpp, not 24.Dave Stevenson1-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 <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-01drm/vc4: dpi: Support BGR666 formatsJoerg Quinten1-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 <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-12-01drm/vc4: dpi: Support RGB565 formatChris Morgan1-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 <[email protected]> Signed-off-by: Chris Morgan <[email protected]> Reviewed-by: Laurent Pinchart <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-11-28drm/vc4: vec: Use pm_runtime_resume_and_get() in vc4_vec_encoder_enable()Shang XiaoJing1-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 <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-11-28drm/vc4: crtc: Provide a CRTC nameMaxime Ripard3-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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-28drm/vc4: crtc: Pass the device and data in vc4_crtc_initMaxime Ripard3-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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-28drm/vc4: txp: Initialise the CRTC before the encoder and connectorMaxime Ripard1-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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-28drm/vc4: Add TXP encoder typeMaxime Ripard2-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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-28drm/vc4: txp: Reorder the variable assignmentsMaxime Ripard1-9/+6
The current order of variable assignments is unneccessarily complex, let's make it simpler. Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-28drm/vc4: kms: Sort the CRTCs by output before assigning themMaxime Ripard1-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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-28drm/vc4: kms: Constify the HVS old/new state helpersMaxime Ripard1-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/[email protected] Reviewed-by: Javier Martinez Canillas <[email protected]> Signed-off-by: Maxime Ripard <[email protected]>
2022-11-28drm/vc4: Constify container_of wrappersMaxime Ripard1-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 <[email protected]> Signed-off-by: Maxime Ripard <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2022-11-24drm/vc4: vec: Add support for more analog TV standardsMateusz Kwiatkowski1-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 <[email protected]> Signed-off-by: Mateusz Kwiatkowski <[email protected]> Tested-by: Mateusz Kwiatkowski <[email protected]> Acked-in-principle-or-something-like-that-by: Daniel Vetter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-11-24drm/vc4: vec: Convert to the new TV mode propertyMaxime Ripard1-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 <[email protected]> Tested-by: Mateusz Kwiatkowski <[email protected]> Acked-in-principle-or-something-like-that-by: Daniel Vetter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-11-24drm/vc4: vec: Check for VEC output constraintsMateusz Kwiatkowski1-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 <[email protected]> Signed-off-by: Mateusz Kwiatkowski <[email protected]> Tested-by: Mateusz Kwiatkowski <[email protected]> Acked-in-principle-or-something-like-that-by: Daniel Vetter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-11-24drm/vc4: vec: Use TV Reset implementationMaxime Ripard1-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 <[email protected]> Tested-by: Mateusz Kwiatkowski <[email protected]> Acked-in-principle-or-something-like-that-by: Daniel Vetter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-11-24drm/connector: Rename drm_mode_create_tv_propertiesMaxime Ripard1-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 <[email protected]> # nouveau Reviewed-by: Noralf Trønnes <[email protected]> Tested-by: Mateusz Kwiatkowski <[email protected]> Acked-in-principle-or-something-like-that-by: Daniel Vetter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
2022-11-24drm/connector: Rename legacy TV propertyMaxime Ripard1-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 <[email protected]> Reviewed-by: Lyude Paul <[email protected]> # nouveau Reviewed-by: Noralf Trønnes <[email protected]> Tested-by: Mateusz Kwiatkowski <[email protected]> Acked-in-principle-or-something-like-that-by: Daniel Vetter <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Maxime Ripard <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.