summaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAgeFilesLines
* drm/mipi-dbi: Prepare framebuffer copy operation in pipe-update helpersThomas Zimmermann2022-12-053-45/+71
| | | | | | | | | | | | | | | | | | | | | Move the vmap/vunmap blocks from the inner fb_dirty helpers into the MIPI DBI update helpers. The function calls can result in waiting and/or processing overhead. Reduce the penalties by executing the functions once in the outer-most function of the pipe update. This change also prepares for MIPI DBI for shadow-plane helpers. With shadow-plane helpers, transfer source buffers are mapped into kernel address space automatically. v2: * keep each driver's existing buffer-mapping patter (Noralf) * zero-initialize iosys_map arrays (Noralf) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> # drm/tiny/mi0283qt Link: https://patchwork.freedesktop.org/patch/msgid/20221202125644.7917-6-tzimmermann@suse.de
* drm/mipi-dbi: Initialize default driver functions with macroThomas Zimmermann2022-12-058-32/+8
| | | | | | | | | | | | | Introduce DRM_MIPI_DBI_SIMPLE_DISPLAY_PIPE_FUNCS to initialize MIPI-DBI helpers to default values and convert drivers. The prepare_fb function set by some drivers is called implicitly by simple-kms helpers, so leave it out. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Javier Martinez Canillas <javierm@redhat.com> Tested-by: Noralf Trønnes <noralf@tronnes.org> # drm/tiny/mi0283qt Link: https://patchwork.freedesktop.org/patch/msgid/20221202125644.7917-5-tzimmermann@suse.de
* drm/st7586: Call MIPI DBI mode_valid helperThomas Zimmermann2022-12-051-0/+1
| | | | | | | | | MIPI DBI drivers validate each mode against their native resolution. Add this test to st7586. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221202125644.7917-4-tzimmermann@suse.de
* drm/ili9225: Call MIPI DBI mode_valid helperThomas Zimmermann2022-12-051-0/+1
| | | | | | | | | MIPI DBI drivers validate each mode against their native resolution. Add this test to ili9225. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221202125644.7917-3-tzimmermann@suse.de
* drm/simple-kms: Remove drm_gem_simple_display_pipe_prepare_fb()Thomas Zimmermann2022-12-054-33/+2
| | | | | | | | | | | | | | | | | The helper drm_gem_simple_display_pipe_prepare_fb() is simple-KMS' default implementation for prepare_fb. Remove the call from drivers that set it explicitly. Then inline the helper into the only caller within simple-kms helpers. No functional changes. Simple-KMS drivers that implement the prepare_fb callback should call drm_gem_plane_helper_prepare_fb() directly. v2: * fix typo in commit message Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221202125644.7917-2-tzimmermann@suse.de
* drm/vc4: dpi: Fix format mapping for RGB565Dave Stevenson2022-12-011-1/+1
| | | | | | | | | | | The mapping is incorrect for RGB565_1X16 as it should be DPI_FORMAT_18BIT_666_RGB_1 instead of DPI_FORMAT_18BIT_666_RGB_3. Fixes: 08302c35b59d ("drm/vc4: Add DPI driver") Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-7-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dpi: Change the default DPI format to being 18bpp, not 24.Dave Stevenson2022-12-011-2/+2
| | | | | | | | | | | | | | | | | DPI hasn't really been used up until now, so the default has been meaningless. In theory we should be able to pass the desired format for the adjacent bridge chip through, but framework seems to be missing for that. As the main device to use DPI is the VGA666 or Adafruit Kippah, both of which use RGB666, change the default to being RGB666 instead of RGB888. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-6-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dpi: Support BGR666 formatsJoerg Quinten2022-12-011-0/+6
| | | | | | | | | | The VC4 DPI output can support multiple BGR666 variants, but they were never added to the driver. Let's add the the support for those formats. Signed-off-by: Joerg Quinten <aBUGSworstnightmare@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-5-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: dpi: Support RGB565 formatChris Morgan2022-12-011-0/+4
| | | | | | | | | | | | | The RGB565 format with padding over 24 bits (MEDIA_BUS_FMT_RGB565_1X24_CPADHI) is supported by the vc4 DPI controller. This is what the Geekworm MZP280 DPI display uses, so let's add support for it in the DPI controller driver. Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-4-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: probe_helper: Fix uninitialized variableMaxime Ripard2022-12-011-0/+1
| | | | | | | | | | The len variable is used while uninitialized. Initialize it. Fixes: 1e4a91db109f ("drm/probe-helper: Provide a TV get_modes helper") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221201090736.290935-1-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/modes: Use strscpy() to copy command-line mode nameMaxime Ripard2022-12-011-1/+1
| | | | | | | | | | | | | The mode name in struct drm_cmdline_mode can hold 32 characters at most, which can easily get overrun. Switch to strscpy() to prevent such a thing. Reported-by: coverity-bot <keescook+coverity-bot@chromium.org> Addresses-Coverity-ID: 1527354 ("Security best practices violations") Fixes: a7ab155397dd ("drm/modes: Switch to named mode descriptors") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221128081938.742410-2-maxime@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/meson: dw-hdmi: Use devm_regulator_*get_enable*()Matti Vaittinen2022-12-011-20/+3
| | | | | | | | | | Simplify using the devm_regulator_get_enable_optional(). Also drop the now unused struct member 'hdmi_supply'. Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/df0096b5aea2a18d1540cde379c5abf589ccd7c4.1669799805.git.mazziesaccount@gmail.com
* drm/bridge: sii902x: Use devm_regulator_bulk_get_enable()Matti Vaittinen2022-12-011-22/+4
| | | | | | | | | Simplify using devm_regulator_bulk_get_enable() Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com> Acked-by: Robert Foss <robert.foss@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/e6153c7beb2076b9ea13082b2024ec3296bc08bc.1669799805.git.mazziesaccount@gmail.com
* drm/vkms: change min cursor size to accept smaller valuesAlaa Emad2022-11-291-2/+2
| | | | | | | | | | | Change min cursor size of vkms driver from 20 to 10, to increase the IGT test coverage of vkms by enabling 32x10 cursor size subtests in kms_cursor_crc Signed-off-by: Alaa Emad <aemad@igalia.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221109113945.20938-1-aemad@igalia.com
* drm/vkms: Fix null-ptr-deref in vkms_release()Yuan Can2022-11-291-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A null-ptr-deref is triggered when it tries to destroy the workqueue in vkms->output.composer_workq in vkms_release(). KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24 RIP: 0010:destroy_workqueue+0x2f/0x710 ... Call Trace: <TASK> ? vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/0x1000 [vkms] do_one_initcall+0xd0/0x4f0 do_init_module+0x1a4/0x680 load_module+0x6249/0x7110 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that an OOM happened which triggers the destroy of the workqueue, however, the workqueue is alloced in the later process, thus a null-ptr-deref happened. A simple call graph is shown as below: vkms_init() vkms_create() devm_drm_dev_alloc() __devm_drm_dev_alloc() devm_drm_dev_init() devm_add_action_or_reset() devm_add_action() # an error happened devm_drm_dev_init_release() drm_dev_put() kref_put() drm_dev_release() vkms_release() destroy_workqueue() # null-ptr-deref happened vkms_modeset_init() vkms_output_init() vkms_crtc_init() # where the workqueue get allocated Fix this by checking if composer_workq is NULL before passing it to the destroy_workqueue() in vkms_release(). Fixes: 6c234fe37c57 ("drm/vkms: Implement CRC debugfs API") Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221101065156.41584-3-yuancan@huawei.com
* drm/vkms: Fix memory leak in vkms_init()Yuan Can2022-11-291-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A memory leak was reported after the vkms module install failed. unreferenced object 0xffff88810bc28520 (size 16): comm "modprobe", pid 9662, jiffies 4298009455 (age 42.590s) hex dump (first 16 bytes): 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............ backtrace: [<00000000e7561ff8>] kmalloc_trace+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0 [<000000001505ee87>] do_init_module+0x1a4/0x680 [<00000000958079ad>] load_module+0x6249/0x7110 [<00000000117e4696>] __do_sys_finit_module+0x140/0x200 [<00000000f74b12d2>] do_syscall_64+0x35/0x80 [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that the vkms_init() returns without checking the return value of vkms_create(), and if the vkms_create() failed, the config allocated at the beginning of vkms_init() is leaked. vkms_init() config = kmalloc(...) # config allocated ... return vkms_create() # vkms_create failed and config is leaked Fix this problem by checking return value of vkms_create() and free the config if error happened. Fixes: 2df7af93fdad ("drm/vkms: Add vkms_config type") Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Melissa Wen <melissa.srw@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221101065156.41584-2-yuancan@huawei.com
* drm/panel-samsung-atna33xc20: Extend autosuspend delayDrew Davenport2022-11-291-1/+1
| | | | | | | | | | | | Avoid the panel oscillating on and off during boot. In some cases it will be more than 1000ms between powering the panel to read the EDID early during boot, and enabling the panel for display. Extending the autosuspend delay avoids autosuspending during this interval. Signed-off-by: Drew Davenport <ddavenport@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.5.I96ce2a565ff893eddcbee70174c991179311a3ae@changeid
* drm/bridge/parade-ps8640: Extend autosuspendDrew Davenport2022-11-291-2/+2
| | | | | | | | | | Same change as done for panel-samsung-atna33xc20. Extend the autosuspend delay to avoid oscillating between power status during boot. Signed-off-by: Drew Davenport <ddavenport@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.4.If6153da69ec4bc9e83d5f095ef6e6b07283940a5@changeid
* drm/panel-simple: Use ktime_get_boottime for delaysDrew Davenport2022-11-291-3/+3
| | | | | | | | | | | ktime_get_boottime continues while the device is suspended. This change ensures that the resume path will not be delayed if the power off delay has already been met while the device is suspended Signed-off-by: Drew Davenport <ddavenport@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.3.Iebd9f79aba0a62015fd2383fe6986c2d6fe12cfd@changeid
* drm/panel-samsung-atna33xc20: Use ktime_get_boottime for delaysDrew Davenport2022-11-291-4/+4
| | | | | | | | | | | ktime_get_boottime continues while the device is suspended. This change ensures that the resume path will not be delayed if the power off delay has already been met while the device is suspended Signed-off-by: Drew Davenport <ddavenport@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.2.Iebd9f79aba0a62015fd2383fe6986c2d6fe12cfd@changeid
* drm/panel-edp: Use ktime_get_boottime for delaysDrew Davenport2022-11-291-4/+4
| | | | | | | | | | | | | | | | | | | | | | ktime_get is based on CLOCK_MONOTONIC which stops on suspend. On suspend, the time that the panel was powerd off is recorded with ktime_get, and on resume this time is compared to the current ktime_get time to determine if the driver should wait for the panel to power down completely before re-enabling it. Because we're using ktime_get, this delay doesn't account for the time that the device is suspended, during which the power down delay may have already elapsed. Change to use ktime_get_boottime throughout, which uses CLOCK_BOOTTIME which does not stop when suspended. This ensures that the resume path will not be delayed if the power off delay has already been met while the device is suspended. Signed-off-by: Drew Davenport <ddavenport@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221117133655.1.I51639dc112bbbe27259df6bdad56dbabd655d91a@changeid
* drm/bridge: ti-sn65dsi86: Convert to i2c's .probe_new()Uwe Kleine-König2022-11-291-3/+2
| | | | | | | | | | | The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221118224540.619276-37-uwe@kleine-koenig.org
* drm/bridge: megachips: Fix error handling in i2c_register_driver()Yuan Can2022-11-291-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A problem about insmod megachips-stdpxxxx-ge-b850v3-fw.ko failed is triggered with the following log given: [ 4497.981497] Error: Driver 'stdp4028-ge-b850v3-fw' is already registered, aborting... insmod: ERROR: could not insert module megachips-stdpxxxx-ge-b850v3-fw.ko: Device or resource busy The reason is that stdpxxxx_ge_b850v3_init() returns i2c_add_driver() directly without checking its return value, if i2c_add_driver() failed, it returns without calling i2c_del_driver() on the previous i2c driver, resulting the megachips-stdpxxxx-ge-b850v3-fw can never be installed later. A simple call graph is shown as below: stdpxxxx_ge_b850v3_init() i2c_add_driver(&stdp4028_ge_b850v3_fw_driver) i2c_add_driver(&stdp2690_ge_b850v3_fw_driver) i2c_register_driver() driver_register() bus_add_driver() priv = kzalloc(...) # OOM happened # return without delete stdp4028_ge_b850v3_fw_driver Fix by calling i2c_del_driver() on stdp4028_ge_b850v3_fw_driver when i2c_add_driver() returns error. Fixes: fcfa0ddc18ed ("drm/bridge: Drivers for megachips-stdpxxxx-ge-b850v3-fw (LVDS-DP++)") Signed-off-by: Yuan Can <yuancan@huawei.com> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> Tested-by: Ian Ray <ian.ray@ge.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221108091226.114524-1-yuancan@huawei.com
* drm/tests: helpers: Add missing exportMaxime Ripard2022-11-281-0/+1
| | | | | | | | | | | drm_kunit_device_init() is a public function meant to be used by other tests, but isn't exported. This leads to modpost errors when the other tests are compiled as module. Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Maíra Canal <mairacanal@riseup.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221128081938.742410-3-maxime@cerno.tech
* drm/vc4: vec: Use pm_runtime_resume_and_get() in vc4_vec_encoder_enable()Shang XiaoJing2022-11-281-1/+1
| | | | | | | | | | | | | | Commit f0601ef8631c ("drm/vc4: vec: Protect device resources after removal") add fail path for vc4_vec_encoder_enable(), and will put usage_counter only when pm_runtime_get_sync() succeeds. However, pm_runtime_get_sync() will increment usage_counter even it failed. Fix it by replacing it with pm_runtime_resume_and_get() to keep usage counter balanced. Fixes: e4b81f8c74c8 ("drm/vc4: Add support for the VEC (Video Encoder) IP") Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com> Link: https://lore.kernel.org/r/20221124015113.18540-1-shangxiaojing@huawei.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: crtc: Provide a CRTC nameMaxime Ripard2022-11-283-1/+12
| | | | | | | | | | | | It's fairly hard to figure out the instance of the CRTC affected by an atomic change using the default name. Since we can provide our own to the CRTC initialization functions, let's do so to make the debugging sessions easier. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-20-051a0bb60a16@cerno.tech
* drm/vc4: crtc: Pass the device and data in vc4_crtc_initMaxime Ripard2022-11-283-13/+17
| | | | | | | | | | Both users of vc4_crtc_init need the same extra initialization to set the pointer to the platform_device and the CRTC data. Since it's mandatory, let's make them both arguments of vc4_crtc_init(). Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-17-051a0bb60a16@cerno.tech
* drm/vc4: txp: Initialise the CRTC before the encoder and connectorMaxime Ripard2022-11-281-5/+5
| | | | | | | | | It makes more sense to register the CRTC before the encoder and connectors, so let's move our call around. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-16-051a0bb60a16@cerno.tech
* drm/vc4: Add TXP encoder typeMaxime Ripard2022-11-282-10/+21
| | | | | | | | | | | | The TXP is integrated as a separate CRTC/Encoder/Connector combo, but for some reason doesn't rely on the vc4_encoder type and it's associated type. Let's create a type to make it consistent with the other encoders. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-15-051a0bb60a16@cerno.tech
* drm/vc4: txp: Reorder the variable assignmentsMaxime Ripard2022-11-281-9/+6
| | | | | | | | | The current order of variable assignments is unneccessarily complex, let's make it simpler. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-14-051a0bb60a16@cerno.tech
* drm/vc4: kms: Sort the CRTCs by output before assigning themMaxime Ripard2022-11-281-33/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On the vc4 devices (and later), the blending is done by a single device called the HVS. The HVS has three FIFO that can operate in parallel, and route their output to 6 CRTCs and 7 encoders on the BCM2711. Each of these CRTCs and encoders have some constraints on which FIFO they can feed from, so we need some code to take all those constraints into account and assign FIFOs to CRTCs. The problem can be simplified by assigning those FIFOs to CRTCs by ascending output index number. We had a comment mentioning it already, but we were never actually enforcing it. It was working still in most situations because the probe order is roughly equivalent, except for the (optional, and fairly rarely used on the Pi4) VEC which was last in the probe order sequence, but one of the earliest device to assign. This resulted in configurations that were rejected by our code but were still valid with a different assignment. We can fix this by making sure we assign CRTCs to FIFOs by ordering them by ascending HVS output index. Fixes: 87ebcd42fb7b ("drm/vc4: crtc: Assign output to channel automatically") Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-10-051a0bb60a16@cerno.tech
* drm/vc4: kms: Constify the HVS old/new state helpersMaxime Ripard2022-11-281-2/+2
| | | | | | | | | The vc4_hvs_get_(old|new)_global_state functions don't modify the drm_atomic_state passed as an argument, so let's make it const. Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v1-13-051a0bb60a16@cerno.tech Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: Constify container_of wrappersMaxime Ripard2022-11-281-8/+8
| | | | | | | | | | | None of our wrappers around container_of to access our objects from the DRM object pointer actually modify the latter. Let's make them const. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-11-051a0bb60a16@cerno.tech
* drm/atomic: Constify the old/new state accessorsMaxime Ripard2022-11-281-6/+6
| | | | | | | | | The drm_atomic_get_(old|new)_*_state don't modify the passed drm_atomic_state, so we can make it const. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20221123-rpi-kunit-tests-v1-9-051a0bb60a16@cerno.tech
* drm: mxsfb: DRM_MXSFB should depend on ARCH_MXS || ARCH_MXCGeert Uytterhoeven2022-11-251-0/+1
| | | | | | | | | | | | | Freescale/NXP i.MX LCDIF and eLCDIF LCD controllers are only present on Freescale/NXP i.MX SoCs. Hence add a dependency on ARCH_MXS || ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without Freescale/NXP i.MX support. Fixes: 45d59d704080cc0c ("drm: Add new driver for MXSFB controller") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/98e74779ca2bc575d91afff03369e86b080c01ac.1669046358.git.geert+renesas@glider.be
* drm: mxsfb: DRM_IMX_LCDIF should depend on ARCH_MXCGeert Uytterhoeven2022-11-251-0/+1
| | | | | | | | | | | | | The Freescale/NXP i.MX LCDIFv3 LCD controller is only present on Freescale/NXP i.MX SoCs. Hence add a dependency on ARCH_MXC, to prevent asking the user about this driver when configuring a kernel without Freescale/NXP i.MX support. Fixes: 9db35bb349a0ef32 ("drm: lcdif: Add support for i.MX8MP LCDIF variant") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/6103c1aa65a7888c12d351ae63f29850f29f42b9.1669046403.git.geert+renesas@glider.be
* drm/fb-helper: Don't use the preferred depth for the BPP defaultThomas Zimmermann2022-11-241-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | If no preferred value for bits-per-pixel has been given, fall back to 32. Never use the preferred depth. The color depth is the number of color/alpha bits per pixel, while bpp is the overall number of bits in most cases. Most noteworthy, XRGB8888 has a depth of 24 and a bpp value of 32. Using depth for bpp would make the value 24 as well and format selection in fbdev helpers fails. Unfortunately XRGB8888 is the most common format and the old heuristic therefore fails for most of the drivers (unless they implement the 24-bit RGB888 format). Picking a bpp of 32 will later on result in a default depth of 24 and the format XRGB8888. As XRGB8888 is the default format for most of the current and legacy graphics stack, all drivers must support it. So it is the safe choice. v2: * fix commit-message typo (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-8-tzimmermann@suse.de
* drm/solomon: Set preferred color depth and bpp to the correct valuesThomas Zimmermann2022-11-241-2/+2
| | | | | | | | | | Set the preferred color depth to 24 bits and the fbdev bpp to 32 bits. This will signal XRGB8888 as default format to clients. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-7-tzimmermann@suse.de
* drm/simpledrm: Set preferred depth from format of scanout bufferThomas Zimmermann2022-11-241-2/+2
| | | | | | | | | | | | | | | Set the preferred depth from the format of the scanout buffer. The value cannot be hardcoded, as the scanout buffer is only known at runtime. Also derive the fbdev emulation's bpp value from the scanout format. v2: * fix commit-message typo Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-6-tzimmermann@suse.de
* drm/ofdrm: Set preferred depth from format of scanout bufferThomas Zimmermann2022-11-241-12/+1
| | | | | | | | | | | | | | | | | | Set the preferred depth from the format of the scanout buffer. The value cannot be hardcoded, as the scanout buffer is only known at runtime. Keeping the existing switch statement just duplicates the driver's existing logic for format detection. Also remove the FIXME comment from the call to drm_fbdev_generic_setup() as the driver now handles color depth and bpp values correctly. v2: * fix commit-message typo Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-5-tzimmermann@suse.de
* drm/cirrus: Decouple fbdev bpp value from color depthThomas Zimmermann2022-11-241-1/+1
| | | | | | | | | | | Cirrus has a preferred color depth of 16 bit; also use it as fbdev bpp value. Don't use the color depth directly. It has a different meaning than bpp and both cannot be used interchangeably. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-4-tzimmermann@suse.de
* drm/logicvc: Fix preferred fbdev cppThomas Zimmermann2022-11-241-1/+12
| | | | | | | | | | | | | Logicvc can have different values for the preferred color depth. Set the fbdev bpp value depending on the runtime value. v2: * remove unused color depth of 15 from switch (Javier) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-3-tzimmermann@suse.de
* drm/hisilicon/hibmc: Fix preferred depth and bppThomas Zimmermann2022-11-241-2/+2
| | | | | | | | | | Set the preferred color depth to 24 bits and the fbdev bpp to 32 bits. This will signal XRGB8888 as default format to clients. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20221123115348.2521-2-tzimmermann@suse.de
* drm/bridge: ti-sn65dsi83: Fix delay after reset deassert to match specFrieder Schrempf2022-11-241-1/+1
| | | | | | | | | | | | The datasheet specifies a delay of 10 milliseconds, but the current driver only waits for 1 ms. Fix this to make sure the initialization sequence meets the spec. Fixes: ceb515ba29ba ("drm/bridge: ti-sn65dsi83: Add TI SN65DSI83 and SN65DSI84 driver") Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by: Alexander Stein <alexander.stein@ew.tq-group.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221122081219.20143-1-frieder@fris.de
* drm/sun4i: tv: Convert to the new TV mode propertyMaxime Ripard2022-11-241-107/+34
| | | | | | | | | | | Now that the core can deal fine with analog TV modes, let's convert the sun4i TV driver to leverage those new features. Acked-by: Noralf Trønnes <noralf@tronnes.org> Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-19-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: vec: Add support for more analog TV standardsMateusz Kwiatkowski2022-11-241-4/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for the following composite output modes (all of them are somewhat more obscure than the previously defined ones): - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to 4.43361875 MHz (the PAL subcarrier frequency). Never used for broadcasting, but sometimes used as a hack to play NTSC content in PAL regions (e.g. on VCRs). - PAL_N - PAL with alternative chroma subcarrier frequency, 3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay and Uruguay to fit 576i50 with colour in 6 MHz channel raster. - PAL60 - 480i60 signal with PAL-style color at normal European PAL frequency. Another non-standard, non-broadcast mode, used in similar contexts as NTSC_443. Some displays support one but not the other. - SECAM - French frequency-modulated analog color standard; also have been broadcast in Eastern Europe and various parts of Africa and Asia. Uses the same 576i50 timings as PAL. Also added some comments explaining color subcarrier frequency registers. Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-18-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: vec: Convert to the new TV mode propertyMaxime Ripard2022-11-241-53/+131
| | | | | | | | | | | | | | | | Now that the core can deal fine with analog TV modes, let's convert the vc4 VEC driver to leverage those new features. We've added some backward compatibility to support the old TV mode property and translate it into the new TV norm property. We're also making use of the new analog TV atomic_check helper to make sure we trigger a modeset whenever the TV mode is updated. Acked-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-17-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: vec: Check for VEC output constraintsMateusz Kwiatkowski2022-11-241-0/+50
| | | | | | | | | | | | | | | The VEC can accept pretty much any relatively reasonable mode, but still has a bunch of constraints to meet. Let's create an atomic_check() implementation that will make sure we don't end up accepting a non-functional mode. Acked-by: Noralf Trønnes <noralf@tronnes.org> Signed-off-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-16-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: vec: Use TV Reset implementationMaxime Ripard2022-11-241-1/+7
| | | | | | | | | | | | The analog TV properties created by the drm_mode_create_tv_properties() are not properly initialised at reset. Let's switch our implementation to call drm_atomic_helper_connector_tv_reset(). Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-15-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/atomic-helper: Add an analog TV atomic_check implementationMaxime Ripard2022-11-241-0/+49
| | | | | | | | | | | | | | The analog TV connector drivers share some atomic_check logic, and the new TV standard property have created some boilerplate that can be shared across drivers too. Let's create an atomic_check helper for those use cases. Reviewed-by: Noralf Trønnes <noralf@tronnes.org> Tested-by: Mateusz Kwiatkowski <kfyatek+publicgit@gmail.com> Acked-in-principle-or-something-like-that-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v10-14-256dad125326@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
generated by cgit v1.2.3 (git 2.25.1) at 2024-08-12 12:08:10 +0000