dri-devel April 2022

dri-devel@lists.freedesktop.org

351 participants
951 discussions

[PATCH] drm: exynos: dsi: Use child panel or bridge find helpers
by Jagan Teki 04 May '22

04 May '22

commit <711c7adc4687> ("drm: exynos: dsi: Use drm panel_bridge API") added devm_drm_of_get_bridge for looking up if child node has panel or bridge. However commit <b089c0a9b14c> ("Revert "drm: of: Lookup if child node has panel or bridge") has reverted panel or bridge child node lookup from devm_drm_of_get_bridge which eventually failed to find the DSI devices in exynos drm dsi driver. So, use the conventional child panel bridge lookup helpers like it does before. Signed-off-by: Jagan Teki <jagan(a)amarulasolutions.com> --- drivers/gpu/drm/exynos/exynos_drm_dsi.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c b/drivers/gpu/drm/exynos/exynos_drm_dsi.c index f067c86b0b12..ec673223d6b7 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_dsi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_dsi.c @@ -25,6 +25,7 @@ #include <drm/drm_atomic_helper.h> #include <drm/drm_bridge.h> #include <drm/drm_mipi_dsi.h> +#include <drm/drm_panel.h> #include <drm/drm_print.h> #include <drm/drm_probe_helper.h> #include <drm/drm_simple_kms_helper.h> @@ -1451,9 +1452,18 @@ static int exynos_dsi_host_attach(struct mipi_dsi_host *host, struct device *dev = dsi->dev; struct drm_encoder *encoder = &dsi->encoder; struct drm_device *drm = encoder->dev; + struct drm_panel *panel; int ret; - dsi->out_bridge = devm_drm_of_get_bridge(dev, dev->of_node, 1, 0); + panel = of_drm_find_panel(device->dev.of_node); + if (!IS_ERR(panel)) { + dsi->out_bridge = devm_drm_panel_bridge_add(dev, panel); + } else { + dsi->out_bridge = of_drm_find_bridge(device->dev.of_node); + if (!dsi->out_bridge) + dsi->out_bridge = ERR_PTR(-EINVAL); + } + if (IS_ERR(dsi->out_bridge)) { ret = PTR_ERR(dsi->out_bridge); DRM_DEV_ERROR(dev, "failed to find the bridge: %d\n", ret); -- 2.25.1

3 4

[PATCH 1/2] Revert "drm: of: Properly try all possible cases for bridge/panel detection"
by Bjorn Andersson 04 May '22

04 May '22

Commit '80253168dbfd ("drm: of: Lookup if child node has panel or bridge")' introduced the ability to describe a panel under a display controller without having to use a graph to connect the controller to its single child panel (or bridge). The implementation of this would find the first non-graph node and attempt to acquire the related panel or bridge. This prevents cases where any other child node, such as a aux bus for a DisplayPort controller, or an opp-table to find the referenced panel. Commit '67bae5f28c89 ("drm: of: Properly try all possible cases for bridge/panel detection")' attempted to solve this problem by not bypassing the graph reference lookup before attempting to find the panel or bridge. While this does solve the case where a proper graph reference is present, it does not allow the caller to distinguish between a yet-to-be-probed panel or bridge and the absence of a reference to a panel. One such case is a DisplayPort controller that on some boards have an explicitly described reference to a panel, but on others have a discoverable DisplayPort display attached (which doesn't need to be expressed in DeviceTree). This reverts commit '67bae5f28c89 ("drm: of: Properly try all possible cases for bridge/panel detection")', as a step towards reverting commit '80253168dbfd ("drm: of: Lookup if child node has panel or bridge")'. Signed-off-by: Bjorn Andersson <bjorn.andersson(a)linaro.org> --- drivers/gpu/drm/drm_of.c | 99 ++++++++++++++++++++-------------------- 1 file changed, 49 insertions(+), 50 deletions(-) diff --git a/drivers/gpu/drm/drm_of.c b/drivers/gpu/drm/drm_of.c index f4df344509a8..026e4e29a0f3 100644 --- a/drivers/gpu/drm/drm_of.c +++ b/drivers/gpu/drm/drm_of.c @@ -214,29 +214,6 @@ int drm_of_encoder_active_endpoint(struct device_node *node, } EXPORT_SYMBOL_GPL(drm_of_encoder_active_endpoint); -static int find_panel_or_bridge(struct device_node *node, - struct drm_panel **panel, - struct drm_bridge **bridge) -{ - if (panel) { - *panel = of_drm_find_panel(node); - if (!IS_ERR(*panel)) - return 0; - - /* Clear the panel pointer in case of error. */ - *panel = NULL; - } - - /* No panel found yet, check for a bridge next. */ - if (bridge) { - *bridge = of_drm_find_bridge(node); - if (*bridge) - return 0; - } - - return -EPROBE_DEFER; -} - /** * drm_of_find_panel_or_bridge - return connected panel or bridge device * @np: device tree node containing encoder output ports @@ -259,44 +236,66 @@ int drm_of_find_panel_or_bridge(const struct device_node *np, struct drm_panel **panel, struct drm_bridge **bridge) { - struct device_node *node; - int ret; + int ret = -EPROBE_DEFER; + struct device_node *remote; if (!panel && !bridge) return -EINVAL; - if (panel) *panel = NULL; - if (bridge) - *bridge = NULL; - - /* Check for a graph on the device node first. */ - if (of_graph_is_present(np)) { - node = of_graph_get_remote_node(np, port, endpoint); - if (node) { - ret = find_panel_or_bridge(node, panel, bridge); - of_node_put(node); - - if (!ret) - return 0; - } - } - /* Otherwise check for any child node other than port/ports. */ - for_each_available_child_of_node(np, node) { - if (of_node_name_eq(node, "port") || - of_node_name_eq(node, "ports")) + /** + * Devices can also be child nodes when we also control that device + * through the upstream device (ie, MIPI-DCS for a MIPI-DSI device). + * + * Lookup for a child node of the given parent that isn't either port + * or ports. + */ + for_each_available_child_of_node(np, remote) { + if (of_node_name_eq(remote, "port") || + of_node_name_eq(remote, "ports")) continue; - ret = find_panel_or_bridge(node, panel, bridge); - of_node_put(node); + goto of_find_panel_or_bridge; + } + + /* + * of_graph_get_remote_node() produces a noisy error message if port + * node isn't found and the absence of the port is a legit case here, + * so at first we silently check whether graph presents in the + * device-tree node. + */ + if (!of_graph_is_present(np)) + return -ENODEV; + + remote = of_graph_get_remote_node(np, port, endpoint); + +of_find_panel_or_bridge: + if (!remote) + return -ENODEV; + + if (panel) { + *panel = of_drm_find_panel(remote); + if (!IS_ERR(*panel)) + ret = 0; + else + *panel = NULL; + } + + /* No panel found yet, check for a bridge next. */ + if (bridge) { + if (ret) { + *bridge = of_drm_find_bridge(remote); + if (*bridge) + ret = 0; + } else { + *bridge = NULL; + } - /* Stop at the first found occurrence. */ - if (!ret) - return 0; } - return -EPROBE_DEFER; + of_node_put(remote); + return ret; } EXPORT_SYMBOL_GPL(drm_of_find_panel_or_bridge); -- 2.35.1

7 40

[PATCH] drm/bridge: tc358767: Fix DP bridge mode detection from DT endpoints
by Marek Vasut 04 May '22

04 May '22

Per toshiba,tc358767.yaml DT binding document, port@2 the output (e)DP port is optional. In case this port is not described in DT, the bridge driver operates in DPI-to-DP mode. Make sure the driver treats this as a valid mode of operation instead of reporting invalid mode. Fixes: 71f7d9c03118 ("drm/bridge: tc358767: Detect bridge mode from connected endpoints in DT") Signed-off-by: Marek Vasut <marex(a)denx.de> Cc: Jonas Karlman <jonas(a)kwiboo.se> Cc: Laurent Pinchart <Laurent.pinchart(a)ideasonboard.com> Cc: Lucas Stach <l.stach(a)pengutronix.de> Cc: Marek Vasut <marex(a)denx.de> Cc: Maxime Ripard <maxime(a)cerno.tech> Cc: Neil Armstrong <narmstrong(a)baylibre.com> Cc: Robert Foss <robert.foss(a)linaro.org> Cc: Sam Ravnborg <sam(a)ravnborg.org> --- drivers/gpu/drm/bridge/tc358767.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/bridge/tc358767.c b/drivers/gpu/drm/bridge/tc358767.c index 7dde71313b84..485717c8f0b4 100644 --- a/drivers/gpu/drm/bridge/tc358767.c +++ b/drivers/gpu/drm/bridge/tc358767.c @@ -1964,7 +1964,9 @@ static int tc_probe_bridge_endpoint(struct tc_data *tc) struct of_endpoint endpoint; struct device_node *node = NULL; const u8 mode_dpi_to_edp = BIT(1) | BIT(2); + const u8 mode_dpi_to_dp = BIT(1); const u8 mode_dsi_to_edp = BIT(0) | BIT(2); + const u8 mode_dsi_to_dp = BIT(0); const u8 mode_dsi_to_dpi = BIT(0) | BIT(1); u8 mode = 0; @@ -1990,11 +1992,11 @@ static int tc_probe_bridge_endpoint(struct tc_data *tc) mode |= BIT(endpoint.port); } - if (mode == mode_dpi_to_edp) + if (mode == mode_dpi_to_edp || mode == mode_dpi_to_dp) return tc_probe_edp_bridge_endpoint(tc); else if (mode == mode_dsi_to_dpi) return tc_probe_dpi_bridge_endpoint(tc); - else if (mode == mode_dsi_to_edp) + else if (mode == mode_dsi_to_edp || mode == mode_dsi_to_dp) dev_warn(dev, "The mode DSI-to-(e)DP is not supported!\n"); else dev_warn(dev, "Invalid mode (0x%x) is not supported!\n", mode); -- 2.35.1

2 1

[PATCH 0/3] Handle predicate programming
by Ramalingam C 04 May '22

04 May '22

Userspace can leave SET_PREDICATE_RESULT active at the end of their batch, causing all the kernel operations from the ring to be noop'ed. This includes workarounds for memory corruption on dg2, as well as the usual synchronisation, arbitration, coherency and signaling. The latter can be used to cause system-wide hangs, prevent TLB invalidates, as well as runtime-pm leakage due to a never signaled fence which escapes hangcheck as the context does run. To avoid the issues caused by allowing userspace to disable kernel execution, we explicitly clear SET_PREDICATE_RESULT but not before recording whether predication was active. By tracking if predication was active at the end of the batch, we can restore it immediately prior to executing the users next batch, preserving the status of the user's predication. And also LRI relative addressing is fixed as part of this series. Akeem G Abodunrin (1): drm/i915/xehpsdv/dg1/tgl: Fix issue with LRI relative addressing Chris Wilson (2): drm/i915/selftests: Skip poisoning SET_PREDICATE_RESULT on dg2 drm/i915/gt: Clear SET_PREDICATE_RESULT prior to executing the ring drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 54 +++++++++++++ drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 7 ++ drivers/gpu/drm/i915/gt/intel_engine_regs.h | 2 + .../drm/i915/gt/intel_execlists_submission.c | 15 +++- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 + drivers/gpu/drm/i915/gt/intel_lrc.c | 75 ++++++++++++++----- drivers/gpu/drm/i915/gt/intel_lrc.h | 5 ++ drivers/gpu/drm/i915/gt/selftest_lrc.c | 53 ++++++++++++- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 + 9 files changed, 189 insertions(+), 26 deletions(-) -- 2.20.1

3 7

[PATCH v2] drm/msm/dsi: use RMW cycles in dsi_update_dsc_timing
by Dmitry Baryshkov 04 May '22

04 May '22

The downstream uses read-modify-write for updating command mode compression registers. Let's follow this approach. This also fixes the following warning: drivers/gpu/drm/msm/dsi/dsi_host.c:918:23: warning: variable 'reg_ctrl' set but not used [-Wunused-but-set-variable] Reported-by: kernel test robot <lkp(a)intel.com> Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- Changes since v1: - Fix c&p error and apply mask clear to reg_ctrl2 instead of reg_ctrl (Abhinav) --- drivers/gpu/drm/msm/dsi/dsi_host.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c b/drivers/gpu/drm/msm/dsi/dsi_host.c index c983698d1384..a95d5df52653 100644 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c @@ -961,10 +961,13 @@ static void dsi_update_dsc_timing(struct msm_dsi_host *msm_host, bool is_cmd_mod reg_ctrl = dsi_read(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL); reg_ctrl2 = dsi_read(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL2); + reg_ctrl &= ~0xffff; reg_ctrl |= reg; + + reg_ctrl2 &= ~DSI_COMMAND_COMPRESSION_MODE_CTRL2_STREAM0_SLICE_WIDTH__MASK; reg_ctrl2 |= DSI_COMMAND_COMPRESSION_MODE_CTRL2_STREAM0_SLICE_WIDTH(bytes_in_slice); - dsi_write(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL, reg); + dsi_write(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL, reg_ctrl); dsi_write(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL2, reg_ctrl2); } else { dsi_write(msm_host, REG_DSI_VIDEO_COMPRESSION_MODE_CTRL, reg); -- 2.35.1

4 19

[PATCH 0/4] mgag200: Improve damage handling
by Jocelyn Falempe 04 May '22

04 May '22

This series improves the damage handling on Matrox gpu, and allows Gnome/Wayland to run much better. Also include some driver cleanup. Tested on a Dell T310 with Matrox MGA G200eW WPCM450 (rev 0a) Thanks, Jocelyn Falempe (4): mgag200: Add FB_DAMAGE_CLIPS support mgag200: Optimize damage clips mgag200: remove unused flag mgag200: remove mgag200_probe_vram() drivers/gpu/drm/mgag200/mgag200_drv.c | 3 +- drivers/gpu/drm/mgag200/mgag200_drv.h | 3 -- drivers/gpu/drm/mgag200/mgag200_mm.c | 50 ++++---------------------- drivers/gpu/drm/mgag200/mgag200_mode.c | 17 ++++++--- 4 files changed, 20 insertions(+), 53 deletions(-) -- 2.35.1 -- Jocelyn

3 12

[PATCH 00/11] drm: bridge: Add Samsung MIPI DSIM bridge
by Jagan Teki 04 May '22

04 May '22

This series supports common bridge support for Samsung MIPI DSIM which is used in Exynos and i.MX8MM SoC's. Previous RFC can be available here [1]. The final bridge supports both the Exynos and i.MX8MM DSI devices. On, summary this patch-set break the entire DSIM driver into - platform specific glue code for platform ops, component_ops. - common bridge driver which handle platform glue init and invoke. Patch 0000: Samsung DSIM bridge Patch 0001: platform init flag via driver_data Patch 0002/9: bridge fixes, atomic API's Patch 0010: document fsl,imx8mm-mipi-dsim Patch 0011: add i.MX8MM DSIM support Tested in Engicam i.Core MX8M Mini SoM. Anyone interested, please have a look on this repo [2] [2] https://github.com/openedev/kernel/tree/imx8mm-dsi-v1 [1] https://lore.kernel.org/linux-arm-kernel/YP2j9k5SrZ2%2Fo2%2F5@ravnborg.org/… Any inputs? Jagan. Jagan Teki (11): drm: bridge: Add Samsung DSIM bridge driver drm: bridge: samsung-dsim: Handle platform init via driver_data drm: bridge: samsung-dsim: Mark PHY as optional drm: bridge: samsung-dsim: Add DSI init in bridge pre_enable() drm: bridge: samsung-dsim: Fix PLL_P (PMS_P) offset drm: bridge: samsung-dsim: Add module init, exit drm: bridge: samsung-dsim: Add atomic_check drm: bridge: samsung-dsim: Add atomic_get_input_bus_fmts drm: bridge: samsung-dsim: Add input_bus_flags dt-bindings: display: exynos: dsim: Add NXP i.MX8MM support drm: bridge: samsung-dsim: Add i.MX8MM support .../bindings/display/exynos/exynos_dsim.txt | 1 + MAINTAINERS | 12 + drivers/gpu/drm/bridge/Kconfig | 12 + drivers/gpu/drm/bridge/Makefile | 1 + drivers/gpu/drm/bridge/samsung-dsim.c | 1803 +++++++++++++++++ drivers/gpu/drm/exynos/Kconfig | 1 + drivers/gpu/drm/exynos/exynos_drm_dsi.c | 1704 +--------------- include/drm/bridge/samsung-dsim.h | 97 + 8 files changed, 1982 insertions(+), 1649 deletions(-) create mode 100644 drivers/gpu/drm/bridge/samsung-dsim.c create mode 100644 include/drm/bridge/samsung-dsim.h -- 2.25.1

6 26

[PATCH 1/3] dma-buf/sync_file: cleanup fence merging a bit
by Christian König 04 May '22

04 May '22

krealloc_array() ignores attempts to reduce the array size, so the attempt to save memory is completely pointless here. Also move testing for the no fence case into sync_file_set_fence(), this way we don't even touch the fence array when we don't have any fences. Signed-off-by: Christian König <christian.koenig(a)amd.com> --- drivers/dma-buf/sync_file.c | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c index 514d213261df..0fe564539166 100644 --- a/drivers/dma-buf/sync_file.c +++ b/drivers/dma-buf/sync_file.c @@ -157,9 +157,15 @@ static int sync_file_set_fence(struct sync_file *sync_file, * we already own a new reference to the fence. For num_fence > 1 * we own the reference of the dma_fence_array creation. */ - if (num_fences == 1) { + + if (num_fences == 0) { + sync_file->fence = dma_fence_get_stub(); + kfree(fences); + + } else if (num_fences == 1) { sync_file->fence = fences[0]; kfree(fences); + } else { array = dma_fence_array_create(num_fences, fences, dma_fence_context_alloc(1), @@ -261,19 +267,6 @@ static struct sync_file *sync_file_merge(const char *name, struct sync_file *a, } } - if (index == 0) - fences[index++] = dma_fence_get_stub(); - - if (num_fences > index) { - struct dma_fence **tmp; - - /* Keep going even when reducing the size failed */ - tmp = krealloc_array(fences, index, sizeof(*fences), - GFP_KERNEL); - if (tmp) - fences = tmp; - } - if (sync_file_set_fence(sync_file, fences, index) < 0) goto err_put_fences; -- 2.25.1

4 8

[PATCH] drm/etnaviv: avoid cleaning up sched_job when submit succeeded
by Lucas Stach 04 May '22

04 May '22

While the labels may mislead the casual reader, the tail of the function etnaviv_ioctl_gem_submit is always executed, as a lot of the structures set up in this function need to be cleaned up regardless of whether the submit succeeded or failed. An exception is the newly added drm_sched_job_cleanup, which must only be called when the submit failed before handing the job to the scheduler. Fixes: b827c84f5e84 ("drm/etnaviv: Use scheduler dependency handling") Reported-by: Michael Walle <michael(a)walle.cc> Signed-off-by: Lucas Stach <l.stach(a)pengutronix.de> --- Daniel, please apply to the appropriate drm-misc branch to make sure this ends up in the same pullrequest as the offending commit. --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c index 98bb5c9239de..bf2a400f59c9 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c @@ -607,7 +607,8 @@ int etnaviv_ioctl_gem_submit(struct drm_device *dev, void *data, args->fence = submit->out_fence_id; err_submit_job: - drm_sched_job_cleanup(&submit->sched_job); + if (ret) + drm_sched_job_cleanup(&submit->sched_job); err_submit_put: etnaviv_submit_put(submit); -- 2.30.2

2 2

[PATCH 0/2] Let userspace know when snd-hda-intel needs i915
by Mauro Carvalho Chehab 04 May '22

04 May '22

Currently, kernel/module annotates module dependencies when request_symbol is used, but it doesn't cover more complex inter-driver dependencies that are subsystem and/or driver-specific. In the case of hdmi sound, depending on the CPU/GPU, sometimes the snd_hda_driver can talk directly with the hardware, but sometimes, it uses the i915 driver. When the snd_hda_driver uses i915, it should first be unbind/rmmod, as otherwise trying to unbind/rmmod the i915 driver cause driver issues, as as reported by CI tools with different GPU models: https://intel-gfx-ci.01.org/tree/drm-tip/IGT_6415/fi-tgl-1115g4/igt@core_ho… https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11495/bat-adlm-1/igt@i915_m… In the past, just a few CPUs were doing such bindings, but this issue now applies to all "modern" Intel CPUs that have onboard graphics, as well as to the newer discrete GPUs. With the discrete GPU case, the HDA controller is physically separate and requires i915 to power on the hardware for all hardware access. In this case, the issue is hit basicly 100% of the time. With on-board graphics, i915 driver is needed only when the display codec is accessed. If i915 is unbind during runtime suspend, while snd-hda-intel is still bound, nothing bad happens, but unbinding i915 on other situations may also cause issues. So, add support at kernel/modules to allow snd-hda drivers to properly annotate when a dependency on a DRM driver dependencies exists, and add a call to such new function at the snd-hda driver when it successfully binds into the DRM driver. This would allow userspace tools to check and properly remove the audio driver before trying to remove or unbind the GPU driver. It should be noticed that this series conveys the hidden module dependencies. Other changes are needed in order to allow removing or unbinding the i915 driver while keeping the snd-hda-intel driver loaded/bound. With that regards, there are some discussions on how to improve this at alsa-devel a while back: https://mailman.alsa-project.org/pipermail/alsa-devel/2021-September/190099… So, future improvements on both in i915 and the audio drivers could be made. E.g. with discrete GPUs, it's the only codec of the card, so it seems feasible to detach the ALSA card if i915 is bound (using infra made for VGA switcheroo), but, until these improvements are done and land in upstream, audio drivers needs to be unbound if i915 driver goes unbind. Yet, even if such fixes got merged, this series is still needed, as it makes such dependencies more explicit and easier to debug. PS.: This series was generated against next-20220428. Luis/Takashi/Daniel/David, If OK for you, I would prefer to have such patches applied via the drm-tip tree once reviewed, in order to make easier to use them by some patches I'm preparing to improve the CI tests that use i915 unbind logic. Mauro Carvalho Chehab (2): module: add a function to add module references ALSA: hda - identify when audio is provided by a video driver include/linux/module.h | 7 +++++++ kernel/module/main.c | 31 +++++++++++++++++++++++++++++++ sound/hda/hdac_component.c | 8 ++++++++ 3 files changed, 46 insertions(+) -- 2.35.1

4 11

← Newer
1
...
9
10
11
12
13
14
15
...
96
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel April 2022