aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf/scripts/python/export-to-postgresql.py (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2022-06-28drm/vc4: hdmi: Move pixel doubling from Pixelvalve to HDMI blockDave Stevenson2-7/+31
With the change to 2 pixels/clock, the pixel doubling in the PV results in doubling each pair of pixels, ie ABABCDCD instead of AABBCCDD. Move the pixel doubling to the HDMI block, however this means that DBLCLK modes now fall foul of requiring even values for all the horizontal timing parameters. As both 480i and 576i fail this, attempt to fix up DBLCLK modes that have odd timings values. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-34-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Correct HDMI timing registers for interlaced modesDave Stevenson1-4/+4
For interlaced modes the timings were not being correctly programmed into the HDMI block, so correct them. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-33-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Force modeset when bpc or format changesDom Cobley1-1/+11
Whenever the maximum BPC is changed, vc4_hdmi_encoder_compute_config() might pick up a different BPC or format depending on the display capabilities. That change will have a number of side effects, including the clock rates and whether the scrambling is enabled. However, only drm_crtc_state.connectors_changed will be set to true, since that properly only affects the connector. This means that while drm_atomic_crtc_needs_modeset() will return true, and thus drm_atomic_helper_commit_modeset_enables() will call our encoder atomic_enable() hook, mode_changed will be false. So crtc_set_mode() will not call our encoder .atomic_mode_set() hook. We use this hook in vc4 to set the vc4_hdmi_connector_state.output_bpc (and output_format), and will then reuse the value in .atomic_enable() to select whether or not scrambling should be enabled. However, since our clock rate is pre-computed during .atomic_check(), we end up with the clocks properly configured, but the scrambling disabled, leading to a blank screen. Let's set mode_changed to true in our HDMI driver to force the update of output_bpc, and thus prevent the issue entirely. Fixes: ba8c0faebbb0 ("drm/vc4: hdmi: Enable 10/12 bpc output") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-32-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Fix timings for interlaced modesMateusz Kwiatkowski2-9/+10
Increase the number of post-sync blanking lines on odd fields instead of decreasing it on even fields. This makes the total number of lines properly match the modelines. Additionally fix the value of PV_VCONTROL_ODD_DELAY, which did not take pixels_per_clock into account, causing some displays to invert the fields when driven by bcm2711. Fixes: 682e62c45406 ("drm/vc4: Fix support for interlaced modes on HDMI.") Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-31-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Report that 3d/stereo is allowedDom Cobley1-0/+1
Our HDMI controllers supports Stereo output so let's enable it. Signed-off-by: Dom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-30-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Add MISC_CONTROL register for vc4Dave Stevenson1-0/+1
The MISC_CONTROL register allows configuration of pixel repetition for pixel doubling in the HDMI block instead of PixelValve. It was already defined for vc5, so add it for vc4. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-29-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Add HDMI format detection registers to register listDave Stevenson1-0/+30
The block can detect what the incoming image timings are for debug purposes. Add them to the list of registers understood by the driver to allow easy dumping of the values. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-28-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Remove VC4_HDMI_SCHEDULER_CONTROL_VERT_ALWAYS_KEEPOUTDom Cobley1-3/+0
This bit ensures data island packets are never generated when disallowed by HDCP. As no Pi boards support HDCP this is providing an unnecessary restriction Signed-off-by: Dom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-27-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Skip writes to disabled packet RAMDom Cobley2-1/+12
This path actually occurs when audio is started during a hdmi mode set. As the data will be written by vc4_hdmi_set_infoframes when packet RAM is enabled again, don't treat as an error Signed-off-by: Dom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-26-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Stop checking for enabled output in audioDom Cobley2-33/+3
The current HDMI driver, in vc4_hdmi_audio_can_stream() checks whether the display output is enabled. This has been there in one form or the other since the introduction of the audio support in the VC4 HDMI driver in commit bb7d78568814 ("drm/vc4: Add HDMI audio support"), but no justification for this check is in the commit message, or in the discussions around the patches. One can only assume this was done to prevent a user from playing audio on the ALSA soundcard when the monitor doesn't support it. However, this is causing some issues. Indeed, Kodi, for example, was hitting some errors if it was streaming audio during a modeset. With the theory above, it does make sense, but the display and audio threads are typically completely different processes with no opportunity to synchronise which makes it hard to workaround. Removing that check also doesn't seem to cause any trouble, so let's just remove it. Signed-off-by: Dom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-25-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Move HDMI reset to pm_resumeDave Stevenson1-19/+22
The BCM2835-37 found in the RaspberryPi 0 to 3 have a power domain attached to the HDMI block, handled in Linux through runtime_pm. That power domain is shared with the VEC block, so even if we put our runtime_pm reference in the HDMI driver it would keep being on. If the VEC is disabled though, the power domain would be disabled and we would lose any initialization done in our bind implementation. That initialization involves calling the reset function and initializing the CEC registers. Let's move the initialization to our runtime_resume implementation so that we initialize everything properly if we ever need to. Fixes: c86b41214362 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-24-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Switch to pm_runtime_status_suspendedDave Stevenson1-2/+2
If the controller isn't clocked or its domain powered up, the register accesses will either stall the CPU or return garbage, respectively. Thus, we had a warning in our register access function to complain when that kind of risky accesses were performed. In order to check the runtime_pm power state, we were using pm_runtime_active(), but it turns out that it will become active only once the runtime_resume hook has been executed. This prevents us from doing any WARN-free register access in our runtime_resume() implementation, while this is valid. Let's switch to pm_runtime_status_suspended() instead. Fixes: 14e193b95604 ("drm/vc4: hdmi: Warn if we access the controller while disabled") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-23-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Reset HDMI MISC_CONTROL registerDave Stevenson2-0/+11
The HDMI block can repeat pixels for double clocked modes, and the firmware is now configuring the block to do this as the PV is doing it incorrectly when at 2pixels/clock. If the kernel doesn't reset it then we end up with strange modes. Reset MISC_CONTROL. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-22-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Avoid full hdmi audio fifo writesDom Cobley1-4/+4
We are getting occasional VC4_HD_MAI_CTL_ERRORF in HDMI_MAI_CTL which seem to correspond with audio dropouts. Reduce the threshold where we deassert DREQ to avoid the fifo overfilling Fixes: bb7d78568814 ("drm/vc4: Add HDMI audio support") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-21-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Clear unused infoframe packet RAM registersDom Cobley1-1/+10
Using a hdmi analyser the bytes in packet ram registers beyond the length were visible in the infoframes and it flagged the checksum as invalid. Zeroing unused words of packet RAM avoids this Fixes: 21317b3fba54 ("drm/vc4: Set up the AVI and SPD infoframes.") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-20-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Add all the vc5 HDMI registers into the debugfs dumpsDave Stevenson2-0/+47
The vc5 HDMI registers hadn't been added into the debugfs register sets, therefore weren't dumped on request. Add them in. Fixes: 8323989140f3 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-19-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hdmi: Disable audio if dmas property is present but emptyPhil Elwell1-3/+3
The dmas property is used to hold the dmaengine channel used for audio output. Older device trees were missing that property, so if it's not there we disable the audio output entirely. However, some overlays have set an empty value to that property, mostly to workaround the fact that overlays cannot remove a property. Let's add a test for that case and if it's empty, let's disable it as well. Cc: <stable@vger.kernel.org> Signed-off-by: Phil Elwell <phil@raspberrypi.org> Link: https://lore.kernel.org/r/20220613144800.326124-18-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dsi: Add correct stop condition to vc4_dsi_encoder_disable iterationDave Stevenson1-0/+3
vc4_dsi_encoder_disable is partially an open coded version of drm_bridge_chain_disable, but it missed a termination condition in the loop for ->disable which meant that no post_disable calls were made. Add in the termination clause. Fixes: 033bfe7538a1 ("drm/vc4: dsi: Fix bridge chain handling") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-17-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dsi: Fix dsi0 interrupt supportDave Stevenson1-26/+85
DSI0 seemingly had very little or no testing as a load of the register mappings were incorrect/missing, so host transfers always timed out due to enabling/checking incorrect bits in the interrupt enable and status registers. Fixes: 4078f5757144 ("drm/vc4: Add DSI driver") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-16-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dsi: Register dsi0 as the correct vc4 encoder typeDave Stevenson1-1/+2
vc4_dsi was registering both dsi0 and dsi1 as VC4_ENCODER_TYPE_DSI1 which seemed to work OK for a single DSI display, but fails if there are two DSI displays connected. Update to register the correct type. Fixes: 4078f5757144 ("drm/vc4: Add DSI driver") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-15-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dsi: Correct pixel order for DSI0Dave Stevenson1-1/+2
For slightly unknown reasons, dsi0 takes a different pixel format to dsi1, and that has to be set in the pixel valve. Amend the setup accordingly. Fixes: a86773d120d7 ("drm/vc4: Add support for feeding DSI encoders from the pixel valve.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-14-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dsi: Correct DSI divider calculationsDave Stevenson1-4/+2
The divider calculations tried to find the divider just faster than the clock requested. However if it required a divider of 7 then the for loop aborted without handling the "error" case, and could end up with a clock lower than requested. The integer divider from parent PLL to DSI clock is also capable of going up to /255, not just /7 that the driver was trying. This allows for slower link frequencies on the DSI bus where the resolution permits. Correct the loop so that we always have a clock greater than requested, and covering the whole range of dividers. Fixes: 86c1b9eff3f2 ("drm/vc4: Adjust modes in DSI to work around the integer PLL divider.") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-13-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dsi: Release workaround buffer and DMADave Stevenson1-1/+28
On Pi0-3 the driver allocates a buffer and requests a DMA channel because the ARM can't write to DSI1's registers directly. However, we never release that buffer or channel. Let's add a device-managed action to release each. Fixes: 4078f5757144 ("drm/vc4: Add DSI driver") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-12-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dpi: Ensure a default format is selectedDave Stevenson1-3/+5
In a couple of error/incomplete configuration cases, the DPI_FORMAT bits wouldn't get set. Enforce our RGB888 default in all these cases. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-11-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dpi: Add option for inverting pixel clock and output enableDave Stevenson1-28/+38
DRM provides flags for inverting pixel clock and output enable signals, but these were not mapped to the relevant registers. Add those mappings. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-10-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: dpi: Add support for composite syncs to vc4_dpiDave Stevenson1-9/+16
The hardware can combine H&V syncs onto the output enable line as composite syncs, so add the relevant configuration to do that. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-9-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: hvs: Add debugfs node that dumps the current display listsDave Stevenson1-0/+42
This allows easy analysis of display lists when debugging. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-8-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: plane: Add alpha_blend_mode property to each plane.Dave Stevenson1-13/+49
Move from only supporting the default of pre-multiplied alpha to supporting user specified blend mode using the standardised property. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-7-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: plane: Fix margin calculations for the right/bottom edgesDave Stevenson1-4/+4
The current plane margin calculation code clips the right and bottom edges of the range based using the left and top margins. This is obviously wrong, so let's fix it. Fixes: 666e73587f90 ("drm/vc4: Take margin setup into account when updating planes") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-6-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: plane: Remove subpixel positioning checkDom Cobley1-13/+9
There is little harm in ignoring fractional coordinates (they just get truncated). Without this: modetest -M vc4 -F tiles,gradient -s 32:1920x1080-60 -P89@74:1920x1080*.1.1@XR24 is rejected. We have the same issue in Kodi when trying to use zoom options on video. Note: even if all coordinates are fully integer. e.g. src:[0,0,1920,1080] dest:[-10,-10,1940,1100] it will still get rejected as drm_atomic_helper_check_plane_state uses drm_rect_clip_scaled which transforms this to fractional src coords Fixes: 21af94cf1a4c ("drm/vc4: Add support for scaling of display planes.") Signed-off-by: Dom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-5-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/vc4: kms: Use maximum FIFO load for the HVS clock rateMaxime Ripard1-1/+3
The core clock computation takes into account both the load due to the input (ie, planes) and its output (ie, encoders). However, while the input load needs to consider all the planes, and thus sum all of their associated loads, the output happens mostly in parallel. Therefore, we need to consider only the maximum of all the output loads, and not the sum like we were doing. This resulted in a clock rate way too high which could be discarded for being too high by the clock framework. Since recent changes, the clock framework will even downright reject it, leading to a core clock being too low for its current needs. Fixes: 16e101051f32 ("drm/vc4: Increase the core clock based on HVS load") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-4-maxime@cerno.tech
2022-06-28drm/vc4: kms: Warn if clk_set_min_rate failsMaxime Ripard1-2/+2
We currently ignore the clk_set_min_rate return code assuming it would succeed. However, it can fail if we ask for a rate higher than the current maximum for example. Since we can't fail in atomic_commit, at least warn on failure. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-3-maxime@cerno.tech
2022-06-28drm/vc4: drv: Adopt the dma configuration from the HVS or V3D componentDave Stevenson1-0/+19
vc4_drv isn't necessarily under the /soc node in DT as it is a virtual device, but it is the one that does the allocations. The DMA addresses are consumed by primarily the HVS or V3D, and those require VideoCore cache alias address mapping, and so will be under /soc. During probe find the a suitable device node for HVS or V3D, and adopt the DMA configuration of that node. Cc: <stable@vger.kernel.org> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-2-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2022-06-28drm/fourcc: Document the Intel CCS modifiers' CC plane expected pitchImre Deak1-4/+4
The driver expects the pitch of the Intel CCS CC color planes to be 64 bytes aligned, adjust the modifier descriptions accordingly. Cc: Nanley Chery <nanley.g.chery@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Nanley Chery <nanley.g.chery@intel.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220623144955.2486736-1-imre.deak@intel.com
2022-06-28drm/doc: Fix comment typoMarek Vasut1-1/+1
Replace apprpriately with appropriately. Fixes: 1e4d84c6589e9 ("drm/doc: Polish plane composition property docs") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Benjamin Gaignard <benjamin.gaignard@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Sean Paul <seanpaul@chromium.org> Cc: Simon Ser <contact@emersion.fr> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Simon Ser <contact@emersion.fr> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patchwork.freedesktop.org/patch/msgid/20220628003407.77765-1-marex@denx.de
2022-06-27drm/stm: ltdc: update hardware error managementYannick Fertre2-19/+77
The latest hardware version (0x40100) supports a hardware threshold register (aka FUTR) to trigger a fifo underrun interrupt. A software threshold has been implemented for other hardware versions. The threshold is set to 128 by default. Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220603134654.594373-1-yannick.fertre@foss.st.com
2022-06-27drm/stm: ltdc: add support of horizontal & vertical mirroringYannick Fertre2-56/+108
Support of vertical & horizontal mirroring features thanks to the plane rotation property. Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220603134547.593790-1-yannick.fertre@foss.st.com
2022-06-27drm/stm: ltdc: add support of the dynamic z-orderYannick Fertre3-3/+22
Zpos property is immutable for all hardware versions except the last version (0x40100) which support the blending order feature (dynamic z-order). Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220603134459.593379-1-yannick.fertre@foss.st.com
2022-06-27drm/stm: ltdc: fix various coding-style warningsYannick Fertre1-3/+2
Fix issues reported by checkpatch.pl: - Braces {} should be used on all arms - Blank lines Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Acked-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220603134334.592805-1-yannick.fertre@foss.st.com
2022-06-27drm/stm: ltdc: remove error message about scalingYannick Fertre1-1/+2
Remove error message about scaling & replace it by a debug message to avoid too much error. Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Acked-by: Raphael Gallais-Pou <raphael.gallais-pou@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220603134250.592408-1-yannick.fertre@foss.st.com
2022-06-27drm/stm: ltdc: disable all layers before crtc shutdownYannick Fertre1-0/+6
All plans must be disabled before the CRTC shutdown helping the crtc to restart from a clean situation (without unwanted planes already enable). Signed-off-by: Yannick Fertre <yannick.fertre@foss.st.com> Signed-off-by: Philippe Cornu <philippe.cornu@foss.st.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220603134151.591997-1-yannick.fertre@foss.st.com
2022-06-27drm/doc: Add KUnit documentationJosé Expósito1-0/+32
Explain how to run the KUnit tests present in the DRM subsystem and clarify why the UML-only options were not added to the configuration file present in drivers/gpu/drm/.kunitconfig [1] [2]. [1] https://lore.kernel.org/dri-devel/CABVgOSn8i=LO5p7830h2XU1Jgg0KrN0qTnxkOMhf1oTgxjaKKw@mail.gmail.com/ [2] https://lore.kernel.org/dri-devel/CAGS_qxqpiCim_sy1LDK7PLwVgWf-LKW+uNFTGM=T7ydk-dYcEw@mail.gmail.com/ Reviewed-by: Maxime Ripard <maxime@cerno.tech> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: David Gow <davidgow@google.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220620160640.3790-4-jose.exposito89@gmail.com
2022-06-27drm/format-helper: Add KUnit tests for drm_fb_xrgb8888_to_rgb332()José Expósito5-0/+184
Test the conversion from XRGB8888 to RGB332. What is tested? - Different values for the X in XRGB8888 to make sure it is ignored - Different clip values: Single pixel and full and partial buffer - Well known colors: White, black, red, green, blue, magenta, yellow and cyan - Other colors: Randomly picked - Destination pitch How to run the tests? $ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/tests \ --kconfig_add CONFIG_VIRTIO_UML=y \ --kconfig_add CONFIG_UML_PCI_OVER_VIRTIO=y Suggested-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: David Gow <davidgow@google.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220620160640.3790-3-jose.exposito89@gmail.com
2022-06-27drm/rect: Add DRM_RECT_INIT() macroJosé Expósito1-0/+16
Add a helper macro to initialize a rectangle from x, y, width and height information. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: David Gow <davidgow@google.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: José Expósito <jose.exposito89@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220620160640.3790-2-jose.exposito89@gmail.com
2022-06-27drm/ast: Enable primary plane with CRTCThomas Zimmermann1-4/+9
As the CRTC requires a primary plane for display, ensure that the primary plane is enabled with the CRTC. Use drm_atomic_helper_check_crtc_state(). Add all affected planes to the atomic state so that their state will be checked as well. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220617103226.25617-4-tzimmermann@suse.de
2022-06-27drm/simple-kms: Use drm_atomic_helper_check_crtc_state()Thomas Zimmermann1-8/+6
Simple-KMS helpers guarantee that the CRTC and plane enable flags are synchronized. Implement this with atomic helpers drm_atomic_helper_check_crtc_state() on the CRTC side, and drm_atomic_helper_check_plane_state() on the plane side. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220617103226.25617-3-tzimmermann@suse.de
2022-06-27drm/atomic-helper: Add helper drm_atomic_helper_check_crtc_state()Thomas Zimmermann2-0/+57
Add drm_atomic_helper_check_crtc_state(), which contains tests common to many CRTCs. The first added test verifies that an enabled CRTC has at least one enabled primary plane. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Acked-by: Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220617103226.25617-2-tzimmermann@suse.de
2022-06-27drm/fb-helper: Fix out-of-bounds accessThomas Zimmermann1-8/+19
Clip memory range to screen-buffer size to avoid out-of-bounds access in fbdev deferred I/O's damage handling. Fbdev's deferred I/O can only track pages. From the range of pages, the damage handler computes the clipping rectangle for the display update. If the fbdev screen buffer ends near the beginning of a page, that page could contain more scanlines. The damage handler would then track these non-existing scanlines as dirty and provoke an out-of-bounds access during the screen update. Hence, clip the maximum memory range to the size of the screen buffer. While at it, rename the variables min/max to min_off/max_off in drm_fb_helper_deferred_io(). This avoids confusion with the macros of the same name. Reported-by: Nuno Gonçalves <nunojpg@gmail.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Nuno Gonçalves <nunojpg@gmail.com> Fixes: 67b723f5b742 ("drm/fb-helper: Calculate damaged area in separate helper") Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: <stable@vger.kernel.org> # v5.18+ Link: https://patchwork.freedesktop.org/patch/msgid/20220621104617.8817-1-tzimmermann@suse.de
2022-06-27vfio/pci: Remove console driversAlex Williamson1-0/+5
Console drivers can create conflicts with PCI resources resulting in userspace getting mmap failures to memory BARs. This is especially evident when trying to re-use the system primary console for userspace drivers. Use the aperture helpers to remove these conflicts. v3: * call aperture_remove_conflicting_pci_devices() Reported-by: Laszlo Ersek <lersek@redhat.com> Suggested-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220622140134.12763-4-tzimmermann@suse.de
2022-06-27drm: Implement DRM aperture helpers under video/Thomas Zimmermann11-170/+448
Implement DRM's aperture helpers under video/ for sharing with other sub-systems. Remove DRM-isms from the interface. The helpers track the ownership of framebuffer apertures and provide hand-over from firmware, such as EFI and VESA, to native graphics drivers. Other subsystems, such as fbdev and vfio, also have to maintain ownership of framebuffer apertures. Moving DRM's aperture helpers to a more public location allows all subsystems to interact with each other and share a common implementation. The aperture helpers are selected by the various firmware drivers within DRM and fbdev, and the VGA text-console driver. The original DRM interface is kept in place for use by DRM drivers. v3: * prefix all interfaces with aperture_ (Javier) * rework and simplify documentation (Javier) * rename struct dev_aperture to struct aperture_range * rebase onto latest DRM * update MAINTAINERS entry Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Laszlo Ersek <lersek@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220622140134.12763-3-tzimmermann@suse.de
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.