- 13 7月, 2022 14 次提交
-
-
由 Maxime Ripard 提交于
mutex_init is supposed to be balanced by a call to mutex_destroy that we were never doing in the vc4 driver. Since a DRM-managed mutex_init variant has been introduced, let's just switch to it. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-66-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The vc4 has a custom API to allow components to register a debugfs file before the DRM driver has been registered and the debugfs_init hook has been called. However, the .late_register hook allows to have the debugfs file creation deferred after that time already. Let's remove our custom code to only register later our debugfs entries as part of either debugfs_init or after it. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-65-maxime@cerno.tech
-
由 Maxime Ripard 提交于
devm_pm_runtime_enable() simplifies the driver a bit since it will call pm_runtime_disable() automatically through a device-managed action. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-49-maxime@cerno.tech
-
由 Maxime Ripard 提交于
Whenever the device and driver are unbound, the main device and all the subdevices will be removed by calling their unbind() method. However, the DRM device itself will only be freed when the last user will have closed it. It means that there is a time window where the device and its resources aren't there anymore, but the userspace can still call into our driver. Fortunately, the DRM framework provides the drm_dev_enter() and drm_dev_exit() functions to make sure our underlying device is still there for the section protected by those calls. Let's add them to the HDMI driver. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-48-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The HDMI driver unbind hook doesn't have any ALSA-related code anymore, so let's move the ALSA sanity checks and comments we have to some other part of the driver dedicated to ALSA. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-47-maxime@cerno.tech
-
由 Maxime Ripard 提交于
Commit 776efe80 ("drm/vc4: hdmi: Drop devm interrupt handler for hotplug interrupts") dropped the device-managed interrupt registration because it was creating bugs and races whenever an interrupt was coming in while the device was removed. However, our latest patches to the HDMI controller driver fix this as well, so we can use device-managed interrupt handlers again. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-46-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The current code to build the registers set later exposed in debugfs for the HDMI controller relies on traditional allocations, that are later free'd as part of the driver unbind hook. Since krealloc doesn't have a DRM-managed equivalent, let's add an action to free the buffer later on. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-45-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The reference to the DDC controller device needs to be put back when we're done with it. Let's use a device-managed action to simplify the driver. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-44-maxime@cerno.tech
-
由 Maxime Ripard 提交于
The current code to unregister our CEC device needs to be undone manually when we remove the HDMI driver. Since the CEC framework will allocate its main structure, and will defer its deallocation to when the last user will have closed it, we don't really need to take any particular measure to prevent any use-after-free and can thus use any managed action. Acked-by: NThomas Zimmermann <tzimmermann@suse.de> Signed-off-by: NMaxime Ripard <maxime@cerno.tech> Link: https://lore.kernel.org/r/20220711173939.1132294-43-maxime@cerno.tech
-
由 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 3 次提交
-
-
由 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
-