Re: [PATCH v2 1/3] dt-bindings: vendor-prefixes: Add PrimeView
Hi, On Thu, 06 Jun 2024 10:01:02 +0200, Primoz Fiser wrote: > The Prime View International (PVI) is a LCD panel manufacturer. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/3] dt-bindings: vendor-prefixes: Add PrimeView https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/3b37a419b710797138c31c0f41c2a7d8aa9f62cd [2/3] dt-bindings: display: simple: Add PrimeView PM070WL4 panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/d046611a6187379c19c58d928f342c6884fcbbe7 [3/3] drm/panel: simple: Add PrimeView PM070WL4 support https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/8d1330d24788e1e28f6939779391ce835f19fbd2 -- Neil
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On 06/06/2024 13:23, Maxime Ripard wrote: On Thu, Jun 06, 2024 at 11:37:31AM GMT, Neil Armstrong wrote: On 06/06/2024 11:32, Maxime Ripard wrote: On Fri, May 31, 2024 at 09:12:14AM GMT, Ryan Walklin wrote: The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a number of handheld gaming devices made by Anbernic. By consensus a vendor prefix is not provided as the panel OEM is unknown. Where has this consensus been found? I had a look at the previous discussions, and I can't find any consensus being reached there. And for that kind of thing, having the ack or review of any of the DT maintainers would have been great. There was a consensus with Conor, this is why he acked v2, see https://lore.kernel.org/all/20240525-velvet-citable-a45dd06847a7@spud/ It's probably a matter of semantics here, but if it's with only one person, it's not a consensus but an agreement. ``` I think if we genuinely do not know what the vendor is then we just don't have a prefix. ``` And even then, I don't interpret Conor's statement as a formal agreement but rather an acknowledgment of the issue. Well since both maintainers (DT and Panel) agreed, isn't it all good ? I agree with Conor so I applied the patchset after Connor reviewed it and the comment was fixed in v3: https://lore.kernel.org/all/20240530-satchel-playgroup-e8aa6937b8b9@spud/ Yeah, I know. Still, it's a major deviation to what we've always been doing, getting the DT maintainers voice on that would have been a good idea. I consider Conor's voice enough as one of the DT maintainers. Neil Maxime
Re: [PATCH v3 1/2] dt-bindings: display: panel: Add WL-355608-A8 panel
On 06/06/2024 11:32, Maxime Ripard wrote: On Fri, May 31, 2024 at 09:12:14AM GMT, Ryan Walklin wrote: The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a number of handheld gaming devices made by Anbernic. By consensus a vendor prefix is not provided as the panel OEM is unknown. Where has this consensus been found? I had a look at the previous discussions, and I can't find any consensus being reached there. And for that kind of thing, having the ack or review of any of the DT maintainers would have been great. There was a consensus with Conor, this is why he acked v2, see https://lore.kernel.org/all/20240525-velvet-citable-a45dd06847a7@spud/ ``` I think if we genuinely do not know what the vendor is then we just don't have a prefix. ``` I agree with Conor so I applied the patchset after Connor reviewed it and the comment was fixed in v3: https://lore.kernel.org/all/20240530-satchel-playgroup-e8aa6937b8b9@spud/ For this kind of cases, we usually use the device it's attached to as the vendor, so anbernic in this case. Can you send a followup patch? Maxime Neil
Re: [PATCH v2] [drm/meson] meson_plane: Add error handling v2(re-aligned)
Hi, On Wed, 29 Nov 2023 03:34:05 -0800, Haoran Liu wrote: > This patch adds robust error handling to the meson_plane_create > function in drivers/gpu/drm/meson/meson_plane.c. The function > previously lacked proper handling for potential failure scenarios > of the drm_universal_plane_init call. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] meson_plane: Add error handling v2(re-aligned) https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/3c28b239620e249b68beeca17f429e317fa6b8d4 -- Neil
Re: [PATCH v2 3/3] drm/panel: simple: Add PrimeView PM070WL4 support
On 06/06/2024 10:01, Primoz Fiser wrote:
Add support for PrimeView PM070WL4 7.0" (800x480) TFT-LCD panel.
Datasheet can be found at [1].
[1] https://www.beyondinfinite.com/lcd/Library/Pvi/PM070WL4-V1.0.pdf
Signed-off-by: Primoz Fiser
---
Changes in v2:
- sort alphabetically
drivers/gpu/drm/panel/panel-simple.c | 29
1 file changed, 29 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index dcb6d0b6ced0..80cca841db15 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3567,6 +3567,32 @@ static const struct panel_desc
powertip_ph800480t013_idf02 = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct drm_display_mode primeview_pm070wl4_mode = {
+ .clock = 32000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 42,
+ .hsync_end = 800 + 42 + 128,
+ .htotal = 800 + 42 + 128 + 86,
+ .vdisplay = 480,
+ .vsync_start = 480 + 10,
+ .vsync_end = 480 + 10 + 2,
+ .vtotal = 480 + 10 + 2 + 33,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc primeview_pm070wl4 = {
+ .modes = _pm070wl4_mode,
+ .num_modes = 1,
+ .bpc = 6,
+ .size = {
+ .width = 152,
+ .height = 91,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH | DRM_BUS_FLAG_PIXDATA_SAMPLE_POSEDGE,
+ .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+ .connector_type = DRM_MODE_CONNECTOR_DPI,
+};
+
static const struct drm_display_mode qd43003c0_40_mode = {
.clock = 9000,
.hdisplay = 480,
@@ -4725,6 +4751,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "powertip,ph800480t013-idf02",
.data = _ph800480t013_idf02,
+ }, {
+ .compatible = "primeview,pm070wl4",
+ .data = _pm070wl4,
}, {
.compatible = "qiaodian,qd43003c0-40",
.data = _40,
Reviewed-by: Neil Armstrong
Re: [PATCH v2] [drm/meson] meson_plane: Add error handling v2(re-aligned)
On 29/11/2023 12:34, Haoran Liu wrote:
This patch adds robust error handling to the meson_plane_create
function in drivers/gpu/drm/meson/meson_plane.c. The function
previously lacked proper handling for potential failure scenarios
of the drm_universal_plane_init call.
Signed-off-by: Haoran Liu
---
drivers/gpu/drm/meson/meson_plane.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_plane.c
b/drivers/gpu/drm/meson/meson_plane.c
index 815dfe30492b..b43ac61201f3 100644
--- a/drivers/gpu/drm/meson/meson_plane.c
+++ b/drivers/gpu/drm/meson/meson_plane.c
@@ -534,6 +534,7 @@ int meson_plane_create(struct meson_drm *priv)
struct meson_plane *meson_plane;
struct drm_plane *plane;
const uint64_t *format_modifiers = format_modifiers_default;
+ int ret;
meson_plane = devm_kzalloc(priv->drm->dev, sizeof(*meson_plane),
GFP_KERNEL);
@@ -548,12 +549,16 @@ int meson_plane_create(struct meson_drm *priv)
else if (meson_vpu_is_compatible(priv, VPU_COMPATIBLE_G12A))
format_modifiers = format_modifiers_afbc_g12a;
- drm_universal_plane_init(priv->drm, plane, 0xFF,
-_plane_funcs,
-supported_drm_formats,
-ARRAY_SIZE(supported_drm_formats),
-format_modifiers,
-DRM_PLANE_TYPE_PRIMARY, "meson_primary_plane");
+ ret = drm_universal_plane_init(priv->drm, plane, 0xFF,
+ _plane_funcs,
+ supported_drm_formats,
+ ARRAY_SIZE(supported_drm_formats),
+ format_modifiers,
+ DRM_PLANE_TYPE_PRIMARY,
"meson_primary_plane");
+ if (ret) {
+ devm_kfree(priv->drm->dev, meson_plane);
+ return ret;
+ }
drm_plane_helper_add(plane, _plane_helper_funcs);
Reviewed-by: Neil Armstrong
Re: [PATCH 13/14] drm/bridge: synopsys: Add DW HDMI QP TX controller driver
On 05/06/2024 12:11, Cristian Ciocaltea wrote:
On 6/5/24 12:34 AM, Cristian Ciocaltea wrote:
On 6/4/24 11:41 PM, Sam Ravnborg wrote:
Hi Cristian.
On Tue, Jun 04, 2024 at 10:32:04PM +0300, Cristian Ciocaltea wrote:
Hi Sam,
On 6/1/24 5:32 PM, Sam Ravnborg wrote:
Hi Cristian,
a few drive-by comments below.
Sam
+
+static const struct drm_connector_funcs dw_hdmi_qp_connector_funcs = {
+ .fill_modes = drm_helper_probe_single_connector_modes,
+ .detect = dw_hdmi_connector_detect,
+ .destroy = drm_connector_cleanup,
+ .force = dw_hdmi_qp_connector_force,
+ .reset = drm_atomic_helper_connector_reset,
+ .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int dw_hdmi_qp_bridge_attach(struct drm_bridge *bridge,
+ enum drm_bridge_attach_flags flags)
+{
+ struct dw_hdmi *hdmi = bridge->driver_private;
+
+ if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)
+ return drm_bridge_attach(bridge->encoder, hdmi->next_bridge,
+bridge, flags);
+
+ return dw_hdmi_connector_create(hdmi, _hdmi_qp_connector_funcs);
+}
Are there any users left that requires the display driver to create the
connector?
In other words - could this driver fail if DRM_BRIDGE_ATTACH_NO_CONNECTOR
is not passed and drop dw_hdmi_connector_create()?
I did not try to verify this - just a naive question.
I've just tested this and it doesn't work - dw_hdmi_connector_create()
is still needed.
Hmm, seems the display driver or some other bridge driver fails to
support "DRM_BRIDGE_ATTACH_NO_CONNECTOR".
what other drivers are involved?
Could it be related to the glue driver (updated in the next patch) which
is also responsible for setting up the encoder?
Note that my comments here should be seen as potential future
improvements, and do not block the patch from being used.
Thanks for the heads up! Will try to get back to this soon and investigate.
IIUC, modern bridges should not create the connector but rely on display
drivers to take care of, which in this case is the VOP2 driver. However,
it also handles some of the older SoCs relying on the non-QP variant of
DW HDMI IP. Hence the existing dw-hdmi driver would be also impacted in
order to come up with a proper solution.
A quick check shows there are several users of this IP:
$ git grep -E '= dw_hdmi_(bind|probe)\('
drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c:hdmi->dw_hdmi =
dw_hdmi_probe(pdev, plat_data);
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c: hdmi = dw_hdmi_probe(pdev,
plat_data);
drivers/gpu/drm/imx/ipuv3/dw_hdmi-imx.c:hdmi->hdmi = dw_hdmi_probe(pdev,
match->data);
drivers/gpu/drm/ingenic/ingenic-dw-hdmi.c: hdmi = dw_hdmi_probe(pdev,
_dw_hdmi_plat_data);
drivers/gpu/drm/meson/meson_dw_hdmi.c: meson_dw_hdmi->hdmi = dw_hdmi_probe(pdev,
_dw_hdmi->dw_plat_data);
drivers/gpu/drm/renesas/rcar-du/rcar_dw_hdmi.c: hdmi = dw_hdmi_probe(pdev,
_dw_hdmi_plat_data);
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c:hdmi->hdmi =
dw_hdmi_bind(pdev, encoder, plat_data);
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c: hdmi->hdmi = dw_hdmi_bind(pdev,
encoder, plat_data);
I didn't check which display drivers would be involved, I'd guess there
are quite a few of them as well. So it seems this ends up being a pretty
complex task.
If this would be a brand new driver, then it should only support
DRM_BRIDGE_ATTACH_NO_CONNECTOR,
so you should not create a connector from the driver.
The fact dw-hdmi accepts an attach without the flag is for legacy purpose
since some DRM drivers haven't switched to DRM_BRIDGE_ATTACH_NO_CONNECTOR yes,
but it's a requirement for new bridges so at some point you'll need to make
sure the rockchip glue and drm driver supports DRM_BRIDGE_ATTACH_NO_CONNECTOR.
This will greatly simplify the driver!
Neil
Cristian
Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller
Hi, On 05/06/2024 11:25, Andy Yan wrote: Hi, At 2024-06-05 04:33:57, "Cristian Ciocaltea" wrote: On 6/3/24 4:08 PM, neil.armstr...@linaro.org wrote: Hi, On 03/06/2024 15:03, Heiko Stuebner wrote: Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan: Hi Neil: On 6/3/24 16:55, Neil Armstrong wrote: Hi Christian, On 01/06/2024 15:12, Cristian Ciocaltea wrote: The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the Synopsys DesignWare HDMI TX controller used in the previous SoCs. It is HDMI 2.1 compliant and supports the following features, among others: . .. * SCDC I2C DDC access * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4 * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds * Multi-stream audio * Enhanced Audio Return Channel (EARC) -> Those features were already supported by the HDMI 2.0a compliant HW, just list the _new_ features for HDMI 2.1 I did a quick review of your patchset and I don't understand why you need to add a separate dw-hdmi-qp.c since you only need simple variants of the I2C bus, infoframe and bridge setup. Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version detectable at runtime ? I would prefer to keep a single dw-hdmi driver if possible. The QP HDMI controller is a completely different variant with totally different registers layout, see PATCH 13/14. I think make it a separate driver will be easier for development and maintenance. I'm with Andy here. Trying to navigate a driver for two IP blocks really sounds taxing especially when both are so different. Thank you all for the valuable feedback! I agree, I just wanted more details than "variant of the Synopsys DesignWare HDMI TX controller", if the register mapping is 100% different, and does not match at all with the old IP, then it's indeed time to make a brand new driver, but instead of doing a mix up, it's time to extract the dw-hdmi code that could be common helpers into a dw-hdmi-common module and use them. Sounds good, will handle this in v2. As I see, no "driver" code can be shared, only DRM plumbings, so perhaps those plumbing code should go into the DRM core ? In any case, please add more details on the cover letter, including the detailed HW differrence and the design you chose so support this new IP. Andy, could you please help with a summary of the HW changes? The information I could provide is rather limited, since I don't have access to any DW IP datasheets and I'm also not familiar enough with the old variant. Accurately, we should refer to it as an entirely new IP，it has nothing in common with the current mainline dw-hdmi。 The only commonality is that they both come from Synopsys DesignWare： （1）It has a 100% different register mapping （2）It supports FRL and DSC （3）different configuration flow in many places。 So I have the same feeling with Heiko and Maxime： The DW_HDMI_QP should have a separate driver and with it's own CONFIG such as DRM_DW_HDMI_QP in Kconfig. and the rockchip part should also be split from dw_hdmi-rockchip.c. I am sorry we mixed them in dw_hdmi-rockchip.c when we develop the bsp driver，but we really regretted this decision when we repeatedly broke compatibility with dw-hdmi on other socs。 Yes please, and as I say, if there's code common with the old dw-hdmi, please add a common module if this code can't be moved in core bridge helpers. Neil Neil Synopsis also created a new dsi controller for the DSI2 standard, with a vastly different registers layout. I guess at some point there is time to say this really is a new IP ;-) . Though while on that thought, I don't fully understand why both a compiled under the dw_hdmi kconfig symbol. People going for a minimal kernel might want one or the other, but not both for their specific board. Indeed, it makes sense to have a dedicated Kconfig option. This is mostly a leftover from downstream implementation, will fix in v2. Thanks again, Cristian ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller
Hi, On 03/06/2024 15:03, Heiko Stuebner wrote: Am Montag, 3. Juni 2024, 14:14:17 CEST schrieb Andy Yan: Hi Neil: On 6/3/24 16:55, Neil Armstrong wrote: Hi Christian, On 01/06/2024 15:12, Cristian Ciocaltea wrote: The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the Synopsys DesignWare HDMI TX controller used in the previous SoCs. It is HDMI 2.1 compliant and supports the following features, among others: . .. * SCDC I2C DDC access * TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4 * YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds * Multi-stream audio * Enhanced Audio Return Channel (EARC) -> Those features were already supported by the HDMI 2.0a compliant HW, just list the _new_ features for HDMI 2.1 I did a quick review of your patchset and I don't understand why you need to add a separate dw-hdmi-qp.c since you only need simple variants of the I2C bus, infoframe and bridge setup. Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version detectable at runtime ? I would prefer to keep a single dw-hdmi driver if possible. The QP HDMI controller is a completely different variant with totally different registers layout, see PATCH 13/14. I think make it a separate driver will be easier for development and maintenance. I'm with Andy here. Trying to navigate a driver for two IP blocks really sounds taxing especially when both are so different. I agree, I just wanted more details than "variant of the Synopsys DesignWare HDMI TX controller", if the register mapping is 100% different, and does not match at all with the old IP, then it's indeed time to make a brand new driver, but instead of doing a mix up, it's time to extract the dw-hdmi code that could be common helpers into a dw-hdmi-common module and use them. As I see, no "driver" code can be shared, only DRM plumbings, so perhaps those plumbing code should go into the DRM core ? In any case, please add more details on the cover letter, including the detailed HW differrence and the design you chose so support this new IP. Neil Synopsis also created a new dsi controller for the DSI2 standard, with a vastly different registers layout. I guess at some point there is time to say this really is a new IP ;-) . Though while on that thought, I don't fully understand why both a compiled under the dw_hdmi kconfig symbol. People going for a minimal kernel might want one or the other, but not both for their specific board. Heiko
Re: [PATCH 00/14] Add initial support for the Rockchip RK3588 HDMI TX Controller
Hi Christian,
On 01/06/2024 15:12, Cristian Ciocaltea wrote:
The RK3588 SoC family integrates a Quad-Pixel (QP) variant of the
Synopsys DesignWare HDMI TX controller used in the previous SoCs.
It is HDMI 2.1 compliant and supports the following features, among
others:
.
..
* SCDC I2C DDC access
* TMDS Scrambler enabling 2160p@60Hz with RGB/YCbCr4:4:4
* YCbCr4:2:0 enabling 2160p@60Hz at lower HDMI link speeds
* Multi-stream audio
* Enhanced Audio Return Channel (EARC)
-> Those features were already supported by the HDMI 2.0a compliant HW, just
list the _new_ features for HDMI 2.1
I did a quick review of your patchset and I don't understand why you need
to add a separate dw-hdmi-qp.c since you only need simple variants of the I2C
bus, infoframe and bridge setup.
Can you elaborate further ? isn't this Quad-Pixel (QP) TX controller version
detectable at runtime ?
I would prefer to keep a single dw-hdmi driver if possible.
Thanks,
Neil
This is the last required component that needs to be supported in order
to enable the HDMI output functionality on the RK3588 based SBCs, such
as the RADXA Rock 5B. The other components are the Video Output
Processor (VOP2) and the Samsung IP based HDMI/eDP TX Combo PHY, for
which basic support has been already made available via [1] and [2],
respectively.
The patches are grouped as follows:
* PATCH 1..7: DW HDMI TX driver refactor to minimize code duplication in
the new QP driver (no functional changes intended)
* PATCH 8..11: Rockchip DW HDMI glue driver cleanup/improvements (no
functional changes intended)
* PATCH 12..13: The new DW HDMI QP TX driver reusing the previously
exported functions and structs from existing DW HDMI TX driver
* PATCH 14: Rockchip DW HDMI glue driver update to support RK3588 and
make use of DW HDMI QP TX
They provide just the basic HDMI support for now, i.e. RGB output up to
4K@60Hz, without audio, CEC or any of the HDMI 2.1 specific features.
Also note the vop2 driver is currently not able to properly handle all
display modes supported by the connected screens, e.g. it doesn't cope
with non-integer refresh rates.
A possible workaround consists of enabling the display controller to
make use of the clock provided by the HDMI PHY PLL. This is still work
in progress and will be submitted later, as well as the required DTS
updates.
To facilitate testing and experimentation, all HDMI output related
patches, including those part of this series, are available at [3].
So far I could only verify this on the RADXA Rock 3A and 5B boards.
Thanks,
Cristian
[1]: 5a028e8f062f ("drm/rockchip: vop2: Add support for rk3588")
[2]: 553be2830c5f ("phy: rockchip: Add Samsung HDMI/eDP Combo PHY driver")
[3]:
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commits/rk3588-hdmi-bridge-v6.10-rc1
Signed-off-by: Cristian Ciocaltea
---
Cristian Ciocaltea (14):
drm/bridge: dw-hdmi: Simplify clock handling
drm/bridge: dw-hdmi: Add dw-hdmi-common.h header
drm/bridge: dw-hdmi: Commonize dw_hdmi_i2c_adapter()
drm/bridge: dw-hdmi: Factor out AVI infoframe setup
drm/bridge: dw-hdmi: Factor out vmode setup
drm/bridge: dw-hdmi: Factor out hdmi_data_info setup
drm/bridge: dw-hdmi: Commonize dw_hdmi_connector_create()
drm/rockchip: dw_hdmi: Use modern drm_device based logging
drm/rockchip: dw_hdmi: Simplify clock handling
drm/rockchip: dw_hdmi: Use devm_regulator_get_enable()
drm/rockchip: dw_hdmi: Drop superfluous assignments of mpll_cfg, cur_ctr
and phy_config
dt-bindings: display: rockchip,dw-hdmi: Add compatible for RK3588
drm/bridge: synopsys: Add DW HDMI QP TX controller driver
drm/rockchip: dw_hdmi: Add basic RK3588 support
.../display/rockchip/rockchip,dw-hdmi.yaml | 127 +++-
drivers/gpu/drm/bridge/synopsys/Makefile | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi-common.h | 179 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 787 +++
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.h | 831 +
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 353 +++--
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 351 +++--
include/drm/bridge/dw_hdmi.h | 8 +
8 files changed, 2290 insertions(+), 348 deletions(-)
---
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
change-id: 20240601-b4-rk3588-bridge-upstream-a27baff1b8fc
Re: [PATCH v3 0/2] Add WL-355608-A8 panel
Hi, On Fri, 31 May 2024 09:12:12 +1200, Ryan Walklin wrote: > V3 of this patch with further cleanup to DT binding example code and > whitespace fixes in driver code. No functional change from V2. > > Original cover below. > -- > > The WL_355608_A8 panel is a VGA LCD display with an NV3052C-compatible driver > IC, used in a number of Anbernic handheld gaming devices. This patch adds a > device tree binding, and support for the display timings and init sequence to > the NV3052C SPI/RGB driver. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/2] dt-bindings: display: panel: Add WL-355608-A8 panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/45b888a8980ae9a09fbf2f50b0ffb7505a834533 [2/2] drm: panel: nv3052c: Add WL-355608-A8 panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/62ea2eeba7bf11f4b04e080475de93c2f8ee0f92 -- Neil
Re: [PATCH] MAINTAINERS: drm: Drop sam as panel reviewer
Hi, On Thu, 30 May 2024 23:14:02 +0200, Sam Ravnborg wrote: > Drop myself as reviewer of panel patches, to reflect the reality. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] MAINTAINERS: drm: Drop sam as panel reviewer https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/4a534428ef8df2e3ca91a8341702f6127fb42867 -- Neil
Re: [PATCH v3 2/2] drm: panel: nv3052c: Add WL-355608-A8 panel
_regs = wl_355608_a8_panel_regs,
+ .panel_regs_len = ARRAY_SIZE(wl_355608_a8_panel_regs),
+};
+
static const struct spi_device_id nv3052c_ids[] = {
{ "ltk035c5444t", },
{ "fs035vg158", },
+ { "wl-355608-a8", },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(spi, nv3052c_ids);
@@ -702,6 +925,7 @@ MODULE_DEVICE_TABLE(spi, nv3052c_ids);
static const struct of_device_id nv3052c_of_match[] = {
{ .compatible = "leadtek,ltk035c5444t", .data =
_panel_info },
{ .compatible = "fascontek,fs035vg158", .data = _panel_info
},
+ { .compatible = "wl-355608-a8", .data = _355608_a8_panel_info },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, nv3052c_of_match);
@@ -719,4 +943,5 @@ module_spi_driver(nv3052c_driver);
MODULE_AUTHOR("Paul Cercueil ");
MODULE_AUTHOR("Christophe Branchereau ");
+MODULE_AUTHOR("Ryan Walklin
Reviewed-by: Neil Armstrong
Re: [PATCH] MAINTAINERS: drm: Drop sam as panel reviewer
Hi Sam, On 30/05/2024 23:14, Sam Ravnborg wrote: Drop myself as reviewer of panel patches, to reflect the reality. Thanks for all your work on panel reviewing! Signed-off-by: Sam Ravnborg Cc: Neil Armstrong --- MAINTAINERS | 1 - 1 file changed, 1 deletion(-) diff --git a/MAINTAINERS b/MAINTAINERS index ac285040578e..38978699bef5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7567,7 +7567,6 @@ F:include/drm/gpu_scheduler.h DRM PANEL DRIVERS M:Neil Armstrong R:Jessica Zhang -R: Sam Ravnborg L:dri-devel@lists.freedesktop.org S:Maintained T:git https://gitlab.freedesktop.org/drm/misc/kernel.git Acked-by: Neil Armstrong
Re: [PATCH v2 0/3] drm/panel: sitronix-st7789v: fixes for jt240mhqs_hwt_ek_e3 panel
Hi, On Wed, 29 May 2024 16:42:44 +0200, Gerald Loacker wrote: > At the jt240mhqs_hwt_ek_e3 panel, noticeable flickering occurs. This is > addressed by patch 1, which adjusts the vertical timing. Patch 2 and 3 are > two more minor fixes for timing and dimension. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-fixes) [1/3] drm/panel: sitronix-st7789v: fix timing for jt240mhqs_hwt_ek_e3 panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0e5895ff7fab0fc05ec17daf9a568368828fa6ea [2/3] drm/panel: sitronix-st7789v: tweak timing for jt240mhqs_hwt_ek_e3 panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/2ba50582634d0bfe3a333ab7575a7f0122a7cde8 [3/3] drm/panel: sitronix-st7789v: fix display size for jt240mhqs_hwt_ek_e3 panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/b62c150c3bae72ac1910dcc588f360159eb0744a -- Neil
Re: [PATCH v5 0/6] Add DSC support to DSI video panel
On 27/05/2024 16:21, Jun Nie wrote: This is follow up update to Jonathan's patch set. Changes vs V4: - Polish width calculation with helper function - Split cfg2 compression bit into another patch Changes vs V3: - Rebase to latest msm-next-lumag branch. - Drop the slice_per_pkt change as it does impact basic DSC feature. - Remove change in generated dsi header - update DSC compressed width calculation with bpp and bpc - split wide bus impact on width into another patch - rename patch tile of VIDEO_COMPRESSION_MODE_CTRL_WC change - Polish warning usage - Add tags from reviewers Changes vs V2: - Drop the INTF_CFG2_DATA_HCTL_EN change as it is handled in latest mainline code. - Drop the bonded DSI patch as I do not have device to test it. - Address comments from version 2. Signed-off-by: Jun Nie --- Changes in v5: - Link to v4: https://lore.kernel.org/r/20240524-msm-drm-dsc-dsi-video-upstream-4-v4-0-e61c05b40...@linaro.org --- Jonathan Marek (4): drm/msm/dpu: fix video mode DSC for DSI drm/msm/dsi: set video mode widebus enable bit when widebus is enabled drm/msm/dsi: set VIDEO_COMPRESSION_MODE_CTRL_WC drm/msm/dsi: add a comment to explain pkt_per_line encoding Jun Nie (2): drm/msm/dpu: adjust data width for widen bus case drm/msm/dpu: enable compression bit in cfg2 for DSC drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 2 +- drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys.h | 8 drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_vid.c | 18 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c | 13 + drivers/gpu/drm/msm/dsi/dsi_host.c | 10 +- 5 files changed, 49 insertions(+), 2 deletions(-) --- base-commit: e6428bcb611f6c164856a41fc5a1ae8471a9b5a9 change-id: 20240524-msm-drm-dsc-dsi-video-upstream-4-22e2266fbe89 Best regards, Tested-by: Neil Armstrong # on SM8550-QRD Tested-by: Neil Armstrong # on SM8650-QRD Tested-by: Neil Armstrong # on SM8650-HDK with https://lore.kernel.org/all/20230728012623.22991-1-quic_parel...@quicinc.com/ and enforce-video-mode in panel node. Thanks, Neil
Re: [PATCH 0/8] drm/panel: Some very minor err handling fixes + more _multi
Hi,
On Fri, 17 May 2024 14:36:35 -0700, Douglas Anderson wrote:
> This series is pretty much just addressing a few minor error handling
> bugs that I noticed recently while reviewing some panel patches. For
> the most part these are all old issues.
>
> This also adjusts the new himax-hx83102 in a similar way that Dmitry
> did in his recent series that included commit f79d6d28d8fe
> ("drm/mipi-dsi: wrap more functions for streamline handling"). His
> series handled the panel driver that himax-hx83102 forked from but not
> himax-hx83102.
>
> [...]
Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git
(drm-misc-next)
[1/8] drm/panel: himax-hx8394: Handle errors from mipi_dsi_dcs_set_display_on()
better
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/cc2db2ef8d9eebc0df03808ac0dadbdb96733499
[2/8] drm/panel: boe-tv101wum-nl6: If prepare fails, disable GPIO before
regulators
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/587c48f622374e5d47b1d515c6006a4df4dee882
[3/8] drm/panel: boe-tv101wum-nl6: Check for errors on the NOP in prepare()
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/6320b9199dd99622668649c234d4e8a99e44a9c8
[4/8] drm/panel: ilitek-ili9882t: If prepare fails, disable GPIO before
regulators
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/554c00181968d43426bfe68c86541b89265075de
[5/8] drm/panel: ilitek-ili9882t: Check for errors on the NOP in prepare()
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/6a7bd6cde73f0fb7e5faa964dbdeb45b55c64698
[6/8] drm/panel: himax-hx83102: If prepare fails, disable GPIO before regulators
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/509eaa8aeee64bd7a41ca53d8728e497a9991074
[7/8] drm/panel: himax-hx83102: Check for errors on the NOP in prepare()
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/676a079fb3be66aed12cf40f236c77b8e7c189c3
[8/8] drm/panel: himax-hx83102: use wrapped MIPI DCS functions
https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/a2ab7cb169da38757323929f7b3b4cf396ec53b5
--
Neil
Re: [PATCH] dt-bindings: display: Reorganize legacy eDP panel bindings
Hi, On Mon, 20 May 2024 15:38:17 -0700, Douglas Anderson wrote: > Back in the day, we used to need to list the exact panel in dts for > eDP panels. This led to all sorts of problems including a large number > of cases where people listed a bogus panel in their device tree > because of the needs of second sourcing (and third sourcing, and > fourth sourcing, ...). Back when we needed to add eDP panels to dts > files we used to list them in "panel-simple.yaml". > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] dt-bindings: display: Reorganize legacy eDP panel bindings https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/bd0fc87d5adc8e3a0d6fb84c9ed3c77da1f1242d -- Neil
Re: [PATCH RFC] drm/panel-edp: add fat warning against adding new panel compatibles
On 23/05/2024 00:07, Dmitry Baryshkov wrote:
Add a fat warning against adding new panel compatibles to the panel-edp
driver. All new users of the eDP panels are supposed to use the generic
"edp-panel" compatible device on the AUX bus. The remaining compatibles
are either used by the existing DT or were used previously and are
retained for backwards compatibility.
Suggested-by: Doug Anderson
Signed-off-by: Dmitry Baryshkov
---
The following compatibles were never used by the devices supported by
the upstream kernel and are a subject to possible removal:
- auo,b133han05
- auo,b140han06
- ivo,m133nwf4-r0
- lg,lp097qx1-spa1
- lg,lp129qe
- samsung,lsn122dl01-c01
- samsung,ltn140at29-301
- sharp,ld-d5116z01b
- sharp,lq140m1jw46
- starry,kr122ea0sra
I'm considering dropping them, unless there is a good reason not to do
so.
---
drivers/gpu/drm/panel/panel-edp.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index 6db277efcbb7..95b25ec67168 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -1776,7 +1776,23 @@ static const struct of_device_id platform_of_match[] = {
{
/* Must be first */
.compatible = "edp-panel",
- }, {
+ },
+ /*
+* Do not add panels to the list below unless they cannot be handled by
+* the generic edp-panel compatible.
+*
+* The only two valid reasons are:
+* - because of the panel issues (e.g. broken EDID or broken
+* identification),
+* - because the platform which uses the panel didn't wire up the AUX
+* bus properly.
+*
+* In all other cases the platform should use the aux-bus and declare
+* the panel using the 'edp-panel' compatible as a device on the AUX
+* bus. The lack of the aux-bus support is not a valid case. Platforms
+* are urged to be converted to declaring panels in a proper way.
+*/
+ {
.compatible = "auo,b101ean01",
.data = _b101ean01,
}, {
---
base-commit: 8314289a8d50a4e05d8ece1ae0445a3b57bb4d3b
change-id: 20240523-edp-panel-drop-00aa239b3c6b
Best regards,
Reviewed-by: Neil Armstrong
Re: [PATCH v3 2/3] drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPER
On 22/05/2024 08:25, Dmitry Baryshkov wrote:
This panel driver uses DSC PPS functions and as such depends on the
DRM_DISPLAY_DP_HELPER. Select this symbol to make required functions
available to the driver.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200800.kysryyli-...@intel.com/
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/Kconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 4a2f621433ef..3e3f63479544 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -340,6 +340,8 @@ config DRM_PANEL_LG_SW43408
depends on OF
depends on DRM_MIPI_DSI
depends on BACKLIGHT_CLASS_DEVICE
+ select DRM_DISPLAY_DSC_HELPER
+ select DRM_DISPLAY_HELPER
help
Say Y here if you want to enable support for LG sw43408 panel.
The panel has a 1080x2160@60Hz resolution and uses 24 bit RGB per
Reviewed-by: Neil Armstrong
Re: [PATCH v3 3/3] drm/panel/lg-sw43408: mark sw43408_backlight_ops as static
On 22/05/2024 08:25, Dmitry Baryshkov wrote:
Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being
declared.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200739.hbwzvohr-...@intel.com/
Reviewed-by: Neil Armstrong
Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver")
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index 115f4702d59f..2b3a73696dce 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -182,7 +182,7 @@ static int sw43408_backlight_update_status(struct
backlight_device *bl)
return mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
}
-const struct backlight_ops sw43408_backlight_ops = {
+static const struct backlight_ops sw43408_backlight_ops = {
.update_status = sw43408_backlight_update_status,
};
Reviewed-by: Neil Armstrong
Re: [PATCH] dt-bindings: display: synopsys, dw-hdmi: Mark ddc-i2c-bus as deprecated
On 21/05/2024 14:29, Laurent Pinchart wrote: Hi Marek, Thank you for the patch. On Tue, May 21, 2024 at 12:40:47PM +0200, Marek Vasut wrote: The ddc-i2c-bus property should be placed in connector node, mark the HDMI TX side property as deprecated. Signed-off-by: Marek Vasut --- Cc: Andrzej Hajda Cc: Conor Dooley Cc: Daniel Vetter Cc: David Airlie Cc: Fabio Estevam Cc: Jernej Skrabec Cc: Jonas Karlman Cc: Krzysztof Kozlowski Cc: Laurent Pinchart Cc: Liu Ying Cc: Maarten Lankhorst Cc: Mark Yao Cc: Maxime Ripard Cc: Neil Armstrong Cc: Pengutronix Kernel Team Cc: Philipp Zabel Cc: Rob Herring Cc: Robert Foss Cc: Sascha Hauer Cc: Shawn Guo Cc: Thomas Zimmermann Cc: devicet...@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: i...@lists.linux.dev Cc: ker...@dh-electronics.com Cc: linux-arm-ker...@lists.infradead.org --- .../devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml index 828709a8ded26..d09a0bee54247 100644 --- a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml @@ -47,6 +47,7 @@ properties: ddc-i2c-bus: $ref: /schemas/types.yaml#/definitions/phandle +deprecated: true description: The HDMI DDC bus can be connected to either a system I2C master or the functionally-reduced I2C master contained in the DWC HDMI. When connected How about adding an additional sentence here to explain what should be used instead ? to a system I2C master this property contains a phandle to that I2C master controller. + + This property is deprecated, the system I2C master controller should + be referenced through the ddc-i2c-bus property of the HDMI connector + node. Reviewed-by: Laurent Pinchart With the additional sentence: Reviewed-by: Neil Armstrong
Re: [PATCH v2 5/5] drm/tiny: panel-mipi-dbi: Support the pixel format property
On 12/05/2024 17:25, Noralf Trønnes via B4 Relay wrote:
From: Noralf Trønnes
Add support for these pixel format property values:
- r5g6b5, RGB565
- b6x2g6x2r6x2, BGR666
BGR666 is presented to userspace as RGB888. The 2 LSB in each color
are discarded by the controller. The pixel is sent on the wire using
8 bits per word (little endian) so the controller sees it as BGR.
RGB565 is the default if the property is not present.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/tiny/panel-mipi-dbi.c | 55 ++-
1 file changed, 54 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/panel-mipi-dbi.c
b/drivers/gpu/drm/tiny/panel-mipi-dbi.c
index f80a141fcf36..f3aa2abce314 100644
--- a/drivers/gpu/drm/tiny/panel-mipi-dbi.c
+++ b/drivers/gpu/drm/tiny/panel-mipi-dbi.c
@@ -26,6 +26,49 @@
#include
+struct panel_mipi_dbi_format {
+ const char *name;
+ u32 fourcc;
+ unsigned int bpp;
+};
+
+static const struct panel_mipi_dbi_format panel_mipi_dbi_formats[] = {
+ { "r5g6b5", DRM_FORMAT_RGB565, 16 },
+ { "b6x2g6x2r6x2", DRM_FORMAT_RGB888, 24 },
+};
+
+static int panel_mipi_dbi_get_format(struct device *dev, u32 *formats,
unsigned int *bpp)
+{
+ const char *format_name;
+ unsigned int i;
+ int ret;
+
+ formats[1] = DRM_FORMAT_XRGB;
+
+ ret = device_property_read_string(dev, "format", _name);
+ if (ret) {
+ /* Old Device Trees don't have this property */
+ formats[0] = DRM_FORMAT_RGB565;
+ *bpp = 16;
+ return 0;
+ }
+
+ for (i = 0; i < ARRAY_SIZE(panel_mipi_dbi_formats); i++) {
+ const struct panel_mipi_dbi_format *format =
_mipi_dbi_formats[i];
+
+ if (strcmp(format_name, format->name))
+ continue;
+
+ formats[0] = format->fourcc;
+ *bpp = format->bpp;
+ return 0;
+ }
+
+ dev_err(dev, "Pixel format is not supported: '%s'\n", format_name);
+
+ return -EINVAL;
+}
+
static const u8 panel_mipi_dbi_magic[15] = { 'M', 'I', 'P', 'I', ' ', 'D',
'B', 'I',
0, 0, 0, 0, 0, 0, 0 };
@@ -276,6 +319,9 @@ static int panel_mipi_dbi_spi_probe(struct spi_device *spi)
struct drm_device *drm;
struct mipi_dbi *dbi;
struct gpio_desc *dc;
+ unsigned int bpp;
+ size_t buf_size;
+ u32 formats[2];
int ret;
dbidev = devm_drm_dev_alloc(dev, _mipi_dbi_driver, struct mipi_dbi_dev, drm);
@@ -323,7 +369,14 @@ static int panel_mipi_dbi_spi_probe(struct spi_device *spi)
if (IS_ERR(dbidev->driver_private))
return PTR_ERR(dbidev->driver_private);
- ret = mipi_dbi_dev_init(dbidev, _mipi_dbi_pipe_funcs, , 0);
+ ret = panel_mipi_dbi_get_format(dev, formats, );
+ if (ret)
+ return ret;
+
+ buf_size = DIV_ROUND_UP(mode.hdisplay * mode.vdisplay * bpp, 8);
+ ret = mipi_dbi_dev_init_with_formats(dbidev, _mipi_dbi_pipe_funcs,
+formats, ARRAY_SIZE(formats),
+, 0, buf_size);
if (ret)
return ret;
Reviewed-by: Neil Armstrong
Re: [PATCH v2 0/7] drm/mipi-dsi: simplify MIPI DSI init/cleanup even more
Hi, On Sun, 12 May 2024 02:00:17 +0300, Dmitry Baryshkov wrote: > Follow the example of mipi_dsi_generic_write_multi(), > mipi_dsi_dcs_write_buffer_multi(), mipi_dsi_generic_write_seq_multi() > and mipi_dsi_dcs_write_seq_multi(). Define _multi variants for several > other common MIPI DSI functions and use these functions in the panel > code. > > This series also includes a fix for the LG SW43408. If the proposed > approach is declined, the fix will be submitted separately. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/7] drm/panel: lg-sw43408: add missing error handling https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/51f9183e4af8c7f00e81180cbb9ee4a98a0f0aa1 [2/7] drm/mipi-dsi: wrap more functions for streamline handling https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/f79d6d28d8fe77b14beeaebe5393d9f294f8d09d [3/7] drm/panel: boe-tv101wum-nl6: use wrapped MIPI DCS functions https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/91329f921283b995ac125a0c6e61be0c1399f66f [4/7] drm/panel: ilitek-ili9882t: use wrapped MIPI DCS functions https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/510ba36e86eeb3ca89326dd51da32806e1ede693 [5/7] drm/panel: innolux-p079zca: use mipi_dsi_dcs_nop_multi() https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0f43988fb9c1c0a0c2f5ccf2d1bdb914f6e4e79b [6/7] drm/panel: novatek-nt36672e: use wrapped MIPI DCS functions https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/67ba7a82d99a8a8b4bcc1b8124b5640c63dd51bf [7/7] drm/panel: lg-sw43408: use new streamlined MIPI DSI API https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/85cb9d603953d77de5cb311d229a79c439ff6bfb -- Neil
Re: [PATCH v2 2/7] drm/mipi-dsi: wrap more functions for streamline handling
evice *dsi, int mipi_dsi_dcs_get_display_brightness_large(struct mipi_dsi_device *dsi, u16 *brightness); +void mipi_dsi_dcs_nop_multi(struct mipi_dsi_multi_context *ctx); +void mipi_dsi_dcs_enter_sleep_mode_multi(struct mipi_dsi_multi_context *ctx); +void mipi_dsi_dcs_exit_sleep_mode_multi(struct mipi_dsi_multi_context *ctx); +void mipi_dsi_dcs_set_display_off_multi(struct mipi_dsi_multi_context *ctx); +void mipi_dsi_dcs_set_display_on_multi(struct mipi_dsi_multi_context *ctx); +void mipi_dsi_dcs_set_tear_on_multi(struct mipi_dsi_multi_context *ctx, + enum mipi_dsi_dcs_tear_mode mode); + /** * mipi_dsi_generic_write_seq - transmit data using a generic write packet * The mipi_dsi_msleep() seems a little bit over-enginerred for me, but it serves the purpose so: Reviewed-by: Neil Armstrong Thanks, Neil
Re: [PATCH v8 0/6] Break out as separate driver and add BOE nv110wum-l60 IVO t109nw41 MIPI-DSI panel
Hi, On Thu, 16 May 2024 15:20:33 +0800, Cong Yang wrote: > Discussion with Doug and Linus in V1, we need a > separate driver to enable the hx83102 controller. > > So this series this series mainly Break out as separate driver > for Starry-himax83102-j02 panels from boe tv101wum driver. > > Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/6] dt-bindings: display: panel: Add himax hx83102 panel bindings https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/eba54e9c4483b585f6e2b9dd2472eb110417331b [2/6] drm/panel: himax-hx83102: Break out as separate driver https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0ef94554dc40fbdb7e57ff90cd1e7fa71e1e89fd [3/6] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60 https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/4fd07f679bebc432c72fc2c5cea23e39098e00c2 [4/6] drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/1173db117634b42383cf5d397ddfd4d4860ae20b [5/6] dt-bindings: display: panel: Add compatible for IVO t109nw41 https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/4020c15c0fcac8d66818dceae7f39736cf9f16b0 [6/6] drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/3179338750d83877bbc491493032bdf192266ad9 -- Neil
Re: (subset) [PATCH v7 0/7] Break out as separate driver and add BOE nv110wum-l60 IVO t109nw41 MIPI-DSI panel
Hi, On Wed, 15 May 2024 09:46:36 +0800, Cong Yang wrote: > Discussion with Doug and Linus in V1, we need a > separate driver to enable the hx83102 controller. > > So this series this series mainly Break out as separate driver > for Starry-himax83102-j02 panels from boe tv101wum driver. > > Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/7] dt-bindings: display: panel: Add himax hx83102 panel bindings https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/eba54e9c4483b585f6e2b9dd2472eb110417331b [2/7] drm/panel: himax-hx83102: Break out as separate driver https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0ef94554dc40fbdb7e57ff90cd1e7fa71e1e89fd [4/7] dt-bindings: display: panel: Add compatible for BOE nv110wum-l60 https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/4fd07f679bebc432c72fc2c5cea23e39098e00c2 [5/7] drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/1173db117634b42383cf5d397ddfd4d4860ae20b [6/7] dt-bindings: display: panel: Add compatible for IVO t109nw41 https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/4020c15c0fcac8d66818dceae7f39736cf9f16b0 [7/7] drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/3179338750d83877bbc491493032bdf192266ad9 -- Neil
Re: [PATCH v8 0/6] Break out as separate driver and add BOE nv110wum-l60 IVO t109nw41 MIPI-DSI panel
On 16/05/2024 15:31, Doug Anderson wrote: Hi, On Thu, May 16, 2024 at 12:21 AM Cong Yang wrote: Discussion with Doug and Linus in V1, we need a separate driver to enable the hx83102 controller. So this series this series mainly Break out as separate driver for Starry-himax83102-j02 panels from boe tv101wum driver. Then add BOE nv110wum-l60 and IVO t109nw41 in himax-hx83102 driver. Add compatible for BOE nv110wum-l60 and IVO t109nw41 in dt-bindings Note:this series depend Dous'series [1] [1]: https://lore.kernel.org/all/20240501154251.3302887-1-diand...@chromium.org/ Changes in v8: - Neil think need sent separately to ARM SoC maintainer with "arm64: defconfig: Enable HIMAX_HX83102 panel patch ", so remove it. - PATCH 1/6: No change. - PATCH 2/6: Fix Doug comment "return ret" change to "goto poweroff". - PATCH 3/6: No change. - PATCH 4/6: No change. - PATCH 5/6: No change. - PATCH 6/6: No change. - Link to v7:https://lore.kernel.org/all/20240515014643.2715010-1-yangco...@huaqin.corp-partner.google.com/ This all looks good to me now. Neil: do you want to apply this series plus Dmitry's [1] atop it, or would you like me to? Dmitry's series has a fix in it but I don't think it's critical enough to warrant the merge conflict that would come with putting it through drm-misc-fixes. Yes, it's not critical enough, I'll apply this one now and switch to Dmitry's one. Thanks, Neil [1] https://lore.kernel.org/r/20240512-dsi-panels-upd-api-v2-0-e31ca14d1...@linaro.org/
Re: [PATCH v3 3/6] dt-bindings: display: simple: Add Microtips & Lincolntech Dual-LVDS Panels
On 16/05/2024 13:06, Aradhya Bhatia wrote: Hi Liu, Thanks for reviewing the patch. On 16/05/24 07:49, Liu Ying wrote: On 5/15/24 17:51, Aradhya Bhatia wrote: Add the Microtips Technology USA's MF-101HIEBCAF0 10.1"[0] panel, MF-103HIEB0GA0 10.25"[1] panel, and Lincoln Technology Solutions' LCD185-101CT 10.1"[2] panel. Thes are all dual-lvds panels. Panel Links: [0]: https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2588/13-101HIEBCAF0-S_V1.1_20221104.pdf [1]: https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2660/13-103HIEB0GA0-S_V1.0_20211206.pdf This one mentions some controls in '3. PIN DESCRIPTION' which don't comply with this binding, like RL, TB, STBYB and RESET. Note this binding only allows compatible, ports, backlight, enable-gpios and power-supply properties, nothing more. Maybe the internal module _can_ support these control options but the actual panel hardware does not expose any of these controls on its connector pin-out, and hence has no possibility for additional SW control. Even for the usage, the device-tree node for the panel only has "compatible" and "ports" properties defined. The panel is being used within the confines of a simple panel. If somehow some modules with those panels would need more control lines, we'll simply move them out of simple panel bindings & drivers if required. Those are perfectly fine as is, we don't want useless description and dead code. Neil Regards Aradhya [2]: https://lincolntechsolutions.com/wp-content/uploads/2023/04/LCD185-101CTL1ARNTT_DS_R1.3.pdf Signed-off-by: Aradhya Bhatia --- .../display/panel/panel-simple-lvds-dual-ports.yaml | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml index 716ece5f3978..e78160d1aa24 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple-lvds-dual-ports.yaml @@ -41,6 +41,12 @@ properties: - auo,g190ean01 # Kaohsiung Opto-Electronics Inc. 10.1" WUXGA (1920 x 1200) LVDS TFT LCD panel - koe,tx26d202vm0bwa +# Lincoln Technology Solutions, LCD185-101CT 10.1" TFT 1920x1200 + - lincolntech,lcd185-101ct +# Microtips Technology MF-101HIEBCAF0 10.1" WUXGA (1920x1200) TFT LCD panel + - microtips,mf-101hiebcaf0 +# Microtips Technology MF-103HIEB0GA0 10.25" 1920x720 TFT LCD panel + - microtips,mf-103hieb0ga0 # NLT Technologies, Ltd. 15.6" FHD (1920x1080) LVDS TFT LCD panel - nlt,nl192108ac18-02d
Re: [v7 3/7] arm64: defconfig: Enable HIMAX_HX83102 panel
On 16/05/2024 08:43, cong yang wrote: Hi: If it is determined that a separately patch needs to be sent, then I will remove this patch in V8 series? Doug Anderson 于2024年5月16日周四 05:28写道： Hi, On Wed, May 15, 2024 at 2:16 PM wrote: Hi, On 15/05/2024 03:46, Cong Yang wrote: DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6. Since the arm64 defconfig had the BOE panel driver enabled, let's also enable the himax driver. Signed-off-by: Cong Yang Reviewed-by: Douglas Anderson --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2c30d617e180..687c86ddaece 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -864,6 +864,7 @@ CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m CONFIG_DRM_PANEL_LVDS=m CONFIG_DRM_PANEL_SIMPLE=m CONFIG_DRM_PANEL_EDP=m +CONFIG_DRM_PANEL_HIMAX_HX83102=m CONFIG_DRM_PANEL_ILITEK_ILI9882T=m CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m CONFIG_DRM_PANEL_RAYDIUM_RM67191=m You should probably sent this one separately since only an ARM SoC maintainer can apply this, probably via the qcom tree. Really? I always kinda figured that this was a bit like MAINTAINERS where it can come through a bunch of different trees. Certainly I've landed changes to it before through the drm-misc tree. If that was wrong then I'll certainly stop doing it, of course. Yeah we usually don't mess with arch specific defconfig from drm tree -Doug
Re: [PATCH v3 0/6] drm/panel: simple: Add Panels and Panel Vendors
Hi, On Wed, 15 May 2024 15:21:27 +0530, Aradhya Bhatia wrote: > Picking up this long-standing series which added support for Microtips' > and LincolnTech's dual-lvds panels. > > Microtips Technology Solutions USA, and Lincoln Technology Solutions are > 2 display panel vendors, and the patches 1/6 and 2/6 add their vendor > prefixes. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/6] dt-bindings: vendor-prefixes: Add microtips https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/71465a86296ab963bc120b5e32b9a19f69090e6f [2/6] dt-bindings: vendor-prefixes: Add lincolntech https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/37dbca37f3b53cb698798462f197db2637f6ab34 [3/6] dt-bindings: display: simple: Add Microtips & Lincolntech Dual-LVDS Panels https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/43f092d2540f7869ab5dc5a53ae1f76d44fc6293 [4/6] drm/panel: simple: Add Lincoln Tech Sol LCD185-101CT panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/ac9b8b7fee6578015483c5f130bad78d368c00cd [5/6] drm/panel: simple: Add Microtips Technology 13-101HIEBCAF0-C panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/f558d676cfbc388f2c3175c3c1f99c57902ea3c1 [6/6] drm/panel: simple: Add Microtips Technology MF-103HIEB0GA0 panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/2c3d1bd284c5141a85188f48e7f42112e81ffcd8 -- Neil
Re: [PATCH v3 6/6] drm/panel: simple: Add Microtips Technology MF-103HIEB0GA0 panel
On 15/05/2024 11:51, Aradhya Bhatia wrote:
Add support for Microtips Technology USA MF-103HIEB0GA0 10.25"[0],
1920x720, 8-bit TFT LCD with LVDS interface. Its a Dual-LVDS Panel and
does not support touch.
[0]: Panel Datasheet
https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2660/13-103HIEB0GA0-S_V1.0_20211206.pdf
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 3a0d8f0ff267..1b0a6b4e034c 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3084,6 +3084,35 @@ static const struct panel_desc
microtips_mf_101hiebcaf0_c = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode microtips_mf_103hieb0ga0_mode = {
+ .clock = 93301,
+ .hdisplay = 1920,
+ .hsync_start = 1920 + 72,
+ .hsync_end = 1920 + 72 + 72,
+ .htotal = 1920 + 72 + 72 + 72,
+ .vdisplay = 720,
+ .vsync_start = 720 + 3,
+ .vsync_end = 720 + 3 + 3,
+ .vtotal = 720 + 3 + 3 + 2,
+};
+
+static const struct panel_desc microtips_mf_103hieb0ga0 = {
+ .modes = _mf_103hieb0ga0_mode,
+ .bpc = 8,
+ .num_modes = 1,
+ .size = {
+ .width = 244,
+ .height = 92,
+ },
+ .delay = {
+ .prepare = 50,
+ .disable = 50,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
.clock = 30400,
.hdisplay = 800,
@@ -4726,6 +4755,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "microtips,mf-101hiebcaf0",
.data = _mf_101hiebcaf0_c,
+ }, {
+ .compatible = "microtips,mf-103hieb0ga0",
+ .data = _mf_103hieb0ga0,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = _aa070mc01,
Reviewed-by: Neil Armstrong
Re: [PATCH v3 5/6] drm/panel: simple: Add Microtips Technology 13-101HIEBCAF0-C panel
On 15/05/2024 11:51, Aradhya Bhatia wrote:
Add support for Microtips Technology USA 13-101HIECAF0-C 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and touch
support (ILITEK 2511).
[0]: Panel Datasheet
https://simplespec.microtipsusa.com/uploads/spec/datasheetFile/2588/13-101HIEBCAF0-S_V1.1_20221104.pdf
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 10e974bffd28..3a0d8f0ff267 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -3055,6 +3055,35 @@ static const struct panel_desc logicpd_type_28 = {
.connector_type = DRM_MODE_CONNECTOR_DPI,
};
+static const struct drm_display_mode microtips_mf_101hiebcaf0_c_mode = {
+ .clock = 150275,
+ .hdisplay = 1920,
+ .hsync_start = 1920 + 32,
+ .hsync_end = 1920 + 32 + 52,
+ .htotal = 1920 + 32 + 52 + 24,
+ .vdisplay = 1200,
+ .vsync_start = 1200 + 24,
+ .vsync_end = 1200 + 24 + 8,
+ .vtotal = 1200 + 24 + 8 + 3,
+};
+
+static const struct panel_desc microtips_mf_101hiebcaf0_c = {
+ .modes = _mf_101hiebcaf0_c_mode,
+ .bpc = 8,
+ .num_modes = 1,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 50,
+ .disable = 50,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct drm_display_mode mitsubishi_aa070mc01_mode = {
.clock = 30400,
.hdisplay = 800,
@@ -4694,6 +4723,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "logictechno,lttd800480070-l6wh-rt",
.data = _lttd800480070_l6wh_rt,
+ }, {
+ .compatible = "microtips,mf-101hiebcaf0",
+ .data = _mf_101hiebcaf0_c,
}, {
.compatible = "mitsubishi,aa070mc01-ca1",
.data = _aa070mc01,
Reviewed-by: Neil Armstrong
Re: [PATCH v3 4/6] drm/panel: simple: Add Lincoln Tech Sol LCD185-101CT panel
On 15/05/2024 11:51, Aradhya Bhatia wrote:
Add support for Lincoln Technology Solutions LCD185-101CT, 10.1",
1920x1200, 8-bit TFT LCD with LVDS interface, LED backlight and PCAP
touch support (Goodix GT928).
[0]: Panel Datasheet
https://lincolntechsolutions.com/wp-content/uploads/2023/04/LCD185-101CTL1ARNTT_DS_R1.3.pdf
Signed-off-by: Aradhya Bhatia
---
drivers/gpu/drm/panel/panel-simple.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index dcb6d0b6ced0..10e974bffd28 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -2870,6 +2870,35 @@ static const struct panel_desc lg_lb070wv8 = {
.connector_type = DRM_MODE_CONNECTOR_LVDS,
};
+static const struct drm_display_mode lincolntech_lcd185_101ct_mode = {
+ .clock = 155127,
+ .hdisplay = 1920,
+ .hsync_start = 1920 + 128,
+ .hsync_end = 1920 + 128 + 20,
+ .htotal = 1920 + 128 + 20 + 12,
+ .vdisplay = 1200,
+ .vsync_start = 1200 + 19,
+ .vsync_end = 1200 + 19 + 4,
+ .vtotal = 1200 + 19 + 4 + 20,
+};
+
+static const struct panel_desc lincolntech_lcd185_101ct = {
+ .modes = _lcd185_101ct_mode,
+ .bpc = 8,
+ .num_modes = 1,
+ .size = {
+ .width = 217,
+ .height = 136,
+ },
+ .delay = {
+ .prepare = 50,
+ .disable = 50,
+ },
+ .bus_flags = DRM_BUS_FLAG_DE_HIGH,
+ .bus_format = MEDIA_BUS_FMT_RGB888_1X7X4_SPWG,
+ .connector_type = DRM_MODE_CONNECTOR_LVDS,
+};
+
static const struct display_timing logictechno_lt161010_2nh_timing = {
.pixelclock = { 2640, 3330, 4680 },
.hactive = { 800, 800, 800 },
@@ -4644,6 +4673,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "lg,lb070wv8",
.data = _lb070wv8,
+ }, {
+ .compatible = "lincolntech,lcd185-101ct",
+ .data = _lcd185_101ct,
}, {
.compatible = "logicpd,type28",
.data = _type_28,
Reviewed-by: Neil Armstrong
Re: [v7 3/7] arm64: defconfig: Enable HIMAX_HX83102 panel
Hi, On 15/05/2024 03:46, Cong Yang wrote: DRM_PANEL_HIMAX_HX83102 is being split out from DRM_PANEL_BOE_TV101WUM_NL6. Since the arm64 defconfig had the BOE panel driver enabled, let's also enable the himax driver. Signed-off-by: Cong Yang Reviewed-by: Douglas Anderson --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index 2c30d617e180..687c86ddaece 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -864,6 +864,7 @@ CONFIG_DRM_PANEL_BOE_TV101WUM_NL6=m CONFIG_DRM_PANEL_LVDS=m CONFIG_DRM_PANEL_SIMPLE=m CONFIG_DRM_PANEL_EDP=m +CONFIG_DRM_PANEL_HIMAX_HX83102=m CONFIG_DRM_PANEL_ILITEK_ILI9882T=m CONFIG_DRM_PANEL_MANTIX_MLAF057WE51=m CONFIG_DRM_PANEL_RAYDIUM_RM67191=m You should probably sent this one separately since only an ARM SoC maintainer can apply this, probably via the qcom tree. Thanks, Neil
Re: [PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
On 14/05/2024 11:07, Krzysztof Kozlowski wrote: On 14/05/2024 10:44, Neil Armstrong wrote: On 13/05/2024 18:41, Dmitry Baryshkov wrote: On Mon, 13 May 2024 at 16:17, Rob Herring wrote: On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote: Hi, Cleanups for display panel bindings. Rob, maybe you could take entire set if it applies? I based it on linux-next, so letl me know if I need to rebase on your for-next. Applied. These 2 don't exist in my tree: It's most likely fine, but was there an ack from drm-misc maintainers? Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml Because those were added to drm-misc during the last cycle. So ideally the patch should have gone through drm-misc. Exact there's a conflict on today's next, Rob can you drop them so I can apply them via drm-misc ? It's almost the first time I see bindings picked up via drm-misc. Is this an exception or rather new trend (which would be awesome as this is what we prefer usually)? I usually pick up bindings along drivers like other subsystems, and when reviewed I take independent bindings fixes aswell when rob doesn't pick them before. Neil Best regards, Krzysztof
Re: [PATCH v5 0/9] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs
Hi, On Tue, 14 May 2024 10:20:50 -0700, Douglas Anderson wrote: > The consensus of many DRM folks is that we want to move away from DSI > drivers defining tables of init commands. Instead, we want to move to > init functions that can use common DRM functions. The issue thus far > has been that using the macros mipi_dsi_generic_write_seq() and > mipi_dsi_dcs_write_seq() bloats the driver using them. > > While trying to solve bloat, we realized that the majority of the it > was easy to solve. This series solves the bloat for existing drivers > by moving the printout outside of the macro. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq() https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0b03829fdece47beba9ecb7dbcbde4585ee3663e [2/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq() https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/24acbcce5cc673886c2f4f9b3f6f89a9c6a53b7e [3/9] drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/7d3f6acaf87c7db6dcd868694a2f65e7040478dc [4/9] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq() https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/3b724909a380fddb44dfa0072fc459c698a52658 [5/9] drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi() https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/966e397e4f6032b73438f8d775756541513e7daf [6/9] drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi() https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/d6fcbec281a2ed16794fabea49d4ac93db2d2944 [7/9] drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/d6ddb6624a7fc4fc3d7750bccaf43c66b55beab9 [8/9] drm/panel: ili9882t: Don't use a table for initting panels https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/95951654ca57786c658942a7c6f4471ef3f0d47e [9/9] drm/panel: innolux-p079zca: Don't use a table for initting panels https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/6f6fd690de1aef476e631ac03779e7d1de3fe451 -- Neil
Re: [PATCH 0/3] dt-bindings: display: panel: constrain 'reg'
On 13/05/2024 18:41, Dmitry Baryshkov wrote: On Mon, 13 May 2024 at 16:17, Rob Herring wrote: On Thu, May 09, 2024 at 11:42:50AM +0200, Krzysztof Kozlowski wrote: Hi, Cleanups for display panel bindings. Rob, maybe you could take entire set if it applies? I based it on linux-next, so letl me know if I need to rebase on your for-next. Applied. These 2 don't exist in my tree: It's most likely fine, but was there an ack from drm-misc maintainers? Documentation/devicetree/bindings/display/panel/lg,sw43408.yaml Documentation/devicetree/bindings/display/panel/raydium,rm69380.yaml Because those were added to drm-misc during the last cycle. So ideally the patch should have gone through drm-misc. Exact there's a conflict on today's next, Rob can you drop them so I can apply them via drm-misc ? Thanks, Neil
Re: [PATCH v2 2/2] drm/panel/lg-sw43408: mark sw43408_backlight_ops as static
On 09/05/2024 23:20, Dmitry Baryshkov wrote:
Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being
declared.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200739.hbwzvohr-...@intel.com/
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index 115f4702d59f..2b3a73696dce 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -182,7 +182,7 @@ static int sw43408_backlight_update_status(struct
backlight_device *bl)
return mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
}
-const struct backlight_ops sw43408_backlight_ops = {
+static const struct backlight_ops sw43408_backlight_ops = {
.update_status = sw43408_backlight_update_status,
};
Reviewed-by: Neil Armstrong
Re: [PATCH 0/2] drm/meson: fix hdmi auxiliary system operation without display
Hi, On Fri, 26 Apr 2024 18:02:52 +0200, Jerome Brunet wrote: > CEC and ARC should work even when HDMI is not actively used for the > display but it is not the case with Amlogic HDMI. > > This is important for devices such as sound bars which may use DSI > to display a UI and HDMI for CEC/ARC. A display is not required for these > functions > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-fixes) [1/2] drm/meson: dw-hdmi: power up phy on device init https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/04703bfd7f99c016a823c74712b97f8b5590ce87 [2/2] drm/meson: dw-hdmi: add bandgap setting for g12 https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/08001033121dd92b8297a5b7333636b466c30f13 -- Neil
Re: [PATCH 2/2] drm/meson: dw-hdmi: add bandgap setting for g12
eson-gxm-dw-hdmi",
- .data = _dw_hdmi_gx_data },
+ .data = _dw_hdmi_gxl_data },
{ .compatible = "amlogic,meson-g12a-dw-hdmi",
.data = _dw_hdmi_g12a_data },
{ }
Reviewed-by: Neil Armstrong
Re: [PATCH 1/2] drm/meson: dw-hdmi: power up phy on device init
On 26/04/2024 18:02, Jerome Brunet wrote:
The phy is not in a useful state right after init. It will become useful,
including for auxiliary function such as CEC or ARC, after the first mode
is set. This is a problem on systems where the display is using another
interface like DSI or CVBS.
This change refactor the init and mode change callback to power up the PHY
on init and leave only what is necessary for mode changes in the related
function. This is enough to fix CEC operation when HDMI display is not
enabled.
Fixes: 3f68be7d8e96 ("drm/meson: Add support for HDMI encoder and DW-HDMI bridge +
PHY")
Signed-off-by: Jerome Brunet
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 51 +--
1 file changed, 17 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson_dw_hdmi.c
index 5a9538bc0e26..a83d93078537 100644
--- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
@@ -384,26 +384,6 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
dw_hdmi_bus_fmt_is_420(hdmi))
mode_is_420 = true;
- /* Enable clocks */
- regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
-
- /* Bring HDMITX MEM output of power down */
- regmap_update_bits(priv->hhi, HHI_MEM_PD_REG0, 0xff << 8, 0);
-
- /* Bring out of reset */
- dw_hdmi->data->top_write(dw_hdmi, HDMITX_TOP_SW_RESET, 0);
-
- /* Enable internal pixclk, tmds_clk, spdif_clk, i2s_clk, cecclk */
- dw_hdmi_top_write_bits(dw_hdmi, HDMITX_TOP_CLK_CNTL,
- 0x3, 0x3);
-
- /* Enable cec_clk and hdcp22_tmdsclk_en */
- dw_hdmi_top_write_bits(dw_hdmi, HDMITX_TOP_CLK_CNTL,
- 0x3 << 4, 0x3 << 4);
-
- /* Enable normal output to PHY */
- dw_hdmi->data->top_write(dw_hdmi, HDMITX_TOP_BIST_CNTL, BIT(12));
-
/* TMDS pattern setup */
if (mode->clock > 34 && !mode_is_420) {
dw_hdmi->data->top_write(dw_hdmi, HDMITX_TOP_TMDS_CLK_PTTN_01,
@@ -425,20 +405,6 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
*data,
/* Setup PHY parameters */
meson_hdmi_phy_setup_mode(dw_hdmi, mode, mode_is_420);
- /* Setup PHY */
- regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1,
- 0x << 16, 0x0390 << 16);
-
- /* BIT_INVERT */
- if (dw_hdmi_is_compatible(dw_hdmi, "amlogic,meson-gxl-dw-hdmi") ||
- dw_hdmi_is_compatible(dw_hdmi, "amlogic,meson-gxm-dw-hdmi") ||
- dw_hdmi_is_compatible(dw_hdmi, "amlogic,meson-g12a-dw-hdmi"))
- regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1,
- BIT(17), 0);
- else
- regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1,
- BIT(17), BIT(17));
-
/* Disable clock, fifo, fifo_wr */
regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1, 0xf, 0);
@@ -656,6 +622,23 @@ static void meson_dw_hdmi_init(struct meson_dw_hdmi *meson_dw_hdmi)
meson_dw_hdmi->data->top_write(meson_dw_hdmi,
HDMITX_TOP_CLK_CNTL, 0xff);
+ /* Enable normal output to PHY */
+ meson_dw_hdmi->data->top_write(meson_dw_hdmi, HDMITX_TOP_BIST_CNTL,
BIT(12));
+
+ /* Setup PHY */
+ regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1,
+ 0x << 16, 0x0390 << 16);
+
+ /* BIT_INVERT */
+ if (dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxl-dw-hdmi") ||
+ dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-gxm-dw-hdmi") ||
+ dw_hdmi_is_compatible(meson_dw_hdmi, "amlogic,meson-g12a-dw-hdmi"))
+ regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1,
+ BIT(17), 0);
+ else
+ regmap_update_bits(priv->hhi, HHI_HDMI_PHY_CNTL1,
+ BIT(17), BIT(17));
+
/* Enable HDMI-TX Interrupt */
meson_dw_hdmi->data->top_write(meson_dw_hdmi, HDMITX_TOP_INTR_STAT_CLR,
HDMITX_TOP_INTR_CORE);
Reviewed-by: Neil Armstrong
Re: [PATCH v3 0/9] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs
On 02/05/2024 16:27, Doug Anderson wrote:
Hi,
On Thu, May 2, 2024 at 12:48 AM Neil Armstrong
wrote:
Hi,
On 01/05/2024 17:41, Douglas Anderson wrote:
The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
init functions that can use common DRM functions. The issue thus far
has been that using the macros mipi_dsi_generic_write_seq() and
mipi_dsi_dcs_write_seq() bloats the driver using them.
While trying to solve bloat, we realized that the majority of the it
was easy to solve. This series solves the bloat for existing drivers
by moving the printout outside of the macro.
During discussion of my v1 patch to fix the bloat [1], we also decided
that we really want to change the way that drivers deal with init
sequences to make it clearer. In addition to being cleaner, a side
effect of moving drivers to the new style reduces bloat _even more_.
This series also contains a few minor fixes / cleanups that I found
along the way.
This series converts four drivers over to the new
mipi_dsi_dcs_write_seq_multi() function. Not all conversions have been
tested, but hopefully they are straightforward enough. I'd appreciate
testing.
NOTE: In v3 I tried to incorporate the feedback from v2. I also
converted the other two panels I could find that used table-based
initialization.
[1]
https://lore.kernel.org/r/20240424172017.1.Id15fae80582bc74a0d4f1338987fa375738f45b9@changeid
Changes in v3:
- ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier.
- Add a TODO item for cleaning up the deprecated macros/functions.
- Fix spacing of init function.
- Inline kerneldoc comments for struct mipi_dsi_multi_context.
- Rebased upon patch to remove ratelimit of prints.
- Remove an unneeded error print.
- Squash boe-tv101wum-nl6 lowercase patch into main patch
- Use %zd in print instead of casting errors to int.
- drm/panel: ili9882t: Don't use a table for initting panels
- drm/panel: innolux-p079zca: Don't use a table for initting panels
Changes in v2:
- Add some comments to the macros about printing and returning.
- Change the way err value is handled in prep for next patch.
- Modify commit message now that this is part of a series.
- Rebased upon patches to avoid theoretical int overflow.
- drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
- drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()
- drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
- drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints
- drm/panel: boe-tv101wum-nl6: Convert hex to lowercase
- drm/panel: boe-tv101wum-nl6: Don't use a table for initting commands
- drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
Douglas Anderson (9):
drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
drm/mipi-dsi: Fix theoretical int overflow in
mipi_dsi_generic_write_seq()
drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit
prints
drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels
drm/panel: ili9882t: Don't use a table for initting panels
drm/panel: innolux-p079zca: Don't use a table for initting panels
Thanks Doug!
I think we all agree on the core changes, now I think we can wait a few weeks
and try to get some test feedbacks on the indirectly and directly affected
panels, drm-misc-next won't be merged into linux-next until v6.10-rc1 anyway
so we have some time to test on our boards.
Great!
Just to be clear, are you suggesting that we leave these patches on
the lists for a few weeks before landing in drm-misc-next, or are you
suggesting that it's safe to land them in drm-misc-next because it
won't make it to linuxnext for a while anyway? I assume the former
(AKA leave it on the lists for a while) but just want to be clear. ;-)
Yes you assume right
There's nothing terribly urgent about these patches except that they
are blocking Cong Yang's patch series [0] and lvzhaoxiong's patch
series [1]. I think it would be fine for them to send out their patch
series with mine marked as a dependency so we can finish reviewing
their series and then when mine lands theirs will be good to go too.
Maybe we can aim for 2 weeks of stewing on the list if there are no
issues during that time? I know landing in drm-misc during this time
won't help get into mainline faster, but with ChromeOS's "upstream
first" policy it saves us a bunch of headache if we can land things in
our tree from a maintainer tree with stable git hashes (like
drm-misc-next) instead of landing from a mailing list. Certainly that
doesn't mean we want to rush patches in before they're ready, but I
just want to say that there i
Re: [PATCH v2] drm/panel: ili9341: Remove a superfluous else after return
Hi, On Wed, 01 May 2024 13:24:02 +0800, Sui Jingfeng wrote: > Because the else clause after the return clause is not useful, remove it > to get a better look. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] drm/panel: ili9341: Remove a superfluous else after return https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/e91a36b472862a1d199ea8d1b1ca192a347bf33e -- Neil
Re: [PATCH v3 0/9] drm/mipi-dsi: Reduce bloat and add funcs for cleaner init seqs
Hi,
On 01/05/2024 17:41, Douglas Anderson wrote:
The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
init functions that can use common DRM functions. The issue thus far
has been that using the macros mipi_dsi_generic_write_seq() and
mipi_dsi_dcs_write_seq() bloats the driver using them.
While trying to solve bloat, we realized that the majority of the it
was easy to solve. This series solves the bloat for existing drivers
by moving the printout outside of the macro.
During discussion of my v1 patch to fix the bloat [1], we also decided
that we really want to change the way that drivers deal with init
sequences to make it clearer. In addition to being cleaner, a side
effect of moving drivers to the new style reduces bloat _even more_.
This series also contains a few minor fixes / cleanups that I found
along the way.
This series converts four drivers over to the new
mipi_dsi_dcs_write_seq_multi() function. Not all conversions have been
tested, but hopefully they are straightforward enough. I'd appreciate
testing.
NOTE: In v3 I tried to incorporate the feedback from v2. I also
converted the other two panels I could find that used table-based
initialization.
[1]
https://lore.kernel.org/r/20240424172017.1.Id15fae80582bc74a0d4f1338987fa375738f45b9@changeid
Changes in v3:
- ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier.
- Add a TODO item for cleaning up the deprecated macros/functions.
- Fix spacing of init function.
- Inline kerneldoc comments for struct mipi_dsi_multi_context.
- Rebased upon patch to remove ratelimit of prints.
- Remove an unneeded error print.
- Squash boe-tv101wum-nl6 lowercase patch into main patch
- Use %zd in print instead of casting errors to int.
- drm/panel: ili9882t: Don't use a table for initting panels
- drm/panel: innolux-p079zca: Don't use a table for initting panels
Changes in v2:
- Add some comments to the macros about printing and returning.
- Change the way err value is handled in prep for next patch.
- Modify commit message now that this is part of a series.
- Rebased upon patches to avoid theoretical int overflow.
- drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
- drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()
- drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
- drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints
- drm/panel: boe-tv101wum-nl6: Convert hex to lowercase
- drm/panel: boe-tv101wum-nl6: Don't use a table for initting commands
- drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
Douglas Anderson (9):
drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
drm/mipi-dsi: Fix theoretical int overflow in
mipi_dsi_generic_write_seq()
drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit
prints
drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
drm/panel: novatek-nt36672e: Switch to mipi_dsi_dcs_write_seq_multi()
drm/panel: boe-tv101wum-nl6: Don't use a table for initting panels
drm/panel: ili9882t: Don't use a table for initting panels
drm/panel: innolux-p079zca: Don't use a table for initting panels
Thanks Doug!
I think we all agree on the core changes, now I think we can wait a few weeks
and try to get some test feedbacks on the indirectly and directly affected
panels, drm-misc-next won't be merged into linux-next until v6.10-rc1 anyway
so we have some time to test on our boards.
Neil
Documentation/gpu/todo.rst| 18 +
drivers/gpu/drm/drm_mipi_dsi.c| 112 +
.../gpu/drm/panel/panel-boe-tv101wum-nl6.c| 2792 +
drivers/gpu/drm/panel/panel-ilitek-ili9882t.c | 794 +++--
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 284 +-
.../gpu/drm/panel/panel-novatek-nt36672e.c| 576 ++--
include/drm/drm_mipi_dsi.h| 101 +-
7 files changed, 2451 insertions(+), 2226 deletions(-)
Re: [PATCH v1 0/3] drm/panel: ili9341: Obvious fixes
Hi, On Thu, 25 Apr 2024 17:26:16 +0300, Andy Shevchenko wrote: > A few obvious fixes to the driver. > > Andy Shevchenko (3): > drm/panel: ili9341: Correct use of device property APIs > drm/panel: ili9341: Respect deferred probe > drm/panel: ili9341: Use predefined error codes > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-fixes) [1/3] drm/panel: ili9341: Correct use of device property APIs https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/d43cd48ef1791801c61a54fade4a88d294dedf77 [2/3] drm/panel: ili9341: Respect deferred probe https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/740fc1e0509be3f7e2207e89125b06119ed62943 [3/3] drm/panel: ili9341: Use predefined error codes https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/da85f0aaa9f21999753b01d45c0343f885a8f905 -- Neil
Re: [v1,1/3] drm/panel: ili9341: Correct use of device property APIs
On 30/04/2024 11:34, Maxime Ripard wrote: On Tue, Apr 30, 2024 at 12:54:39AM +0800, Sui Jingfeng wrote: On 2024/4/29 19:55, Maxime Ripard wrote: On Sat, Apr 27, 2024 at 01:57:46PM +0800, Sui Jingfeng wrote: On 2024/4/26 14:23, Maxime Ripard wrote: On Fri, Apr 26, 2024 at 04:43:18AM +0800, Sui Jingfeng wrote: On 2024/4/26 03:10, Andy Shevchenko wrote: On Fri, Apr 26, 2024 at 02:08:16AM +0800, Sui Jingfeng wrote: On 2024/4/25 22:26, Andy Shevchenko wrote: It seems driver missed the point of proper use of device property APIs. Correct this by updating headers and calls respectively. You are using the 'seems' here exactly saying that you are not 100% sure. Please allow me to tell you the truth: This patch again has ZERO effect. It fix nothing. And this patch is has the risks to be wrong. Huh?! Really, stop commenting the stuff you do not understand. I'm actually a professional display drivers developer at the downstream in the past, despite my contribution to upstream is less. But I believe that all panel driver developers know what I'm talking about. So please have take a look at my replies. Most of the interactions you had in this series has been uncalled for. You might be against a patch, but there's no need to go to such length. As far as I'm concerned, this patch is fine to me in itself, and I don't see anything that would prevent us from merging it. No one is preventing you, as long as don't misunderstanding what other people's technical replies intentionally. I'm just a usual and normal contributor, I hope the world will better than yesterday. You should seriously consider your tone when replying then. Saying such thing to me may not proper, I guess you may want to talk to peoples who has the push rights I think you misunderstood me. My point was that your several rants were uncalled for and aren't the kind of things we're doing here. I know very well how to get a patch merged, thanks. just make sure it isn't a insult to the professionalism of drm bridge community itself though. I'm not sure why you're bringing the bridge community or its professionalism. It's a panel, not a bridge, and I never doubted the professionalism of anyone. I means that the code itself could be adopted, as newer and younger programmer (like Andy) need to be encouraged to contribute. Andy has thousands of commits in Linux. He's *very* far from being a new contributor. I express no obvious objections, just hints him that something else probably should also be taken into consideration as well. That might be what you wanted to express, but you definitely didn't express it that way. On the other hand, we probably should allow other people participate in discussion so that it is sufficient discussed and ensure that it won't be reverted by someone in the future for some reasons. Backing to out case happens here, we may need to move things forward. Therefore, it definitely deserve to have a try. It is not a big deal even though it gets reverted someday. In the end, I don't mind if you think there is nothing that could prevent you from merge it, but I still suggest you have a glance at peoples siting at the Cc list. I'm busy now and I have a lot of other tasks to do, and may not be able to reply you emails on time. So it up to you and other maintainers to decide. Thank you. So far, you're the only one who reviewed those patches. I'm not sure what you're talking about here. Well I (as drm-panel maintainer) did review them positively because the patches looked perfectly correct in regards of the commit message and the patchset motivation and because I trust Andy being a long time contributor with a lot of expertise. Anyway since the rant is finished I'll land the patches. Neil Maxime
Re: [PATCH v3 5/9] drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
lti().
+ *
* @dsi: DSI peripheral device
* @cmd: Command
* @seq: buffer containing data to be transmitted
@@ -350,6 +396,22 @@ int mipi_dsi_dcs_get_display_brightness_large(struct
mipi_dsi_device *dsi,
return ret;\
} while (0)
+/**
+ * mipi_dsi_dcs_write_seq_multi - transmit a DCS command with payload
+ *
+ * This macro will print errors for you and error handling is optimized for
+ * callers that call this multiple times in a row.
+ *
+ * @ctx: Context for multiple DSI transactions
+ * @cmd: Command
+ * @seq: buffer containing data to be transmitted
+ */
+#define mipi_dsi_dcs_write_seq_multi(ctx, cmd, seq...) \
+ do {\
+ static const u8 d[] = { cmd, seq }; \
+ mipi_dsi_dcs_write_buffer_multi(ctx, d, ARRAY_SIZE(d)); \
+ } while (0)
+
/**
* struct mipi_dsi_driver - DSI driver
* @driver: device driver model driver
Reviewed-by: Neil Armstrong
Re: [PATCH v3 4/9] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
4
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -256,6 +256,8 @@ int mipi_dsi_picture_parameter_set(struct mipi_dsi_device
*dsi,
ssize_t mipi_dsi_generic_write(struct mipi_dsi_device *dsi, const void *payload,
size_t size);
+int mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi,
+ const void *payload, size_t size);
ssize_t mipi_dsi_generic_read(struct mipi_dsi_device *dsi, const void *params,
size_t num_params, void *data, size_t size);
@@ -279,6 +281,8 @@ enum mipi_dsi_dcs_tear_mode {
ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device *dsi,
const void *data, size_t len);
+int mipi_dsi_dcs_write_buffer_chatty(struct mipi_dsi_device *dsi,
+const void *data, size_t len);
ssize_t mipi_dsi_dcs_write(struct mipi_dsi_device *dsi, u8 cmd,
const void *data, size_t len);
ssize_t mipi_dsi_dcs_read(struct mipi_dsi_device *dsi, u8 cmd, void *data,
@@ -311,38 +315,39 @@ int mipi_dsi_dcs_get_display_brightness_large(struct
mipi_dsi_device *dsi,
/**
* mipi_dsi_generic_write_seq - transmit data using a generic write packet
+ *
+ * This macro will print errors for you and will RETURN FROM THE CALLING
+ * FUNCTION (yes this is non-intuitive) upon error.
+ *
* @dsi: DSI peripheral device
* @seq: buffer containing the payload
*/
-#define mipi_dsi_generic_write_seq(dsi, seq...) \
- do { \
- static const u8 d[] = { seq };\
- struct device *dev = >dev; \
- ssize_t ret; \
- ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d)); \
- if (ret < 0) {\
- dev_err(dev, "transmit data failed: %zd\n", ret); \
- return ret; \
- } \
+#define mipi_dsi_generic_write_seq(dsi, seq...)
\
+ do { \
+ static const u8 d[] = { seq }; \
+ int ret; \
+ ret = mipi_dsi_generic_write_chatty(dsi, d, ARRAY_SIZE(d));\
+ if (ret < 0) \
+ return ret;\
} while (0)
/**
* mipi_dsi_dcs_write_seq - transmit a DCS command with payload
+ *
+ * This macro will print errors for you and will RETURN FROM THE CALLING
+ * FUNCTION (yes this is non-intuitive) upon error.
+ *
* @dsi: DSI peripheral device
* @cmd: Command
* @seq: buffer containing data to be transmitted
*/
-#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...)\
- do {\
- static const u8 d[] = { cmd, seq }; \
- struct device *dev = >dev; \
- ssize_t ret;\
- ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
- if (ret < 0) { \
- dev_err(dev, "sending command %#02x failed: %zd\n", \
- cmd, ret); \
- return ret; \
- } \
+#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...)
\
+ do { \
+ static const u8 d[] = { cmd, seq };\
+ int ret; \
+ ret = mipi_dsi_dcs_write_buffer_chatty(dsi, d, ARRAY_SIZE(d)); \
+ if (ret < 0) \
+ return ret; \
} while (0)
/**
Reviewed-by: Neil Armstrong
Re: [PATCH v3 3/9] drm/mipi-dsi: mipi_dsi_*_write functions don't need to ratelimit prints
On 01/05/2024 17:41, Douglas Anderson wrote:
We really don't expect these errors to be printed over and over
again. When a driver hits the error it should bail out. Just use a
normal error print.
This gives a nice space savings for users of these functions:
$ scripts/bloat-o-meter \
.../before/panel-novatek-nt36672e.ko \
.../after/panel-novatek-nt36672e.ko
add/remove: 0/1 grow/shrink: 0/1 up/down: 0/-16760 (-16760)
Function old new delta
nt36672e_1080x2408_60hz_init 17080 10640 -6440
nt36672e_1080x2408_60hz_init._rs 10320 - -10320
Total: Before=31815, After=15055, chg -52.68%
Signed-off-by: Douglas Anderson
---
Changes in v3:
- ("mipi_dsi_*_write functions don't need to ratelimit...") moved earlier.
Changes in v2:
- New
include/drm/drm_mipi_dsi.h | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index e0f56564bf97..67967be48dbd 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -314,17 +314,16 @@ int mipi_dsi_dcs_get_display_brightness_large(struct
mipi_dsi_device *dsi,
* @dsi: DSI peripheral device
* @seq: buffer containing the payload
*/
-#define mipi_dsi_generic_write_seq(dsi, seq...)
\
- do {
\
- static const u8 d[] = { seq };
\
- struct device *dev = >dev;
\
- ssize_t ret;
\
- ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));
\
- if (ret < 0) {
\
- dev_err_ratelimited(dev, "transmit data failed: %zd\n",
\
- ret);
\
- return ret;
\
- }
\
+#define mipi_dsi_generic_write_seq(dsi, seq...) \
+ do { \
+ static const u8 d[] = { seq };\
+ struct device *dev = >dev; \
+ ssize_t ret; \
+ ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d)); \
+ if (ret < 0) {\
+ dev_err(dev, "transmit data failed: %zd\n", ret); \
+ return ret; \
+ } \
} while (0)
/**
@@ -340,8 +339,7 @@ int mipi_dsi_dcs_get_display_brightness_large(struct
mipi_dsi_device *dsi,
ssize_t ret;\
ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
if (ret < 0) { \
- dev_err_ratelimited(\
- dev, "sending command %#02x failed: %zd\n", \
+ dev_err(dev, "sending command %#02x failed: %zd\n", \
cmd, ret); \
return ret; \
} \
Reviewed-by: Neil Armstrong
Re: [PATCH v3 2/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_generic_write_seq()
On 01/05/2024 17:41, Douglas Anderson wrote:
The mipi_dsi_generic_write_seq() macro makes a call to
mipi_dsi_generic_write() which returns a type ssize_t. The macro then
stores it in an int and checks to see if it's negative. This could
theoretically be a problem if "ssize_t" is larger than "int".
To see the issue, imagine that "ssize_t" is 32-bits and "int" is
16-bits, you could see a problem if there was some code out there that
looked like:
mipi_dsi_generic_write_seq(dsi, <32768 bytes as arguments>);
...since we'd get back that 32768 bytes were transferred and 32768
stored in a 16-bit int would look negative.
Though there are no callsites where we'd actually hit this (even if
"int" was only 16-bit), it's cleaner to make the types match so let's
fix it.
Fixes: a9015ce59320 ("drm/mipi-dsi: Add a mipi_dsi_dcs_write_seq() macro")
Signed-off-by: Douglas Anderson
---
Changes in v3:
- Use %zd in print instead of casting errors to int.
Changes in v2:
- New
include/drm/drm_mipi_dsi.h | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 70ce0b8cbc68..e0f56564bf97 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -314,17 +314,17 @@ int mipi_dsi_dcs_get_display_brightness_large(struct
mipi_dsi_device *dsi,
* @dsi: DSI peripheral device
* @seq: buffer containing the payload
*/
-#define mipi_dsi_generic_write_seq(dsi, seq...)
\
- do { \
- static const u8 d[] = { seq }; \
- struct device *dev = >dev;\
- int ret; \
- ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d)); \
- if (ret < 0) { \
- dev_err_ratelimited(dev, "transmit data failed: %d\n", \
- ret); \
- return ret;\
- } \
+#define mipi_dsi_generic_write_seq(dsi, seq...)
\
+ do {
\
+ static const u8 d[] = { seq };
\
+ struct device *dev = >dev;
\
+ ssize_t ret;
\
+ ret = mipi_dsi_generic_write(dsi, d, ARRAY_SIZE(d));
\
+ if (ret < 0) {
\
+ dev_err_ratelimited(dev, "transmit data failed: %zd\n",
\
+ ret);
\
+ return ret;
\
+ }
\
} while (0)
/**
Reviewed-by: Neil Armstrong
Re: [PATCH v3 1/9] drm/mipi-dsi: Fix theoretical int overflow in mipi_dsi_dcs_write_seq()
On 01/05/2024 17:41, Douglas Anderson wrote:
The mipi_dsi_dcs_write_seq() macro makes a call to
mipi_dsi_dcs_write_buffer() which returns a type ssize_t. The macro
then stores it in an int and checks to see if it's negative. This
could theoretically be a problem if "ssize_t" is larger than "int".
To see the issue, imagine that "ssize_t" is 32-bits and "int" is
16-bits, you could see a problem if there was some code out there that
looked like:
mipi_dsi_dcs_write_seq(dsi, cmd, <32767 bytes as arguments>);
...since we'd get back that 32768 bytes were transferred and 32768
stored in a 16-bit int would look negative.
Though there are no callsites where we'd actually hit this (even if
"int" was only 16-bit), it's cleaner to make the types match so let's
fix it.
Fixes: 2a9e9daf7523 ("drm/mipi-dsi: Introduce mipi_dsi_dcs_write_seq macro")
Signed-off-by: Douglas Anderson
---
Changes in v3:
- Use %zd in print instead of casting errors to int.
Changes in v2:
- New
include/drm/drm_mipi_dsi.h | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 82b1cc434ea3..70ce0b8cbc68 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -333,18 +333,18 @@ int mipi_dsi_dcs_get_display_brightness_large(struct
mipi_dsi_device *dsi,
* @cmd: Command
* @seq: buffer containing data to be transmitted
*/
-#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...) \
- do { \
- static const u8 d[] = { cmd, seq };\
- struct device *dev = >dev;\
- int ret; \
- ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d));\
- if (ret < 0) { \
- dev_err_ratelimited( \
- dev, "sending command %#02x failed: %d\n", \
- cmd, ret); \
- return ret;\
- } \
+#define mipi_dsi_dcs_write_seq(dsi, cmd, seq...)\
+ do {\
+ static const u8 d[] = { cmd, seq }; \
+ struct device *dev = >dev; \
+ ssize_t ret;\
+ ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
+ if (ret < 0) { \
+ dev_err_ratelimited(\
+ dev, "sending command %#02x failed: %zd\n", \
+ cmd, ret); \
+ return ret; \
+ } \
} while (0)
/**
Reviewed-by: Neil Armstrong
Re: [PATCH v2 4/8] drm/mipi-dsi: Introduce mipi_dsi_*_write_seq_multi()
Hello Mister Anderson,
On 27/04/2024 01:58, Douglas Anderson wrote:
The current mipi_dsi_*_write_seq() macros are non-intutitive because
they contain a hidden "return" statement that will return out of the
_caller_ of the macro. Let's mark them as deprecated and instead
introduce some new macros that are more intuitive.
These new macros are less optimal when an error occurs but should
behave more optimally when there is no error. Specifically these new
macros cause smaller code to get generated and the code size savings
(less to fetch from RAM, less cache space used, less RAM used) are
important. Since the error case isn't something we need to optimize
for and these new macros are easier to understand and more flexible,
they should be used.
After converting to use these new functions, one example shows some
nice savings while also being easier to understand.
$ scripts/bloat-o-meter \
...after/panel-novatek-nt36672e.ko \
...ctx/panel-novatek-nt36672e.ko
add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-988 (-988)
Function old new delta
nt36672e_1080x2408_60hz_init62365248-988
Total: Before=10651, After=9663, chg -9.28%
Signed-off-by: Douglas Anderson
---
Right now this patch introduces two new functions in
drm_mipi_dsi.c. Alternatively we could have changed the prototype of
the "chatty" functions and made the deprecated macros adapt to the new
prototype. While this sounds nice, it bloated callers of the
deprecated functioin a bit because it caused the compiler to emit less
optimal code. It doesn't seem terrible to add two more functions, so I
went that way.
Changes in v2:
- New
drivers/gpu/drm/drm_mipi_dsi.c | 56 +
include/drm/drm_mipi_dsi.h | 57 ++
2 files changed, 113 insertions(+)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 1e062eda3b88..b7c75a4396e6 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -792,6 +792,34 @@ int mipi_dsi_generic_write_chatty(struct mipi_dsi_device
*dsi,
}
EXPORT_SYMBOL(mipi_dsi_generic_write_chatty);
};
+/**
+ * struct mipi_dsi_multi_context - Context to call multiple MIPI DSI funcs in
a row
+ * @dsi: Pointer to the MIPI DSI device
+ * @accum_err: Storage for the accumulated error over the multiple calls. Init
+ * to 0. If a function encounters an error then the error code will be
+ * stored here. If you call a function and this points to a non-zero
+ * value then the function will be a noop. This allows calling a function
+ * many times in a row and just checking the error at the end to see if
+ * any of them failed.
+ */
+
+struct mipi_dsi_multi_context {
+ struct mipi_dsi_device *dsi;
+ int accum_err;
+};
I like the design, but having a context struct seems over-engineered while we
could pass
a single int over without encapsulating it with mipi_dsi_multi_context.
void mipi_dsi_dcs_write_buffer_multi(struct mipi_dsi_multi_context *ctx,
const void *data, size_t len);
vs
void mipi_dsi_dcs_write_buffer_multi(struct mipi_dsi_device *dsi, int
*accum_err,
const void *data, size_t len);
is the same, and it avoids having to declare a mipi_dsi_multi_context and set
ctx->dsi,
and I'll find it much easier to migrate, just add a and make sure ret is
initialized to 0.
Re: [PATCH v1 3/3] drm/panel: ili9341: Use predefined error codes
On 25/04/2024 16:26, Andy Shevchenko wrote:
In one case the -1 is returned which is quite confusing code for
the wrong device ID, in another the ret is returning instead of
plain 0 that also confusing as readed may ask the possible meaning
of positive codes, which are never the case there. Convert both
to use explicit predefined error codes to make it clear what's going
on there.
Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 24c74c56e564..b933380b7eb7 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -422,7 +422,7 @@ static int ili9341_dpi_prepare(struct drm_panel *panel)
ili9341_dpi_init(ili);
- return ret;
+ return 0;
}
static int ili9341_dpi_enable(struct drm_panel *panel)
@@ -726,7 +726,7 @@ static int ili9341_probe(struct spi_device *spi)
else if (!strcmp(id->name, "yx240qv29"))
return ili9341_dbi_probe(spi, dc, reset);
- return -1;
+ return -ENODEV;
}
static void ili9341_remove(struct spi_device *spi)
Reviewed-by: Neil Armstrong
Re: [PATCH v1 2/3] drm/panel: ili9341: Respect deferred probe
On 25/04/2024 16:26, Andy Shevchenko wrote:
GPIO controller might not be available when driver is being probed.
There are plenty of reasons why, one of which is deferred probe.
Since GPIOs are optional, return any error code we got to the upper
layer, including deferred probe. With that in mind, use dev_err_probe()
in order to avoid spamming the logs.
Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 7584ddb0e441..24c74c56e564 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -715,11 +715,11 @@ static int ili9341_probe(struct spi_device *spi)
reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
if (IS_ERR(reset))
- dev_err(dev, "Failed to get gpio 'reset'\n");
+ return dev_err_probe(dev, PTR_ERR(reset), "Failed to get gpio
'reset'\n");
dc = devm_gpiod_get_optional(dev, "dc", GPIOD_OUT_LOW);
if (IS_ERR(dc))
- dev_err(dev, "Failed to get gpio 'dc'\n");
+ return dev_err_probe(dev, PTR_ERR(dc), "Failed to get gpio
'dc'\n");
if (!strcmp(id->name, "sf-tc240t-9370-t"))
return ili9341_dpi_probe(spi, dc, reset);
Reviewed-by: Neil Armstrong
Re: [PATCH v1 1/3] drm/panel: ili9341: Correct use of device property APIs
On 25/04/2024 16:26, Andy Shevchenko wrote:
It seems driver missed the point of proper use of device property APIs.
Correct this by updating headers and calls respectively.
Fixes: 5a04227326b0 ("drm/panel: Add ilitek ili9341 panel driver")
Signed-off-by: Andy Shevchenko
---
drivers/gpu/drm/panel/Kconfig| 2 +-
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 5 +++--
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index e54f6f5604ed..2d451820 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -177,7 +177,7 @@ config DRM_PANEL_ILITEK_IL9322
config DRM_PANEL_ILITEK_ILI9341
tristate "Ilitek ILI9341 240x320 QVGA panels"
- depends on OF && SPI
+ depends on SPI
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
depends on BACKLIGHT_CLASS_DEVICE
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index 3574681891e8..7584ddb0e441 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
@@ -22,8 +22,9 @@
#include
#include
#include
+#include
#include
-#include
+#include
#include
#include
@@ -691,7 +692,7 @@ static int ili9341_dpi_probe(struct spi_device *spi, struct gpio_desc *dc,
* Every new incarnation of this display must have a unique
* data entry for the system in this driver.
*/
- ili->conf = of_device_get_match_data(dev);
+ ili->conf = device_get_match_data(dev);
if (!ili->conf) {
dev_err(dev, "missing device configuration\n");
return -ENODEV;
Reviewed-by: Neil Armstrong
Re: [PATCH 02/10] pwm: Add SI-EN SN3112 PWM support
On 25/04/2024 02:57, Junhao Xie wrote: On 2024/4/25 03:37, Konrad Dybcio wrote: On 4/24/24 17:29, Xilin Wu via B4 Relay wrote: From: Junhao Xie Add a new driver for the SI-EN SN3112 12-channel 8-bit PWM LED controller. Signed-off-by: Junhao Xie --- [...] + return sn3112_write_reg(priv, SN3112_REG_PWM_EN + reg, + priv->pwm_en_reg[reg]); This looks like a weird reimplementation of regmap_update_bits We cannot use regmap_update_bits because this chip does not support read command. It will discard all read command. You could use regmap cache with all registers marked as cacheable, but not sure it's worth doing this. Neil +} + [...] devm_pwmchip_add? Konrad Thank you for your reply, I will fix them.
Re: [PATCH] drm/mipi-dsi: Reduce driver bloat of mipi_dsi_*_write_seq()
On 25/04/2024 02:20, Douglas Anderson wrote:
The consensus of many DRM folks is that we want to move away from DSI
drivers defining tables of init commands. Instead, we want to move to
init functions that can use common DRM functions. The issue thus far
has been that using the macros mipi_dsi_generic_write_seq() and
mipi_dsi_dcs_write_seq() bloats the driver using them.
Through a cooperative effort between Hsin-Yi Wang and Dmitry
Baryshkov, we have realized that the majority of the bloat is the fact
that we have the dev_err_ratelimited() directly in the macros. Let's
hoist this call into drm_mipi_dsi.c by adding a "chatty" version of
the functions that includes the print.
Without any changes to clients this gives a dramatic savings. Building
with my build system shows one example:
$ scripts/bloat-o-meter \
.../before/panel-novatek-nt36672e.ko \
.../after/panel-novatek-nt36672e.ko
add/remove: 0/1 grow/shrink: 1/1 up/down: 6/-19652 (-19646)
Function old new delta
__UNIQUE_ID_vermagic520 64 70 +6
nt36672e_1080x2408_60hz_init 165927260 -9332
nt36672e_1080x2408_60hz_init._rs 10320 - -10320
Total: Before=31503, After=11857, chg -62.36%
Note that given the change in location of the print it's harder to
include the "cmd" in the printout for mipi_dsi_dcs_write_seq() since,
theoretically, someone could call the new chatty function with a
zero-size array and it would be illegal to dereference data[0].
There's a printk format to print the whole buffer and this is probably
more useful for debugging anyway. Given that we're doing this for
mipi_dsi_dcs_write_seq(), let's also print the buffer for
mipi_dsi_generic_write_seq() in the error case.
Signed-off-by: Douglas Anderson
---
The MIPI device I have in front of me (wormdingler) hasn't been
converted to use these functions yet, so this is just compile
tested. It's about my end of day so I'm sending this out since it's
pretty straightforward. Hopefully others can confirm it works well for
them and also saves space under their compilers.
drivers/gpu/drm/drm_mipi_dsi.c | 54 ++
include/drm/drm_mipi_dsi.h | 31 ---
2 files changed, 67 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
index 795001bb7ff1..5ded6aef38ed 100644
--- a/drivers/gpu/drm/drm_mipi_dsi.c
+++ b/drivers/gpu/drm/drm_mipi_dsi.c
@@ -764,6 +764,33 @@ ssize_t mipi_dsi_generic_write(struct mipi_dsi_device
*dsi, const void *payload,
}
EXPORT_SYMBOL(mipi_dsi_generic_write);
+/**
+ * mipi_dsi_generic_write_chatty() - mipi_dsi_generic_write() w/ an error log
+ * @dsi: DSI peripheral device
+ * @payload: buffer containing the payload
+ * @size: size of payload buffer
+ *
+ * Just like mipi_dsi_generic_write() but includes a dev_err_ratelimited()
+ * call for you.
+ *
+ * Return: The number of bytes transmitted on success or a negative error code
+ * on failure.
+ */
+ssize_t mipi_dsi_generic_write_chatty(struct mipi_dsi_device *dsi,
+ const void *payload, size_t size)
+{
+ struct device *dev = >dev;
+ int ret;
+
+ ret = mipi_dsi_generic_write(dsi, payload, size);
+ if (ret < 0)
+ dev_err_ratelimited(dev, "sending generic data %*ph failed:
%d\n",
+ (int)size, payload, ret);
+
+ return ret;
+}
+EXPORT_SYMBOL(mipi_dsi_generic_write_chatty);
+
/**
* mipi_dsi_generic_read() - receive data using a generic read packet
* @dsi: DSI peripheral device
@@ -852,6 +879,33 @@ ssize_t mipi_dsi_dcs_write_buffer(struct mipi_dsi_device
*dsi,
}
EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer);
+/**
+ * mipi_dsi_dcs_write_buffer_chatty - mipi_dsi_dcs_write_buffer() w/ an error
log
+ * @dsi: DSI peripheral device
+ * @data: buffer containing data to be transmitted
+ * @len: size of transmission buffer
+ *
+ * Just like mipi_dsi_dcs_write_buffer() but includes a dev_err_ratelimited()
+ * call for you.
+ *
+ * Return: The number of bytes successfully transmitted or a negative error
+ * code on failure.
+ */
+ssize_t mipi_dsi_dcs_write_buffer_chatty(struct mipi_dsi_device *dsi,
+const void *data, size_t len)
+{
+ struct device *dev = >dev;
+ int ret;
+
+ ret = mipi_dsi_dcs_write_buffer(dsi, data, len);
+ if (ret < 0)
+ dev_err_ratelimited(dev, "sending dcs data %*ph failed: %d\n",
+ (int)len, data, ret);
+
+ return ret;
+}
+EXPORT_SYMBOL(mipi_dsi_dcs_write_buffer_chatty);
+
/**
* mipi_dsi_dcs_write() - send DCS write command
* @dsi: DSI peripheral device
diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
index 82b1cc434ea3..784e425dc4c8 100644
--- a/include/drm/drm_mipi_dsi.h
+++ b/include/drm/drm_mipi_dsi.h
@@ -256,6 +256,8 @@
Re: [PATCH 1/2] drm/bridge: chipone-icn6211: drop driver owner assignment
Hi Dmitry, On 24/04/2024 11:12, Dmitry Baryshkov wrote: On Sat, Mar 30, 2024 at 09:27:40PM +0100, Krzysztof Kozlowski wrote: Core in mipi_dsi_driver_register() already sets the .owner, so driver does not need to. Signed-off-by: Krzysztof Kozlowski --- drivers/gpu/drm/bridge/chipone-icn6211.c | 1 - 1 file changed, 1 deletion(-) Reviewed-by: Dmitry Baryshkov I tried to apply them but you already applied them... could you make sure to notify the list when applying ? Thanks, Neil
Re: [PATCH] drm/panel: jdi-fhd-r63452: make use of prepare_prev_first
Hi, On Tue, 23 Apr 2024 22:54:33 +0200, Barnabás Czémán wrote: > The DSI host must be enabled for the panel to be initialized in > prepare(). Set the prepare_prev_first flag to guarantee this. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] drm/panel: jdi-fhd-r63452: make use of prepare_prev_first https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/4edd73d174de5e8ec43f0de303f4a8b80e643529 -- Neil
Re: [PATCH v2] drm/bridge: adv7511: make it honour next bridge in DT
Hi, On Sun, 31 Mar 2024 23:45:48 +0300, Dmitry Baryshkov wrote: > DT bindings for adv7511 and adv7533 bridges specify HDMI output to be > present at the port@1. This allows board DT to add e.g. HDMI connector > nodes or any other next chained bridge. Make adv7511 driver discover > that bridge and attach it to the chain. > > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] drm/bridge: adv7511: make it honour next bridge in DT https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/14b3cdbd0e5b73824b7b2c7a4b1fbfd743044a5e -- Neil
Re: (subset) [PATCH 0/6] drm/panel: small fixes for visionox and novatek panel drivers
Hi, On Thu, 04 Apr 2024 13:07:58 +0300, Dmitry Baryshkov wrote: > While taking a glance at the novatek-nt36672e driver I stumbled upon a > call to unregister the DSI device for the panel, although it was not the > panel driver that registered the device. > > Remove this call and a similar call from the visionox-rm69299 driver. > While we are at it, also optimize regulator API calls in these two > drivers and in the novatek-nt36672a driver. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [3/6] drm/panel: novatek-nt36672e: stop setting register load before disable https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/302aeb946731923c4ff7cca093868e4148ebc701 [4/6] drm/panel: novatek-nt36672e: stop calling regulator_set_load manually https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/9dab1af1e7592d9317bf3857e8cf019120973053 [5/6] drm/panel: novatek-nt36672a: stop calling regulator_set_load manually https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/a8ee5f50a9d87f35ca80d6ea74ac07ae97d5a21b [6/6] drm/panel: visionox-rm69299: stop calling regulator_set_load manually https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/251e3c1fe15cb8bf71a834f863f6225b8164f7b8 -- Neil
Re: [PATCH 2/2] drm/panel/lg-sw43408: mark sw43408_backlight_ops as static
On 20/04/2024 04:41, Dmitry Baryshkov wrote:
Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being
declared.
Reported-by: kernel test robot
Closes:
https://lore.kernel.org/oe-kbuild-all/202404200739.hbwzvohr-...@intel.com/
Signed-off-by: Dmitry Baryshkov
No fixed either ?
---
drivers/gpu/drm/panel/panel-lg-sw43408.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-lg-sw43408.c
b/drivers/gpu/drm/panel/panel-lg-sw43408.c
index 115f4702d59f..2b3a73696dce 100644
--- a/drivers/gpu/drm/panel/panel-lg-sw43408.c
+++ b/drivers/gpu/drm/panel/panel-lg-sw43408.c
@@ -182,7 +182,7 @@ static int sw43408_backlight_update_status(struct
backlight_device *bl)
return mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
}
-const struct backlight_ops sw43408_backlight_ops = {
+static const struct backlight_ops sw43408_backlight_ops = {
.update_status = sw43408_backlight_update_status,
};
Reviewed-by: Neil Armstrong
Re: [PATCH 1/2] drm/panel/lg-sw43408: depends on CONFIG_DRM_DISPLAY_DP_HELPER
On 20/04/2024 04:41, Dmitry Baryshkov wrote: This panel driver uses DSC PPS functions and as such depends on the DRM_DISPLAY_DP_HELPER. Add missing dependency Reported-by: kernel test robot Closes: https://lore.kernel.org/oe-kbuild-all/202404200800.kysryyli-...@intel.com/ No Fixes ? Signed-off-by: Dmitry Baryshkov --- drivers/gpu/drm/panel/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig index ab67789e59a2..5e6692207beb 100644 --- a/drivers/gpu/drm/panel/Kconfig +++ b/drivers/gpu/drm/panel/Kconfig @@ -340,6 +340,7 @@ config DRM_PANEL_LG_SW43408 depends on OF depends on DRM_MIPI_DSI depends on BACKLIGHT_CLASS_DEVICE + depends on DRM_DISPLAY_DP_HELPER help Say Y here if you want to enable support for LG sw43408 panel. The panel has a 1080x2160@60Hz resolution and uses 24 bit RGB per Reviewed-by: Neil Armstrong
Re: [PATCH 6/6] drm/panel: visionox-rm69299: stop calling regulator_set_load manually
On 04/04/2024 12:08, Dmitry Baryshkov wrote:
Use .init_load_uA part of the bulk regulator API instead of calling
register_set_load() manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-visionox-rm69299.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
index b15ca56a09a7..272490b9565b 100644
--- a/drivers/gpu/drm/panel/panel-visionox-rm69299.c
+++ b/drivers/gpu/drm/panel/panel-visionox-rm69299.c
@@ -197,7 +197,9 @@ static int visionox_rm69299_probe(struct mipi_dsi_device
*dsi)
ctx->dsi = dsi;
ctx->supplies[0].supply = "vdda";
+ ctx->supplies[0].init_load_uA = 32000;
ctx->supplies[1].supply = "vdd3p3";
+ ctx->supplies[1].init_load_uA = 13200;
ret = devm_regulator_bulk_get(ctx->panel.dev, ARRAY_SIZE(ctx->supplies),
ctx->supplies);
@@ -227,22 +229,8 @@ static int visionox_rm69299_probe(struct mipi_dsi_device
*dsi)
goto err_dsi_attach;
}
- ret = regulator_set_load(ctx->supplies[0].consumer, 32000);
- if (ret) {
- dev_err(dev, "regulator set load failed for vdda supply ret =
%d\n", ret);
- goto err_set_load;
- }
-
- ret = regulator_set_load(ctx->supplies[1].consumer, 13200);
- if (ret) {
- dev_err(dev, "regulator set load failed for vdd3p3 supply ret =
%d\n", ret);
- goto err_set_load;
- }
-
return 0;
-err_set_load:
- mipi_dsi_detach(dsi);
err_dsi_attach:
drm_panel_remove(>panel);
return ret;
Reviewed-by: Neil Armstrong
Re: [PATCH 5/6] drm/panel: novatek-nt36672a: stop calling regulator_set_load manually
On 04/04/2024 12:08, Dmitry Baryshkov wrote:
Use .init_load_uA part of the bulk regulator API instead of calling
register_set_load() manually.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672a.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
index 33fb3d715e54..3886372415c2 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672a.c
@@ -605,21 +605,16 @@ static int nt36672a_panel_add(struct nt36672a_panel
*pinfo)
struct device *dev = >link->dev;
int i, ret;
- for (i = 0; i < ARRAY_SIZE(pinfo->supplies); i++)
+ for (i = 0; i < ARRAY_SIZE(pinfo->supplies); i++) {
pinfo->supplies[i].supply = nt36672a_regulator_names[i];
+ pinfo->supplies[i].init_load_uA =
nt36672a_regulator_enable_loads[i];
+ }
ret = devm_regulator_bulk_get(dev, ARRAY_SIZE(pinfo->supplies),
pinfo->supplies);
if (ret < 0)
return dev_err_probe(dev, ret, "failed to get regulators\n");
- for (i = 0; i < ARRAY_SIZE(pinfo->supplies); i++) {
- ret = regulator_set_load(pinfo->supplies[i].consumer,
-nt36672a_regulator_enable_loads[i]);
- if (ret)
- return dev_err_probe(dev, ret, "failed to set regulator
enable loads\n");
- }
-
pinfo->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
if (IS_ERR(pinfo->reset_gpio))
return dev_err_probe(dev, PTR_ERR(pinfo->reset_gpio),
Reviewed-by: Neil Armstrong
Re: [PATCH 3/6] drm/panel: novatek-nt36672e: stop setting register load before disable
On 04/04/2024 12:08, Dmitry Baryshkov wrote:
It is pointless to set register load before disabling the register. This
vote is going to be dropped as soon as the register is disabled. Drop
these register_set_load calls.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/panel/panel-novatek-nt36672e.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
index c39fe0fc5d69..9a870b9b6765 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt36672e.c
@@ -25,12 +25,6 @@ static const unsigned long regulator_enable_loads[] = {
10,
};
-static const unsigned long regulator_disable_loads[] = {
- 80,
- 100,
- 100,
-};
-
struct panel_desc {
const struct drm_display_mode *display_mode;
u32 width_mm;
@@ -385,20 +379,9 @@ static int nt36672e_power_off(struct nt36672e_panel *ctx)
{
struct mipi_dsi_device *dsi = ctx->dsi;
int ret = 0;
- int i;
gpiod_set_value(ctx->reset_gpio, 0);
- for (i = 0; i < ARRAY_SIZE(ctx->supplies); i++) {
- ret = regulator_set_load(ctx->supplies[i].consumer,
- regulator_disable_loads[i]);
- if (ret) {
- dev_err(>dev, "regulator set load failed for supply %s:
%d\n",
- ctx->supplies[i].supply, ret);
- return ret;
- }
- }
-
ret = regulator_bulk_disable(ARRAY_SIZE(ctx->supplies), ctx->supplies);
if (ret)
dev_err(>dev, "regulator bulk disable failed: %d\n", ret);
Reviewed-by: Neil Armstrong
Re: [PATCH] drm/panel: jdi-fhd-r63452: make use of prepare_prev_first
On 23/04/2024 22:54, Barnabás Czémán wrote: The DSI host must be enabled for the panel to be initialized in prepare(). Set the prepare_prev_first flag to guarantee this. Signed-off-by: Barnabás Czémán --- drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c b/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c index 3e0a8e0d58a0..483dc88d16d8 100644 --- a/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c +++ b/drivers/gpu/drm/panel/panel-jdi-fhd-r63452.c @@ -247,6 +247,7 @@ static int jdi_fhd_r63452_probe(struct mipi_dsi_device *dsi) drm_panel_init(>panel, dev, _fhd_r63452_panel_funcs, DRM_MODE_CONNECTOR_DSI); + ctx->panel.prepare_prev_first = true; ret = drm_panel_of_backlight(>panel); if (ret) --- base-commit: a59668a9397e7245b26e9be85d23f242ff757ae8 change-id: 20240423-jdi-fix-986a796a3101 Best regards, Reviewed-by: Neil Armstrong
Re: [PATCH v2] drm/bridge: adv7511: make it honour next bridge in DT
On 31/03/2024 22:45, Dmitry Baryshkov wrote:
DT bindings for adv7511 and adv7533 bridges specify HDMI output to be
present at the port@1. This allows board DT to add e.g. HDMI connector
nodes or any other next chained bridge. Make adv7511 driver discover
that bridge and attach it to the chain.
Signed-off-by: Dmitry Baryshkov
---
Changes in v2:
- Fixed the absent next bridge usecase
- Link to v1:
https://lore.kernel.org/r/20240309-adv7511-next-bridge-v1-1-d1ad522ef...@linaro.org
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 +
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 12
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 39c9ece373b0..ea271f62b214 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -356,6 +356,7 @@ struct adv7511 {
enum drm_connector_status status;
bool powered;
+ struct drm_bridge *next_bridge;
struct drm_display_mode curr_mode;
unsigned int f_tmds;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index b5518ff97165..c50d994a33b5 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -946,6 +947,12 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge,
struct adv7511 *adv = bridge_to_adv7511(bridge);
int ret = 0;
+ if (adv->next_bridge) {
+ ret = drm_bridge_attach(bridge->encoder, adv->next_bridge,
bridge, flags);
+ if (ret)
+ return ret;
+ }
+
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
ret = adv7511_connector_init(adv);
if (ret < 0)
@@ -1216,6 +1223,11 @@ static int adv7511_probe(struct i2c_client *i2c)
memset(_config, 0, sizeof(link_config));
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 1, -1, NULL,
+ >next_bridge);
+ if (ret && ret != -ENODEV)
+ return ret;
+
if (adv7511->info->link_config)
ret = adv7511_parse_dt(dev->of_node, _config);
else
---
base-commit: 1843e16d2df9d98427ef8045589571749d627cf7
change-id: 20240309-adv7511-next-bridge-10d8bbe0544e
Best regards,
Indeed looks safer.
Reviewed-by: Neil Armstrong
Neil
Re: [PATCH] drm/bridge: adv7511: make it honour next bridge in DT
On 09/03/2024 16:33, Dmitry Baryshkov wrote:
DT bindings for adv7511 and adv7533 bridges specify HDMI output to be
present at the port@1. This allows board DT to add e.g. HDMI connector
nodes or any other next chained bridge. Make adv7511 driver discover
that bridge and attach it to the chain.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/bridge/adv7511/adv7511.h | 1 +
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511.h
b/drivers/gpu/drm/bridge/adv7511/adv7511.h
index 39c9ece373b0..ea271f62b214 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511.h
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511.h
@@ -356,6 +356,7 @@ struct adv7511 {
enum drm_connector_status status;
bool powered;
+ struct drm_bridge *next_bridge;
struct drm_display_mode curr_mode;
unsigned int f_tmds;
diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index b5518ff97165..4eea9e8fb603 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -946,6 +947,10 @@ static int adv7511_bridge_attach(struct drm_bridge *bridge,
struct adv7511 *adv = bridge_to_adv7511(bridge);
int ret = 0;
+ ret = drm_bridge_attach(bridge->encoder, adv->next_bridge, bridge, flags);
+ if (ret)
+ return ret;
+
if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR)) {
ret = adv7511_connector_init(adv);
if (ret < 0)
@@ -1216,6 +1221,11 @@ static int adv7511_probe(struct i2c_client *i2c)
memset(_config, 0, sizeof(link_config));
+ ret = drm_of_find_panel_or_bridge(dev->of_node, 1, -1, NULL,
+ >next_bridge);
+ if (ret)
+ return ret;
+
if (adv7511->info->link_config)
ret = adv7511_parse_dt(dev->of_node, _config);
else
---
base-commit: 1843e16d2df9d98427ef8045589571749d627cf7
change-id: 20240309-adv7511-next-bridge-10d8bbe0544e
Best regards,
Reviewed-by: Neil Armstrong
Looks fine, I check most of the DT using this bridge and the port@1 seems
correctly defined.
LGTM.
Neil
Re: (subset) [PATCH v8 0/4] LVDS Controller Support for SAM9X75 SoC
Hi, On Sun, 21 Apr 2024 06:40:46 +0530, Dharma Balasubiramani wrote: > This patch series introduces LVDS controller support for the SAM9X75 SoC. The > LVDS controller is designed to work with Microchip's sam9x7 series > System-on-Chip (SoC) devices, providing Low Voltage Differential Signaling > capabilities. > > Patch series Changelog: > - Include configs: at91: Enable LVDS serializer > - include all necessary To/Cc entries. > The Individual Changelogs are available on the respective patches. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/4] dt-bindings: display: bridge: add sam9x75-lvds binding https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/c24177ca3b27e5a7ddaab8d330cedecd7eb9244a [2/4] drm/bridge: add lvds controller support for sam9x7 https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/179b0769fc5fc193d7837bdcb6ddee118a0fa9b8 [3/4] MAINTAINERS: add SAM9X7 SoC's LVDS controller https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/e95752752eaf06c860811ac5ddf9badf6c1b43ca -- Neil
Re: (subset) [PATCH v12 0/7] drm/meson: add support for MIPI DSI Display
Hi, On Wed, 03 Apr 2024 09:46:31 +0200, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [4/7] drm/meson: gate px_clk when setting rate https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/5c9837374ecf55a1fa3b7622d365a0456960270f -- Neil
Re: [PATCH v12 4/7] drm/meson: gate px_clk when setting rate
Hi Martin,
On 10/04/2024 21:34, Martin Blumenstingl wrote:
Hi Neil,
On Wed, Apr 3, 2024 at 9:46 AM Neil Armstrong wrote:
Disable the px_clk when setting the rate to recover a fully
configured and correctly reset VCLK clock tree after the rate
is set.
Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
index a6bc1bdb3d0d..a10cff3ca1fe 100644
--- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -95,6 +95,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ clk_disable_unprepare(mipi_dsi->px_clk);
nit-pick: clk_disable(mipi_dsi->px_clk); should be enough here as my
understanding is that we only need to {un,}prepare a clock once.
ret = clk_set_rate(mipi_dsi->px_clk, mipi_dsi->mode->clock * 1000);
if (ret) {
@@ -103,6 +104,12 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ ret = clk_prepare_enable(mipi_dsi->px_clk);
+ if (ret) {
+ dev_err(mipi_dsi->dev, "Failed to enable DSI Pixel clock (ret
%d)\n", ret);
+ return ret;
If we ever hit this error case then there will be a lot of additional
errors in the kernel log:
- initially the clock is prepared and enabled in
meson_dw_mipi_dsi_probe() by calling devm_clk_get_enabled()
- we then disable the clock above (generally disabling a clock is
expected to always succeed)
- if the clock can NOT be re-enabled here we just log the error
- in case a user tries to rmmod the driver (to modprobe it again) to
try and recover from an error the automatic disabling of the pix_clk
(based on devm_clk_get_enabled() where it was enabled initially) there
will be a splat because the clock is already disabled (and enabled
count is zero, so it cannot be disabled any further)
For the 32-bit SoC video clocks I keep track of them being enabled or
disabled, see [0], [1] and [2].
In my case this is important because we can run into cases where the
PLL doesn't lock (I am not sure how likely this is for your case).
It *seems* like we need to do something similar as
dw_mipi_dsi_phy_init() can be called when changing the display
resolution (or whenever drm_bridge_funcs.atomic_pre_enable) is called.
To illustrate what I have in mind I attached a diff (it's based on
this patch) - it's compile tested only as I have no DSI hardware.
In case dw_mipi_dsi_phy_init() is called only once per device
lifecycle things may get easier.
PS: I'm so happy that we don't need any clock notifiers for this!
So: good work with the clock driver bits.
I checked and tested your patches and it doesn't work because the pc_clk
needs to be disabled & prepared in order to correctly reset and setup again
the video clock tree.
dw_mipi_dsi_phy_init() is called at each DSI mode change, but it requires a
full clock tree recalc and reset, so it's safer to keep the current design.
I'll try to send a change to better handle the disable_unprepare() failure, but
definitely only calling clk_disable() wasn't enough.
Thanks,
Neil
Let me know what you think,
Martin
[0]
https://github.com/xdarklight/linux/blob/meson-mx-integration-6.9-20240323/drivers/gpu/drm/meson/meson_vclk.c#L1177-L1179
[1]
https://github.com/xdarklight/linux/blob/meson-mx-integration-6.9-20240323/drivers/gpu/drm/meson/meson_vclk.c#L1077
[2]
https://github.com/xdarklight/linux/blob/meson-mx-integration-6.9-20240323/drivers/gpu/drm/meson/meson_vclk.c#L1053
Re: [PATCH v4 0/2] Add driver for Raydium RM69380-based DSI panels
Hi, On Wed, 17 Apr 2024 18:29:32 +0200, David Wronek wrote: > This patch adds support the 2560x1600@90Hz dual DSI command mode panel by > EDO in combination with a Raydium RM69380 driver IC. > > This driver IC can be found in the following devices: > * Lenovo Xiaoxin Pad Pro 2021 (TB-J716F) with EDO panel > * Lenovo Tab P11 Pro (TB-J706F) with EDO panel > * Robo & Kala 2-in-1 Laptop with Sharp panel > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/2] dt-bindings: display: panel: Add Raydium RM69380 https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/4f888782d30276b08a32fa3d9b5c13b7dc123e28 [2/2] drm/panel: Add driver for EDO RM69380 OLED panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/9a314ea512b7db9d38107ea0284b56f805b8fc9a -- Neil
Re: [PATCH v3 0/2] drm/panel: add Khadas TS050 V2 panel support
Hi, On Fri, 19 Apr 2024 09:48:50 +0800, Jacobe Zang wrote: > Khadas has update its TS050 panel, the only different between the newer and > older is timing squence. In patches, add new TS050 panel named "ts050v2" as > make it compatible with the old one. > Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/2] dt-bindings: panel-simple-dsi: add Khadas TS050 V2 panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/0546e01d5a0269f02b4aa227f44b30a5a5558792 [2/2] drm/panel: add Khadas TS050 V2 panel support https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/26f9339212db569310d4b0ef4284efcbb462a86f -- Neil
Re: [PATCH v2 0/2] drm/panel: add Khadas TS050 V2 panel support
Hi, On Mon, 15 Apr 2024 11:14:06 +0800, Jacobe Zang wrote: > Changes from v1 at [1]: > - Fix name from "newts050" to "ts050v2" > - Add specific description about controller change > > [1]https://patchwork.kernel.org/project/linux-amlogic/list/?series=842707 > > Jacobe Zang (2): > dt-bindings: panel-simple-dsi: add Khadas TS050 V2 panel bindings > drm/panel: add Khadas TS050 V2 panel support > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/2] dt-bindings: panel-simple-dsi: add Khadas TS050 V2 panel bindings (no commit info) [2/2] drm/panel: add Khadas TS050 V2 panel support https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/26f9339212db569310d4b0ef4284efcbb462a86f -- Neil
Re: [PATCH v2 2/2] drm/panel: add Khadas TS050 V2 panel support
{0xcb, {0x02}, 0x01},
+ {0xcc, {0x1e}, 0x01},
+ {0xcd, {0x02}, 0x01},
+ {0xce, {0x20}, 0x01},
+ {0xcf, {0x02}, 0x01},
+ {0xd0, {0x52}, 0x01},
+ {0xd1, {0x02}, 0x01},
+ {0xd2, {0x88}, 0x01},
+ {0xd3, {0x02}, 0x01},
+ {0xd4, {0xaa}, 0x01},
+ {0xd5, {0x02}, 0x01},
+ {0xd6, {0xd7}, 0x01},
+ {0xd7, {0x02}, 0x01},
+ {0xd8, {0xf7}, 0x01},
+ {0xd9, {0x03}, 0x01},
+ {0xda, {0x21}, 0x01},
+ {0xdb, {0x03}, 0x01},
+ {0xdc, {0x2e}, 0x01},
+ {0xdd, {0x03}, 0x01},
+ {0xde, {0x3d}, 0x01},
+ {0xdf, {0x03}, 0x01},
+ {0xe0, {0x4c}, 0x01},
+ {0xe1, {0x03}, 0x01},
+ {0xe2, {0x5e}, 0x01},
+ {0xe3, {0x03}, 0x01},
+ {0xe4, {0x71}, 0x01},
+ {0xe5, {0x03}, 0x01},
+ {0xe6, {0x86}, 0x01},
+ {0xe7, {0x03}, 0x01},
+ {0xe8, {0x94}, 0x01},
+ {0xe9, {0x03}, 0x01},
+ {0xea, {0xfa}, 0x01},
/* Select CMD2 Page0 (Undocumented) */
- {0xff, 0x01},
+ {0xff, {0x01}, 0x01},
/* Reload CMD1: Don't reload default value to register */
- {0xfb, 0x01},
+ {0xfb, {0x01}, 0x01},
/* Select CMD2 Page1 (Undocumented) */
- {0xff, 0x02},
+ {0xff, {0x02}, 0x01},
/* Reload CMD1: Don't reload default value to register */
- {0xfb, 0x01},
+ {0xfb, {0x01}, 0x01},
/* Select CMD2 Page3 (Undocumented) */
- {0xff, 0x04},
+ {0xff, {0x04}, 0x01},
/* Reload CMD1: Don't reload default value to register */
- {0xfb, 0x01},
+ {0xfb, {0x01}, 0x01},
/* Select CMD1 */
- {0xff, 0x00},
- {0xd3, 0x22}, /* RGBMIPICTRL: VSYNC back porch = 34 */
- {0xd4, 0x04}, /* RGBMIPICTRL: VSYNC front porch = 4 */
+ {0xff, {0x00}, 0x01},
+ {0xd3, {0x22}, 0x01}, /* RGBMIPICTRL: VSYNC back porch = 34 */
+ {0xd4, {0x04}, 0x01}, /* RGBMIPICTRL: VSYNC front porch = 4 */
+};
+
+struct khadas_ts050_panel_data ts050_panel_data = {
+ .init_code = (struct khadas_ts050_panel_cmd *)ts050_init_code,
+ .len = ARRAY_SIZE(ts050_init_code)
+};
+
+struct khadas_ts050_panel_data ts050v2_panel_data = {
+ .init_code = (struct khadas_ts050_panel_cmd *)ts050v2_init_code,
+ .len = ARRAY_SIZE(ts050v2_init_code)
};
static inline
@@ -613,10 +671,11 @@ static int khadas_ts050_panel_prepare(struct drm_panel
*panel)
msleep(100);
- for (i = 0; i < ARRAY_SIZE(init_code); i++) {
+ for (i = 0; i < khadas_ts050->panel_data->len; i++) {
err = mipi_dsi_dcs_write(khadas_ts050->link,
-init_code[i].cmd,
-_code[i].data, 1);
+
khadas_ts050->panel_data->init_code[i].cmd,
+
_ts050->panel_data->init_code[i].data,
+
khadas_ts050->panel_data->init_code[i].size);
if (err < 0) {
dev_err(panel->dev, "failed write cmds: %d\n", err);
goto poweroff;
@@ -762,7 +821,8 @@ static const struct drm_panel_funcs
khadas_ts050_panel_funcs = {
};
static const struct of_device_id khadas_ts050_of_match[] = {
- { .compatible = "khadas,ts050", },
+ { .compatible = "khadas,ts050",.data = _panel_data, },
+ { .compatible = "khadas,ts050v2", .data = _panel_data, },
{ /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, khadas_ts050_of_match);
@@ -806,6 +866,13 @@ static int khadas_ts050_panel_probe(struct mipi_dsi_device
*dsi)
struct khadas_ts050_panel *khadas_ts050;
int err;
+ const void *data = of_device_get_match_data(>dev);
+
+ if (!data) {
+ dev_err(>dev, "No matching data\n");
+ return -ENODEV;
+ }
+
dsi->lanes = 4;
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
@@ -816,6 +883,7 @@ static int khadas_ts050_panel_probe(struct mipi_dsi_device
*dsi)
if (!khadas_ts050)
return -ENOMEM;
+ khadas_ts050->panel_data = (struct khadas_ts050_panel_data *)data;
mipi_dsi_set_drvdata(dsi, khadas_ts050);
khadas_ts050->link = dsi;
Reviewed-by: Neil Armstrong
Re: [PATCH v3 8/9] drm/panel: novatek-nt35950: Don't log an error when DSI host can't be found
On 15/04/2024 23:49, Nícolas F. R. A. Prado wrote:
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: 623a3531e9cf ("drm/panel: Add driver for Novatek NT35950 DSI DriverIC
panels")
Suggested-by: AngeloGioacchino Del Regno
Reviewed-by: Laurent Pinchart
Signed-off-by: Nícolas F. R. A. Prado
---
drivers/gpu/drm/panel/panel-novatek-nt35950.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35950.c
b/drivers/gpu/drm/panel/panel-novatek-nt35950.c
index 648ce9201426..028fdac293f7 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35950.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35950.c
@@ -556,10 +556,8 @@ static int nt35950_probe(struct mipi_dsi_device *dsi)
}
dsi_r_host = of_find_mipi_dsi_host_by_node(dsi_r);
of_node_put(dsi_r);
- if (!dsi_r_host) {
- dev_err(dev, "Cannot get secondary DSI host\n");
- return -EPROBE_DEFER;
- }
+ if (!dsi_r_host)
+ return dev_err_probe(dev, -EPROBE_DEFER, "Cannot get
secondary DSI host\n");
nt->dsi[1] = mipi_dsi_device_register_full(dsi_r_host, info);
if (!nt->dsi[1]) {
Reviewed-by: Neil Armstrong
Re: [PATCH 03/15] drm/panel-edp: switch to struct drm_edid
On 16/04/2024 15:22, Jani Nikula wrote:
Prefer struct drm_edid based functions over struct edid.
Signed-off-by: Jani Nikula
---
Cc: Douglas Anderson
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-edp.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index d29bacf25c12..ece1e3553c1f 100644
--- a/drivers/gpu/drm/panel/panel-edp.c
+++ b/drivers/gpu/drm/panel/panel-edp.c
@@ -242,7 +242,7 @@ struct panel_edp {
const struct edp_panel_entry *detected_panel;
- struct edid *edid;
+ const struct drm_edid *drm_edid;
struct drm_display_mode override_mode;
@@ -617,13 +617,16 @@ static int panel_edp_get_modes(struct drm_panel *panel,
if (p->ddc) {
pm_runtime_get_sync(panel->dev);
- if (!p->edid)
- p->edid = drm_get_edid(connector, p->ddc);
+ if (!p->drm_edid)
+ p->drm_edid = drm_edid_read_ddc(connector, p->ddc);
+
+ drm_edid_connector_update(connector, p->drm_edid);
+
/*
* If both edid and hard-coded modes exists, skip edid modes to
* avoid multiple preferred modes.
*/
- if (p->edid && !has_hard_coded_modes) {
+ if (p->drm_edid && !has_hard_coded_modes) {
if (has_override_edid_mode) {
/*
* override_edid_mode is specified. Use
@@ -632,7 +635,7 @@ static int panel_edp_get_modes(struct drm_panel *panel,
num += panel_edp_override_edid_mode(p,
connector,
p->detected_panel->override_edid_mode);
} else {
- num += drm_add_edid_modes(connector, p->edid);
+ num += drm_edid_connector_add_modes(connector);
}
}
@@ -981,8 +984,8 @@ static void panel_edp_remove(struct device *dev)
if (panel->ddc && (!panel->aux || panel->ddc != >aux->ddc))
put_device(>ddc->dev);
- kfree(panel->edid);
- panel->edid = NULL;
+ drm_edid_free(panel->drm_edid);
+ panel->drm_edid = NULL;
}
static void panel_edp_shutdown(struct device *dev)
Reviewed-by: Neil Armstrong
Re: [PATCH 02/15] drm/panel-samsung-atna33xc20: switch to struct drm_edid
On 16/04/2024 15:22, Jani Nikula wrote:
Prefer struct drm_edid based functions over struct edid.
Signed-off-by: Jani Nikula
---
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-samsung-atna33xc20.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c
b/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c
index 6828a4f24d14..a9f0d214a900 100644
--- a/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c
+++ b/drivers/gpu/drm/panel/panel-samsung-atna33xc20.c
@@ -36,7 +36,7 @@ struct atana33xc20_panel {
struct gpio_desc *el_on3_gpio;
struct drm_dp_aux *aux;
- struct edid *edid;
+ const struct drm_edid *drm_edid;
ktime_t powered_off_time;
ktime_t powered_on_time;
@@ -253,9 +253,12 @@ static int atana33xc20_get_modes(struct drm_panel *panel,
pm_runtime_get_sync(panel->dev);
- if (!p->edid)
- p->edid = drm_get_edid(connector, _ep->aux->ddc);
- num = drm_add_edid_modes(connector, p->edid);
+ if (!p->drm_edid)
+ p->drm_edid = drm_edid_read_ddc(connector, _ep->aux->ddc);
+
+ drm_edid_connector_update(connector, p->drm_edid);
+
+ num = drm_edid_connector_add_modes(connector);
pm_runtime_mark_last_busy(panel->dev);
pm_runtime_put_autosuspend(panel->dev);
@@ -351,7 +354,7 @@ static void atana33xc20_remove(struct dp_aux_ep_device
*aux_ep)
drm_panel_disable(>base);
drm_panel_unprepare(>base);
- kfree(panel->edid);
+ drm_edid_free(panel->drm_edid);
}
static void atana33xc20_shutdown(struct dp_aux_ep_device *aux_ep)
Reviewed-by: Neil Armstrong
Re: [PATCH 01/15] drm/panel: simple: switch to struct drm_edid
On 16/04/2024 15:22, Jani Nikula wrote:
Prefer struct drm_edid based functions over struct edid.
Signed-off-by: Jani Nikula
---
Cc: Neil Armstrong
Cc: Jessica Zhang
Cc: Sam Ravnborg
---
drivers/gpu/drm/panel/panel-simple.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 7215cf767898..d3264fa2f3ff 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -151,7 +151,7 @@ struct panel_simple {
struct gpio_desc *enable_gpio;
- struct edid *edid;
+ const struct drm_edid *drm_edid;
struct drm_display_mode override_mode;
@@ -309,8 +309,8 @@ static int panel_simple_suspend(struct device *dev)
regulator_disable(p->supply);
p->unprepared_time = ktime_get_boottime();
- kfree(p->edid);
- p->edid = NULL;
+ drm_edid_free(p->drm_edid);
+ p->drm_edid = NULL;
return 0;
}
@@ -399,11 +399,12 @@ static int panel_simple_get_modes(struct drm_panel *panel,
if (p->ddc) {
pm_runtime_get_sync(panel->dev);
- if (!p->edid)
- p->edid = drm_get_edid(connector, p->ddc);
+ if (!p->drm_edid)
+ p->drm_edid = drm_edid_read_ddc(connector, p->ddc);
- if (p->edid)
- num += drm_add_edid_modes(connector, p->edid);
+ drm_edid_connector_update(connector, p->drm_edid);
+
+ num += drm_edid_connector_add_modes(connector);
pm_runtime_mark_last_busy(panel->dev);
pm_runtime_put_autosuspend(panel->dev);
Reviewed-by: Neil Armstrong
Re: [PATCH v12 4/7] drm/meson: gate px_clk when setting rate
On 10/04/2024 21:34, Martin Blumenstingl wrote:
Hi Neil,
On Wed, Apr 3, 2024 at 9:46 AM Neil Armstrong wrote:
Disable the px_clk when setting the rate to recover a fully
configured and correctly reset VCLK clock tree after the rate
is set.
Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
index a6bc1bdb3d0d..a10cff3ca1fe 100644
--- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -95,6 +95,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ clk_disable_unprepare(mipi_dsi->px_clk);
nit-pick: clk_disable(mipi_dsi->px_clk); should be enough here as my
understanding is that we only need to {un,}prepare a clock once.
ret = clk_set_rate(mipi_dsi->px_clk, mipi_dsi->mode->clock * 1000);
if (ret) {
@@ -103,6 +104,12 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ ret = clk_prepare_enable(mipi_dsi->px_clk);
+ if (ret) {
+ dev_err(mipi_dsi->dev, "Failed to enable DSI Pixel clock (ret
%d)\n", ret);
+ return ret;
If we ever hit this error case then there will be a lot of additional
errors in the kernel log:
- initially the clock is prepared and enabled in
meson_dw_mipi_dsi_probe() by calling devm_clk_get_enabled()
- we then disable the clock above (generally disabling a clock is
expected to always succeed)
- if the clock can NOT be re-enabled here we just log the error
- in case a user tries to rmmod the driver (to modprobe it again) to
try and recover from an error the automatic disabling of the pix_clk
(based on devm_clk_get_enabled() where it was enabled initially) there
will be a splat because the clock is already disabled (and enabled
count is zero, so it cannot be disabled any further)
For the 32-bit SoC video clocks I keep track of them being enabled or
disabled, see [0], [1] and [2].
In my case this is important because we can run into cases where the
PLL doesn't lock (I am not sure how likely this is for your case).
It *seems* like we need to do something similar as
dw_mipi_dsi_phy_init() can be called when changing the display
resolution (or whenever drm_bridge_funcs.atomic_pre_enable) is called.
To illustrate what I have in mind I attached a diff (it's based on
this patch) - it's compile tested only as I have no DSI hardware.
In case dw_mipi_dsi_phy_init() is called only once per device
lifecycle things may get easier.
Indeed your scheme looks good, I'll try it since indeed we only need
to prepare it once in the lifetime of the driver.
PS: I'm so happy that we don't need any clock notifiers for this!
So: good work with the clock driver bits.
Thx !
Let me know what you think,
Martin
[0]
https://github.com/xdarklight/linux/blob/meson-mx-integration-6.9-20240323/drivers/gpu/drm/meson/meson_vclk.c#L1177-L1179
[1]
https://github.com/xdarklight/linux/blob/meson-mx-integration-6.9-20240323/drivers/gpu/drm/meson/meson_vclk.c#L1077
[2]
https://github.com/xdarklight/linux/blob/meson-mx-integration-6.9-20240323/drivers/gpu/drm/meson/meson_vclk.c#L1053
Re: [PATCH RESEND] drm/armada: drop unneeded MODULE_ALIAS
On 10/04/2024 10:22, Krzysztof Kozlowski wrote:
The MODULE_DEVICE_TABLE already creates proper alias for platform
driver. Having another MODULE_ALIAS causes the alias to be duplicated.
Signed-off-by: Krzysztof Kozlowski
---
Resent third time
https://lore.kernel.org/all/20220407202443.23000-1-krzysztof.kozlow...@linaro.org/
Cc: Dmitry Baryshkov
Cc: Neil Armstrong
---
drivers/gpu/drm/armada/armada_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index e51ecc4f7ef4..f48e2cf8de43 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -283,4 +283,3 @@ module_exit(armada_drm_exit);
MODULE_AUTHOR("Russell King ");
MODULE_DESCRIPTION("Armada DRM Driver");
MODULE_LICENSE("GPL");
-MODULE_ALIAS("platform:armada-drm");
Reviewed-by: Neil Armstrong
I think we'll need maxime or thomas ack to apply this via drm-misc-next
Neil
Re: [PATCH RESEND] drm: use capital "OR" for multiple licenses in SPDX
On 10/04/2024 10:22, Krzysztof Kozlowski wrote: Documentation/process/license-rules.rst expects the SPDX identifier syntax for multiple licenses to use capital "OR". Correct it to keep consistent format and avoid copy-paste issues. Signed-off-by: Krzysztof Kozlowski --- Resend... Cc: Dmitry Baryshkov Cc: Neil Armstrong --- drivers/gpu/drm/drm_client.c| 2 +- drivers/gpu/drm/drm_format_helper.c | 2 +- include/drm/drm_client.h| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c index 77fe217aeaf3..d8e3427ae205 100644 --- a/drivers/gpu/drm/drm_client.c +++ b/drivers/gpu/drm/drm_client.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 or MIT +// SPDX-License-Identifier: GPL-2.0 OR MIT /* * Copyright 2018 Noralf Trønnes */ diff --git a/drivers/gpu/drm/drm_format_helper.c b/drivers/gpu/drm/drm_format_helper.c index b1be458ed4dd..2348135fb6c0 100644 --- a/drivers/gpu/drm/drm_format_helper.c +++ b/drivers/gpu/drm/drm_format_helper.c @@ -1,4 +1,4 @@ -// SPDX-License-Identifier: GPL-2.0 or MIT +// SPDX-License-Identifier: GPL-2.0 OR MIT /* * Copyright (C) 2016 Noralf Trønnes * diff --git a/include/drm/drm_client.h b/include/drm/drm_client.h index bc0e66f9c425..1b907709115e 100644 --- a/include/drm/drm_client.h +++ b/include/drm/drm_client.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0 or MIT */ +/* SPDX-License-Identifier: GPL-2.0 OR MIT */ #ifndef _DRM_CLIENT_H_ #define _DRM_CLIENT_H_ Reviewed-by: Neil Armstrong I think we'll need maxime or thomas ack to apply this via drm-misc-next Neil
Re: [PATCH v11 0/7] drm/meson: add support for MIPI DSI Display
Hi, On Mon, 25 Mar 2024 12:09:46 +0100, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > [...] Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.10/arm64-dt) [1/7] dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module https://git.kernel.org/amlogic/c/ef5a84d716042871599ff7c8ff571a6390b99718 [2/7] clk: meson: add vclk driver (no commit info) [3/7] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF (no commit info) [4/7] drm/meson: gate px_clk when setting rate (no commit info) [5/7] arm64: meson: g12-common: add the MIPI DSI nodes https://git.kernel.org/amlogic/c/6f1c2a12ed1138c3e680935718672d361afee372 [6/7] arm64: meson: khadas-vim3l: add TS050 DSI panel overlay https://git.kernel.org/amlogic/c/2a885bad5ba4d553758d3f1689000cee8e6dae87 [7/7] arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper https://git.kernel.org/amlogic/c/fde2d69c1626bebb3a8851909c912e582db1ca95 These changes has been applied on the intermediate git tree [1]. The v6.10/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes. In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2]. The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists. If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset. [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -- Neil
Re: (subset) [PATCH v12 0/7] drm/meson: add support for MIPI DSI Display
Hi, On Wed, 03 Apr 2024 09:46:31 +0200, Neil Armstrong wrote: > The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver > (ver 1.21a), > with a custom glue managing the IP resets, clock and data input similar to > the DW-HDMI > glue on the same Amlogic SoCs. > > This is a follow-up of v5 now the DRM patches are applied, the clk & DT > changes > remains for a full DSI support on G12A & SM1 platforms. > > [...] Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v6.10/arm64-dt) [1/7] dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module https://git.kernel.org/amlogic/c/ef5a84d716042871599ff7c8ff571a6390b99718 [5/7] arm64: meson: g12-common: add the MIPI DSI nodes https://git.kernel.org/amlogic/c/6f1c2a12ed1138c3e680935718672d361afee372 [6/7] arm64: meson: khadas-vim3l: add TS050 DSI panel overlay https://git.kernel.org/amlogic/c/2a885bad5ba4d553758d3f1689000cee8e6dae87 [7/7] arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper https://git.kernel.org/amlogic/c/fde2d69c1626bebb3a8851909c912e582db1ca95 These changes has been applied on the intermediate git tree [1]. The v6.10/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers for inclusion in their intermediate git branches in order to be sent to Linus during the next merge window, or sooner if it's a set of fixes. In the cases of fixes, those will be merged in the current release candidate kernel and as soon they appear on the Linux master branch they will be backported to the previous Stable and Long-Stable kernels [2]. The intermediate git branches are merged daily in the linux-next tree [3], people are encouraged testing these pre-release kernels and report issues on the relevant mailing-lists. If problems are discovered on those changes, please submit a signed-off-by revert patch followed by a corrective changeset. [1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git [2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git -- Neil
Re: [PATCH 2/2] drm/panel: add New TS050 panel support
Hi Jacobe,
On 09/04/2024 10:29, Jacobe Zang wrote:
This add New TS050 Panel and make it compatible with old one.
Signed-off-by: Jacobe Zang
---
drivers/gpu/drm/panel/panel-khadas-ts050.c | 1112 +++-
1 file changed, 590 insertions(+), 522 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-khadas-ts050.c
b/drivers/gpu/drm/panel/panel-khadas-ts050.c
index b942a01622743..564b3c8ae4d91 100644
--- a/drivers/gpu/drm/panel/panel-khadas-ts050.c
+++ b/drivers/gpu/drm/panel/panel-khadas-ts050.c
@@ -25,6 +25,7 @@ struct khadas_ts050_panel {
struct regulator *supply;
struct gpio_desc *reset_gpio;
struct gpio_desc *enable_gpio;
+ struct khadas_ts050_panel_data *panel_data;
bool prepared;
bool enabled;
@@ -32,544 +33,601 @@ struct khadas_ts050_panel {
struct khadas_ts050_panel_cmd {
u8 cmd;
- u8 data;
+ u8 data[55];
+ u8 size;
+};
+
+struct khadas_ts050_panel_data {
+ struct khadas_ts050_panel_cmd *init_code;
+ int len;
+};
+
+static const struct khadas_ts050_panel_cmd new_ts050_init_code[] = {
+ {0xB9, {0xFF, 0x83, 0x99}, 0x03},
+ {0xBA, {0x63, 0x23, 0x68, 0xCF}, 0x04},
+ {0xD2, {0x55}, 0x01},
+ {0xB1, {0x02, 0x04, 0x70, 0x90, 0x01, 0x32, 0x33,
+ 0x11, 0x11, 0x4D, 0x57, 0x56, 0x73, 0x02, 0x02}, 0x0f},
+ {0xB2, {0x00, 0x80, 0x80, 0xAE, 0x0A, 0x0E, 0x75, 0x11, 0x00, 0x00,
0x00}, 0x0b},
+ {0xB4, {0x00, 0xFF, 0x04, 0xA4, 0x02, 0xA0, 0x00, 0x00, 0x10, 0x00,
0x00, 0x02,
+ 0x00, 0x24, 0x02, 0x04, 0x0A, 0x21, 0x03, 0x00,
0x00, 0x08, 0xA6, 0x88,
+ 0x04, 0xA4, 0x02, 0xA0, 0x00, 0x00, 0x10, 0x00,
0x00, 0x02, 0x00, 0x24,
+ 0x02, 0x04, 0x0A, 0x00, 0x00, 0x08, 0xA6, 0x00,
0x08, 0x11}, 0x2e},
+ {0xD3, {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x18,
+ 0x18, 0x32, 0x10, 0x09, 0x00, 0x09, 0x32,
+ 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+ 0x00, 0x00, 0x11, 0x00, 0x02, 0x02, 0x03, 0x00, 0x00,
0x00, 0x0A,
+ 0x40}, 0x21},
+ {0xD5, {0x18, 0x18, 0x18, 0x18, 0x21, 0x20, 0x18, 0x18, 0x19, 0x19,
0x19,
+ 0x19, 0x18, 0x18, 0x18, 0x18, 0x03, 0x02, 0x01, 0x00,
0x2F, 0x2F,
+ 0x30, 0x30, 0x31, 0x31, 0x18, 0x18, 0x18, 0x18, 0x18,
0x18}, 0x20},
+ {0xD6, {0x18, 0x18, 0x18, 0x18, 0x20, 0x21, 0x19, 0x19, 0x18, 0x18,
0x19,
+ 0x19, 0x18, 0x18, 0x18, 0x18, 0x00, 0x01, 0x02, 0x03,
0x2F, 0x2F,
+ 0x30, 0x30, 0x31, 0x31, 0x18, 0x18, 0x18, 0x18, 0x18,
0x18}, 0x20},
+ {0xD8, {0x0A, 0xBE, 0xFA, 0xA0, 0x0A, 0xBE, 0xFA, 0xA0}, 0x08},
+ {0xBD, {0x01}, 0x01},
+ {0xD8, {0x0F, 0xFF, 0xFF, 0xE0, 0x0F, 0xFF, 0xFF, 0xE0}, 0x08},
+ {0xBD, {0x02}, 0x01},
+ {0xD8, {0x0F, 0xFF, 0xFF, 0xE0, 0x0F, 0xFF, 0xFF, 0xE0}, 0x08},
+ {0xBD, {0x00}, 0x01},
+ {0xE0, {0x01, 0x35, 0x41, 0x3B, 0x79, 0x81, 0x8C, 0x85, 0x8E,
+ 0x95, 0x9B, 0xA0, 0xA4, 0xAB, 0xB1, 0xB3, 0xB7, 0xC5,
0xBD, 0xC5,
+ 0xB6, 0xC2, 0xC2, 0x62, 0x5D, 0x66, 0x73, 0x01, 0x35,
0x41, 0x3B,
+ 0x79, 0x81, 0x8C, 0x85, 0x8E, 0x95, 0x9B, 0xA0, 0xA4,
0xAB, 0xB1,
+ 0xB3, 0xB7, 0xB5, 0xBD, 0xC5, 0xB6, 0xC2, 0xC2, 0x62,
0x5D, 0x66,
+ 0x73}, 0x36},
+ {0xB6, {0x97, 0x97}, 0x02},
+ {0xCC, {0xC8}, 0x02},
+ {0xBF, {0x40, 0x41, 0x50, 0x19}, 0x04},
+ {0xC6, {0xFF, 0xF9}, 0x02},
+ {0xC0, {0x25, 0x5A}, 0x02},
};
This init sequence looks very very close to the ltk050h3146w one in
https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c#L247
could it probably be adding in this driver instead ? do you know which
controller is used in this new panel ?
Thanks,
Neil
/* Only the CMD1 User Command set is documented */
-static const struct khadas_ts050_panel_cmd init_code[] = {
+static const struct khadas_ts050_panel_cmd ts050_init_code[] = {
/* Select Unknown CMD Page (Undocumented) */
- {0xff, 0xee},
+ {0xff, {0xee}, 0x01},
/* Reload CMD1: Don't reload default value to register */
- {0xfb, 0x01},
- {0x1f, 0x45},
- {0x24, 0x4f},
- {0x38, 0xc8},
- {0x39, 0x27},
- {0x1e, 0x77},
- {0x1d, 0x0f},
- {0x7e, 0x71},
- {0x7c, 0x03},
- {0xff, 0x00},
- {0xfb, 0x01},
- {0x35, 0x01},
+ {0xfb, {0x01}, 0x01},
+ {0x1f, {0x45}, 0x01},
+ {0x24, {0x4f}, 0x01},
+ {0x38, {0xc8}, 0x01},
+ {0x39, {0x27}, 0x01},
+ {0x1e, {0x77}, 0x01},
+ {0x1d, {0x0f}, 0x01},
+ {0x7e, {0x71}, 0x01},
+ {0x7c, {0x03}, 0x01},
+ {0xff, {0x00}, 0x01},
+ {0xfb, {0x01}, 0x01},
+ {0x35, {0x01}, 0x01},
/* Select CMD2 Page0 (Undocumented) */
Re: Khadas VIM3/3L New TS050 support patch
Hi Jacobe, On 08/04/2024 15:16, Jacobe Zang wrote: Subject: [PATCH] drm/panel: add New TS050 Panel support Hello all, I have made some changes to the panel-khadas-ts050.c. Here is a brief overview of what has been done: - Add dt-bindings in document. - Add New TS050 Panel timing sequence. - Make it compatible with the old TS050 panel. - The only difference between them is the timing, so I change the node in overlay to identify the specific panel. - Changes in DTS doesn't push, because preceding commits have not been merged. The proposed changes have been successfully run on Khadas VIM3/3L. Please find the patch attached/inline. You should read https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html and perhaps use a tool like b4 (https://b4.docs.kernel.org/en/latest/) to send your patches in text only, you can follow https://www.marcusfolkesson.se/blog/use-b4-for-kernel-contributions/ for example. I'm afraid this patchset will be rejected and not reviewed if sent in this format with patches as attachments. Thanks, Neil Jacobe Zang (2): drm/panel: add New TS050 panel support dt-bindings: panel-simple-dsi: add New Khadas TS050 panel bindings drivers/gpu/drm/panel/panel-khadas-ts050.c | 1119 - Documentation/devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++ --- Best Regards Jacobe 臧介皓 Amazing Khadas, Always Amazes You!
Re: [PATCH v12 2/7] clk: meson: add vclk driver
On 05/04/2024 09:00, Jerome Brunet wrote:
On Thu 04 Apr 2024 at 18:59, Neil Armstrong wrote:
On 04/04/2024 10:13, Jerome Brunet wrote:
On Wed 03 Apr 2024 at 09:46, Neil Armstrong
wrote:
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK gate has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
The VCLK_DIV clocks as enable and reset bits used to disable
and reset the divider, associated with CLK_SET_RATE_GATE it ensures
the rate is set while the divider is disabled and in reset mode.
The VCLK_DIV enable bit isn't implemented as a gate since it's part
of the divider logic and vendor does this exact sequence to ensure
the divider is correctly set.
The checkpatch warning is still there. Is it a choice or a mistake ?
Documentation says "GPL v2" exists for historic reason which seems to
hint "GPL" is preferred, and I suppose this is why checkpatch warns for
it.
Well I didn't see this warning, this is what I fixed:
$ scripts/checkpatch.pl --strict drivers/clk/meson/vclk.c
CHECK: Alignment should match open parenthesis
#63: FILE: drivers/clk/meson/vclk.c:63:
+static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
CHECK: Alignment should match open parenthesis
#73: FILE: drivers/clk/meson/vclk.c:73:
+static int meson_vclk_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
CHECK: Alignment should match open parenthesis
#83: FILE: drivers/clk/meson/vclk.c:83:
+static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
I would not ask a respin solely for this. It's nice to fix it but I was
mostly after the warning TBH.
It seems that checking a commit triggers an extra check
$ scripts/checkpatch.pl --strict -G 1bac9f6aa3c3
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#58:
new file mode 100644
WARNING: Prefer "GPL" over "GPL v2" - see commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE
"GPL" vs. "GPL v2" bogosity")
#203: FILE: drivers/clk/meson/vclk.c:141:
+MODULE_LICENSE("GPL v2");
Hum, I'm running checkpatch against the mail itself, not the commit. I
still get the warning
Patch or commit seems to trigger more tests than a file directly, anyway I sent
a follow-up patch:
https://lore.kernel.org/all/20240408-amlogic-v6-9-upstream-fix-clk-module-license-v1-1-366ddc0f3...@linaro.org/
Thanks,
Neil
Neil
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 4 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/vclk.c | 141
+
drivers/clk/meson/vclk.h | 51
4 files changed, 197 insertions(+)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 29ffd14d267b..8a9823789fa3 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
tristate
select COMMON_CLK_MESON_REGMAP
+config COMMON_CLK_MESON_VCLK
+ tristate
+ select COMMON_CLK_MESON_REGMAP
+
config COMMON_CLK_MESON_CLKC_UTILS
tristate
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 9ee4b954c896..9ba43fe7a07a 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
+obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
# Amlogic Clock controllers
diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
new file mode 100644
index ..45dc216941ea
--- /dev/null
+++ b/drivers/clk/meson/vclk.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2024 Neil Armstrong
+ */
+
+#include
+#include "vclk.h"
+
+/* The VCLK gate has a supplementary reset bit to pulse after ungating */
+
+static inline struct meson_vclk_gate_data *
+clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
+{
+ return (struct meson_vclk_gate_data *)clk->data;
+}
+
+static int meson_vclk_gate_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, >enable, 1);
+
+ /* Do a reset pulse */
+ meson_parm_write(clk->map, >reset, 1);
+ meson_parm_write(clk->map, >reset, 0);
+
+ return 0;
+}
+
+static void meson_vclk_gate_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_
Re: [PATCH v12 2/7] clk: meson: add vclk driver
On 04/04/2024 10:13, Jerome Brunet wrote:
On Wed 03 Apr 2024 at 09:46, Neil Armstrong wrote:
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK gate has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
The VCLK_DIV clocks as enable and reset bits used to disable
and reset the divider, associated with CLK_SET_RATE_GATE it ensures
the rate is set while the divider is disabled and in reset mode.
The VCLK_DIV enable bit isn't implemented as a gate since it's part
of the divider logic and vendor does this exact sequence to ensure
the divider is correctly set.
The checkpatch warning is still there. Is it a choice or a mistake ?
Documentation says "GPL v2" exists for historic reason which seems to
hint "GPL" is preferred, and I suppose this is why checkpatch warns for
it.
Well I didn't see this warning, this is what I fixed:
$ scripts/checkpatch.pl --strict drivers/clk/meson/vclk.c
CHECK: Alignment should match open parenthesis
#63: FILE: drivers/clk/meson/vclk.c:63:
+static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
+unsigned long prate)
CHECK: Alignment should match open parenthesis
#73: FILE: drivers/clk/meson/vclk.c:73:
+static int meson_vclk_div_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
CHECK: Alignment should match open parenthesis
#83: FILE: drivers/clk/meson/vclk.c:83:
+static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
It seems that checking a commit triggers an extra check
$ scripts/checkpatch.pl --strict -G 1bac9f6aa3c3
WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
#58:
new file mode 100644
WARNING: Prefer "GPL" over "GPL v2" - see commit bf7fbeeae6db ("module: Cure the MODULE_LICENSE
"GPL" vs. "GPL v2" bogosity")
#203: FILE: drivers/clk/meson/vclk.c:141:
+MODULE_LICENSE("GPL v2");
Neil
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 4 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/vclk.c | 141 +
drivers/clk/meson/vclk.h | 51
4 files changed, 197 insertions(+)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 29ffd14d267b..8a9823789fa3 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
tristate
select COMMON_CLK_MESON_REGMAP
+config COMMON_CLK_MESON_VCLK
+ tristate
+ select COMMON_CLK_MESON_REGMAP
+
config COMMON_CLK_MESON_CLKC_UTILS
tristate
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 9ee4b954c896..9ba43fe7a07a 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
+obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
# Amlogic Clock controllers
diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
new file mode 100644
index ..45dc216941ea
--- /dev/null
+++ b/drivers/clk/meson/vclk.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2024 Neil Armstrong
+ */
+
+#include
+#include "vclk.h"
+
+/* The VCLK gate has a supplementary reset bit to pulse after ungating */
+
+static inline struct meson_vclk_gate_data *
+clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
+{
+ return (struct meson_vclk_gate_data *)clk->data;
+}
+
+static int meson_vclk_gate_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, >enable, 1);
+
+ /* Do a reset pulse */
+ meson_parm_write(clk->map, >reset, 1);
+ meson_parm_write(clk->map, >reset, 0);
+
+ return 0;
+}
+
+static void meson_vclk_gate_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, >enable, 0);
+}
+
+static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ return meson_parm_read(clk->map, >enable);
+}
+
+const struct clk_ops meson_vclk_gate_ops = {
+ .enable = meson_vclk_gate_enable,
+ .disable = meson_vclk_ga
[PATCH v12 7/7] arm64: dts: amlogic: meson-g12b-bananapi-cm4: add support for MNT Reform2 with CM4 adaper
This adds a basic devicetree for the MNT Reform2 DIY laptop when using a
CM4 adapter and a BPI-CM4 module.
Co-developed-by: Lukas F. Hartmann
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../meson-g12b-bananapi-cm4-mnt-reform2.dts| 384 +
2 files changed, 385 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index 0b7961de3db7..d525e5123fbc 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -18,6 +18,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-bananapi-m2s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3-ts050.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-cm4io.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-mnt-reform2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gsking-x.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking.dtb
diff --git
a/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
b/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
new file mode 100644
index ..003efed529ba
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-reform2.dts
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Neil Armstrong
+ * Copyright 2023 MNT Research GmbH
+ */
+
+/dts-v1/;
+
+#include "meson-g12b-bananapi-cm4.dtsi"
+#include
+#include
+#include
+
+/ {
+ model = "MNT Reform 2 with BPI-CM4 Module";
+ compatible = "mntre,reform2-cm4", "bananapi,bpi-cm4", "amlogic,a311d",
"amlogic,g12b";
+ chassis-type = "laptop";
+
+ aliases {
+ ethernet0 =
+ i2c0 =
+ i2c1 =
+ };
+
+ hdmi_connector: hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <_tx_tmds_out>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-blue {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ gpios = <_ao GPIOAO_7 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-green {
+ color = ;
+ function = LED_FUNCTION_STATUS;
+ gpios = <_ao GPIOAO_2 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ sound {
+ compatible = "amlogic,axg-sound-card";
+ model = "MNT-REFORM2-BPI-CM4";
+ audio-widgets = "Headphone", "Headphone Jack",
+ "Speaker", "External Speaker",
+ "Microphone", "Mic Jack";
+ audio-aux-devs = <_a>, <_b>, <_b>;
+ audio-routing = "TDMOUT_A IN 0", "FRDDR_A OUT 0",
+ "TDMOUT_A IN 1", "FRDDR_B OUT 0",
+ "TDMOUT_A IN 2", "FRDDR_C OUT 0",
+ "TDM_A Playback", "TDMOUT_A OUT",
+ "TDMOUT_B IN 0", "FRDDR_A OUT 1",
+ "TDMOUT_B IN 1", "FRDDR_B OUT 1",
+ "TDMOUT_B IN 2", "FRDDR_C OUT 1",
+ "TDM_B Playback", "TDMOUT_B OUT",
+ "TDMIN_B IN 1", "TDM_B Capture",
+ "TDMIN_B IN 4", "TDM_B Loopback",
+ "TODDR_A IN 1", "TDMIN_B OUT",
+ "TODDR_B IN 1", "TDMIN_B OUT",
+ "TODDR_C IN 1", "TDMIN_B OUT",
+ "Headphone Jack", "HP_L",
+ "Headphone Jack", "HP_R",
+ "External Speaker", "SPK_LP",
+ "External Speaker", "SPK_LN",
+ "External Speaker", "SPK_RP",
+ "External Speaker", "SPK_RN",
+ "L
[PATCH v12 4/7] drm/meson: gate px_clk when setting rate
Disable the px_clk when setting the rate to recover a fully
configured and correctly reset VCLK clock tree after the rate
is set.
Fixes: 77d9e1e6b846 ("drm/meson: add support for MIPI-DSI transceiver")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_mipi_dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
index a6bc1bdb3d0d..a10cff3ca1fe 100644
--- a/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
+++ b/drivers/gpu/drm/meson/meson_dw_mipi_dsi.c
@@ -95,6 +95,7 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ clk_disable_unprepare(mipi_dsi->px_clk);
ret = clk_set_rate(mipi_dsi->px_clk, mipi_dsi->mode->clock * 1000);
if (ret) {
@@ -103,6 +104,12 @@ static int dw_mipi_dsi_phy_init(void *priv_data)
return ret;
}
+ ret = clk_prepare_enable(mipi_dsi->px_clk);
+ if (ret) {
+ dev_err(mipi_dsi->dev, "Failed to enable DSI Pixel clock (ret
%d)\n", ret);
+ return ret;
+ }
+
switch (mipi_dsi->dsi_device->format) {
case MIPI_DSI_FMT_RGB888:
dpi_data_format = DPI_COLOR_24BIT;
--
2.34.1
[PATCH v12 5/7] arm64: meson: g12-common: add the MIPI DSI nodes
Add the MIPI DSI Analog & Digital PHY nodes and the DSI control
nodes with proper port endpoint to the VPU.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 70 +++
1 file changed, 70 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
index 9d5eab6595d0..b058ed78faf0 100644
--- a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
@@ -1663,9 +1663,28 @@ pwrc: power-controller {
<25000>,
<0>; /*
Do Nothing */
};
+
+ mipi_analog_dphy: phy {
+ compatible =
"amlogic,g12a-mipi-dphy-analog";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
};
};
+ mipi_dphy: phy@44000 {
+ compatible = "amlogic,axg-mipi-dphy";
+ reg = <0x0 0x44000 0x0 0x2000>;
+ clocks = < CLKID_MIPI_DSI_PHY>;
+ clock-names = "pclk";
+ resets = < RESET_MIPI_DSI_PHY>;
+ reset-names = "phy";
+ phys = <_analog_dphy>;
+ phy-names = "analog";
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+
usb3_pcie_phy: phy@46000 {
compatible = "amlogic,g12a-usb3-pcie-phy";
reg = <0x0 0x46000 0x0 0x2000>;
@@ -2152,6 +2171,15 @@ hdmi_tx_out: endpoint {
remote-endpoint = <_tx_in>;
};
};
+
+ /* DPI output port */
+ dpi_port: port@2 {
+ reg = <2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <_dsi_in>;
+ };
+ };
};
gic: interrupt-controller@ffc01000 {
@@ -2189,6 +2217,48 @@ gpio_intc: interrupt-controller@f080 {
amlogic,channel-interrupts = <64 65 66 67 68 69
70 71>;
};
+ mipi_dsi: dsi@7000 {
+ compatible = "amlogic,meson-g12a-dw-mipi-dsi";
+ reg = <0x0 0x7000 0x0 0x1000>;
+ resets = < RESET_MIPI_DSI_HOST>;
+ reset-names = "top";
+ clocks = < CLKID_MIPI_DSI_HOST>,
+< CLKID_MIPI_DSI_PXCLK>,
+< CLKID_CTS_ENCL>;
+ clock-names = "pclk", "bit", "px";
+ phys = <_dphy>;
+ phy-names = "dphy";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+
+ assigned-clocks = <
CLKID_MIPI_DSI_PXCLK_SEL>,
+< CLKID_CTS_ENCL_SEL>,
+< CLKID_VCLK2_SEL>;
+ assigned-clock-parents = < CLKID_GP0_PLL>,
+< CLKID_VCLK2_DIV1>,
+< CLKID_GP0_PLL>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VPU VENC Input */
+ mipi_dsi_venc_port: port@0 {
+ reg = <0>;
+
+ mipi_dsi_in: endpoint {
+ remote-endpoint =
<_out>;
+ };
+ };
+
[PATCH v12 6/7] arm64: meson: khadas-vim3l: add TS050 DSI panel overlay
This add dtbo overlay to support the Khadas TS050 panel on the
Khadas VIM3 & VIM3L boards.
Signed-off-by: Neil Armstrong
---
arch/arm64/boot/dts/amlogic/Makefile | 4 +
.../boot/dts/amlogic/meson-khadas-vim3-ts050.dtso | 108 +
2 files changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/Makefile
b/arch/arm64/boot/dts/amlogic/Makefile
index 1ab160bf928a..0b7961de3db7 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -16,6 +16,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-g12a-u200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12a-x96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-bananapi-m2s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-g12b-a311d-khadas-vim3-ts050.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-bananapi-cm4-cm4io.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gsking-x.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-g12b-gtking-pro.dtb
@@ -76,6 +77,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m2-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-bananapi-m5.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-h96-max.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-khadas-vim3l-ts050.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-s905d3-libretech-cc.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-c4.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-odroid-hc4.dtb
@@ -86,3 +88,5 @@ dtb-$(CONFIG_ARCH_MESON) += meson-sm1-x96-air.dtb
# Overlays
meson-g12a-fbx8am-brcm-dtbs:= meson-g12a-fbx8am.dtb
meson-g12a-fbx8am-brcm.dtbo
meson-g12a-fbx8am-realtek-dtbs := meson-g12a-fbx8am.dtb
meson-g12a-fbx8am-realtek.dtbo
+meson-g12b-a311d-khadas-vim3-ts050-dtbs := meson-g12b-a311d-khadas-vim3.dtb
meson-khadas-vim3-ts050.dtbo
+meson-sm1-khadas-vim3l-ts050-dtbs := meson-sm1-khadas-vim3l.dtb
meson-khadas-vim3-ts050.dtbo
diff --git a/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
new file mode 100644
index ..a41b4e619580
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-khadas-vim3-ts050.dtso
@@ -0,0 +1,108 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/dts-v1/;
+/plugin/;
+
+/*
+ * Enable Khadas TS050 DSI Panel + Touch Controller
+ * on Khadas VIM3 (A311D) and VIM3L (S905D3)
+ */
+
+&{/} {
+ panel_backlight: backlight {
+ compatible = "pwm-backlight";
+ pwms = <_AO_cd 0 25000 0>;
+ brightness-levels = <0 255>;
+ num-interpolated-steps = <255>;
+ default-brightness-level = <200>;
+ };
+};
+
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-0 = <_sda_a_pins>, <_sck_a_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ touch-controller@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ interrupt-parent = <_intc>;
+ interrupts = ;
+ reset-gpios = <_expander 6 GPIO_ACTIVE_LOW>;
+ touchscreen-size-x = <1080>;
+ touchscreen-size-y = <1920>;
+ status = "okay";
+ };
+};
+
+_dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ assigned-clocks = < CLKID_GP0_PLL>,
+ < CLKID_MIPI_DSI_PXCLK_SEL>,
+ < CLKID_MIPI_DSI_PXCLK>,
+ < CLKID_CTS_ENCL_SEL>,
+ < CLKID_VCLK2_SEL>;
+ assigned-clock-parents = <0>,
+< CLKID_GP0_PLL>,
+<0>,
+< CLKID_VCLK2_DIV1>,
+< CLKID_GP0_PLL>;
+ assigned-clock-rates = <96000>,
+ <0>,
+ <96000>,
+ <0>,
+ <0>;
+
+ panel@0 {
+ compatible = "khadas,ts050";
+ reset-gpios = <_expander 0 GPIO_ACTIVE_LOW>;
+ enable-gpios = <_expander 1 GPIO_ACTIVE_HIGH>;
+ power-supply = <_3v3>;
+ backlight = <_backlight>;
+ reg = <0>;
+
+ port {
+ mipi_in_panel: endpoint {
+ remote-endpoint = <_out_panel>;
+ };
+ };
+ };
+
+ ports {
+ #address-cells = <
[PATCH v12 3/7] clk: meson: g12a: make VCLK2 and ENCL clock path configurable by CCF
In order to setup the DSI clock, let's make the unused VCLK2 clock path
configuration via CCF.
The nocache option is removed from following clocks:
- vclk2_sel
- vclk2_input
- vclk2_div
- vclk2
- vclk_div1
- vclk2_div2_en
- vclk2_div4_en
- vclk2_div6_en
- vclk2_div12_en
- vclk2_div2
- vclk2_div4
- vclk2_div6
- vclk2_div12
- cts_encl_sel
vclk2 and vclk2_div uses the newly introduced vclk regmap driver
to handle the enable and reset bits.
In order to set a rate on cts_encl via the vclk2 clock path,
the NO_REPARENT flag is set on cts_encl_sel & vclk2_sel in order
to keep CCF from selection a parent.
The parents of cts_encl_sel & vclk2_sel are expected to be defined
in DT or manually set by the display driver at some point.
The following clock scheme is to be used for DSI:
xtal
\_ gp0_pll_dco
\_ gp0_pll
|- vclk2_sel
| \_ vclk2_input
| \_ vclk2_div
|\_ vclk2
| \_ vclk2_div1
| \_ cts_encl_sel
| \_ cts_encl -> to VPU LCD Encoder
|- mipi_dsi_pxclk_sel
\_ mipi_dsi_pxclk_div
\_ mipi_dsi_pxclk -> to DSI controller
The mipi_dsi_pxclk_div is set as bypass with a single /1 entry in div_table
in order to use the same GP0 for mipi_dsi_pxclk and vclk2_input.
The SET_RATE_PARENT is only set on the mipi_dsi_pxclk_sel clock so the
DSI bitclock is the reference base clock to calculate the vclk2_div value
when pixel clock is set on the cts_encl endpoint.
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 1 +
drivers/clk/meson/g12a.c | 76 ++-
2 files changed, 57 insertions(+), 20 deletions(-)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 8a9823789fa3..59a40a49f8e1 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -144,6 +144,7 @@ config COMMON_CLK_G12A
select COMMON_CLK_MESON_EE_CLKC
select COMMON_CLK_MESON_CPU_DYNDIV
select COMMON_CLK_MESON_VID_PLL_DIV
+ select COMMON_CLK_MESON_VCLK
select MFD_SYSCON
help
Support for the clock controller on Amlogic S905D2, S905X2 and S905Y2
diff --git a/drivers/clk/meson/g12a.c b/drivers/clk/meson/g12a.c
index 90f4c6103014..df7e17c850d8 100644
--- a/drivers/clk/meson/g12a.c
+++ b/drivers/clk/meson/g12a.c
@@ -22,6 +22,7 @@
#include "clk-regmap.h"
#include "clk-cpu-dyndiv.h"
#include "vid-pll-div.h"
+#include "vclk.h"
#include "meson-eeclk.h"
#include "g12a.h"
@@ -3165,7 +3166,7 @@ static struct clk_regmap g12a_vclk2_sel = {
.ops = _regmap_mux_ops,
.parent_hws = g12a_vclk_parent_hws,
.num_parents = ARRAY_SIZE(g12a_vclk_parent_hws),
- .flags = CLK_SET_RATE_NO_REPARENT | CLK_GET_RATE_NOCACHE,
+ .flags = CLK_SET_RATE_NO_REPARENT,
},
};
@@ -3193,7 +3194,6 @@ static struct clk_regmap g12a_vclk2_input = {
.ops = _regmap_gate_ops,
.parent_hws = (const struct clk_hw *[]) { _vclk2_sel.hw },
.num_parents = 1,
- .flags = CLK_SET_RATE_PARENT | CLK_IGNORE_UNUSED,
},
};
@@ -3215,19 +3215,32 @@ static struct clk_regmap g12a_vclk_div = {
};
static struct clk_regmap g12a_vclk2_div = {
- .data = &(struct clk_regmap_div_data){
- .offset = HHI_VIID_CLK_DIV,
- .shift = 0,
- .width = 8,
+ .data = &(struct meson_vclk_div_data){
+ .div = {
+ .reg_off = HHI_VIID_CLK_DIV,
+ .shift = 0,
+ .width = 8,
+ },
+ .enable = {
+ .reg_off = HHI_VIID_CLK_DIV,
+ .shift = 16,
+ .width = 1,
+ },
+ .reset = {
+ .reg_off = HHI_VIID_CLK_DIV,
+ .shift = 17,
+ .width = 1,
+ },
+ .flags = CLK_DIVIDER_ROUND_CLOSEST,
},
.hw.init = &(struct clk_init_data){
.name = "vclk2_div",
- .ops = _regmap_divider_ops,
+ .ops = _vclk_div_ops,
.parent_hws = (const struct clk_hw *[]) {
_vclk2_input.hw
},
.num_parents = 1,
- .flags = CLK_GET_RATE_NOCACHE,
+ .flags = CLK_SET_RATE_GATE,
},
};
@@ -3246,16 +3259,24 @@ static struct clk_regmap g12a_vclk = {
};
static struct clk_regmap g12a_vclk2 = {
- .data = &(struct clk_regmap_gate_data){
- .offset = HHI_VIID_CLK_CNTL,
- .bit_idx = 19,
+ .data = &(struct meson_vclk_gate_data){
+ .enable = {
+ .
[PATCH v12 2/7] clk: meson: add vclk driver
The VCLK and VCLK_DIV clocks have supplementary bits.
The VCLK gate has a "SOFT RESET" bit to toggle after the whole
VCLK sub-tree rate has been set, this is implemented in
the gate enable callback.
The VCLK_DIV clocks as enable and reset bits used to disable
and reset the divider, associated with CLK_SET_RATE_GATE it ensures
the rate is set while the divider is disabled and in reset mode.
The VCLK_DIV enable bit isn't implemented as a gate since it's part
of the divider logic and vendor does this exact sequence to ensure
the divider is correctly set.
Signed-off-by: Neil Armstrong
---
drivers/clk/meson/Kconfig | 4 ++
drivers/clk/meson/Makefile | 1 +
drivers/clk/meson/vclk.c | 141 +
drivers/clk/meson/vclk.h | 51
4 files changed, 197 insertions(+)
diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
index 29ffd14d267b..8a9823789fa3 100644
--- a/drivers/clk/meson/Kconfig
+++ b/drivers/clk/meson/Kconfig
@@ -30,6 +30,10 @@ config COMMON_CLK_MESON_VID_PLL_DIV
tristate
select COMMON_CLK_MESON_REGMAP
+config COMMON_CLK_MESON_VCLK
+ tristate
+ select COMMON_CLK_MESON_REGMAP
+
config COMMON_CLK_MESON_CLKC_UTILS
tristate
diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
index 9ee4b954c896..9ba43fe7a07a 100644
--- a/drivers/clk/meson/Makefile
+++ b/drivers/clk/meson/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_COMMON_CLK_MESON_PLL) += clk-pll.o
obj-$(CONFIG_COMMON_CLK_MESON_REGMAP) += clk-regmap.o
obj-$(CONFIG_COMMON_CLK_MESON_SCLK_DIV) += sclk-div.o
obj-$(CONFIG_COMMON_CLK_MESON_VID_PLL_DIV) += vid-pll-div.o
+obj-$(CONFIG_COMMON_CLK_MESON_VCLK) += vclk.o
# Amlogic Clock controllers
diff --git a/drivers/clk/meson/vclk.c b/drivers/clk/meson/vclk.c
new file mode 100644
index ..45dc216941ea
--- /dev/null
+++ b/drivers/clk/meson/vclk.c
@@ -0,0 +1,141 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2024 Neil Armstrong
+ */
+
+#include
+#include "vclk.h"
+
+/* The VCLK gate has a supplementary reset bit to pulse after ungating */
+
+static inline struct meson_vclk_gate_data *
+clk_get_meson_vclk_gate_data(struct clk_regmap *clk)
+{
+ return (struct meson_vclk_gate_data *)clk->data;
+}
+
+static int meson_vclk_gate_enable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, >enable, 1);
+
+ /* Do a reset pulse */
+ meson_parm_write(clk->map, >reset, 1);
+ meson_parm_write(clk->map, >reset, 0);
+
+ return 0;
+}
+
+static void meson_vclk_gate_disable(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ meson_parm_write(clk->map, >enable, 0);
+}
+
+static int meson_vclk_gate_is_enabled(struct clk_hw *hw)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_gate_data *vclk = clk_get_meson_vclk_gate_data(clk);
+
+ return meson_parm_read(clk->map, >enable);
+}
+
+const struct clk_ops meson_vclk_gate_ops = {
+ .enable = meson_vclk_gate_enable,
+ .disable = meson_vclk_gate_disable,
+ .is_enabled = meson_vclk_gate_is_enabled,
+};
+EXPORT_SYMBOL_GPL(meson_vclk_gate_ops);
+
+/* The VCLK Divider has supplementary reset & enable bits */
+
+static inline struct meson_vclk_div_data *
+clk_get_meson_vclk_div_data(struct clk_regmap *clk)
+{
+ return (struct meson_vclk_div_data *)clk->data;
+}
+
+static unsigned long meson_vclk_div_recalc_rate(struct clk_hw *hw,
+ unsigned long prate)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+
+ return divider_recalc_rate(hw, prate, meson_parm_read(clk->map,
>div),
+ vclk->table, vclk->flags, vclk->div.width);
+}
+
+static int meson_vclk_div_determine_rate(struct clk_hw *hw,
+struct clk_rate_request *req)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+
+ return divider_determine_rate(hw, req, vclk->table, vclk->div.width,
+ vclk->flags);
+}
+
+static int meson_vclk_div_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+ struct clk_regmap *clk = to_clk_regmap(hw);
+ struct meson_vclk_div_data *vclk = clk_get_meson_vclk_div_data(clk);
+ int ret;
+
+ ret = divider_get_val(rate, parent_rate, vclk->table, vclk->div.width,
+ vclk->flags);
+ if (ret <
[PATCH v12 1/7] dt-bindings: arm: amlogic: Document the MNT Reform 2 CM4 adapter with a BPI-CM4 Module
The MNT Reform 2 CM4 adapter can be populated with any Raspberry Pi CM4 compatible module such as a BPI-CM4 Module, document that. Acked-by: Conor Dooley Signed-off-by: Neil Armstrong --- Documentation/devicetree/bindings/arm/amlogic.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 949537cea6be..b66b93b8bfd3 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -157,6 +157,7 @@ properties: items: - enum: - bananapi,bpi-cm4io + - mntre,reform2-cm4 - const: bananapi,bpi-cm4 - const: amlogic,a311d - const: amlogic,g12b -- 2.34.1
[PATCH v12 0/7] drm/meson: add support for MIPI DSI Display
The Amlogic G12A, G12B & SM1 SoCs embeds a Synopsys DW-MIPI-DSI transceiver (ver 1.21a), with a custom glue managing the IP resets, clock and data input similar to the DW-HDMI glue on the same Amlogic SoCs. This is a follow-up of v5 now the DRM patches are applied, the clk & DT changes remains for a full DSI support on G12A & SM1 platforms. The DW-MIPI-DSI transceiver + D-PHY are clocked by the GP0 PLL, and the ENCL encoder + VIU pixel reader by the VCLK2 clock using the HDMI PLL. The DW-MIPI-DSI transceiver gets this pixel stream as input clocked with the VCLK2 clock. An optional "MEAS" clock can be enabled to measure the delay between each vsync feeding the DW-MIPI-DSI transceiver. The clock setup has been redesigned to use CCF, a common PLL (GP0) and the VCLK2 clock path for DSI in preparation of full CCF support and possibly dual display with HDMI. The change from v5 is that now we use a "VCLK" driver instead of notifier and rely on CLK_SET_RATE_GATE to ensure the VCLK gate operation are called. Signed-off-by: Neil Armstrong --- Changes in v12: - fix parameters alignment in patch 2 - update g12a_mipi_dsi_pxclk_div_table comment with jerome's suggestions - fix dtbs overlay build, fix missed v11... thx khadas for reporting it off-list & testing - Link to v11: https://lore.kernel.org/r/20240325-amlogic-v6-4-upstream-dsi-ccf-vim3-v11-0-04f55de44...@linaro.org Changes in v11: - Rebased on v6.9-rc1 - Fixed overlay handling/creation - Link to v10: https://lore.kernel.org/r/20240205-amlogic-v6-4-upstream-dsi-ccf-vim3-v10-0-dc06073d5...@linaro.org Changes in v10: - Rename regmap_vclk to meson_clk and add _gate for the gate - Move COMMON_CLK_MESON_VCLK to following patch - Remove CLK_SET_RATE_PARENT from g12a_vclk2_sel, keep it only on mipi_dsi_pxclk_sel - Add more info on commit message to specify how clock setup is designed - Remove forgotten CLK_IGNORE_UNUSED on g12a_vclk2_input - Remove useless CLK_SET_RATE_PARENT on g12a_vclk2_div to stop propagatting rate _after_ vclk2_div - Remove invalid CLK_SET_RATE_GATE on g12a_vclk2 since it's not a divider... - Drop already applied patches - move Khadas TS050 changes as an overlay - Link to v9: https://lore.kernel.org/r/20231124-amlogic-v6-4-upstream-dsi-ccf-vim3-v9-0-95256ed13...@linaro.org Changes in v9: - Colledte reviewed-bys - Fixed patches 2 & 4, commit messages and bindings format - Link to v8: https://lore.kernel.org/r/20231109-amlogic-v6-4-upstream-dsi-ccf-vim3-v8-0-81e4aeeda...@linaro.org Changes in v8: - Switch vclk clk driver to parm as requested by Jerome - Added bindings fixes to amlogic,meson-axg-mipi-pcie-analog & amlogic,g12a-mipi-dphy-analog - Fixed DT errors in vim3 example and MNT Reform DT - Rebased on next-20231107, successfully tested on VIM3L - Link to v7: https://lore.kernel.org/r/20230803-amlogic-v6-4-upstream-dsi-ccf-vim3-v7-0-762219fc5...@linaro.org Changes in v7: - Added review tags - Fixed patch 5 thanks to George - Link to v6: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v6-0-fd2ac9845...@linaro.org Changes in v6: - dropped applied DRM patches - dropped clk private prefix patches - rebased on top of 20230607-topic-amlogic-upstream-clkid-public-migration-v2-0-38172d17c...@linaro.org - re-ordered/cleaned ENCL patches to match clkid public migration - Added new "vclk" driver - uses vclk driver instead of notifier - cleaned VCLK2 clk flags - add px_clk gating from DSI driver - Link to v5: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v5-0-56eb7a4d5...@linaro.org Changes in v5: - Aded PRIV all the G12 internal clk IDS to simplify public exposing - Fixed the DSI bindings - Fixed the DSI HSYNC/VSYNC polarity handling - Fixed the DSI clock setup - Fixed the DSI phy timings - Dropped components for DSI, only keeping it for HDMI - Added MNT Reform 2 CM4 DT - Dropped already applied PHY fix - Link to v4: https://lore.kernel.org/r/20230512-amlogic-v6-4-upstream-dsi-ccf-vim3-v4-0-2592c29ea...@linaro.org Changes from v3 at [3]: - switched all clk setup via CCF - using single PLL for DSI controller & ENCL encoder - added ENCL clocks to CCF - make the VCLK2 clocks configuration by CCF - fixed probe/bind of DSI controller to work with panels & bridges - added bit_clk to controller to it can setup the BIT clock aswell - added fix for components unbind - added fix for analog phy setup value - added TS050 timings fix - dropped previous clk control patch Changes from v2 at [2]: - Fixed patch 3 - Added reviews from Jagan - Rebased on v5.19-rc1 Changes from v1 at [1]: - fixed DSI host bindings - add reviewed-by tags for bindings - moved magic values to defines thanks to Martin's searches - added proper prefixes to defines - moved phy_configure to phy_init() dw-mipi-dsi callback - moved phy_on to a new phy_power_on() dw-mipi-dsi callback - correctly return phy_init/configure errors to callback return
Re: [PATCH] drm/meson: vclk: fix calculation of 59.94 fractional rates
Hi, On Tue, 09 Jan 2024 23:07:04 +, Christian Hewitt wrote: > Playing 4K media with 59.94 fractional rate (typically VP9) causes the screen > to lose > sync with the following error reported in the system log: > > [ 89.610280] Fatal Error, invalid HDMI vclk freq 593406 > > Modetest shows the following: > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/1] drm/meson: vclk: fix calculation of 59.94 fractional rates https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/bfbc68e4d8695497f858a45a142665e22a512ea3 -- Neil
Re: (subset) [PATCH 0/5] Add Support for RK3326 GameForce Chi
Hi, On Mon, 25 Mar 2024 08:49:54 -0500, Chris Morgan wrote: > From: Chris Morgan > > Add support for the GameForce Chi [1]. > > The GameForce Chi has the following hardware: > Tested: > - 3.5" dual lane 640x480 DSI display. > - 15 GPIO based face buttons. > - 2 ADC based face buttons. > - 1 ADC joystick (left) connected to internal SARADC. > - RGB LED arrays for key backlighting > - Dual internal speakers. > - Realtek RTL8723BS SDIO WiFi. > - Single SDMMC slot. > > [...] Thanks, Applied to https://gitlab.freedesktop.org/drm/misc/kernel.git (drm-misc-next) [1/5] dt-bindings: vendor-prefix: Add prefix for GameForce https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/59237fc04ee1c4cdf62ad5dba18244713970e36f [2/5] dt-bindings: display: Add GameForce Chi Panel https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/387974a21a63b1c7efcbc19c48b9930f6ef5ac63 [3/5] drm/panel: st7703: Add GameForce Chi Panel Support https://gitlab.freedesktop.org/drm/misc/kernel/-/commit/4c4f33be7e4d476566246e7166c54ef175287e00 -- Neil
