- 16 Apr, 2024 2 commits
-
-
Nícolas F. R. A. Prado authored
Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 8dde6f74 ("drm: bridge: icn6211: Add I2C configuration support") Suggested-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by:
Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240415-anx7625-defer-log-no-dsi-host-v3-2-619a28148e5c@collabora.com
-
Nícolas F. R. A. Prado authored
Given that failing to find a DSI host causes the driver to defer probe, make use of dev_err_probe() to log the reason. This makes the defer probe reason available and avoids alerting userspace about something that is not necessarily an error. Fixes: 26933299 ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host was not found") Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
-
- 15 Apr, 2024 32 commits
-
-
Zack Rusin authored
crc checksums are used to validate the output. Normally they're part of the actual display hardware but on virtual stack there's nothing to automatically generate them. Implement crc generation for the vmwgfx stack. This works only on screen targets, where it's possibly to easily make sure that the guest side contents of the surface matches the host sides output. Just like the vblank support, crc generation can only be enabled via: guestinfo.vmwgfx.vkms_enable = "TRUE" option in the vmx file. Makes IGT's kms_pipe_crc_basic pass and allows a huge number of other IGT tests which require CRC generation of the output to actually run on vmwgfx. Makes it possible to actually validate a lof of the kms and drm functionality with vmwgfx. Signed-off-by:
Zack Rusin <zack.rusin@broadcom.com> Acked-by:
Martin Krastev <martin.krastev@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240412025511.78553-3-zack.rusin@broadcom.com
-
Zack Rusin authored
By default vmwgfx doesn't support vblanking or crc generation which makes it impossible to use various IGT tests to validate vmwgfx. Implement virtual kernel mode setting, which is mainly related to simulated vblank support. Code is very similar to amd's vkms and the vkms module itself, except that it's integrated with vmwgfx three different output technologies - legacy, screen object and screen targets. Make IGT's kms_vblank pass on vmwgfx and allows a lot of other IGT tests to run with vmwgfx. Support for vkms needs to be manually enabled by adding: guestinfo.vmwgfx.vkms_enable = "TRUE" somewhere in the vmx file, otherwise it's off by default. Signed-off-by:
-
Tvrtko Ursulin authored
There is no point in compiling in the list and mutex operations which are only used from the dma-buf debugfs code, if debugfs is not compiled in. Put the code in questions behind some kconfig guards and so save some text and maybe even a pointer per object at runtime when not enabled. Signed-off-by:
Tvrtko Ursulin <tursulin@ursulin.net> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Christian König <christian.koenig@amd.com> Cc: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: linux-kernel@vger.kernel.org Cc: kernel-dev@igalia.com Reviewed-by:
T.J. Mercier <tjmercier@google.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240328145323.68872-1-tursulin@igalia.com
-
Maíra Canal authored
On version 11 of the "drm/panic: Add a drm panic handler" series [1], Thomas suggested to change the name of the function `drm_panic_gem_get_scanout_buffer` to `drm_fb_dma_get_scanout_buffer` and this request was applied on version 12, which is the version that landed [2]. Although the name of the function changed on the C file, it didn't changed on the header file, leading to a compilation error as such: drivers/gpu/drm/imx/ipuv3/ipuv3-plane.c:780:24: error: use of undeclared identifier 'drm_fb_dma_get_scanout_buffer'; did you mean 'drm_panic_gem_get_scanout_buffer'? 780 | .get_scanout_buffer = drm_fb_dma_get_scanout_buffer, | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | drm_panic_gem_get_scanout_buffer ./include/drm/drm_fb_dma_helper.h:23:5: note: 'drm_panic_gem_get_scanout_buffer' declared here 23 | int drm_panic_gem_get_scanout_buffer(struct drm_plane *plane, | ^ 1 error generated. Fix the compilation error by changing `drm_panic_gem_get_scanout_buffer` to `drm_fb_dma_get_scanout_buffer` on the header file. Link: https://lore.kernel.org/dri-devel/20240328120638.468738-1-jfalempe@redhat.com/ [1] Link: https://lore.kernel.org/dri-devel/aea2aa01-7f03-453b-8b30-8f4d90b1b47f@redhat.com/ [2] Fixes: 879b3b65 ("drm/fb_dma: Add generic get_scanout_buffer() for drm_panic") Signed-off-by:Jocelyn Falempe <jfalempe@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240415151013.3210278-1-mcanal@igalia.com
-
Jocelyn Falempe authored
Add support for the drm_panic module, which displays a message to the screen when a kernel panic occurs. v7 * Use drm_for_each_primary_visible_plane() v8: * Replace get_scanout_buffer() logic with drm_panic_set_buffer() (Thomas Zimmermann) v9: * Revert to using get_scanout_buffer() (Sima) * move get_scanout_buffer() to plane helper functions v12: * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) Signed-off-by:
Sui Jingfeng <sui.jingfeng@linux.dev> Tested-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240409163432.352518-10-jfalempe@redhat.comAcked-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jocelyn Falempe authored
Add support for the drm_panic module, which displays a user-friendly message to the screen when a kernel panic occurs. v7: * use drm_panic_gem_get_scanout_buffer() helper v8: * Replace get_scanout_buffer() logic with drm_panic_set_buffer() v9: * Revert to using get_scanout_buffer() (Sima) * move get_scanout_buffer() to plane helper functions v12: * Rename drm_panic_gem_get_scanout_buffer to drm_fb_dma_get_scanout_buffer (Thomas Zimmermann) Signed-off-by:
-
Jocelyn Falempe authored
Add support for the drm_panic module, which displays a message to the screen when a kernel panic occurs. v5: * Also check that the plane is visible and primary. (Thomas Zimmermann) v7: * use drm_for_each_primary_visible_plane() v8: * Replace get_scanout_buffer() logic with drm_panic_set_buffer() (Thomas Zimmermann) v9: * Revert to using get_scanout_buffer() (Sima) * move get_scanout_buffer() to plane helper functions (Thomas Zimmermann) v12: * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) Signed-off-by:
-
Jocelyn Falempe authored
Add support for the drm_panic module, which displays a user-friendly message to the screen when a kernel panic occurs. v8: * Replace get_scanout_buffer() with drm_panic_set_buffer() (Thomas Zimmermann) v9: * Revert to using get_scanout_buffer() (Sima) * move get_scanout_buffer() to plane helper functions (Thomas Zimmermann) v12: * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) Signed-off-by:
-
Jocelyn Falempe authored
This was initialy done for imx6, but should work on most drivers using drm_fb_dma_helper. v8: * Replace get_scanout_buffer() logic with drm_panic_set_buffer() (Thomas Zimmermann) v9: * go back to get_scanout_buffer() * move get_scanout_buffer() to plane helper functions v12: * Rename drm_panic_gem_get_scanout_buffer to drm_fb_dma_get_scanout_buffer (Thomas Zimmermann) * Remove the #ifdef CONFIG_DRM_PANIC, and build it unconditionnaly, as it's a small function. (Thomas Zimmermann) Signed-off-by:
-
Jocelyn Falempe authored
Add a debugfs file, so you can test drm_panic without freezing your machine. This is unsafe, and should be enabled only for developer or tester. To display the drm_panic screen on the device 0: echo 1 > /sys/kernel/debug/dri/0/drm_panic_plane_0 v9: * Create a debugfs file for each plane in the device's debugfs directory. This allows to test for each plane of each GPU independently. Signed-off-by:
-
Jocelyn Falempe authored
Add support for the following formats: DRM_FORMAT_RGB565 DRM_FORMAT_RGBA5551 DRM_FORMAT_XRGB1555 DRM_FORMAT_ARGB1555 DRM_FORMAT_RGB888 DRM_FORMAT_XRGB8888 DRM_FORMAT_ARGB8888 DRM_FORMAT_XBGR8888 DRM_FORMAT_XRGB2101010 DRM_FORMAT_ARGB2101010 v10: * move and simplify the functions from the drm format helper to drm_panic v12: * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) Signed-off-by:
-
Jocelyn Falempe authored
This module displays a user friendly message when a kernel panic occurs. It currently doesn't contain any debug information, but that can be added later. v2 * Use get_scanout_buffer() instead of the drm client API. (Thomas Zimmermann) * Add the panic reason to the panic message (Nerdopolis) * Add an exclamation mark (Nerdopolis) v3 * Rework the drawing functions, to write the pixels line by line and to use the drm conversion helper to support other formats. (Thomas Zimmermann) v4 * Use drm_fb_r1_to_32bit for fonts (Thomas Zimmermann) * Remove the default y to DRM_PANIC config option (Thomas Zimmermann) * Add foreground/background color config option * Fix the bottom lines not painted if the framebuffer height is not a multiple of the font height. * Automatically register the device to drm_panic, if the function get_scanout_buffer exists. (Thomas Zimmermann) v5 * Change the drawing API, use drm_fb_blit_from_r1() to draw the font. * Also add drm_fb_fill() to fill area with background color. * Add draw_pixel_xy() API for drivers that can't provide a linear buffer. * Add a flush() callback for drivers that needs to synchronize the buffer. * Add a void *private field, so drivers can pass private data to draw_pixel_xy() and flush(). v6 * Fix sparse warning for panic_msg and logo. v7 * Add select DRM_KMS_HELPER for the color conversion functions. v8 * Register directly each plane to the panic notifier (Sima) * Add raw_spinlock to properly handle concurrency (Sima) * Register plane instead of device, to avoid looping through plane list, and simplify code. * Replace get_scanout_buffer() logic with drm_panic_set_buffer() (Thomas Zimmermann) * Removed the draw_pixel_xy() API, will see later if it can be added back. v9 * Revert to using get_scanout_buffer() (Sima) * Move get_scanout_buffer() and panic_flush() to the plane helper functions (Thomas Zimmermann) * Register all planes with get_scanout_buffer() to the panic notifier * Use drm_panic_lock() to protect against race (Sima) v10 * Move blit and fill functions back in drm_panic (Thomas Zimmermann). * Simplify the text drawing functions. * Use kmsg_dumper instead of panic_notifier (Sima). v12 * Use array for map and pitch in struct drm_scanout_buffer to support multi-planar format later. (Thomas Zimmermann) * Better indent struct drm_scanout_buffer declaration. (Thomas Zimmermann) Signed-off-by:
-
Daniel Vetter authored
Rough sketch for the locking of drm panic printing code. The upshot of this approach is that we can pretty much entirely rely on the atomic commit flow, with the pair of raw_spin_lock/unlock providing any barriers we need, without having to create really big critical sections in code. This also avoids the need that drivers must explicitly update the panic handler state, which they might forget to do, or not do consistently, and then we blow up in the worst possible times. It is somewhat racy against a concurrent atomic update, and we might write into a buffer which the hardware will never display. But there's fundamentally no way to avoid that - if we do the panic state update explicitly after writing to the hardware, we might instead write to an old buffer that the user will barely ever see. Note that an rcu protected deference of plane->state would give us the the same guarantees, but it has the downside that we then need to protect the plane state freeing functions with call_rcu too. Which would very widely impact a lot of code and therefore doesn't seem worth the complexity compared to a raw spinlock with very tiny critical sections. Plus rcu cannot be used to protect access to peek/poke registers anyway, so we'd still need it for those cases. Peek/poke registers for vram access (or a gart pte reserved just for panic code) are also the reason I've gone with a per-device and not per-plane spinlock, since usually these things are global for the entire display. Going with per-plane locks would mean drivers for such hardware would need additional locks, which we don't want, since it deviates from the per-console takeoverlocks design. Longer term it might be useful if the panic notifiers grow a bit more structure than just the absolute bare EXPORT_SYMBOL(panic_notifier_list) - somewhat aside, why is that not EXPORT_SYMBOL_GPL ... If panic notifiers would be more like console drivers with proper register/unregister interfaces we could perhaps reuse the very fancy console lock with all it's check and takeover semantics that John Ogness is developing to fix the console_lock mess. But for the initial cut of a drm panic printing support I don't think we need that, because the critical sections are extremely small and only happen once per display refresh. So generally just 60 tiny locked sections per second, which is nothing compared to a serial console running a 115kbaud doing really slow mmio writes for each byte. So for now the raw spintrylock in drm panic notifier callback should be good enough. Another benefit of making panic notifiers more like full blown consoles (that are used in panics only) would be that we get the two stage design, where first all the safe outputs are used. And then the dangerous takeover tricks are deployed (where for display drivers we also might try to intercept any in-flight display buffer flips, which if we race and misprogram fifos and watermarks can hang the memory controller on some hw). For context the actual implementation on the drm side is by Jocelyn and this patch is meant to be combined with the overall approach in v7 (v8 is a bit less flexible, which I think is the wrong direction): https://lore.kernel.org/dri-devel/20240104160301.185915-1-jfalempe@redhat.com/ Note that the locking is very much not correct there, hence this separate rfc. Starting from v10, I (Jocelyn) have included this patch in the drm_panic series, and done the corresponding changes. v2: - fix authorship, this was all my typing - some typo oopsies - link to the drm panic work by Jocelyn for context v10: - Use spinlock_irqsave/restore (John Ogness) v11: - Use macro instead of inline functions for drm_panic_lock/unlock (John Ogness) Signed-off-by:
-
Jani Nikula authored
We have DRM_MODE_FMT and DRM_MODE_ARG() macros to allow unified debug printing of modes in any printk-formatted logging. Prefer them over drm_mode_debug_printmodeline(). This allows drm device specific logging of modes, in the right drm debug category, and inline with the rest of the logging instead of split to multiple lines. Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Jani Nikula authored
Prefer drm device based drm_dbg_kms(), drm_err(), drm_WARN_ON() over DRM_DEBUG_KMS(), DRM_ERROR(), and WARN_ON(). Also update encoder, connector, and crtc logging to include the object id and name, where possible. Reviewed-by:
-
Jani Nikula authored
Prefer drm device based drm_dbg_kms() over DRM_DEBUG_KMS(). Reviewed-by:
-
Jani Nikula authored
Switch to drm device based logging and WARNs, and unify connector and crtc logging formats. Pass drm device around a bit more to be able to do this. Drop logging for -ENOMEM. Reviewed-by:
-
Jani Nikula authored
Prefer drm_dbg_kms() and drm_dbg_lease() over DRM_DEBUG_KMS() and DRM_DEBUG() to debug log the drm device info. Fix some debug categories and unify connector logging while at it. v2: Drop superfluous newline Reviewed-by:
-
Jani Nikula authored
Prefer drm_err() and drm_dbg_kms() over DRM_ERROR() and DRM_DEBUG_KMS(). Reviewed-by:
-
Jani Nikula authored
Prefer drm_dbg_kms() over DRM_DEBUG_KMS() to debug log the drm device info. v2: Drop changes to mode printing (Ville) Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> # v1 Link: https://patchwork.freedesktop.org/patch/msgid/8b6a83edd1c3896b9d652b5368702eba5f382a1c.1712568037.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Use a more suitable type to avoid the cast. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
Melissa Wen <mwen@igalia.com> Reviewed-by:
-
Jani Nikula authored
To avoid accessing and parsing the raw EDID with drm_edid_raw(), switch to the struct drm_edid based function to extract product id, and use the drm printer function to debug log it. The underlying assumption is that struct drm_edid_product_id and struct lvds_pnp_id describe identical data, albeit with slightly different member definitions. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
Jani Nikula authored
Add a function to print a decoded EDID vendor and product id to a drm printer, optionally with the raw data. v2: - refactor date printing - use seq_buf to avoid kasprintf() (Ville) - handle week == 0 (Ville) - use be16_to_cpu() on manufacturer_name Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Melissa Wen <mwen@igalia.com> # v1 Reviewed-by:
-
Jani Nikula authored
Add a struct drm_edid based function to get the vendor and product ID from an EDID. Add a separate struct for defining this part of the EDID, with defined byte order for manufacturer name, product code and serial number. v2: Define manufacturer_name as __be16 instead of u8[2] (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by:
-
Arnd Bergmann authored
After my fix yesterday, I ran into another problem of the same kind: aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `drm_dp_dpcd_readb': analogix_dp_core.c:(.text+0x194): undefined reference to `drm_dp_dpcd_read' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `drm_dp_dpcd_writeb': analogix_dp_core.c:(.text+0x214): undefined reference to `drm_dp_dpcd_write' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `analogix_dp_stop_crc': analogix_dp_core.c:(.text+0x4b0): undefined reference to `drm_dp_stop_crc' aarch64-linux-ld: drivers/gpu/drm/bridge/analogix/analogix_dp_core.o: in function `analogix_dp_start_crc': analogix_dp_core.c:(.text+0xbe8): undefined reference to `drm_dp_start_crc' Add the same dependency again to ROCKCHIP_ANALOGIX_DP after checking that nothing else selects the analogix driver. Also add a dependency to DRM_ANALOGIX_DP to make it easier to identifier future problems of this type when they get introduced. Fixes: 0323287d ("drm: Switch DRM_DISPLAY_DP_HELPER to depends on") Fixes: d1ef8fc1 ("drm: fix DRM_DISPLAY_DP_HELPER dependencies") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240405143531.925589-1-arnd@kernel.org
-
Aleksandr Mishin authored
In vc4_hdmi_audio_init() of_get_address() may return NULL which is later dereferenced. Fix this bug by adding NULL check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: bb7d7856 ("drm/vc4: Add HDMI audio support") Signed-off-by:
Aleksandr Mishin <amishin@t-argos.ru> Signed-off-by:
-
Sebastian Wick authored
When extending support for a driver-specific KMS property to additional drivers, we should apply all the requirements for new properties and make sure the semantics are the same and documented. v2: devs of the driver which introduced property shall help and ack Signed-off-by:
Sebastian Wick <sebastian.wick@redhat.com> Acked-by:
-
Erico Nunes authored
Create a simple data struct to hold compatible data so that we don't have to do the casts to void pointer to hold data. Fixes the following warning: drivers/gpu/drm/lima/lima_drv.c:387:13: error: cast to smaller integer type 'enum lima_gpu_id' from 'const void *' Signed-off-by:
Erico Nunes <nunes.erico@gmail.com> Signed-off-by:
Qiang Yu <yuq825@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240401224329.1228468-3-nunes.erico@gmail.com
-
Erico Nunes authored
lima uses a shared interrupt, so the interrupt handlers must be prepared to be called at any time. At driver removal time, the clocks are disabled early and the interrupts stay registered until the very end of the remove process due to the devm usage. This is potentially a bug as the interrupts access device registers which assumes clocks are enabled. A crash can be triggered by removing the driver in a kernel with CONFIG_DEBUG_SHIRQ enabled. This patch frees the interrupts at each lima device finishing callback so that the handlers are already unregistered by the time we fully disable clocks. Signed-off-by:
-
Erico Nunes authored
There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on lima_pm_idle, with a stack dump such as: [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler. Signed-off-by:
-
Erico Nunes authored
In commit 53cb55b2 ("drm/lima: handle spurious timeouts due to high irq latency") a check was added to detect an unexpectedly high interrupt latency timeout. With further investigation it was noted that on Mali-450 the pp bcast irq may also be a trigger of race conditions against the timeout handler, so add it to this check too. Signed-off-by:
-
Erico Nunes authored
This is needed because we want to reset those devices in device-agnostic code such as lima_sched. In particular, masking irqs will be useful before a hard reset to prevent race conditions. Signed-off-by:
-
- 12 Apr, 2024 3 commits
-
-
Arnd Bergmann authored
The alternative stub functions are listed as global, which produces a build failure in some configs: In file included from drivers/accel/qaic/qaic_drv.c:31: drivers/accel/qaic/qaic_debugfs.h:16:5: error: no previous prototype for 'qaic_bootlog_register' [-Werror=missing-prototypes] 16 | int qaic_bootlog_register(void) { return 0; } | ^~~~~~~~~~~~~~~~~~~~~ drivers/accel/qaic/qaic_debugfs.h:17:6: error: no previous prototype for 'qaic_bootlog_unregister' [-Werror=missing-prototypes] 17 | void qaic_bootlog_unregister(void) {} | ^~~~~~~~~~~~~~~~~~~~~~~ drivers/accel/qaic/qaic_debugfs.h:18:6: error: no previous prototype for 'qaic_debugfs_init' [-Werror=missing-prototypes] 18 | void qaic_debugfs_init(struct qaic_drm_device *qddev) {} | ^~~~~~~~~~~~~~~~~ Make them static inline as intended. Fixes: 5f8df5c6 ("accel/qaic: Add bootlog debugfs") Signed-off-by:Jeffrey Hugo <quic_jhugo@quicinc.com> Signed-off-by:
-
Jeffrey Hugo authored
The AIC100 secondary bootloader uses the Sahara protocol for two purposes - loading the runtime firmware images from the host, and offloading crashdumps to the host. The crashdump functionality is only invoked when the AIC100 device encounters a crash and dumps are enabled. Also the collection of the dump is optional - the host can reject collecting the dump. The Sahara protocol contains many features and modes including firmware upload, crashdump download, and client commands. For simplicity, implement the parts of the protocol needed for loading firmware to the device. Fundamentally, the Sahara protocol is an embedded file transfer protocol. Both sides negotiate a connection through a simple exchange of hello messages. After handshaking through a hello message, the device either sends a message requesting images, or a message advertising the memory dump available for the host. For image transfer, the remote device issues a read data request that provides an image (by ID), an offset, and a length. The host has an internal mapping of image IDs to filenames. The host is expected to access the image and transfer the requested chunk to the device. The device can issue additional read requests, or signal that it has consumed enough data from this image with an end of image message. The host confirms the end of image, and the device can proceed with another image by starting over with the hello exchange again. Some images may be optional, and only provided as part of a provisioning flow. The host is not aware of this information, and thus should report an error to the device when an image is not available. The device will evaluate if the image is required or not, and take the appropriate action. Signed-off-by:
Carl Vanderlip <quic_carlv@quicinc.com> Reviewed-by:
Pranjal Ramajor Asha Kanojiya <quic_pkanojiy@quicinc.com> Reviewed-by:
Bjorn Andersson <andersson@kernel.org> Reviewed-by:
Jacek Lawrynowicz <jacek.lawrynowicz@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240322034917.3522388-1-quic_jhugo@quicinc.com
-
Huai-Yuan Liu authored
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but no check is performed. In order to prevent null pointer dereferencing, ensure that mw_state is checked before calling __drm_atomic_helper_connector_reset. Fixes: 8cbc5caf ("drm: mali-dp: Add writeback connector") Signed-off-by:
Huai-Yuan Liu <qq810974084@gmail.com> Signed-off-by:
Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240407063053.5481-1-qq810974084@gmail.com
-
- 11 Apr, 2024 3 commits
-
-
Ville Syrjälä authored
Advertize more suitable cursor sizes via the new SIZE_HINTS plane property. We can't really enumerate all supported cursor sizes on the platforms where the cursor height can vary freely, so for simplicity we'll just expose all square+POT sizes between each platform's min and max cursor limits. Depending on the platform this will give us one of three results: - 64x64,128x128,256x256,512x512 - 64x64,128x128,256x256 - 64x64 Cc: Simon Ser <contact@emersion.fr> Cc: Jonas Ådahl <jadahl@redhat.com> Cc: Daniel Stone <daniel@fooishbar.org> Cc: Sameer Lattannavar <sameer.lattannavar@intel.com> Cc: Sebastian Wick <sebastian.wick@redhat.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
Add a new immutable plane property by which a plane can advertise a handful of recommended plane sizes. This would be mostly exposed by cursor planes as a slightly more capable replacement for the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare a one size fits all limit for the whole device. Currently eg. amdgpu/i915/nouveau just advertize the max cursor size via the cursor size caps. But always using the max sized cursor can waste a surprising amount of power, so a better strategy is desirable. Most other drivers don't specify any cursor size at all, in which case the ioctl code just claims that 64x64 is a great choice. Whether that is actually true is debatable. A poll of various compositor developers informs us that blindly probing with setcursor/atomic ioctl to determine suitable cursor sizes is not acceptable, thus the introduction of the new property to supplant the cursor size caps. The compositor will now be free to select a more optimal cursor size from the short list of options. Note that the reported sizes (either via the property or the caps) make no claims about things such as plane scaling. So these things should only really be consulted for simple "cursor like" use cases. Userspace consumer in the form of mutter seems ready: https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3165 v2: Try to add some docs v3: Specify that value 0 is reserved for future use (basic idea from Jonas) Drop the note about typical hardware (Pekka) v4: Update the docs to indicate the list is "in order of preference" Add a a link to the mutter MR v5: Limit to cursors only for now (Simon) Cc: Jonas Ådahl <jadahl@redhat.com> Cc: Sameer Lattannavar <sameer.lattannavar@intel.com> Reviewed-by:
Simon Ser <contact@emersion.fr> Acked-by:
Daniel Stone <daniels@collabora.com> Acked-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Signed-off-by:
-
Jesse Zhang authored
remove the unsed the paramter in the function ttm_bo_bounce_temp_buffer and ttm_bo_add_move_fence. V2:rebase the patch on top of drm-misc-next (Christian) Signed-off-by:
Jesse Zhang <Jesse.Zhang@amd.com> Reviewed-by:
-
