summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* drm/panel: Add prepare_prev_first flag to drm_panelDave Stevenson2022-12-082-0/+12
| | | | | | | | | | | | Mapping to the drm_bridge flag pre_enable_prev_first, add a new flag prepare_prev_first to drm_panel to allow the panel driver to request that the upstream bridge should be pre_enabled before the panel prepare. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20221205173328.1395350-6-dave.stevenson@raspberrypi.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/bridge: Introduce pre_enable_prev_first to alter bridge init orderDave Stevenson2022-12-082-24/+129
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DSI sink devices typically want the DSI host powered up and configured before they are powered up. pre_enable is the place this would normally happen, but they are called in reverse order from panel/connector towards the encoder, which is the "wrong" order. Add a new flag pre_enable_prev_first that any bridge can set to swap the order of pre_enable (and post_disable) for that and the immediately previous bridge. Should the immediately previous bridge also set the pre_enable_prev_first flag, the previous bridge to that will be called before either of those which requested pre_enable_prev_first. eg: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20221205173328.1395350-5-dave.stevenson@raspberrypi.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/bridge: Drop unused drm_bridge_chain functionsSam Ravnborg2022-12-082-138/+0
| | | | | | | | | | | | | | | | | | | | | | | The drm_bridge_chain_{pre_enable,enable,disable,post_disable} has no users left and we have atomic variants that should be used. Drop them so they do not gain new users. Adjust a few comments to avoid references to the dropped functions. Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Maxime Ripard <mripard@kernel.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: Andrzej Hajda <a.hajda@samsung.com> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221205173328.1395350-4-dave.stevenson@raspberrypi.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/mediatek: dp: Replace usage of drm_bridge_chain_ functionsDave Stevenson2022-12-081-2/+2
| | | | | | | | | | | | | Commit f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") added usage of the drm_bridge_chain_ functions which are to be deprecated. Replace with the drm_atomic_bridge_chain_ variants using the current state. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221205173328.1395350-3-dave.stevenson@raspberrypi.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/bridge: ps8640: Use atomic variants of drm_bridge_funcsSam Ravnborg2022-12-081-6/+12
| | | | | | | | | | | | | | | | | | | | | | | | | The atomic variants of enable/disable in drm_bridge_funcs are the preferred operations - introduce these. The ps8640 driver used the non-atomic variants of the drm_bridge_chain_pre_enable/ drm_bridge_chain_post_disable - convert these to the atomic variants. v2: - Init state operations in drm_bridge_funcs (Laurent) Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Maxime Ripard <mripard@kernel.org> Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Philip Chen <philipchen@chromium.org> Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Robert Foss <robert.foss@linaro.org> Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com> Cc: Jonas Karlman <jonas@kwiboo.se> Cc: Jernej Skrabec <jernej.skrabec@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20221205173328.1395350-2-dave.stevenson@raspberrypi.com Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* Documentation: gpu: vc4: Add KUnit Tests SectionMaxime Ripard2022-12-081-0/+16
| | | | | | | | | Now that we have VC4-specific tests in place, let's document them properly. Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-20-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: tests: Add unit test suite for the PV muxingMaxime Ripard2022-12-084-9/+1091
| | | | | | | | | | | | | The HVS to PixelValve muxing code is fairly error prone and has a bunch of arbitrary constraints due to the hardware setup. Let's create a test suite that makes sure that the possible combinations work and the invalid ones don't. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-19-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: tests: Fail the current test if we access a registerMaxime Ripard2022-12-087-13/+81
| | | | | | | | | | | | Accessing a register when running under kunit is a bad idea since our device is completely mocked. Fail the current test if we ever access any of our hardware registers. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-18-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: tests: Introduce a mocking infrastructureMaxime Ripard2022-12-0812-13/+511
| | | | | | | | | | | | | | | In order to test the current atomic_check hooks we need to have a DRM device that has roughly the same capabilities and layout that the actual hardware. We'll also need a bunch of functions to create arbitrary atomic states. Let's create some helpers to create a device that behaves like the real one, and some helpers to maintain the atomic state we want to check. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-17-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: hvs: Provide a function to initialize the HVS structureMaxime Ripard2022-12-082-30/+44
| | | | | | | | | | | We'll need to initialize the HVS structure without a backing device to create a mock we'll use for testing. Split the structure initialization part into a separate function. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-16-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: crtc: Make encoder lookup helper publicMaxime Ripard2022-12-082-16/+17
| | | | | | | | | | | We'll need a function that looks up an encoder by its vc4_encoder_type. Such a function is already present in the CRTC code, so let's make it public so that we can reuse it in the unit tests. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-15-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: crtc: Introduce a lower-level crtc init helperMaxime Ripard2022-12-082-19/+57
| | | | | | | | | | | | | | The current vc4_crtc_init() helper assumes that we will be using hardware planes and calls vc4_plane_init(). While it's a reasonable assumption, we'll want to mock the plane and thus provide our own. Let's create a helper that will take the plane as an argument. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-14-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/vc4: Move HVS state to main headerMaxime Ripard2022-12-082-22/+26
| | | | | | | | | | | | | In order to introduce unit tests for the HVS state computation, we'll need access to the vc4_hvs_state struct definition and its associated helpers. Let's move them in our driver header. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-13-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: Add a test for DRM managed actionsMaxime Ripard2022-12-082-0/+72
| | | | | | | | | | DRM-managed actions are supposed to be ran whenever the device is released. Let's introduce a basic unit test to make sure it happens. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-12-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Allow to pass a custom drm_driverMaxime Ripard2022-12-082-12/+54
| | | | | | | | | | Some tests will need to provide their own drm_driver instead of relying on the dumb one in the helpers, so let's create a helper that allows to do so. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-11-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Allow for a custom device struct to be allocatedMaxime Ripard2022-12-085-38/+48
| | | | | | | | | | | | | The current helper to allocate a DRM device doesn't allow for any subclassing by drivers, which is going to be troublesome as we work on getting some kunit testing on atomic modesetting code. Let's use a similar pattern to the other allocation helpers by providing the structure size and offset as arguments. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-10-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Make sure the device is boundMaxime Ripard2022-12-081-1/+25
| | | | | | | | | | | | The device managed resources are freed when the device is detached, so it has to be bound in the first place. Let's create a fake driver that we will bind to our fake device to benefit from the device managed cleanups in our tests. Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-9-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Switch to a platform_deviceMaxime Ripard2022-12-081-2/+14
| | | | | | | | | | | | The device managed resources are ran if the device has bus, which is not the case of a root_device. Let's use a platform_device instead. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-8-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Create the device in another functionMaxime Ripard2022-12-085-27/+77
| | | | | | | | | | We'll need in some tests to control when the device needs to be added and removed, so let's split the device creation from the DRM device creation function. Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-7-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Remove the name parameterMaxime Ripard2022-12-085-11/+8
| | | | | | | | | The device name isn't really useful, we can just define it instead of exposing it in the API. Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-6-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Rename the device init helperMaxime Ripard2022-12-085-8/+16
| | | | | | | | | | The name doesn't really fit the conventions for the other helpers in DRM/KMS, so let's rename it to make it obvious that we allocate a new DRM device. Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-5-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Switch to EXPORT_SYMBOL_GPLMaxime Ripard2022-12-081-1/+1
| | | | | | | | | | | | drm_kunit_device_init() among other things will allocate a device and wrap around root_device_register. This function is exported with EXPORT_SYMBOL_GPL, so we can't really change the license. Fixes: a77a3ffa151b ("drm/tests: helpers: Add missing export") Suggested-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-4-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Document drm_kunit_device_init()Maxime Ripard2022-12-081-0/+17
| | | | | | | | | | Commit 44a3928324e9 ("drm/tests: Add Kunit Helpers") introduced the drm_kunit_device_init() function but didn't document it properly. Add that documentation. Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-3-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: Introduce a config option for the KUnit helpersMaxime Ripard2022-12-083-2/+11
| | | | | | | | | | | Driver-specific tests will need access to the helpers without pulling every DRM framework test. Let's create an intermediate Kconfig options for the helpers. Suggested-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Maíra Canal <mcanal@igalia.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-2-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm/tests: helpers: Move the helper header to include/drmMaxime Ripard2022-12-085-8/+4
| | | | | | | | | We'll need to use those helpers from drivers too, so let's move it to a more visible location. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://lore.kernel.org/r/20221123-rpi-kunit-tests-v3-1-4615a663a84a@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
* drm: panel-orientation-quirks: Add quirk for DynaBook K50Allen Ballway2022-12-071-7/+13
| | | | | | | | | | | | Like the ASUS T100HAN for which there is already a quirk, the DynaBook K50 has a 800x1280 portrait screen mounted in the tablet part of a landscape oriented 2-in-1. Update the quirk to be more generic and apply to this device. Signed-off-by: Allen Ballway <ballway@chromium.org> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221130170811.1.Iee9a494547541dade9eeee9521cc8b811e76a8a0@changeid
* drm: panel-orientation-quirks: Add quirk for Lenovo Yoga Tab 3 X90FHans de Goede2022-12-071-0/+13
| | | | | | | | | The Lenovo Yoga Tab 3 X90F has a portrait 1600x2560 LCD used in landscape mode, add a quirk for this. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221127181539.104223-1-hdegoede@redhat.com
* drm/gud: Enable synchronous flushing by defaultNoralf Trønnes2022-12-061-8/+4
| | | | | | | | | | | | | | | | | | gud has a module parameter that controls whether framebuffer flushing happens synchronously during the commit or asynchronously in a worker. GNOME before version 3.38 handled all displays in the same rendering loop. This lead to gud slowing down the refresh rate for a faster monitor. This has now been fixed so lets change the default. The plan is to remove async flushing in the future. The code is now structured in a way that makes it easy to do this. Link: https://blogs.gnome.org/shell-dev/2020/07/02/splitting-up-the-frame-clock/ Suggested-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221122-gud-shadow-plane-v2-6-435037990a83@tronnes.org
* drm/gud: Use the shadow plane helperNoralf Trønnes2022-12-063-26/+57
| | | | | | | | | | | | | | | | Use the shadow plane helper to take care of mapping the framebuffer for CPU access. The synchronous flushing is now done inline without the use of a worker. The async path now uses a shadow buffer to hold framebuffer changes and it doesn't read the framebuffer behind userspace's back anymore. v2: - Use src as variable name for iosys_map (Thomas) - Prepare imported buffer for CPU access in the driver (Thomas) Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221122-gud-shadow-plane-v2-5-435037990a83@tronnes.org
* drm/gud: Prepare buffer for CPU access in gud_flush_work()Noralf Trønnes2022-12-061-34/+33
| | | | | | | | | | | | | In preparation for moving to the shadow plane helper prepare the framebuffer for CPU access as early as possible. v2: - Use src as variable name for iosys_map (Thomas) Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221122-gud-shadow-plane-v2-4-435037990a83@tronnes.org
* drm/gud: Split up gud_flush_work()Noralf Trønnes2022-12-061-25/+31
| | | | | | | | | | In preparation for inlining synchronous flushing split out the part of gud_flush_work() that can be shared by the sync and async code paths. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221122-gud-shadow-plane-v2-3-435037990a83@tronnes.org
* drm/gud: Don't retry a failed framebuffer flushNoralf Trønnes2022-12-061-40/+8
| | | | | | | | | | | | | | | | | If a framebuffer flush fails the driver will do one retry by requeing the worker. Currently the worker is used even for synchronous flushing, but a later patch will inline it, so this needs to change. Thinking about how to solve this I came to the conclusion that this retry mechanism was a fix for a problem that was only in the mind of the developer (me) and not something that solved a real problem. So let's remove this for now and revisit later should it become necessary. gud_add_damage() has now only one caller so it can be inlined. Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221122-gud-shadow-plane-v2-2-435037990a83@tronnes.org
* drm/gud: Fix UBSAN warningNoralf Trønnes2022-12-061-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | UBSAN complains about invalid value for bool: [ 101.165172] [drm] Initialized gud 1.0.0 20200422 for 2-3.2:1.0 on minor 1 [ 101.213360] gud 2-3.2:1.0: [drm] fb1: guddrmfb frame buffer device [ 101.213426] usbcore: registered new interface driver gud [ 101.989431] ================================================================================ [ 101.989441] UBSAN: invalid-load in linux/include/linux/iosys-map.h:253:9 [ 101.989447] load of value 121 is not a valid value for type '_Bool' [ 101.989451] CPU: 1 PID: 455 Comm: kworker/1:6 Not tainted 5.18.0-rc5-gud-5.18-rc5 #3 [ 101.989456] Hardware name: Hewlett-Packard HP EliteBook 820 G1/1991, BIOS L71 Ver. 01.44 04/12/2018 [ 101.989459] Workqueue: events_long gud_flush_work [gud] [ 101.989471] Call Trace: [ 101.989474] <TASK> [ 101.989479] dump_stack_lvl+0x49/0x5f [ 101.989488] dump_stack+0x10/0x12 [ 101.989493] ubsan_epilogue+0x9/0x3b [ 101.989498] __ubsan_handle_load_invalid_value.cold+0x44/0x49 [ 101.989504] dma_buf_vmap.cold+0x38/0x3d [ 101.989511] ? find_busiest_group+0x48/0x300 [ 101.989520] drm_gem_shmem_vmap+0x76/0x1b0 [drm_shmem_helper] [ 101.989528] drm_gem_shmem_object_vmap+0x9/0xb [drm_shmem_helper] [ 101.989535] drm_gem_vmap+0x26/0x60 [drm] [ 101.989594] drm_gem_fb_vmap+0x47/0x150 [drm_kms_helper] [ 101.989630] gud_prep_flush+0xc1/0x710 [gud] [ 101.989639] ? _raw_spin_lock+0x17/0x40 [ 101.989648] gud_flush_work+0x1e0/0x430 [gud] [ 101.989653] ? __switch_to+0x11d/0x470 [ 101.989664] process_one_work+0x21f/0x3f0 [ 101.989673] worker_thread+0x200/0x3e0 [ 101.989679] ? rescuer_thread+0x390/0x390 [ 101.989684] kthread+0xfd/0x130 [ 101.989690] ? kthread_complete_and_exit+0x20/0x20 [ 101.989696] ret_from_fork+0x22/0x30 [ 101.989706] </TASK> [ 101.989708] ================================================================================ The source of this warning is in iosys_map_clear() called from dma_buf_vmap(). It conditionally sets values based on map->is_iomem. The iosys_map variables are allocated uninitialized on the stack leading to ->is_iomem having all kinds of values and not only 0/1. Fix this by zeroing the iosys_map variables. Fixes: 40e1a70b4aed ("drm: Add GUD USB Display driver") Cc: <stable@vger.kernel.org> # v5.18+ Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Link: https://patchwork.freedesktop.org/patch/msgid/20221122-gud-shadow-plane-v2-1-435037990a83@tronnes.org
* drm/ttm: use ttm_bo_wait_ctx instead of ttm_bo_waitChristian König2022-12-061-2/+2
| | | | | | | | Make sure that we use the correct settings from the context. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221125102137.1801-8-christian.koenig@amd.com
* drm/ttm: merge ttm_bo_api.h and ttm_bo_driver.h v2Christian König2022-12-0655-556/+409
| | | | | | | | | | | | | | Merge and cleanup the two headers into a single description of the object API. Also move all the documentation to the implementation and drop unnecessary includes from the header. No functional change. v2: minimal checkpatch.pl cleanup Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221125102137.1801-4-christian.koenig@amd.com
* drm/ttm: use per BO cleanup workersChristian König2022-12-068-111/+57
| | | | | | | | | | | | | | Instead of a single worker going over the list of delete BOs in regular intervals use a per BO worker which blocks for the resv object and locking of the BO. This not only simplifies the handling massively, but also results in much better response time when cleaning up buffers. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221125102137.1801-3-christian.koenig@amd.com
* drm/ttm: remove ttm_bo_(un)lock_delayed_workqueueChristian König2022-12-066-46/+3
| | | | | | | | | | | Those functions never worked correctly since it is still perfectly possible that a buffer object is released and the background worker restarted even after calling them. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221125102137.1801-2-christian.koenig@amd.com
* drm/mipi-dbi: Move drm_dev_{enter, exit}() out from fb_dirty functionsThomas Zimmermann2022-12-053-18/+21
| | | | | | | | | | | | Call drm_dev_enter() and drm_dev_exit() in the outer-most callbacks of the modesetting pipeline. If drm_dev_enter() fails, the driver can thus avoid unnecessary work. 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-9-tzimmermann@suse.de
* drm/mipi-dbi: Use shadow-plane mappingsThomas Zimmermann2022-12-053-44/+13
| | | | | | | | | | | | | | | Use the buffer mappings provided by shadow-plane helpers. As the mappings are established while the commit can still fail, errors are now reported correctly to callers. v2: * use shadow-plane state directly (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-8-tzimmermann@suse.de
* drm/mipi-dbi: Support shadow-plane stateThomas Zimmermann2022-12-054-1/+110
| | | | | | | | | | | | | | | | | | | Implement MIPI DBI planes with struct drm_shadow_plane_state, so that the respective drivers can use the vmap'ed GEM-buffer memory. Implement state helpers, the {begin,end}_fb_access helpers and wire up everything. With this commit, MIPI DBI drivers can access the GEM object's memory that is provided by shadow-plane state. The actual changes to drivers are implemented separately. v2: * use shadow-plane state directly (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-7-tzimmermann@suse.de
* drm/mipi-dbi: Prepare framebuffer copy operation in pipe-update helpersThomas Zimmermann2022-12-054-47/+75
| | | | | | | | | | | | | | | | | | | | | 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-059-32/+24
| | | | | | | | | | | | | 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-057-39/+6
| | | | | | | | | | | | | | | | | 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>
* media: uapi: add MEDIA_BUS_FMT_BGR666_1X24_CPADHIJoerg Quinten2022-12-012-1/+39
| | | | | | | | | | Add the BGR666 format MEDIA_BUS_FMT_BGR666_1X24_CPADHI supported by the RaspberryPi. Signed-off-by: Joerg Quinten <aBUGSworstnightmare@gmail.com> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20221013-rpi-dpi-improvements-v3-3-eb76e26a772d@cerno.tech Signed-off-by: Maxime Ripard <maxime@cerno.tech>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-15 02:20:14 +0000