Move the "exit sleep mode" and "set display on" command from
enable() to init() function.
As mentioned in the patch:
https://lore.kernel.org/all/20240624141926.5250-2-lvzhaoxiong@huaqin.corp-partner.google.com/
The Mediatek Soc DSI host has different modes in prepare() and
enable() functions, prepare() is in LP mode and enable() is in
HS mode. Since the "exit sleep mode" and "set display on"
command must also be sent in LP mode, so we also move "exit
sleep mode" and "set display on" command to the init() function.
We have no other actions in the enable() function after moves
"exit sleep mode" and "set display on", and we checked the call
of the enable() function during the "startup" process. It seems
that only one judgment was made in drm_panel_enabel(). If the
panel does not define enable(), the judgment will skip the
enable() and continue execution. This does not seem to have
any other effect, and we found that some drivers also seem
to have no enable() function added, for example:
panel-asus-z00t-tm5p5-n35596 / panel-boe-himax8279d...
In addition, we briefly tested the kingdisplay_kd101ne3 panel and
melfas_lmfbx101117480 panel, and it seems that there is no garbage
on the panel, so we delete enable() function.
After moving the "exit sleep mode" and "set display on" command
to the init() function, we no longer need additional delay
judgment, so we delete variables "exit_sleep_to_display_on_delay_ms"
and "display_on_delay_ms".
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Zhaoxiong Lv <lvzhaoxiong@huaqin.corp-partner.google.com>
Acked-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Link: https://lore.kernel.org/r/20240807100429.13260-2-lvzhaoxiong@huaqin.corp-partner.google.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240807100429.13260-2-lvzhaoxiong@huaqin.corp-partner.google.com
The RG28XX panel is a display panel of the Anbernic RG28XX, a handheld
gaming device from Anbernic. It is 2.8 inches in size (diagonally) with
a resolution of 480x640.
This panel is driven by a variant of the ST7701 driver IC internally,
confirmed by dumping and analyzing its BSP initialization sequence
by using a logic analyzer. It is very similar to the existing
densitron,dmt028vghmcmi-1a panel, but differs in some unknown
register values, so add a new entry for the panel to distinguish them.
Additionally, the panel only has an SPI instead of MIPI DSI.
So add and modify for SPI as well.
Although a panel connected via SPI with a D/CX pin theoretically exists,
no such panels have been found for this driver yet. Therefore, disable
the use of the dc-gpios property for all currently known devices.
Signed-off-by: Hironori KIKUCHI <kikuchan98@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com>
Link: https://lore.kernel.org/r/20240804061503.881283-4-kikuchan98@gmail.com
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240804061503.881283-4-kikuchan98@gmail.com
There's no need to get the length of an DT array property before
parsing the array. of_property_read_variable_u8_array() takes a minimum
and maximum length and returns the actual length (or error code).
This is part of a larger effort to remove callers of of_get_property()
and similar functions. of_get_property() leaks the DT property data
pointer which is a problem for dynamically allocated nodes which may
be freed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240731201407.1838385-4-robh@kernel.org
If the bridge is attached with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
this driver won't initialize a connector and hence display mode won't be
validated in drm_connector_helper_funcs::mode_valid(). So, move the mode
validation from drm_connector_helper_funcs::mode_valid() to
drm_bridge_funcs::mode_valid(), because the mode validation is always done
for the bridge.
Fixes: 30e2ae943c ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240813091637.1054586-1-victor.liu@nxp.com
Add max_tmds_clock validation to prepare for additions and changes to
the MPLL config table. Use the same rate restrictions that is currently
applied.
The rate limit for RK3288, RK3399 and RK3568 is based on current mpll
table. The rate limit for RK3228 and RK3328 is based on the
inno-hdmi-phy pre-pll table.
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240615170417.3134517-7-jonas@kwiboo.se
EDID cannot be read on RK3328 until after read_hpd has been called and
correct io voltage has been configured based on connection status.
When a forced mode is used, e.g. video=1920x1080@60e, the connector
detect ops, that in turn normally calls the read_hpd, never gets called.
This result in reading EDID to fail in connector get_modes ops.
Call dw_hdmi_rk3328_read_hpd at end of dw_hdmi_rk3328_setup_hpd to
correct io voltage and allow reading EDID after setup_hpd.
Fixes: 1c53ba8f22 ("drm/rockchip: dw_hdmi: add dw-hdmi support for the rk3328")
Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240615170417.3134517-5-jonas@kwiboo.se
The mpll_cfg, cur_ctr and phy_config members in struct dw_hdmi_plat_data
are only used to configure the Synopsys PHYs supported internally by DW
HDMI transmitter driver (gpu/drm/bridge/synopsys/dw-hdmi.c), via
hdmi_phy_configure_dwc_hdmi_3d_tx(), which is further invoked from
dw_hdmi_phy_init(). This is part of the internal
dw_hdmi_synopsys_phy_ops struct, managed within dw_hdmi_detect_phy().
To handle vendor PHYs, DW HDMI driver doesn't make use of the internal
PHY ops and, instead, relies on the glue layer to provide the phy_ops
and phy_name members of struct dw_hdmi_plat_data.
Drop the unnecessary assignments of DW internal PHY related members from
structs rk3228_hdmi_drv_data and rk3328_hdmi_drv_data, since both set
the phy_force_vendor flag and correctly provide the expected vendor PHY
data.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240813-dw-hdmi-rockchip-cleanup-v1-4-b3e73b5f4fd6@collabora.com
The RK3066 VOP sets a dma_stop bit when it's done scanning out a frame
and needs the driver to acknowledge that by clearing the bit.
Unless we clear it "between" frames, the RGB output only shows noise
instead of the picture. atomic_flush is the place for it that least
affects other code (doing it on vblank would require converting all
other usages of the reg_lock to spin_(un)lock_irq, which would affect
performance for everyone).
This seems to be a redundant synchronization mechanism that was removed
in later iterations of the VOP hardware block.
Fixes: f4a6de855e ("drm: rockchip: vop: add rk3066 vop definitions")
Cc: stable@vger.kernel.org
Signed-off-by: Val Packett <val@packett.cool>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20240624204054.5524-2-val@packett.cool
GitHub Dependabot has issued the following alert:
"Upgrade setuptools to version 70.0.0 or later.
A vulnerability in the package_index module of pypa/setuptools
versions up to 69.1.1 allows for remote code execution via its
download functions. These functions, which are used to download
packages from URLs provided by users or retrieved from package
index servers, are susceptible to code injection. If these
functions are exposed to user-controlled inputs, such as package
URLs, they can execute arbitrary commands on the system. The
issue is fixed in version 70.0.
Severity: 8.8 / 10 (High)
Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: Required
Scope: Unchanged
Confidentiality: High
Integrity: High
Availability: High
CVE ID: CVE-2024-6345"
To avoid disturbing everyone with the kernel repo hosted on GitHub,
I suggest we upgrade our python dependencies once again to appease
GitHub Dependabot.
Link: https://github.com/dependabot
Signed-off-by: WangYuli <wangyuli@uniontech.com>
Acked-by: Helen Koike <helen.koike@collabora.com>
Signed-off-by: Helen Koike <helen.koike@collabora.com>
Link: https://patchwork.freedesktop.org/patch/msgid/0237854884D6DB3C+20240716083743.33415-1-wangyuli@uniontech.com
