- 13 7月, 2022 5 次提交
-
-
由 Maxime Ripard 提交于
The current code to unregister our ALSA device needs to be undone manually when we remove the HDMI driver. Since ALSA doesn't seem to support any mechanism to defer freeing something until the last user of the ALSA device is gone, we can either use a device-managed or a DRM-managed action. The consistent way would be to use a DRM-managed one, just like pretty much any framework-facing structure should be doing. However, ALSA does a lot of allocation and registration using device-managed calls. Thus, if we're going that way, by the time the DRM-managed action would run all of those allocation would have been freed and we would end up with a use-after-free. Thus, let's do a device-managed action. It's been tested with KASAN enabled and doesn't seem to trigger any issue, so it's as good as anything. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-42-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The current code will call drm_connector_unregister() and drm_connector_cleanup() when the device is unbound. However, by then, there might still be some references held to that connector, including by the userspace that might still have the DRM device open. Let's switch to a DRM-managed initialization to clean up after ourselves only once the DRM device has been last closed. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-41-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The current code will call drm_encoder_cleanup() when the device is unbound. However, by then, there might still be some references held to that encoder, including by the userspace that might still have the DRM device open. Let's switch to a DRM-managed initialization to clean up after ourselves only once the DRM device has been last closed. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-40-maxime@cerno.tech
-
由 Maxime Ripard 提交于
drm_connector_unregister() is only to be used for connectors that have been registered through drm_connector_register() after drm_dev_register() has been called. This is our case here so let's remove the call. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-39-maxime@cerno.tech
-
由 Maxime Ripard 提交于
Our internal structure that stores the DRM entities structure is allocated through a device-managed kzalloc. This means that this will eventually be freed whenever the device is removed. In our case, the most likely source of removal is that the main device is going to be unbound, and component_unbind_all() is being run. However, it occurs while the DRM device is still registered, which will create dangling pointers, eventually resulting in use-after-free. Switch to a DRM-managed allocation to keep our structure until the DRM driver doesn't need it anymore. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-38-maxime@cerno.tech
-
- 08 7月, 2022 2 次提交
-
-
由 Maxime Ripard 提交于
The current code tries to handle the case where CONFIG_PM isn't selected by first calling our runtime_resume implementation and then properly report the power state to the runtime_pm core. This allows to have a functionning device even if pm_runtime_get_* functions are nops. However, the device power state if CONFIG_PM is enabled is RPM_SUSPENDED, and thus our vc4_hdmi_write() and vc4_hdmi_read() calls in the runtime_pm hooks will now report a warning since the device might not be properly powered. Even more so, we need CONFIG_PM enabled since the previous RaspberryPi have a power domain that needs to be powered up for the HDMI controller to be usable. The previous patch has created a dependency on CONFIG_PM, now we can just assume it's there and only call pm_runtime_resume_and_get() to make sure our device is powered in bind. Link: https://lore.kernel.org/r/20220629123510.1915022-39-maxime@cerno.techAcked-by: NThomas Zimmermann <tzimmermann@suse.de> Tested-by: NStefan Wahren <stefan.wahren@i2se.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Maxime Ripard 提交于
We already depend on runtime PM to get the power domains and clocks for most of the devices supported by the vc4 driver, so let's just select it to make sure it's there. Link: https://lore.kernel.org/r/20220629123510.1915022-38-maxime@cerno.techAcked-by: NThomas Zimmermann <tzimmermann@suse.de> Tested-by: NStefan Wahren <stefan.wahren@i2se.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech>
-
- 28 6月, 2022 14 次提交
-
-
由 Dave Stevenson 提交于
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: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-34-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dave Stevenson 提交于
For interlaced modes the timings were not being correctly programmed into the HDMI block, so correct them. Fixes: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-33-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dom Cobley 提交于
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: ba8c0fae ("drm/vc4: hdmi: Enable 10/12 bpc output") Signed-off-by: NDom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-32-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Mateusz Kwiatkowski 提交于
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: 682e62c4 ("drm/vc4: Fix support for interlaced modes on HDMI.") Signed-off-by: NMateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-31-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dom Cobley 提交于
Our HDMI controllers supports Stereo output so let's enable it. Signed-off-by: NDom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-30-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dom Cobley 提交于
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: NDom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-27-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dom Cobley 提交于
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: NDom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-26-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dom Cobley 提交于
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 bb7d7856 ("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: NDom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-25-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dave Stevenson 提交于
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: c86b4121 ("drm/vc4: hdmi: Move the HSM clock enable to runtime_pm") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-24-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dave Stevenson 提交于
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: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-22-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dom Cobley 提交于
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: bb7d7856 ("drm/vc4: Add HDMI audio support") Signed-off-by: NDom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-21-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dom Cobley 提交于
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: 21317b3f ("drm/vc4: Set up the AVI and SPD infoframes.") Signed-off-by: NDom Cobley <popcornmix@gmail.com> Link: https://lore.kernel.org/r/20220613144800.326124-20-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Dave Stevenson 提交于
The vc5 HDMI registers hadn't been added into the debugfs register sets, therefore weren't dumped on request. Add them in. Fixes: 83239891 ("drm/vc4: hdmi: Support the BCM2711 HDMI controllers") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20220613144800.326124-19-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
由 Phil Elwell 提交于
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: NPhil Elwell <phil@raspberrypi.org> Link: https://lore.kernel.org/r/20220613144800.326124-18-maxime@cerno.techSigned-off-by: NMaxime Ripard <maxime@cerno.tech>
-
- 22 6月, 2022 1 次提交
-
-
由 Saud Farooqui 提交于
Multiplying ints and saving it in unsigned long long could lead to integer overflow before being type casted to unsigned long long. Addresses-Coverity: 1505113: Unintentional integer overflow. Signed-off-by: NSaud Farooqui <farooqui_saud@hotmail.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/PA4P189MB1421E63C0FF3EBF234A80AB38BA79@PA4P189MB1421.EURP189.PROD.OUTLOOK.COM
-
- 12 5月, 2022 1 次提交
-
-
由 Hui Tang 提交于
drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_connector_detect’: drivers/gpu/drm/vc4/vc4_hdmi.c:228:7: error: implicit declaration of function ‘gpiod_get_value_cansleep’; did you mean ‘gpio_get_value_cansleep’? [-Werror=implicit-function-declaration] if (gpiod_get_value_cansleep(vc4_hdmi->hpd_gpio)) ^~~~~~~~~~~~~~~~~~~~~~~~ gpio_get_value_cansleep CC [M] drivers/gpu/drm/vc4/vc4_validate.o CC [M] drivers/gpu/drm/vc4/vc4_v3d.o CC [M] drivers/gpu/drm/vc4/vc4_validate_shaders.o CC [M] drivers/gpu/drm/vc4/vc4_debugfs.o drivers/gpu/drm/vc4/vc4_hdmi.c: In function ‘vc4_hdmi_bind’: drivers/gpu/drm/vc4/vc4_hdmi.c:2883:23: error: implicit declaration of function ‘devm_gpiod_get_optional’; did you mean ‘devm_clk_get_optional’? [-Werror=implicit-function-declaration] vc4_hdmi->hpd_gpio = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN); ^~~~~~~~~~~~~~~~~~~~~~~ devm_clk_get_optional drivers/gpu/drm/vc4/vc4_hdmi.c:2883:59: error: ‘GPIOD_IN’ undeclared (first use in this function); did you mean ‘GPIOF_IN’? vc4_hdmi->hpd_gpio = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN); ^~~~~~~~ GPIOF_IN drivers/gpu/drm/vc4/vc4_hdmi.c:2883:59: note: each undeclared identifier is reported only once for each function it appears in cc1: all warnings being treated as errors Fixes: 6800234c ("drm/vc4: hdmi: Convert to gpiod") Signed-off-by: NHui Tang <tanghui20@huawei.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220510135148.247719-1-tanghui20@huawei.com
-
- 25 4月, 2022 2 次提交
-
-
由 Thomas Zimmermann 提交于
SCDC is the Status and Control Data Channel for HDMI. Move the SCDC helpers into display/ and split the header into files for core and helpers. Update all affected drivers. No functional changes. To avoid the proliferation of Kconfig options, SCDC is part of DRM's support for HDMI. If necessary, a new option could make SCDC an independent feature. Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de> Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-9-tzimmermann@suse.de
-
由 Thomas Zimmermann 提交于
Move DRM's HMDI helpers into the display/ subdirectoy and add it to DRM's display helpers. Update all affected drivers. No functional changes. The HDMI helpers were implemented in the EDID and connector code, but are actually unrelated. With the move to the display-helper library, we can remove the dependency on drm_edid.{c,h} in some driver's HDMI source files. Several of the HDMI helpers remain in EDID code because both share parts of their implementation internally. With better refractoring of the EDID code, those HDMI helpers could be moved into the display-helper library as well. v3: * fix Kconfig dependencies (Javier) v2: * reduce HDMI helpers to avoid exporting functions (Jani) * fix include statements (Jani, Javier) * update Kconfig symbols Signed-off-by: NThomas Zimmermann <tzimmermann@suse.de> Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220421073108.19226-8-tzimmermann@suse.de
-
- 21 4月, 2022 2 次提交
-
-
由 José Expósito 提交于
The vc4_hdmi_encoder struct was used exclusively to cache the value returned by drm_detect_hdmi_monitor() in order to avoid calling it multiple times. Now that drm_detect_hdmi_monitor() has been replaced with drm_display_info.is_hdmi, there is no need to have an extra struct. Remove vc4_hdmi_encoder. Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220420114500.187664-3-jose.exposito89@gmail.com
-
由 José Expósito 提交于
Once EDID is parsed, the monitor HDMI support information is cached in drm_display_info.is_hdmi by drm_parse_hdmi_vsdb_video(). This driver calls drm_detect_hdmi_monitor() to receive the same information and stores its own cached value in vc4_hdmi_encoder.hdmi_monitor, which is less efficient. Avoid calling drm_detect_hdmi_monitor() and use drm_display_info.is_hdmi instead. This also allows to remove vc4_hdmi_encoder.hdmi_monitor. drm_detect_hdmi_monitor() is called in vc4_hdmi_connector_detect() and vc4_hdmi_connector_get_modes(). In both cases it is safe to rely on drm_display_info.is_hdmi as shown by ftrace: $ sudo trace-cmd record -p function_graph -l "vc4_hdmi_*" -l "drm_*" vc4_hdmi_connector_detect: vc4_hdmi_connector_detect() { drm_get_edid() { drm_connector_update_edid_property() { drm_add_display_info() { drm_reset_display_info(); drm_for_each_detailed_block.part.0(); drm_parse_cea_ext() { drm_find_cea_extension(); drm_parse_hdmi_vsdb_video(); /* drm_display_info.is_hdmi is cached here */ } } } } /* drm_display_info.is_hdmi is used here */ } vc4_hdmi_connector_get_modes: vc4_hdmi_connector_get_modes() { drm_get_edid() { drm_connector_update_edid_property() { drm_add_display_info() { drm_reset_display_info(); drm_for_each_detailed_block.part.0(); drm_parse_cea_ext() { drm_find_cea_extension(); drm_parse_hdmi_vsdb_video(); /* drm_display_info.is_hdmi is cached here */ } } } } /* drm_display_info.is_hdmi is used here */ drm_connector_update_edid_property(); } Signed-off-by: NJosé Expósito <jose.exposito89@gmail.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220420114500.187664-2-jose.exposito89@gmail.com
-
- 06 4月, 2022 1 次提交
-
-
由 Maxime Ripard 提交于
Now that the clock driver makes sure we never end up with a rate of 0, the HDMI driver doesn't need to care anymore. Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Link: https://lore.kernel.org/r/20220225143534.405820-13-maxime@cerno.tech
-
- 24 3月, 2022 7 次提交
-
-
由 Maxime Ripard 提交于
In addition to the RGB444 output, the BCM2711 HDMI controller supports the YUV444 and YUV422 output formats. Let's add support for them in the driver, but still use RGB as the preferred format. Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220222164042.403112-8-maxime@cerno.tech
-
由 Maxime Ripard 提交于
Currently we take the max_bpc property as the bpc value and do not try anything else. However, what the other drivers seem to be doing is that they would try with the highest bpc allowed by the max_bpc property and the hardware capabilities, test if it results in an acceptable configuration, and if not decrease the bpc and try again. Let's use the same logic. Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220222164042.403112-7-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The current code only base its decision for whether the scrambler must be enabled or not on the pixel clock of the mode, but doesn't take the bits per color into account. Let's leverage the new function to compute the clock rate in the scrambler setup code. Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220222164042.403112-6-maxime@cerno.tech
-
由 Maxime Ripard 提交于
In the function that validates that the clock isn't too high, we've only taken our controller limitations into account so far. However, the sink can have a limit on the maximum TMDS clock it can deal with too which is exposed through the EDID and the drm_display_info. Make sure we check it. Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220222164042.403112-5-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The code to compute our clock rate for a given setup will be called in multiple places in the next patches, so let's create a separate function for it. Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220222164042.403112-4-maxime@cerno.tech
-
由 Maxime Ripard 提交于
Our code is doing the same clock rate validation in multiple instances. Let's create a helper to share the rate validation. Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220222164042.403112-3-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The pixel_rate field in the vc4_hdmi_connector_state struct actually stores the TMDS character rate, let's rename it for consistency. Suggested-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220222164042.403112-2-maxime@cerno.tech
-
- 21 2月, 2022 1 次提交
-
-
由 Ville Syrjälä 提交于
struct drm_display_mode embeds a list head, so overwriting the full struct with another one will corrupt the list (if the destination mode is on a list). Use drm_mode_copy() instead which explicitly preserves the list head of the destination mode. Even if we know the destination mode is not on any list using drm_mode_copy() seems decent as it sets a good example. Bad examples of not using it might eventually get copied into code where preserving the list head actually matters. Obviously one case not covered here is when the mode itself is embedded in a larger structure and the whole structure is copied. But if we are careful when copying into modes embedded in structures I think we can be a little more reassured that bogus list heads haven't been propagated in. @is_mode_copy@ @@ drm_mode_copy(...) { ... } @depends on !is_mode_copy@ struct drm_display_mode *mode; expression E, S; @@ ( - *mode = E + drm_mode_copy(mode, &E) | - memcpy(mode, E, S) + drm_mode_copy(mode, E) ) @depends on !is_mode_copy@ struct drm_display_mode mode; expression E; @@ ( - mode = E + drm_mode_copy(&mode, &E) | - memcpy(&mode, E, S) + drm_mode_copy(&mode, E) ) @@ struct drm_display_mode *mode; @@ - &*mode + mode Cc: Emma Anholt <emma@anholt.net> Cc: Maxime Ripard <mripard@kernel.org> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220218100403.7028-18-ville.syrjala@linux.intel.com
-
- 18 2月, 2022 1 次提交
-
-
由 Maxime Ripard 提交于
On bind we will register the HDMI codec device but we don't unregister it on unbind, leading to a device leakage. Unregister our device at unbind. Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Reviewed-by: NJavier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220127111452.222002-1-maxime@cerno.tech
-
- 03 2月, 2022 3 次提交
-
-
由 Dave Stevenson 提交于
The 2711 pixel valve can't produce odd horizontal timings, and checks were added to vc4_hdmi_encoder_atomic_check and vc4_hdmi_encoder_mode_valid to filter out/block selection of such modes. Modes with DRM_MODE_FLAG_DBLCLK double all the horizontal timing values before programming them into the PV. The PV values, therefore, can not be odd, and so the modes can be supported. Amend the filtering appropriately. Fixes: 57fb32e6 ("drm/vc4: hdmi: Block odd horizontal timings") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220127135116.298278-1-maxime@cerno.tech
-
由 Dave Stevenson 提交于
The code that set the scdc_enabled flag to ensure it was disabled at boot time also ran on Pi0-3 where there is no SCDC support. This lead to a warning in vc4_hdmi_encoder_post_crtc_disable due to vc4_hdmi_disable_scrambling being called and trying to read (and write) register HDMI_SCRAMBLER_CTL which doesn't exist on those platforms. Only set the flag should the interface be configured to support more than HDMI 1.4. Fixes: 19986461 ("drm/vc4: hdmi: Introduce a scdc_enabled flag") Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220127134559.292778-1-maxime@cerno.tech
-
由 Dave Stevenson 提交于
The existing logic was flawed in that it could try reading the 2711 specific registers for HPD on a CM1/3 where the HPD GPIO hadn't been defined in DT. Ensure we don't do the 2711 register read on invalid hardware, and then Signed-off-by: NDave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220127131754.236074-1-maxime@cerno.tech
-