In a whole pile of panel drivers, we have code to make the
prepare/unprepare/enable/disable callbacks behave as no-ops if they've
already been called. It's silly to have this code duplicated
everywhere. Add it to the core instead so that we can eventually
delete it from all the drivers. Note: to get some idea of the
duplicated code, try:
git grep 'if.*>prepared' -- drivers/gpu/drm/panel
git grep 'if.*>enabled' -- drivers/gpu/drm/panel
NOTE: arguably, the right thing to do here is actually to skip this
patch and simply remove all the extra checks from the individual
drivers. Perhaps the checks were needed at some point in time in the
past but maybe they no longer are? Certainly as we continue
transitioning over to "panel_bridge" then we expect there to be much
less variety in how these calls are made. When we're called as part of
the bridge chain, things should be pretty simple. In fact, there was
some discussion in the past about these checks [1], including a
discussion about whether the checks were needed and whether the calls
ought to be refcounted. At the time, I decided not to mess with it
because it felt too risky.
Looking closer at it now, I'm fairly certain that nothing in the
existing codebase is expecting these calls to be refcounted. The only
real question is whether someone is already doing something to ensure
prepare()/unprepare() match and enabled()/disable() match. I would say
that, even if there is something else ensuring that things match,
there's enough complexity that adding an extra bool and an extra
double-check here is a good idea. Let's add a drm_warn() to let people
know that it's considered a minor error to take advantage of
drm_panel's double-checking but we'll still make things work fine.
We'll also add an entry to the official DRM todo list to remove the
now pointless check from the panels after this patch lands and,
eventually, fixup anyone who is triggering the new warning.
[1] https://lore.kernel.org/r/20210416153909.v4.27.I502f2a92ddd36c3d28d014dd75e170c2d405a0a5@changeid
Acked-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.2.I59b417d4c29151cc2eff053369ec4822b606f375@changeid
As talked about in the patch ("drm/panel: Add a way for other devices
to follow panel state"), touchscreens that are connected to panels are
generally expected to be power sequenced together with the panel
they're attached to. Today, nothing provides information allowing you
to find out that a touchscreen is connected to a panel. Let's add a
phandle for this.
The proerty is added to the generic touchscreen bindings and then
enabled in the bindings for the i2c-hid backed devices. This can and
should be added for other touchscreens in the future, but for now
let's start small.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Benjamin Tissoires <bentiss@kernel.org>
Acked-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727101636.v4.1.Id68e30343bb1e11470582a9078b086176cfec46b@changeid
A very basic debugging rule when a device is connected for the first
time is to access a read-only register which contains known data in
order to ensure the communication protocol is properly working. This
driver lacked any read helper which is often a critical piece for
speeding-up bring-ups.
Add a read helper and use it to verify the communication with the panel
is working as soon as possible in order to inform the user early if this
is not the case.
As this panel may work with no MISO line, the check is discarded in this
case. Upon error, we do not fail probing but just warn the user, in case
the DT description would be lacking the Rx bus width (which is likely on
old descriptions) in order to avoid breaking existing devices.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Sebastian Reichel <sre@kernel.org> # no MISO line
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-20-sre@kernel.org
This panel from Emerging Display Technologies Corporation features an
ST7789V2 LCD controller panel inside which is almost identical to what
the Sitronix panel driver supports.
In practice, the module physical size is specific, and experiments show
that the display will malfunction if any of the following situation
occurs:
* Pixel clock is above 3MHz
* Pixel clock is not inverted
I could not properly identify the reasons behind these failures, scope
captures show valid input signals.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-19-sre@kernel.org
The Sitronix datasheet explains BIT(1) of the RGBCTRL register as the
DOTCLK/PCLK edge used to sample the data lines:
“0” The data is input on the positive edge of DOTCLK
“1” The data is input on the negative edge of DOTCLK
IOW, this bit implies a falling edge and not a high state. Correct the
definition to ease the comparison with the datasheet.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-18-sre@kernel.org
The Sitronix controller expects 9-bit words, provide this as default at
probe time rather than specifying this in each and every access.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-17-sre@kernel.org
The ST7789V LCD controller supports regular SPI wiring, as well as no Rx
data line at all. The operating system needs to know whether it can read
registers from the device or not. Let's detail this specific design
possibility by bounding the spi-rx-bus-width property.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-16-sre@kernel.org
The ST7789V LCD controller is also embedded in the ET028013DMA
panel. Add a compatible string to describe this other panel.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-15-sre@kernel.org
UNI-T UTi260b has a Inanbo T28CP45TN89 v17 panel. I could not find
proper documentation for the panel apart from a technical drawing, but
according to the vendor U-Boot it is based on a Sitronix st7789v chip.
I generated the init sequence by modifying the default one until proper
graphics output has been seen on the device.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-14-sre@kernel.org
Add polarity information via mode and bus flags, so that they are no
longer hardcoded and forward the information to the DRM stack. This is
required for adding panels with different settings.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-13-sre@kernel.org
While the default panel uses invert mode, some panels
require non-invert mode instead.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-12-sre@kernel.org
Add support for describing the media bus format in the
panel configuration and expose that to userspace. Since
both supported formats (RGB565 and RGB666) are using 6
bits per color also hardcode that information.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-11-sre@kernel.org
Move the panel size information to the mode struct, so
that different panel sizes can be specified depending
on the panel type.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-10-sre@kernel.org
Avoid hard-coding the default_mode and supply it from match data. One
additional layer of abstraction has been introduced, which will be
needed for specifying other panel information (e.g. bus flags) in the
next steps.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-9-sre@kernel.org
Improve error handling in the probe routine, so that probe
defer errors are captured in /sys/kernel/debug/devices_deferred
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-8-sre@kernel.org
st7789v_spi_write initializes a message with just
a single transfer, spi_sync_transfer can be used
for that.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-7-sre@kernel.org
The reset pin might not be software controllable from the SoC,
so make it optional.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-6-sre@kernel.org
ST7789V_COLMOD_RGB_FMT_18BITS and ST7789V_COLMOD_CTRL_FMT_18BITS
are unused in favour of MIPI_DCS_PIXEL_FMT_18BIT, remove them.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-5-sre@kernel.org
Add compatible value for Inanbo t28cp45tn89 and make reset GPIO non
mandatory, since it might not be connected to the CPU.
Reviewed-by: Michael Riesch <michael.riesch@wolfvision.net>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230714013756.1546769-3-sre@kernel.org
Add sync object DRM UAPI support to VirtIO-GPU driver. Sync objects
support is needed by native context VirtIO-GPU Mesa drivers, it also will
be used by Venus and Virgl contexts.
Reviewed-by; Emil Velikov <emil.velikov@collabora.com>
Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Tested-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com> # amdgpu nctx
Tested-by: Rob Clark <robdclark@gmail.com> # freedreno nctx
Reviewed-by: Rob Clark <robdclark@gmail.com>
Acked-by: Gurchetan Singh <gurchetansingh@chromium.org>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-4-dmitry.osipenko@collabora.com
Deferred-I/O generator macros generate callbacks for struct fb_ops
that operate on memory ranges in I/O address space or system address
space. Rename the macros to use the _IOMEM_ and _SYSMEM_ infixes of
their underlying helpers. Adapt all users. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230729193157.15446-5-tzimmermann@suse.de
Change the infix for fbdev's DMA-memory helpers from _DMA_ to
_DMAMEM_. The helpers perform operations within DMA-able memory,
but they don't perform DMA operations. Naming should make this
clear. Adapt all users. No functional changes.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230729193157.15446-4-tzimmermann@suse.de
Change the infix for fbdev's system-memory helpers from _SYS_ to
_SYSMEM_. The helpers perform operations within system memory, but
not on the state of the operating system itself. Naming should make
this clear. Adapt all users. No functional changes.
Suggested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230729193157.15446-3-tzimmermann@suse.de
Change the infix for fbdev's I/O-memory helpers from _IO_ to _IOMEM_
to distiguish them from other types of I/O, such as file operations.
The helpers operate on memory ranges in the I/O address space and the
naming should make this clear. Adapt all users. No functional changes.
Suggested-by: Helge Deller <deller@gmx.de>
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Acked-by: Helge Deller <deller@gmx.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20230729193157.15446-2-tzimmermann@suse.de
The connector type and pixel format are missing for this panel,
add them to prevent various drivers from failing to determine
either of those parameters.
Fixes: 7ee933a1d5 ("drm/panel: simple: Add support for AUO T215HVN01")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230709134914.449328-1-marex@denx.de
This driver support the Startek KD070FHFID015, which is a 7-inch TFT LCD
display using MIPI DSI interface.
Signed-off-by: Guillaume La Roque <glaroque@baylibre.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230711-startek_display-v4-2-fb1d53bfdef6@baylibre.com
Specify bpc value for the powertip_ph800480t013_idf02 panel to stop drm
code from complaining about unexpected bpc value (0).
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230727172445.1548834-1-dmitry.baryshkov@linaro.org
The newly added driver only builds when DRM_DISPLAY_DP_HELPER is enabled:
x86_64-linux-ld: drivers/gpu/drm/panel/panel-visionox-r66451.o: in function `visionox_r66451_enable':
panel-visionox-r66451.c:(.text+0x105): undefined reference to `drm_dsc_pps_payload_pack'
Select both CONFIG_DRM_DISPLAY_DP_HELPER and CONFIG_DRM_DISPLAY_HELPER to
ensure the helper function is always available.
Fixes: a6dfab2738 ("drm/panel: Add driver for Visionox r66451 panel")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230719130940.659837-1-arnd@kernel.org
We've had a couple of tests that weren't really obvious, nor did they
document what they were supposed to test. Document that to make it
hopefully more obvious.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Link: https://lore.kernel.org/r/20230728-kms-kunit-actions-rework-v3-11-952565ccccfe@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Now that we have a helper that takes care of an atomic state allocation
and cleanup, we can migrate to it to simplify our tests.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Link: https://lore.kernel.org/r/20230728-kms-kunit-actions-rework-v3-10-952565ccccfe@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
The *_mock_device functions allocate a DRM device that needs to be
released using drm_dev_unregister.
Now that we have a kunit release action API, we can switch to it and
don't require any kind of garbage collection from the caller.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Link: https://lore.kernel.org/r/20230728-kms-kunit-actions-rework-v3-8-952565ccccfe@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Remove it.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Link: https://lore.kernel.org/r/20230728-kms-kunit-actions-rework-v3-7-952565ccccfe@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
As we gain more tests, boilerplate to allocate an atomic state and free
it starts to be there more and more as well.
In order to reduce the allocation boilerplate, we can create a helper
to create that atomic state, and call an action when the test is done.
This will also clean up the exit path.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Link: https://lore.kernel.org/r/20230728-kms-kunit-actions-rework-v3-6-952565ccccfe@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
As we get more and more tests, the locking context initialisation
creates more and more boilerplate, both at creation and destruction.
Let's create a helper that will allocate, initialise a context, and
register kunit actions to clean up once the test is done.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Link: https://lore.kernel.org/r/20230728-kms-kunit-actions-rework-v3-5-952565ccccfe@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Remove it.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Link: https://lore.kernel.org/r/20230728-kms-kunit-actions-rework-v3-4-952565ccccfe@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Remove it.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Link: https://lore.kernel.org/r/20230728-kms-kunit-actions-rework-v3-3-952565ccccfe@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Calling drm_kunit_helper_free_device() to clean up the resources
allocated by drm_kunit_helper_alloc_device() is now optional and not
needed in most cases.
Remove it.
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Maíra Canal <mairacanal@riseup.net>
Link: https://lore.kernel.org/r/20230728-kms-kunit-actions-rework-v3-2-952565ccccfe@kernel.org
Signed-off-by: Maxime Ripard <mripard@kernel.org>
When building with W=1, the following warning occurs.
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c:48:17: warning: ‘anx781x_i2c_addresses’ defined but not used [-Wunused-const-variable=] static const u8 anx781x_i2c_addresses[] = {
^~~~~~~~~~~~~~~~~~~~~
drivers/gpu/drm/bridge/analogix/analogix-anx78xx.c:40:17: warning: ‘anx7808_i2c_addresses’ defined but not used [-Wunused-const-variable=] static const u8 anx7808_i2c_addresses[] = {
When CONFIG_IO is disabled, above two variables are not used,
since the place where it is used is inclueded in the macro
CONFIG_OF.
Even for drivers that do not depend on CONFIG_OF, it's almost
always better to leave out the of_match_ptr(), since the only
thing it can possibly do is to save a few bytes of .text if a
driver can be used both with and without it. Hence we remove
all of_match_ptr() used in other places.
Fixes: 0647e7dd3f ("drm/bridge: Add Analogix anx78xx support")
Signed-off-by: Zhu Wang <wangzhu9@huawei.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20230731021345.219588-1-wangzhu9@huawei.com
