- 18 Apr, 2024 2 commits
-
-
Ville Syrjälä authored
Replace the open coded drm_crtc_vblank_crtc() with the real thing. Cc: Karol Herbst <kherbst@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Danilo Krummrich <dakr@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408190611.24914-4-ville.syrjala@linux.intel.comReviewed-by:
Lyude Paul <lyude@redhat.com>
-
Ville Syrjälä authored
Make life easier by providing a function that hands out the correct drm_vblank_crtc for a given a drm_crtc. Also abstract the lower level internals of the vblank code in a similar fashion. Signed-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
- 17 Apr, 2024 11 commits
-
-
Marek Vasut authored
G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of a TFT LCD panel, a driver circuit, and LED backlight system. The screen format is intended to support the 4:3, 1024(H) x 768(V) screen and either 262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit. All input signals are LVDS interface compatible. Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are effectively identical panels, use the former as RGB 6-bits variant and add the later as RGB 8-bits variant. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf [2] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121XCE-L01_Datasheet.pdfSigned-off-by:
Marek Vasut <marex@denx.de> Acked-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240328102746.17868-4-marex@denx.de
-
Marek Vasut authored
Use display_timing instead of drm_display_mode to define a range of possible display timings supported by this panel. This makes the panel support more flexible and improves compatibility. No functional change is expected. The settings are picked from documentation [1] section 6.1 INPUT SIGNAL TIMING SPECIFICATIONS. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdfSigned-off-by:
-
Marek Vasut authored
The .bpc = 6 implies .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , add the missing bus_format. Add missing connector type and bus_flags as well. Documentation [1] 1.4 GENERAL SPECIFICATI0NS indicates this panel is capable of both RGB 18bit/24bit panel, the current configuration uses 18bit mode, .bus_format = MEDIA_BUS_FMT_RGB666_1X7X3_SPWG , .bpc = 6. Support for the 24bit mode would require another entry in panel-simple with .bus_format = MEDIA_BUS_FMT_RGB666_1X7X4_SPWG and .bpc = 8, which is out of scope of this fix. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf Fixes: f8fa17ba ("drm/panel: simple: Add support for Innolux G121X1-L03") Signed-off-by:
-
Marek Vasut authored
Document support for Innolux CheMei 12" G121XCE-L01 XGA LVDS display. G121XCE-L01 is a Color Active Matrix Liquid Crystal Display composed of a TFT LCD panel, a driver circuit, and LED backlight system. The screen format is intended to support the 4:3, 1024(H) x 768(V) screen and either 262k/16.7M colors (RGB 6-bits or 8-bits) with LED backlight driver circuit. All input signals are LVDS interface compatible. Documentation [1] and [2] indicate that G121X1-L03 and G121XCE-L01 are effectively identical panels, use the former as RGB 6-bits variant and document the later as RGB 8-bits variant. [1] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121X1-L03_Datasheet.pdf [2] https://www.distec.de/fileadmin/pdf/produkte/TFT-Displays/Innolux/G121XCE-L01_Datasheet.pdfSigned-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240328102746.17868-1-marex@denx.de
-
Jani Nikula authored
Repurpose drm_edid_are_equal() to be more helpful for its single user, and rename drm_edid_eq(). Functionally deduce the length from the blob size, not the blob data, making it more robust against any errors. Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1011a285d30babce3aabd8218abb7ece7dcf58a2.1713259151.git.jani.nikula@intel.comSigned-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Jani Nikula authored
drm_edid_are_equal() is only used within drm_edid.c. Make it static. Do not encourage more uses of struct edid. Reviewed-by:
-
Jani Nikula authored
Prefer the EDID iterators over drm_edid_find_extension() in drm_edid_has_cta_extension(), even if this leads to more code. The key is to use the same patterns as much as possible. Reviewed-by:
-
Jani Nikula authored
Follow the drm_edid_ naming convention. Reviewed-by:
-
Jani Nikula authored
Keep the declarations for struct drm_edid based functions together. Reviewed-by:
-
Jani Nikula authored
The declarations for internal EDID functions are a bit scattered. Put them all in drm_crtc_internal.h. Reviewed-by:
-
Jani Nikula authored
There are no exported symbols for displayid, and it's all internal interfaces. Move the header to drivers/gpu/drm/drm_displayd_internal.h. Reviewed-by:
-
- 16 Apr, 2024 11 commits
-
-
Jocelyn Falempe authored
The parameter name is 'sb' and not 'drm_scanout_buffer'. It fixes the following warnings: drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Excess function parameter 'drm_scanout_buffer' description in 'drm_fb_dma_get_scanout_buffer' drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Function parameter or struct member 'sb' not described in 'drm_fb_dma_get_scanout_buffer' drivers/gpu/drm/drm_fb_dma_helper.c:166: warning: Excess function parameter 'drm_scanout_buffer' description in 'drm_fb_dma_get_scanout_buffer' Fixes: 879b3b65 ("drm/fb_dma: Add generic get_scanout_buffer() for drm_panic") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
Jocelyn Falempe <jfalempe@redhat.com> Reviewed-by:
-
Hsin-Te Yuan authored
Previously, the audio status was not updated during detection, leading to a persistent audio despite hot plugging events. To resolve this issue, update the audio status during detection. Fixes: 566fef12 ("drm/bridge: anx7625: add HDMI audio function") Signed-off-by:
Hsin-Te Yuan <yuanhsinte@chromium.org> Reviewed-by:
Robert Foss <rfoss@kernel.org> Signed-off-by:
-
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. Suggested-by:
AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by:
Nícolas F. R. A. Prado <nfraprado@collabora.com> Signed-off-by:
-
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: 623a3531 ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC panels") Suggested-by:
-
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. Also move the "failed to attach" error message so that it's only printed when the devm_mipi_dsi_attach() call fails. Fixes: 6352cd45 ("drm: bridge: Add TI DLPC3433 DSI to DMD bridge") Suggested-by:
-
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: b2697559 ("display/drm/bridge: TC358775 DSI/LVDS driver") Suggested-by:
-
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: 0cbbd5b1 ("drm: bridge: add support for lontium LT9611UXC bridge") Suggested-by:
-
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: 23278bf5 ("drm/bridge: Introduce LT9611 DSI to HDMI bridge") Suggested-by:
-
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: 30e2ae94 ("drm/bridge: Introduce LT8912B DSI to HDMI bridge") Suggested-by:
-
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:
-
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:
-
- 15 Apr, 2024 16 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 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:
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:
-
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:
-
