* [PATCH v5 1/3] drm/bridge: ti-sn65dsi83: Simplify error condition logic
From: Wojciech Dubowik @ 2026-07-17 11:49 UTC (permalink / raw)
To: linux-kernel
Cc: Wojciech Dubowik, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Marek Vasut, dri-devel, devicetree
In-Reply-To: <20260717115002.308035-1-wojciech.dubowik@mt.com>
From: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
Simplify error condition logic in lvds device tree property parsing. It
makes it easier to add extra properties without handling complex goto
entries.
Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 43 ++++++++-------------------
1 file changed, 13 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index 42b451432bbb..f8a786953526 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -825,48 +825,35 @@ static int sn65dsi83_select_lvds_vod_swing(struct device *dev,
static int sn65dsi83_parse_lvds_endpoint(struct sn65dsi83 *ctx, int channel)
{
struct device *dev = ctx->dev;
- struct device_node *endpoint;
- int endpoint_reg;
+ int endpoint_reg = (channel == CHANNEL_A) ? 2 : 3;
+ struct device_node *endpoint __free(device_node) =
+ of_graph_get_endpoint_by_regs(dev->of_node, endpoint_reg, -1);
/* Set so the property can be freely selected if not defined */
u32 lvds_vod_swing_data[2] = { 0, 1000000 };
u32 lvds_vod_swing_clk[2] = { 0, 1000000 };
/* Set default near end terminataion to 200 Ohm */
u32 lvds_term = 200;
int lvds_vod_swing_conf;
- int ret = 0;
int ret_data;
int ret_clock;
- if (channel == CHANNEL_A)
- endpoint_reg = 2;
- else
- endpoint_reg = 3;
-
- endpoint = of_graph_get_endpoint_by_regs(dev->of_node, endpoint_reg, -1);
-
of_property_read_u32(endpoint, "ti,lvds-termination-ohms", &lvds_term);
if (lvds_term == 100)
ctx->lvds_term_conf[channel] = OHM_100;
else if (lvds_term == 200)
ctx->lvds_term_conf[channel] = OHM_200;
- else {
- ret = -EINVAL;
- goto exit;
- }
+ else
+ return -EINVAL;
ret_data = of_property_read_u32_array(endpoint, "ti,lvds-vod-swing-data-microvolt",
lvds_vod_swing_data, ARRAY_SIZE(lvds_vod_swing_data));
- if (ret_data != 0 && ret_data != -EINVAL) {
- ret = ret_data;
- goto exit;
- }
+ if (ret_data != 0 && ret_data != -EINVAL)
+ return ret_data;
ret_clock = of_property_read_u32_array(endpoint, "ti,lvds-vod-swing-clock-microvolt",
lvds_vod_swing_clk, ARRAY_SIZE(lvds_vod_swing_clk));
- if (ret_clock != 0 && ret_clock != -EINVAL) {
- ret = ret_clock;
- goto exit;
- }
+ if (ret_clock != 0 && ret_clock != -EINVAL)
+ return ret_clock;
/* Use default value if both properties are NOT defined. */
if (ret_data == -EINVAL && ret_clock == -EINVAL)
@@ -876,17 +863,13 @@ static int sn65dsi83_parse_lvds_endpoint(struct sn65dsi83 *ctx, int channel)
if (!ret_data || !ret_clock) {
lvds_vod_swing_conf = sn65dsi83_select_lvds_vod_swing(dev, lvds_vod_swing_data,
lvds_vod_swing_clk, ctx->lvds_term_conf[channel]);
- if (lvds_vod_swing_conf < 0) {
- ret = lvds_vod_swing_conf;
- goto exit;
- }
+ if (lvds_vod_swing_conf < 0)
+ return lvds_vod_swing_conf;
}
ctx->lvds_vod_swing_conf[channel] = lvds_vod_swing_conf;
- ret = 0;
-exit:
- of_node_put(endpoint);
- return ret;
+
+ return 0;
}
static int sn65dsi83_parse_dt(struct sn65dsi83 *ctx, enum sn65dsi83_model model)
--
2.47.3
^ permalink raw reply related
* [PATCH v5 0/3] drm/bridge: ti-sn65dsi83: Add reverse lvds lanes support
From: Wojciech Dubowik @ 2026-07-17 11:49 UTC (permalink / raw)
To: linux-kernel
Cc: Wojciech Dubowik, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Marek Vasut, dri-devel, devicetree
From: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
Add support for reversed lvds output lanes. With an optional
data-lanes property one can support default layout <1 2 3 4>
or reversed layout <4 3 2 1>. The property is optional and when
not set it keeps the default output layout.
Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
---
Changes in v5:
- Add an extra patch to simplify error handling in lvds DT parsing
suggested by Luca
- Fix formatting and description in dt-bindings
- Make naming consistent for lane mappings constants
- Simplify parsing of data-lanes
Changes in v4:
- Fix data-lanes bindings to be under endpoint subnode and not in
the node itself, discovered by shashiko-reviews
Changes in v3:
- Add optional data-lanes bindings for output nodes
Changes in v2:
- Parse existing data-lanes property instead of ading new DT
bindings
---
Wojciech Dubowik (3):
drm/bridge: ti-sn65dsi83: Simplify error condition logic
dt-bindings: display: sn65dsi83: Add output data-lanes property
drm/bridge: ti-sn65dsi83: Add reversed lvds lanes support
.../bindings/display/bridge/ti,sn65dsi83.yaml | 44 ++++++++++++
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 72 +++++++++++--------
2 files changed, 87 insertions(+), 29 deletions(-)
--
2.47.3
^ permalink raw reply
* [PATCH v5 2/3] dt-bindings: display: sn65dsi83: Add output data-lanes property
From: Wojciech Dubowik @ 2026-07-17 11:50 UTC (permalink / raw)
To: linux-kernel
Cc: Wojciech Dubowik, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Marek Vasut, dri-devel, devicetree
In-Reply-To: <20260717115002.308035-1-wojciech.dubowik@mt.com>
From: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
Add an optional output lvds data lanes property with two allowed values.
The array <1 2 3 4> for standard layout and <4 3 2 1> for reversed lvds
output lanes. The latter informs the driver that reverse lvds config
option has to be set in config register for the respective output channel.
Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
---
.../bindings/display/bridge/ti,sn65dsi83.yaml | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
index e69b6343a8eb..4000bf0b1370 100644
--- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
@@ -86,10 +86,54 @@ properties:
description: Video port for LVDS Channel-A output (panel or bridge).
$ref: '#/$defs/lvds-port'
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Array of physical LVDS data lane indexes
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+ - items:
+ - const: 4
+ - const: 3
+ - const: 2
+ - const: 1
+
port@3:
description: Video port for LVDS Channel-B output (panel or bridge).
$ref: '#/$defs/lvds-port'
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description:
+ Array of physical LVDS data lane indexes
+ oneOf:
+ - items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+ - items:
+ - const: 4
+ - const: 3
+ - const: 2
+ - const: 1
+
required:
- port@0
- port@2
--
2.47.3
^ permalink raw reply related
* [PATCH v5 3/3] drm/bridge: ti-sn65dsi83: Add reversed lvds lanes support
From: Wojciech Dubowik @ 2026-07-17 11:50 UTC (permalink / raw)
To: linux-kernel
Cc: Wojciech Dubowik, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Luca Ceresoli,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Marek Vasut, dri-devel, devicetree
In-Reply-To: <20260717115002.308035-1-wojciech.dubowik@mt.com>
From: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
The chip supports output lvds lanes in two orders, the default <1 2 3 4>
and <4 3 2 1>. Add parsing of an optional output lvds data-lanes property
so we can inform chip that the lanes have been reversed.
Signed-off-by: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
---
drivers/gpu/drm/bridge/ti-sn65dsi83.c | 31 +++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
index f8a786953526..df44df2e872a 100644
--- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
+++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
@@ -148,6 +148,18 @@ enum sn65dsi83_lvds_term {
OHM_200
};
+enum {
+ LANE_MAPPING_NORMAL,
+ LANE_MAPPING_REVERSE,
+};
+
+#define DATA_LANES_COUNT 4
+
+static const u32 supported_data_lane_mapping[][DATA_LANES_COUNT] = {
+ [LANE_MAPPING_NORMAL] = { 1, 2, 3, 4 },
+ [LANE_MAPPING_REVERSE] = { 4, 3, 2, 1},
+};
+
enum sn65dsi83_model {
MODEL_SN65DSI83,
MODEL_SN65DSI84,
@@ -163,6 +175,7 @@ struct sn65dsi83 {
struct regulator *vcc;
bool lvds_dual_link;
bool lvds_dual_link_even_odd_swap;
+ bool lvds_reverse_lanes_conf[2];
int lvds_vod_swing_conf[2];
int lvds_term_conf[2];
int irq;
@@ -644,6 +657,10 @@ static void sn65dsi83_atomic_pre_enable(struct drm_bridge *bridge,
regmap_write(ctx->regmap, REG_LVDS_LANE,
(ctx->lvds_dual_link_even_odd_swap ?
REG_LVDS_LANE_EVEN_ODD_SWAP : 0) |
+ (ctx->lvds_reverse_lanes_conf[CHANNEL_A] ?
+ REG_LVDS_LANE_CHA_REVERSE_LVDS : 0) |
+ (ctx->lvds_reverse_lanes_conf[CHANNEL_B] ?
+ REG_LVDS_LANE_CHB_REVERSE_LVDS : 0) |
(ctx->lvds_term_conf[CHANNEL_A] ?
REG_LVDS_LANE_CHA_LVDS_TERM : 0) |
(ctx->lvds_term_conf[CHANNEL_B] ?
@@ -833,6 +850,7 @@ static int sn65dsi83_parse_lvds_endpoint(struct sn65dsi83 *ctx, int channel)
u32 lvds_vod_swing_clk[2] = { 0, 1000000 };
/* Set default near end terminataion to 200 Ohm */
u32 lvds_term = 200;
+ u32 data_lanes[DATA_LANES_COUNT];
int lvds_vod_swing_conf;
int ret_data;
int ret_clock;
@@ -845,6 +863,19 @@ static int sn65dsi83_parse_lvds_endpoint(struct sn65dsi83 *ctx, int channel)
else
return -EINVAL;
+ ret_data = of_property_read_u32_array(endpoint, "data-lanes", data_lanes,
+ ARRAY_SIZE(data_lanes));
+ if (!ret_data) {
+ if (memcmp(data_lanes,
+ supported_data_lane_mapping[LANE_MAPPING_REVERSE],
+ ARRAY_SIZE(data_lanes)) == 0)
+ ctx->lvds_reverse_lanes_conf[channel] = true;
+ else if (memcmp(data_lanes,
+ supported_data_lane_mapping[LANE_MAPPING_NORMAL],
+ ARRAY_SIZE(data_lanes)) != 0)
+ return dev_err_probe(dev, -EINVAL, "invalid data lanes mapping\n");
+ }
+
ret_data = of_property_read_u32_array(endpoint, "ti,lvds-vod-swing-data-microvolt",
lvds_vod_swing_data, ARRAY_SIZE(lvds_vod_swing_data));
if (ret_data != 0 && ret_data != -EINVAL)
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v6 1/5] spi: dt-bindings: Add spi-device-addr peripheral property
From: Mark Brown @ 2026-07-17 11:51 UTC (permalink / raw)
To: Conor Dooley
Cc: Nuno Sá, Janani Sunil, Lars-Peter Clausen, Michael Hennerich,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Philipp Zabel,
Jonathan Corbet, Shuah Khan, Marius Cristea, Marcus Folkesson,
Kent Gustavsson, linux-iio, devicetree, linux-kernel, linux-doc,
Janani Sunil, linux-spi, Kent Gustavsson
In-Reply-To: <20260716-stole-copious-7cdaacb6cef6@spud>
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
On Thu, Jul 16, 2026 at 06:06:13PM +0100, Conor Dooley wrote:
> On Thu, Jul 16, 2026 at 01:28:15PM +0100, Mark Brown wrote:
> > Oh, isn't that just multi-pin chip selects then:
> > https://patch.msgid.link/cover.1783729282.git.Jonathan.Santos@analog.com
> No, I think that's something different.
> In this case, there is one chip select that all instances of the device
> share. Both the ADI and Microchip devices then use the upper bits of the
> first/address byte during reads and write to access individual devices.
> In the microchip case that I'm familiar with, what upper bits the device
> responds to are set by fuses in the factory. They also share the same MOSI
> and MISO.
I'm struggling to identify a way in which this is functionally different
to a multi-pin chip select.
> The SPI core already supports two of these devices from Microchip, since
> it just modifies the contents of tx_buf in a spi_transfer.
When I said we'd have to modify the bitstream I was told that wasn't the
case and this was just asserting more pins along with the "chip select".
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 0/4] arm64: dts: qcom: Add Glymur QCB
From: Gopikrishna Garmidi @ 2026-07-17 11:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Anvesh Jain P, Sibi Sankar, Pankaj Patil
Cc: Rajendra Nayak, linux-arm-msm, devicetree, linux-kernel,
Gopikrishna Garmidi
Add initial support for the Glymur QCB (Qualcomm Compute Board), a board
built on Qualcomm's Glymur SoC.
Unlike the CRD's closed enclosure, the QCB is an open form factor, suited
for bring-up and power, signal measurement.
The base support boots to shell with rootfs on NVMe.
This series adds the bindings the board relies on before enabling the
device tree itself:
- Document the qcom,glymur-qcb board compatible.
- Document the qcom,glymur-qcb-ec embedded controller compatible.
- Allow QSEECOM on the Glymur QCB so efivars and the UEFI-backed RTC work.
Features enabled in the device tree:
1. Board and sleep clocks
2. Volume up/down keys
3. PMIC RPMH regulators (banks 0 - 4) and the NVMe, WWAN and WCN rails
4. PCIe4/5/6 controllers and PHYs
5. WCN7850 WiFi on PCIe4 and Bluetooth on UART14
6. Embedded controller on I2C9
7. ADSP and CDSP remote processors, with a firmware path for SoCCP
---
Gopikrishna Garmidi (4):
dt-bindings: arm: qcom: Add Glymur QCB
dt-bindings: embedded-controller: Add Glymur QCB EC
firmware: qcom: scm: Allow QSEECOM on the Glymur QCB
arm64: dts: qcom: Add Glymur QCB
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
.../embedded-controller/qcom,hamoa-crd-ec.yaml | 1 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/glymur-qcb.dts | 679 +++++++++++++++++++++
drivers/firmware/qcom/qcom_scm.c | 1 +
5 files changed, 683 insertions(+)
---
base-commit: ce28329fef089fc63dbaadcc4c1fbf9c287e57e0
change-id: 20260711-glymur-qcb-1e2d2bc913fd
prerequisite-message-id: <20260709-glymur-soccp-v6-4-16f70227547d@oss.qualcomm.com>
prerequisite-patch-id: 26f384ecfe96620007cab0ae3dd01db6e2314bc8
prerequisite-patch-id: 711fb836c2a609ad2f1f07f8785df3e8b72e97a5
prerequisite-patch-id: e9fe3e572292afc1ea6f98dba6c2176a28183dc7
prerequisite-patch-id: 5b78db9f6345733d9dce683ec231fa93859a1a0e
Best regards,
--
Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/4] dt-bindings: arm: qcom: Add Glymur QCB
From: Gopikrishna Garmidi @ 2026-07-17 11:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Anvesh Jain P, Sibi Sankar, Pankaj Patil
Cc: Rajendra Nayak, linux-arm-msm, devicetree, linux-kernel,
Gopikrishna Garmidi
In-Reply-To: <20260717-glymur-qcb-v1-0-aaf1cff84aab@oss.qualcomm.com>
Document the Glymur QCB (Qualcomm Compute Board) board id, an open
form-factor Glymur board intended for compute bring-up and power/signal
measurement.
Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index c7c9a9279684..0ca766f12147 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -87,6 +87,7 @@ properties:
- items:
- enum:
- qcom,glymur-crd
+ - qcom,glymur-qcb
- const: qcom,glymur
- items:
--
2.34.1
^ permalink raw reply related
* [PATCH 3/4] firmware: qcom: scm: Allow QSEECOM on the Glymur QCB
From: Gopikrishna Garmidi @ 2026-07-17 11:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Anvesh Jain P, Sibi Sankar, Pankaj Patil
Cc: Rajendra Nayak, linux-arm-msm, devicetree, linux-kernel,
Gopikrishna Garmidi
In-Reply-To: <20260717-glymur-qcb-v1-0-aaf1cff84aab@oss.qualcomm.com>
Add Glymur QCB board to the QSEECOM allowlist for enabling access to
efivars and uefi bootloader.
Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
drivers/firmware/qcom/qcom_scm.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
index f35f2ee39130..e0ea40b4302c 100644
--- a/drivers/firmware/qcom/qcom_scm.c
+++ b/drivers/firmware/qcom/qcom_scm.c
@@ -2326,6 +2326,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
{ .compatible = "microsoft,romulus13", },
{ .compatible = "microsoft,romulus15", },
{ .compatible = "qcom,glymur-crd" },
+ { .compatible = "qcom,glymur-qcb" },
{ .compatible = "qcom,hamoa-iot-evk" },
{ .compatible = "qcom,mahua-crd" },
{ .compatible = "qcom,purwa-iot-evk" },
--
2.34.1
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: embedded-controller: Add Glymur QCB EC
From: Gopikrishna Garmidi @ 2026-07-17 11:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Anvesh Jain P, Sibi Sankar, Pankaj Patil
Cc: Rajendra Nayak, linux-arm-msm, devicetree, linux-kernel,
Gopikrishna Garmidi
In-Reply-To: <20260717-glymur-qcb-v1-0-aaf1cff84aab@oss.qualcomm.com>
Add the qcom,glymur-qcb-ec compatible for the embedded controller on the
Glymur QCB. It is the same EC used on the CRD.
Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
.../devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
index ac5a08f8f76d..de416057063c 100644
--- a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
+++ b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
@@ -21,6 +21,7 @@ properties:
- items:
- enum:
- qcom,glymur-crd-ec
+ - qcom,glymur-qcb-ec
- qcom,hamoa-iot-evk-ec
- const: qcom,hamoa-crd-ec
- enum:
--
2.34.1
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: qcom: Add Glymur QCB
From: Gopikrishna Garmidi @ 2026-07-17 11:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Anvesh Jain P, Sibi Sankar, Pankaj Patil
Cc: Rajendra Nayak, linux-arm-msm, devicetree, linux-kernel,
Gopikrishna Garmidi
In-Reply-To: <20260717-glymur-qcb-v1-0-aaf1cff84aab@oss.qualcomm.com>
The Glymur QCB (Qualcomm Compute Board) is a Glymur-based board in an
open form factor, aimed at compute bring-up and power/signal measurement
rather than the closed enclosure of the CRD.
Add its device tree. The board boots to a shell over the uart21 console
with its root filesystem on NVMe. Enabled so far:
- Board and sleep clocks
- Volume up/down keys
- PMIC RPMH regulators (banks 0 - 4) and the NVMe, WWAN and WCN rails
- PCIe4/5/6 controllers and PHYs, with their PERST/WAKE/CLKREQ lines
- WCN7850 WiFi on PCIe4 and Bluetooth on UART14
- Embedded controller on I2C9
- ADSP,CDSP and SoCCP remote processors
Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/glymur-qcb.dts | 679 ++++++++++++++++++++++++++++++++
2 files changed, 680 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index e05414290d8e..96fca1e11bf8 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -17,6 +17,7 @@ dtb-$(CONFIG_ARCH_QCOM) += apq8096-ifc6640.dtb
dtb-$(CONFIG_ARCH_QCOM) += eliza-cqs-evk.dtb
dtb-$(CONFIG_ARCH_QCOM) += eliza-mtp.dtb
dtb-$(CONFIG_ARCH_QCOM) += glymur-crd.dtb
+dtb-$(CONFIG_ARCH_QCOM) += glymur-qcb.dtb
dtb-$(CONFIG_ARCH_QCOM) += hamoa-iot-evk.dtb
hamoa-iot-evk-el2-dtbs := hamoa-iot-evk.dtb x1-el2.dtbo
diff --git a/arch/arm64/boot/dts/qcom/glymur-qcb.dts b/arch/arm64/boot/dts/qcom/glymur-qcb.dts
new file mode 100644
index 000000000000..592357de7fb6
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/glymur-qcb.dts
@@ -0,0 +1,679 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
+ */
+
+/dts-v1/;
+
+#include "glymur.dtsi"
+
+#include "pmcx0102.dtsi" /* SPMI0: SID-2/3 SPMI1: SID-2/3 */
+#include "pmh0101.dtsi" /* SPMI0: SID-1 */
+#include "pmh0110-glymur.dtsi" /* SPMI0: SID-5/7 SPMI1: SID-5 */
+#include "pmh0104-glymur.dtsi" /* SPMI0: SID-8/9 SPMI1: SID-11 */
+#include "pmk8850.dtsi" /* SPMI0: SID-0 */
+#include "smb2370.dtsi" /* SPMI2: SID-9/10/11 */
+
+/ {
+ model = "Qualcomm Technologies, Inc. Glymur QCB";
+ compatible = "qcom,glymur-qcb", "qcom,glymur";
+
+ aliases {
+ serial0 = &uart21;
+ serial1 = &uart14;
+ i2c0 = &i2c0;
+ i2c1 = &i2c4;
+ i2c2 = &i2c5;
+ i2c3 = &i2c9;
+ spi0 = &spi18;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ clocks {
+ xo_board: xo-board {
+ compatible = "fixed-clock";
+ clock-frequency = <38400000>;
+ #clock-cells = <0>;
+ };
+
+ sleep_clk: sleep-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <32000>;
+ #clock-cells = <0>;
+ };
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ pinctrl-0 = <&key_vol_up_default>;
+ pinctrl-names = "default";
+
+ key-volume-up {
+ label = "Volume Up";
+ linux,code = <KEY_VOLUMEUP>;
+ gpios = <&pmh0101_gpios 6 GPIO_ACTIVE_LOW>;
+ debounce-interval = <15>;
+ linux,can-disable;
+ wakeup-source;
+ };
+ };
+
+ vreg_nvme: regulator-nvme {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_NVME_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&pmh0101_gpios 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&nvme_reg_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
+ vreg_wcn_0p95: regulator-wcn-0p95 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_WCN_0P95";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <950000>;
+
+ vin-supply = <&vreg_wcn_3p3>;
+ };
+
+ vreg_wcn_3p3: regulator-wcn-3p3 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_WCN_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 94 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&wcn_sw_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ };
+
+ vreg_wwan: regulator-wwan {
+ compatible = "regulator-fixed";
+
+ regulator-name = "VREG_WWAN_3P3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&tlmm 246 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&wwan_reg_en>;
+ pinctrl-names = "default";
+ };
+
+ wcn7850-pmu {
+ compatible = "qcom,wcn7850-pmu";
+
+ vdd-supply = <&vreg_wcn_0p95>;
+ vddio-supply = <&vreg_l15b_e0_1p8>;
+ vddaon-supply = <&vreg_l15b_e0_1p8>;
+ vdddig-supply = <&vreg_l15b_e0_1p8>;
+ vddrfa1p2-supply = <&vreg_l15b_e0_1p8>;
+ vddrfa1p8-supply = <&vreg_l15b_e0_1p8>;
+
+ wlan-enable-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
+ bt-enable-gpios = <&tlmm 116 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&wcn_wlan_bt_en>;
+ pinctrl-names = "default";
+
+ regulators {
+ vreg_pmu_rfa_cmn: ldo0 {
+ regulator-name = "vreg_pmu_rfa_cmn";
+ };
+
+ vreg_pmu_aon_0p59: ldo1 {
+ regulator-name = "vreg_pmu_aon_0p59";
+ };
+
+ vreg_pmu_wlcx_0p8: ldo2 {
+ regulator-name = "vreg_pmu_wlcx_0p8";
+ };
+
+ vreg_pmu_wlmx_0p85: ldo3 {
+ regulator-name = "vreg_pmu_wlmx_0p85";
+ };
+
+ vreg_pmu_btcmx_0p85: ldo4 {
+ regulator-name = "vreg_pmu_btcmx_0p85";
+ };
+
+ vreg_pmu_rfa_0p8: ldo5 {
+ regulator-name = "vreg_pmu_rfa_0p8";
+ };
+
+ vreg_pmu_rfa_1p2: ldo6 {
+ regulator-name = "vreg_pmu_rfa_1p2";
+ };
+
+ vreg_pmu_rfa_1p8: ldo7 {
+ regulator-name = "vreg_pmu_rfa_1p8";
+ };
+
+ vreg_pmu_pcie_0p9: ldo8 {
+ regulator-name = "vreg_pmu_pcie_0p9";
+ };
+
+ vreg_pmu_pcie_1p8: ldo9 {
+ regulator-name = "vreg_pmu_pcie_1p8";
+ };
+ };
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pmh0101-rpmh-regulators";
+ qcom,pmic-id = "B_E0";
+
+ vreg_bob1_e0: bob1 {
+ regulator-name = "vreg_bob1_e0";
+ regulator-min-microvolt = <2200000>;
+ regulator-max-microvolt = <4224000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+ };
+
+ vreg_bob2_e0: bob2 {
+ regulator-name = "vreg_bob2_e0";
+ regulator-min-microvolt = <2540000>;
+ regulator-max-microvolt = <3600000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_AUTO>;
+ };
+
+ vreg_l1b_e0_1p8: ldo1 {
+ regulator-name = "vreg_l1b_e0_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2b_e0_2p9: ldo2 {
+ regulator-name = "vreg_l2b_e0_2p9";
+ regulator-min-microvolt = <2904000>;
+ regulator-max-microvolt = <2904000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_e0_2p79: ldo7 {
+ regulator-name = "vreg_l7b_e0_2p79";
+ regulator-min-microvolt = <2790000>;
+ regulator-max-microvolt = <2792000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8b_e0_1p50: ldo8 {
+ regulator-name = "vreg_l8b_e0_1p50";
+ regulator-min-microvolt = <1504000>;
+ regulator-max-microvolt = <1504000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_e0_2p7: ldo9 {
+ regulator-name = "vreg_l9b_e0_2p7";
+ regulator-min-microvolt = <2704000>;
+ regulator-max-microvolt = <2704000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l10b_e0_1p8: ldo10 {
+ regulator-name = "vreg_l10b_e0_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11b_e0_1p2: ldo11 {
+ regulator-name = "vreg_l11b_e0_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12b_e0_1p14: ldo12 {
+ regulator-name = "vreg_l12b_e0_1p14";
+ regulator-min-microvolt = <1144000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_e0_1p8: ldo15 {
+ regulator-name = "vreg_l15b_e0_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_e0_2p4: ldo17 {
+ regulator-name = "vreg_l17b_e0_2p4";
+ regulator-min-microvolt = <2400000>;
+ regulator-max-microvolt = <2700000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l18b_e0_1p2: ldo18 {
+ regulator-name = "vreg_l18b_e0_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pmcx0102-rpmh-regulators";
+ qcom,pmic-id = "C_E1";
+
+ vreg_l1c_e1_0p82: ldo1 {
+ regulator-name = "vreg_l1c_e1_0p82";
+ regulator-min-microvolt = <832000>;
+ regulator-max-microvolt = <832000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2c_e1_1p14: ldo2 {
+ regulator-name = "vreg_l2c_e1_1p14";
+ regulator-min-microvolt = <1144000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3c_e1_0p89: ldo3 {
+ regulator-name = "vreg_l3c_e1_0p89";
+ regulator-min-microvolt = <890000>;
+ regulator-max-microvolt = <980000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4c_e1_0p72: ldo4 {
+ regulator-name = "vreg_l4c_e1_0p72";
+ regulator-min-microvolt = <720000>;
+ regulator-max-microvolt = <720000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pmh0110-rpmh-regulators";
+ qcom,pmic-id = "F_E0";
+
+ vreg_s7f_e0_1p32: smps7 {
+ regulator-name = "vreg_s7f_e0_1p32";
+ regulator-min-microvolt = <1320000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s8f_e0_0p95: smps8 {
+ regulator-name = "vreg_s8f_e0_0p95";
+ regulator-min-microvolt = <952000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s9f_e0_1p9: smps9 {
+ regulator-name = "vreg_s9f_e0_1p9";
+ regulator-min-microvolt = <1900000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2f_e0_0p82: ldo2 {
+ regulator-name = "vreg_l2f_e0_0p82";
+ regulator-min-microvolt = <832000>;
+ regulator-max-microvolt = <832000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3f_e0_0p72: ldo3 {
+ regulator-name = "vreg_l3f_e0_0p72";
+ regulator-min-microvolt = <720000>;
+ regulator-max-microvolt = <720000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4f_e0_1p08: ldo4 {
+ regulator-name = "vreg_l4f_e0_1p08";
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-3 {
+ compatible = "qcom,pmh0110-rpmh-regulators";
+ qcom,pmic-id = "F_E1";
+
+ vreg_s7f_e1_0p3: smps7 {
+ regulator-name = "vreg_s7f_e1_0p3";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1f_e1_0p82: ldo1 {
+ regulator-name = "vreg_l1f_e1_0p82";
+ regulator-min-microvolt = <832000>;
+ regulator-max-microvolt = <832000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2f_e1_0p83: ldo2 {
+ regulator-name = "vreg_l2f_e1_0p83";
+ regulator-min-microvolt = <832000>;
+ regulator-max-microvolt = <832000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4f_e1_1p08: ldo4 {
+ regulator-name = "vreg_l4f_e1_1p08";
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-4 {
+ compatible = "qcom,pmh0110-rpmh-regulators";
+ qcom,pmic-id = "H_E0";
+
+ vreg_l1h_e0_0p89: ldo1 {
+ regulator-name = "vreg_l1h_e0_0p89";
+ regulator-min-microvolt = <832000>;
+ regulator-max-microvolt = <832000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2h_e0_0p72: ldo2 {
+ regulator-name = "vreg_l2h_e0_0p72";
+ regulator-min-microvolt = <832000>;
+ regulator-max-microvolt = <832000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3h_e0_0p32: ldo3 {
+ regulator-name = "vreg_l3h_e0_0p32";
+ regulator-min-microvolt = <320000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4h_e0_1p2: ldo4 {
+ regulator-name = "vreg_l4h_e0_1p2";
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1320000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&i2c9 {
+ clock-frequency = <400000>;
+
+ status = "okay";
+
+ embedded-controller@76 {
+ compatible = "qcom,glymur-qcb-ec", "qcom,hamoa-crd-ec";
+ reg = <0x76>;
+
+ interrupts-extended = <&tlmm 66 IRQ_TYPE_EDGE_FALLING>;
+
+ pinctrl-0 = <&ec_int_n_default>;
+ pinctrl-names = "default";
+ };
+};
+
+&pcie4 {
+ pinctrl-0 = <&pcie4_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie4_phy {
+ vdda-phy-supply = <&vreg_l1c_e1_0p82>;
+ vdda-pll-supply = <&vreg_l4f_e1_1p08>;
+
+ status = "okay";
+};
+
+&pcie4_port0 {
+ reset-gpios = <&tlmm 146 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 148 GPIO_ACTIVE_LOW>;
+
+ wifi@0 {
+ compatible = "pci17cb,1107";
+ reg = <0x10000 0x0 0x0 0x0 0x0>;
+
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ vddpcie0p9-supply = <&vreg_pmu_pcie_0p9>;
+ vddpcie1p8-supply = <&vreg_pmu_pcie_1p8>;
+ };
+};
+
+&pcie5 {
+ vddpe-3v3-supply = <&vreg_nvme>;
+
+ pinctrl-0 = <&pcie5_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie5_phy {
+ vdda-phy-supply = <&vreg_l2f_e0_0p82>;
+ vdda-pll-supply = <&vreg_l4h_e0_1p2>;
+
+ status = "okay";
+};
+
+&pcie5_port0 {
+ reset-gpios = <&tlmm 152 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 154 GPIO_ACTIVE_LOW>;
+};
+
+&pcie6 {
+ vddpe-3v3-supply = <&vreg_wwan>;
+
+ pinctrl-0 = <&pcie6_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie6_phy {
+ vdda-phy-supply = <&vreg_l1c_e1_0p82>;
+ vdda-pll-supply = <&vreg_l4f_e1_1p08>;
+
+ status = "okay";
+};
+
+&pcie6_port0 {
+ reset-gpios = <&tlmm 149 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 151 GPIO_ACTIVE_LOW>;
+};
+
+&pmh0101_gpios {
+ key_vol_up_default: key-vol-up-default-state {
+ pins = "gpio6";
+ function = "normal";
+ output-disable;
+ bias-pull-up;
+ };
+
+ nvme_reg_en: nvme-reg-en-state {
+ pins = "gpio14";
+ function = "normal";
+ bias-disable;
+ };
+};
+
+&pmk8850_rtc {
+ qcom,no-alarm;
+ qcom,uefi-rtc-info;
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/glymur/adsp.mbn",
+ "qcom/glymur/adsp_dtb.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/glymur/cdsp.mbn",
+ "qcom/glymur/cdsp_dtb.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_soccp {
+ firmware-name = "qcom/glymur/soccp.mbn",
+ "qcom/glymur/soccp_dtb.mbn";
+};
+
+&tlmm {
+ gpio-reserved-ranges = <4 4>, /* EC TZ Secure I3C */
+ <10 2>, /* OOB UART */
+ <44 4>; /* Security SPI (TPM) */
+
+ ec_int_n_default: ec-int-n-state {
+ pins = "gpio66";
+ function = "gpio";
+ bias-disable;
+ };
+
+ pcie4_default: pcie4-default-state {
+ clkreq-n-pins {
+ pins = "gpio147";
+ function = "pcie4_clk_req_n";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-n-pins {
+ pins = "gpio146";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wake-n-pins {
+ pins = "gpio148";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ pcie5_default: pcie5-default-state {
+ clkreq-n-pins {
+ pins = "gpio153";
+ function = "pcie5_clk_req_n";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-n-pins {
+ pins = "gpio152";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wake-n-pins {
+ pins = "gpio154";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ pcie6_default: pcie6-default-state {
+ clkreq-n-pins {
+ pins = "gpio150";
+ function = "pcie6_clk_req_n";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ perst-n-pins {
+ pins = "gpio149";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wake-n-pins {
+ pins = "gpio151";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+ };
+
+ wcn_wlan_bt_en: wcn-wlan-bt-en-state {
+ pins = "gpio116", "gpio117";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wcn_sw_en: wcn-sw-en-state {
+ pins = "gpio94";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wwan_reg_en: wwan-reg-en-state {
+ pins = "gpio246";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+};
+
+&uart14 {
+ status = "okay";
+
+ bluetooth {
+ compatible = "qcom,wcn7850-bt";
+ max-speed = <3200000>;
+
+ vddaon-supply = <&vreg_pmu_aon_0p59>;
+ vddwlcx-supply = <&vreg_pmu_wlcx_0p8>;
+ vddwlmx-supply = <&vreg_pmu_wlmx_0p85>;
+ vddrfacmn-supply = <&vreg_pmu_rfa_cmn>;
+ vddrfa0p8-supply = <&vreg_pmu_rfa_0p8>;
+ vddrfa1p2-supply = <&vreg_pmu_rfa_1p2>;
+ vddrfa1p8-supply = <&vreg_pmu_rfa_1p8>;
+ };
+};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v5 3/3] drm/bridge: ti-sn65dsi83: Add reversed lvds lanes support
From: sashiko-bot @ 2026-07-17 11:56 UTC (permalink / raw)
To: Wojciech Dubowik; +Cc: devicetree, conor+dt, dri-devel, robh
In-Reply-To: <20260717115002.308035-4-wojciech.dubowik@mt.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] `memcmp()` is called with `ARRAY_SIZE(data_lanes)` instead of `sizeof(data_lanes)`, causing it to compare only the first element of the `u32` array.
--
--- Patch [3]: [PATCH v5 3/3] drm/bridge: ti-sn65dsi83: Add reversed lvds lanes support ---
commit 5b0901160799f83c03f127b68580169dd845ac90
Author: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
drm/bridge: ti-sn65dsi83: Add reversed lvds lanes support
This commit adds support for parsing an optional "data-lanes" device tree
property. It allows the driver to configure the ti-sn65dsi83 chip for
reversed output LVDS lane order.
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index f8a786953526d..df44df2e872af 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
[ ... ]
> @@ -845,6 +863,19 @@ static int sn65dsi83_parse_lvds_endpoint(struct sn65dsi83 *ctx, int channel)
> else
> return -EINVAL;
>
> + ret_data = of_property_read_u32_array(endpoint, "data-lanes", data_lanes,
> + ARRAY_SIZE(data_lanes));
> + if (!ret_data) {
> + if (memcmp(data_lanes,
> + supported_data_lane_mapping[LANE_MAPPING_REVERSE],
> + ARRAY_SIZE(data_lanes)) == 0)
[Severity: Medium]
Does this code compare the entire array? memcmp() expects the length in
bytes, but ARRAY_SIZE(data_lanes) evaluates to 4 (the number of elements).
Because data_lanes is an array of u32, checking only 4 bytes means only
the first element is compared. Should this be using sizeof(data_lanes)
instead?
> + ctx->lvds_reverse_lanes_conf[channel] = true;
> + else if (memcmp(data_lanes,
> + supported_data_lane_mapping[LANE_MAPPING_NORMAL],
> + ARRAY_SIZE(data_lanes)) != 0)
[Severity: Medium]
The same question applies here. Because only the first element is verified,
would an invalid device tree configuration like <4 0 0 0> erroneously match
LANE_MAPPING_REVERSE and bypass the expected validation?
> + return dev_err_probe(dev, -EINVAL, "invalid data lanes mapping\n");
> + }
> +
> ret_data = of_property_read_u32_array(endpoint, "ti,lvds-vod-swing-data-microvolt",
> lvds_vod_swing_data, ARRAY_SIZE(lvds_vod_swing_data));
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717115002.308035-1-wojciech.dubowik@mt.com?part=3
^ permalink raw reply
* [PATCH v4 0/2] cover: arm64: dts: qcom: glymur-crd: Add touchscreen node for ft3d81
From: Pradyot Kumar Nayak @ 2026-07-17 11:58 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Peng, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, Pradyot Kumar Nayak
The touchscreen module on Glymur/Mahua CRDs is a ft3d81 chip which, while
hardware-compatible with the ft8112 (same I2C-HID protocol, same
power-on/reset sequencing), requires the reset-gpios line to be
explicitly wired up in the DT. Without it the reset line remains
permanently asserted after a suspend/resume cycle and all subsequent
I2C transactions fail with -ENXIO.
V2 incorrectly used the generic hid-over-i2c binding. V3
takes a cleaner approach: extend the chip-specific focaltech,ft8112
binding to cover the ft3d81 (they share the same driver) and switch
the glymur-crd node to that binding. This removes the dependency on
the hid-over-i2c properties (hid-descr-addr) and aligns the supply
property names (vcc33-supply / vccio-supply) with the binding schema.
V3 was not picked up; instead V1 was accidentally merged by the maintainer.
V4 corrects this by superseding the partial V1 fix, and moves the DT change
from glymur-crd.dts to glymur-crd.dtsi where the shared board nodes belong.
v1: https://lore.kernel.org/linux-arm-msm/20260522-arm64-dts-glymur-crd-add-reset-gpio-to-touchscreen-v1-1-c7653924acdc@oss.qualcomm.com/
Changes in v1:
- Initial submission: add reset-gpios to touchscreen node in glymur-crd.dtsi
v2: https://lore.kernel.org/linux-arm-msm/20260523-arm64-dts-glymur-crd-add-reset-gpio-to-touchscreen-v2-0-5c333051e5bb@oss.qualcomm.com/
Changes in v2:
- Add dt-bindings patch to document reset-gpios in hid-over-i2c schema
(flagged by dtbs_check on v1)
- No change to the DTS patch itself
v3: https://lore.kernel.org/linux-arm-msm/20260603-arm64-dts-glymur-crd-add-reset-gpio-to-v3-0-3453ef577bcf@oss.qualcomm.com/
Changes in v3:
- Drop prerequisite-message-id; series is now self-contained
- Patch 1 (new): add focaltech,ft3d81 to the focaltech,ft8112
binding compatible enum
- Patch 2: Added focaltech,ft3d81 DT support which is hardware-compatible with the ft8112
Changes in v4:
- v1 was accidentally merged by the maintainer instead of v3; raising
v4 to correct this
- Move DT change from glymur-crd.dts to glymur-crd.dtsi as the
touchscreen node belongs to the shared board DTSI
---
Pradyot Kumar Nayak (2):
dt-bindings: input: focaltech,ft8112: Add focaltech,ft3d81 compatible
arm64: dts: qcom: glymur-crd: Add FocalTech ft3d81 touchscreen support
Documentation/devicetree/bindings/input/focaltech,ft8112.yaml | 9 +++++++--
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 7 +++----
2 files changed, 10 insertions(+), 6 deletions(-)
---
base-commit: 1a1757b76427f6201bfe0bf1bea9f7574f332a93
change-id: 20260717-add_focaltech_ft3d81_touchscreen_support-263409a84b78
Best regards,
--
Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v4 1/2] dt-bindings: input: focaltech,ft8112: Add focaltech,ft3d81 compatible
From: Pradyot Kumar Nayak @ 2026-07-17 11:58 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Peng, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, devicetree, linux-kernel,
Konrad Dybcio, Krzysztof Kozlowski, Pradyot Kumar Nayak
In-Reply-To: <20260717-add_focaltech_ft3d81_touchscreen_support-v4-0-5dd091e25801@oss.qualcomm.com>
The Focaltech ft3d81 is fully compatible with the ft8112 i.e.
it uses the same I2C-HID protocol and the same power-on/reset sequencing,
DT nodes for boards carrying an ft3d81,can therefore bind to the existing
ft8112 driver without any additional changes.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
---
Documentation/devicetree/bindings/input/focaltech,ft8112.yaml | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/input/focaltech,ft8112.yaml b/Documentation/devicetree/bindings/input/focaltech,ft8112.yaml
index 197f30b14d45..5ffa1246aba1 100644
--- a/Documentation/devicetree/bindings/input/focaltech,ft8112.yaml
+++ b/Documentation/devicetree/bindings/input/focaltech,ft8112.yaml
@@ -18,8 +18,13 @@ allOf:
properties:
compatible:
- enum:
- - focaltech,ft8112
+ oneOf:
+ - items:
+ - enum:
+ - focaltech,ft3d81
+ - const: focaltech,ft8112
+ - enum:
+ - focaltech,ft8112
reg:
maxItems: 1
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/2] arm64: dts: qcom: glymur-crd: Add FocalTech ft3d81 touchscreen support
From: Pradyot Kumar Nayak @ 2026-07-17 11:58 UTC (permalink / raw)
To: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Peng, Bjorn Andersson, Konrad Dybcio, Abel Vesa,
Dmitry Baryshkov
Cc: linux-arm-msm, linux-input, devicetree, linux-kernel,
Konrad Dybcio, Pradyot Kumar Nayak
In-Reply-To: <20260717-add_focaltech_ft3d81_touchscreen_support-v4-0-5dd091e25801@oss.qualcomm.com>
The touchscreen module on Glymur/Mahua CRDs is different from
the one used on Hamoa CRDs and requires the reset-gpios to be wired to
the device. Without this in place the reset line will remain
permanently asserted during resume leaving the device offline and causing
all I2C transactions to fail with -ENXIO.
i2c_hid_of 3-0038: failed to change power setting.
i2c_hid_of 3-0038: PM: dpm_run_callback():
i2c_hid_core_pm_resume [i2c_hid] returns -6
i2c_hid_of 3-0038: PM: failed to resume async: error -6
The touchscreen on Glymur/Mahua-CRD is a focaltech ft3d81,
which is hardware-compatible with the ft8112.
we have added the required change in DT.
Fixes: e6bf559f7eb9 ("arm64: dts: qcom: glymur-crd: Enable keyboard, trackpad and touchscreen")
Fixes: f64ef325f1d9 ("arm64: dts: glymur-crd: Add reset GPIO to touchscreen node")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Pradyot Kumar Nayak <pradyot.nayak@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur-crd.dtsi | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
index b314c6dd423c..4ae8834b4110 100644
--- a/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur-crd.dtsi
@@ -679,14 +679,13 @@ &i2c8 {
status = "okay";
touchscreen@38 {
- compatible = "hid-over-i2c";
+ compatible = "focaltech,ft3d81", "focaltech,ft8112";
reg = <0x38>;
- hid-descr-addr = <0x1>;
interrupts-extended = <&tlmm 51 IRQ_TYPE_LEVEL_LOW>;
- vdd-supply = <&vreg_misc_3p3>;
- vddl-supply = <&vreg_l15b_e0_1p8>;
+ vcc33-supply = <&vreg_misc_3p3>;
+ vccio-supply = <&vreg_l15b_e0_1p8>;
reset-gpios = <&tlmm 48 GPIO_ACTIVE_LOW>;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 2/3] dt-bindings: display: sn65dsi83: Add output data-lanes property
From: sashiko-bot @ 2026-07-17 12:00 UTC (permalink / raw)
To: Wojciech Dubowik; +Cc: robh, dri-devel, conor+dt, devicetree
In-Reply-To: <20260717115002.308035-3-wojciech.dubowik@mt.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Redefining `endpoint` with `unevaluatedProperties: false` locally masks properties evaluated by the sibling `$ref: '#/$defs/lvds-port'`, causing valid TI-specific LVDS properties to be improperly rejected.
--
--- Patch [2]: [PATCH v5 2/3] dt-bindings: display: sn65dsi83: Add output data-lanes property ---
commit c64bd236e14a70bf7062c9fee49e33ef3475908b
Author: Wojciech Dubowik <Wojciech.Dubowik@mt.com>
dt-bindings: display: sn65dsi83: Add output data-lanes property
Add an optional output LVDS data lanes property with two allowed values
for standard and reversed layouts. The reversed layout informs the driver
that the reverse LVDS config option must be set for the respective output
channel.
> diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> index e69b6343a8ebb..4000bf0b13709 100644
> --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml
> @@ -86,10 +86,54 @@ properties:
> description: Video port for LVDS Channel-A output (panel or bridge).
> $ref: '#/$defs/lvds-port'
>
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
[Severity: Medium]
Will this unevaluatedProperties constraint cause valid properties inherited
from the sibling '$ref: '#/$defs/lvds-port'' reference to be improperly
rejected?
Since unevaluatedProperties is scoped only to this inline schema, it cannot
see annotations from the lvds-port definition. If a device tree file defines
port@2 with both data-lanes and properties like ti,lvds-termination-ohms,
could this result in a validation failure when running make dtbs_check?
[ ... ]
> port@3:
> description: Video port for LVDS Channel-B output (panel or bridge).
> $ref: '#/$defs/lvds-port'
>
> + properties:
> + endpoint:
> + $ref: /schemas/media/video-interfaces.yaml#
> + unevaluatedProperties: false
[Severity: Medium]
Similar to port@2 above, could this locally scoped unevaluatedProperties: false
block reject valid properties inherited from the lvds-port definition on
port@3?
> +
> + properties:
> + data-lanes:
> + $ref: /schemas/types.yaml#/definitions/uint32-array
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260717115002.308035-1-wojciech.dubowik@mt.com?part=2
^ permalink raw reply
* Re: [PATCH 1/4] regulator: dt-bindings: Add Silergy SYR82X allowed modes
From: Victor Krawiec @ 2026-07-17 12:02 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: lgirdwood, broonie, robh, krzk+dt, conor+dt, linux-kernel,
devicetree
In-Reply-To: <20260717-nostalgic-raptor-of-sunshine-1aba9a@quoll>
On 7/17/26 11:08, Krzysztof Kozlowski wrote:
> On Wed, Jul 15, 2026 at 05:51:38PM +0200, Victor Krawiec wrote:
>> Make the PWM mode configurable from devicetree. Some boards require forced
>> PWM mode to keep the supply ripple within acceptable limits under light
>> load conditions
>>
>> Indexes are starting from 1 to keep backward compatibility with existing
>> device trees
>>
>> Signed-off-by: Victor Krawiec <victor.krawiec@arturia.com>
>> ---
>> .../dt-bindings/regulator/silergy,syr82x.h | 20 +++++++++++++++++++
>> 1 file changed, 20 insertions(+)
>> create mode 100644 include/dt-bindings/regulator/silergy,syr82x.h
>>
> This header should be mentioned in the binding in property description.
Thank you for the review. I'll add it to the binding in the next iteration.
>> diff --git a/include/dt-bindings/regulator/silergy,syr82x.h b/include/dt-bindings/regulator/silergy,syr82x.h
>> new file mode 100644
>> index 000000000000..6d4aa86bb5c1
>> --- /dev/null
>> +++ b/include/dt-bindings/regulator/silergy,syr82x.h
> Some confusing name. How is your binding file called? This must be the
> same.
The binding file is named fcs,fan53555.yaml and handles several devices including the Silergy SYR82X which I was targeting in this patch serie. I will rename the header to have the same name as the binding file. Should I also rename the macros defined inside the header (SYR82X_REGULATOR_MODE_*) ?
The underlying implementation in the driver (in fan53555_device_mode_map_setup() it the patch serie) is limited to SYR82X because it is the only hardware that I'm able to test. That's why the binding part was referring to this specific device.
Best regards,
Victor
^ permalink raw reply
* [PATCH 1/4] drm/rockchip: lvds: propagate bus_flags to the CRTC state
From: Rok Markovic @ 2026-07-17 12:00 UTC (permalink / raw)
To: Heiko Stuebner, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Alibek Omarov, Rok Markovic
In-Reply-To: <20260717120005.2087386-1-rok@kanardia.eu>
rockchip_lvds_encoder_atomic_check() sets output_mode and output_type
but never copies the connector's bus_flags into the Rockchip CRTC
state, unlike dw_dp-rockchip.c and dw-mipi-dsi2-rockchip.c which both
do.
panel-lvds parses pixelclk-active from the DT display timing and
publishes it on the connector as DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE.
VOP2 reads that flag back out of the CRTC state to decide
POLFLAG_DCLK_INV. With the flag dropped here, vcstate->bus_flags is
always zero, so a panel that asks to be clocked on the falling edge is
driven on the rising one, and there is no way to express the panel's
requirement from DT at all.
No functional change for the SoCs currently supported by this driver:
rk3288 and px30 pair with the VOP1 driver (rockchip_drm_vop.c), which
never reads bus_flags - only VOP2 consumes it. The flag becomes live
with the RK3568 support added later in this series.
Signed-off-by: Rok Markovic <rok@kanardia.eu>
Assisted-by: Claude:claude-opus-4-8
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 75f898a..95fa0a9 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -129,7 +129,15 @@ rockchip_lvds_encoder_atomic_check(struct drm_encoder *encoder,
struct drm_connector_state *conn_state)
{
struct rockchip_crtc_state *s = to_rockchip_crtc_state(crtc_state);
-
+ struct drm_connector *connector = conn_state->connector;
+
+ /*
+ * The VOP derives the pixel clock polarity from this. Without it a
+ * panel that declares pixelclk-active = <0> is clocked on the wrong
+ * edge. panel-lvds fills the connector's bus_flags in from the DT
+ * display timing.
+ */
+ s->bus_flags = connector->display_info.bus_flags;
s->output_mode = ROCKCHIP_OUT_MODE_P888;
s->output_type = DRM_MODE_CONNECTOR_LVDS;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 6/8] dt-bindings: spi: dw-apb-ssi: add Axiado AX3005 SPI variant
From: Mark Brown @ 2026-07-17 12:02 UTC (permalink / raw)
To: Swark Yang
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
Linus Walleij, Bartosz Golaszewski, Jan Kotas, Michal Simek,
Andi Shyti, Przemysław Gaj, Alexandre Belloni, Frank Li,
Boris Brezillon, Greg Kroah-Hartman, Jiri Slaby, Mathias Nyman,
devicetree, linux-arm-kernel, linux-kernel, linux-gpio, linux-i2c,
linux-i3c, linux-serial, linux-spi, linux-usb
In-Reply-To: <20260716-upstream-axiado-ax3005-upstream-v3-6-c429095143ec@axiado.com>
[-- Attachment #1: Type: text/plain, Size: 728 bytes --]
On Thu, Jul 16, 2026 at 08:51:13PM -0700, Swark Yang wrote:
> Add binding for Axiado AX3005 SPI controller. So far, no changes
> are known, so it can fall back to the snps,dwc-ssi-1.01a compatible.
Please include human readable descriptions of things like commits and
issues being discussed in e-mail in your mails, this makes them much
easier for humans to read especially when they have no internet access.
I do frequently catch up on my mail on flights or while otherwise
travelling so this is even more pressing for me than just being about
making things a bit easier to read.
If there is no need for things to be part of a multi-subsystem series
(eg, dependencies) it's normally better to send each subsystem
separately.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH 2/4] dt-bindings: display: rockchip,lvds: add RK3568
From: Rok Markovic @ 2026-07-17 12:00 UTC (permalink / raw)
To: Heiko Stuebner, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Alibek Omarov, Rok Markovic
In-Reply-To: <20260717120005.2087386-1-rok@kanardia.eu>
The RK3568 LVDS transmitter has no register block of its own: it is
programmed entirely through the GRF and re-uses the MIPI DSI0 D-PHY
(rockchip,rk3568-dsi-dphy) in LVDS mode. It therefore needs
phys/phy-names like px30, but unlike px30 it does take a pclk
(PCLK_DSITX_0, shared with the DSI controller the D-PHY belongs to).
It has no analog supplies of its own and no pinctrl: the lanes are
dedicated D-PHY pins, not muxable GPIOs.
Signed-off-by: Rok Markovic <rok@kanardia.eu>
Assisted-by: Claude:claude-opus-4-8
---
.../display/rockchip/rockchip,lvds.yaml | 22 +++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
index 03b002a..6280f7e 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,lvds.yaml
@@ -15,6 +15,7 @@ properties:
enum:
- rockchip,px30-lvds
- rockchip,rk3288-lvds
+ - rockchip,rk3568-lvds
reg:
maxItems: 1
@@ -121,6 +122,27 @@ allOf:
- avdd1v8-supply
- avdd3v3-supply
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: rockchip,rk3568-lvds
+
+ then:
+ properties:
+ reg: false
+ avdd1v0-supply: false
+ avdd1v8-supply: false
+ avdd3v3-supply: false
+ pinctrl-names: false
+ pinctrl-0: false
+
+ required:
+ - clocks
+ - clock-names
+ - phys
+ - phy-names
+
additionalProperties: false
examples:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/2] iio: accel: mma8452: Allow open drain interrupt pin configuration
From: Esben Haabendal @ 2026-07-17 12:02 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, Lars-Peter Clausen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Martin Kepplinger,
Sean Nyekjaer, David Lechner, Nuno Sá, Andy Shevchenko,
Martin Kepplinger, linux-iio, devicetree, linux-kernel
In-Reply-To: <alkgZTnHyvEasMCk@ashevche-desk.local>
"Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
> On Thu, Jul 16, 2026 at 04:51:34PM +0000, Esben Haabendal wrote:
>> On Wednesday, 15 July 2026 at 16:56, Andy Shevchenko <andriy.shevchenko@intel.com> wrote:
>> > On Wed, Jul 15, 2026 at 04:25:20PM +0200, Esben Haabendal wrote:
>> > > "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
>> > > > On Wed, Jul 15, 2026 at 01:35:41PM +0200, Esben Haabendal wrote:
>> > > >> "Andy Shevchenko" <andriy.shevchenko@intel.com> writes:
>> > > >> > On Wed, Jul 15, 2026 at 10:07:39AM +0200, Esben Haabendal wrote:
>
> ...
>
>> > > >> >> if (client->irq) {
>> > > >> >> ret = request_threaded_irq(client->irq, NULL, mma8452_interrupt,
>> > > >> >> - IRQF_TRIGGER_LOW | IRQF_ONESHOT,
>> > > >> >> + IRQF_TRIGGER_LOW | IRQF_ONESHOT |
>> > > >> >> + data->open_drain ? IRQF_SHARED : 0,
>> > > >> >> client->name, indio_dev);
>> > > >> >
>> > > >> > Why do we care?
>> > > >>
>> > > >> Care about what exactly?
>> > > >
>> > > > About exclusivity of the interrupt.
>> > >
>> > > Ok.
>> > >
>> > > >> We need to add IRQF_SHARED flag in order to allow shared interrupt, and
>> > > >> we should not add it when using (the default) push-pull mode.
>> > > >
>> > > > Why not? How would it make any difference from SW perspective?
>> > >
>> > > Not adding the IRQF_SHARED flag prevents use with shared interrupts. I
>> > > think we are on the same page on that.
>> > >
>> > > Unconditional adding IRQF_SHARED flag would allow configurations where
>> > > other devices share interrupt line with mma8452 compatible chip
>> > > configured with push-pull, resulting in broken or unpredictable results.
>> > > I don't see why we should not care about that.
>> >
>> > But it's not their problem! If it's this device that prevents this
>> > configuration, it should have a check. With this code it just hides
>> > and changing a DT property will lead to kernel warning.
>>
>> The chip such does not prevent the configuration, and does not prevent
>> sharing the interrupt. The irq pin in the device can be configured in either
>> push-pull mode or open-drain mode.
>> In order to allow sharing interrupt line with other chips, the chip
>> must be configured with irq pin in open-drain mode, which is what the
>> drive-open-drain device-tree property I am adding in this series enables
>> developers to do.
>> If/when you add this property to the device-tree, the irq pin will be
>> in open-drain mode, and the IRQF_SHARED flag can (and should IMHO) be set
>> as the interrupt line can be shared.
>> If/when the drive-open-drain property is not set (existing device-trees
>> and current only supported behavior), the chip cannot support sharing the
>> interrupt line, and adding the IRQF_SHARED flag would be a bug, as the
>> chip irq pin requires an exclusive interrupt input.
>>
>> Maybe the confusion is caused by the fact that the drive-open-drain
>> does not describe how the irq pin IS behaving, but rather how it SHOULD
>> behave, and possibly required because of the HW designed having tied the
>> irq pin to an irq input together with other irq sources.
>
> Why do we care of push-pull then? Can't we always make it open-drain?
No. Open-drain requires an external pull-up resistor. If there are no
external pull-up resistor, open-drain will not work, and interrupt
sharing is not possible.
>> > > > Yes, I understand the HW case.
>> > > >
>> > > >> > The (hidden) problem this will have in the future is that the IRQ core
>> > > >> > will splat a warning in case that other shared IRQs might be
>> > > >> > configured with different flags. Putting that flag conditionally makes
>> > > >> > it a mine field for the users. Instead just unconditionally add that
>> > > >> > flag and we will get reports as soon as there will be a user that
>> > > >> > shares the same interrupt pin with some other devices which drivers do
>> > > >> > not use the same settings.
>> > > >>
>> > > >> If we add the IRQF_SHARED flag unconditionally, it will be set also when
>> > > >> push-pull mode is enabled. I don't see how the kernel will be able to
>> > > >> notice that that is not going to work. If you have another device that
>> > > >> uses IRQF_TRIGGER_LOW|IRF_ONESHOT|IRQF_SHARED, it will not work with the
>> > > >> MMA8452 device when configured as push-pull.
>> > > >
>> > > > Right, and why do we care (again)?
>> > >
>> > > Why we care that the system as a whole (SW on top of HW) will not work?
>> > >
>> > > If we don't care about that, why do we even have this IRQF_SHARED flag?
>> > > The only purpose of that is to tell the kernel that this particular
>> > > device / interrupt will work with shared interrupt or not.
>> > >
>> > > Isn't that exactly what I do with this change? Nothing more, nothing less.
>> > >
>> > > > It's pure DT/FW/HW issue, not an SW issue.
>> > > > Otherwise it will become a carefully placed mine for the poor user who will
>> > > > use these flags and try to share an interrupt with the mma8452 device which
>> > > > has no set property and uses push-pull mode.
>> > >
>> > > I don't get how you see it like that. Adding IRQF_SHARED unconditionally
>> > > would create exactly the mine field you are talking about. Poor users
>> > > can specify a system configuration (DT) that tries to use a shared
>> > > interrupt line, but configures the mma8452 compatible chip in push-pull.
>> > > The poor user will not only be poor, but also unhappy.
>> >
>> > > By applying the IRQF_SHARED dynamically, the kernel will be able to fail
>> > > in a controlled manner instead, making it much less painful to create a
>> > > working system configuration (DT)
>> >
>> > And my point that we need to make less painful runtime experience.
>>
>> Yes. We agree on that.
>>
>> But I do believe that my patch is that painful runtime experience.
>>
>> Adding IRQF_SHARED flag when irq pin is configured in push-pull mode
>> will be painful. I know, that was my initial approach. Does really not
>> work, and can lead to wasting time on debugging the HW.
>>
>> > > Going back to your poor user story above, if the poor user tries to
>> > > share the interrupt pin with the mma8452 device, it will get an error
>> > > (just as it is with the kernel today). The device does not support
>> > > shared interrupts. Reading the DT bindings documentation, the user
>> > > should be able to find the drive-open-drain property, and add that to
>> > > the device-tree to make things work. Maybe even consider if that is
>> > > compatible with the hardware being used.
>> > >
>> > > If IRQF_SHARED was set unconditionally, the user would not get an error,
>> > > but most likely would get a system where no irq's were raised for the
>> > > other chips. I sincerely believe that debugging this is much more
>> > > painful than reading device-tree bindings.
>> > >
>> > > > Did I miss anything?
>> > >
>> > > I don't know. Maybe I am missing the obvious here.
>> >
>> > I consider the case when shared interrupt is enabled on both devices, but
>> > second one (driver) missed the same IRQ flags. This becomes a warning in
>> > IRQ core.
>>
>> Missed which IRQ flags?
>
> _LOW, for instance.
All devices sharing an interrupt really do need to agree on these
flags. Do you known any drivers that does not specify the trigger type
when requesting an irq?.
You cannot share an interrupt line if not all devices have the
same trigger mode. So if one device on a shared interrupt has _LOW, all
the other devices need to have that. Not just the flags, but the actual
triggering mode of the device. Some chips might support more than one
mode, others only one specific mode.
>> > Shared interrupts it's also a contract with all stakeholders on keeping
>> > the same flags for all devices.
>>
>> Of-course.
>>
>> And adding IRQF_SHARED is a contract that says that the interrupt can be
>> shared. I can only see that it would be a bug to add that flag in cases
>> where we know that the interrupt really cannot be shared.
>>
>> As for the IRQF_TRIGGER_LOW flag being set, I think that looks correct
>> as long as we do not support switching to active high irq polarity.
>
> No, it's not. It overrides whatever platform wants to have.
The trigger type is not just a platform thing. It describes how the
device behaves. Device that only support one triggering mode must set
the flag that describes that. Devices that can be configured for
different triggering modes can implement that, and should then configure
the device for the chosen mode and set the flags accordingly.
> It prevents PCB level designs from anything else.
Yes. In this case, the current driver does not support designs that
requires the mma8452 compatible chip to be configured for active high
irq trigger. We could and probably should address that.
But that is a different issue than what I am doing here. And I don't
have hardware readily available where this can be tested, so I would
prefer to let somebody else do that.
I am adding support for designs that require the mma8452 compatible chip
to be configured for open-drain, while staying backwards compatible and
allowing support for designs without external pull-up.
In all cases, the driver should register the interrupt handle with the
IRQF_TRIGGER_* flag that matches what the chip is configured for.
I believe leaving it out is invalid.
>> But on that topic, the chip actually supports selecting between active
>> low and high irq polarity. Should we implement something along the lines
>> of what is done in smi330_setup_irq() in iio/imu/smi330/smi330_core.c?
>> And thereby allow using the device with active high irq?
>
> ...
>
>> > After looking into genirq code I don't see other way how to handle this.
>> > It looks like we need to address the TRIGGER_LOW first, in other words
>> > we need drop that flag when IRQF_SHARED is set, and leave it to users
>> > to setup IRQ trigger properly on all sides.
>>
>> Why do we need to drop the IRQF_TRIGGER_LOW flag because IRQF_SHARED is
>> set?
>>
>> Users as in those specifying the system device-tree?
>
> No, because like I said, the SHARED is a *contract*, it's not just a setting.
Absolutely. That is the key here.
IQRF_SHARED is a contract, where the driver promises to return IRQ_NONE
if the interrupt is not for that device. This is already implemented
by mma8452_interrupt().
> And that contract includes the similarities on the IRQ flags. One may not
> have two devices with different trigger level, it's a common sense,
> right?
Right.
And that is exactly why we have to specify the IRQF_TRIGGER_* flag that
the irq output is configured for. The driver will not switch to the
desired trigger level based on what other devices on the same interrupt
uses. You have to configure/specify the trigger mode and leve and set
the IRQF_TRIGGER_* flag accordingly.
> So, SHARED must exclude anything that comes from the platform description or
> IRQ chip controller (limitations).
Now you got me confused again. The IRQF_TRIGGER_LOW flag given to
request_threaded_irq() is not coming from platform description or IRQ
chip controller. It describes the trigger mode that the chip is
excercising in the current implementation.
The kernel would not know how to configure the IRQ chip controller, and
in case of shared interrupts, would not be able to check that the
devices sharing the interrupt is configured correctly.
> So, without addressing that, it makes a little sense to add SHARED.
Not true.
Let me take my system here. I have multiple chips / irq sources
connected to the same interrupt input on the CPU. They are all using
level low triggering (which hardware and system engineers have ofcourse
been observant enough to ensure).
Without my change, the mma8452 driver does not support configuring the
chip to use open-drain, so it will be pulling the interrupt line high,
interrupting irq for all interrupt sources.
With my change, I can now configure the device to use open-drain,
register the interrupt, and everything works nicely.
And the change is backwards compatible, as you have to specify
drive-open-drain to switch from PP to OD.
How does that not make sense?
> I would accept this patch without adding SHARED, perhaps.
Without IRQF_SHARED, I cannot use it with the hardware I have which are
sharing the interrupt.
> But still question why we can't use the OD instead of PP for the pin
> to begin with?
Because HW needs to be designed for OD. It is perfectly valid to design
hardware that relies on the default mode of mma8452 and compatible chips
to use PP. Switching to OD will not work for such systems without
external pull-up.
> Do we have real HW that uses IRQ input without a pull-up?
I certainly have had such designs many times in the past.
Why should we implement the driver so that we cannot support such valid
HW designs?
/Esben
^ permalink raw reply
* [PATCH 3/4] drm/rockchip: lvds: add RK3568 support
From: Rok Markovic @ 2026-07-17 12:00 UTC (permalink / raw)
To: Heiko Stuebner, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Alibek Omarov, Rok Markovic
In-Reply-To: <20260717120005.2087386-1-rok@kanardia.eu>
The RK3568 LVDS transmitter has no register block of its own. It is
driven entirely through the GRF and re-uses the MIPI DSI0 D-PHY in
PHY_MODE_LVDS, which phy-rockchip-inno-dsidphy already supports.
Based on Alibek Omarov's earlier posting [1], with the changes below.
Power the D-PHY from the encoder enable path rather than from probe.
phy_power_on() runs the phy driver's whole LVDS bring-up: PLL and
bandgap power-on, a settle, PLL mode select, then a reset pulse of the
serializer and the lane enables. None of that is safe at probe time -
the GRF has not yet switched the block to LVDS mode (LVDS0_MODE_EN is
set from rk3568_lvds_poweron(), i.e. the enable path) and the VOP is
not driving dclk. The serializer is clocked from dclk and latches its
state coming out of that reset, so it comes up dead and stays dead.
The failure is silent: every register in the phy, the GRF and the VOP
reads back exactly as on a working system while the lanes sit at
common mode and never toggle.
Program RK3568_LVDS0_DCLK_INV_SEL from the CRTC state's bus_flags so
the panel's declared pixelclk-active is honoured on the LVDS block as
well as on the VOP pin polarity. Both have to agree with the edge the
panel samples on.
Re-assert RK3568_LVDS0_P2S_EN in rk3568_lvds_poweron().
rk3568_lvds_poweroff() clears MODE_EN and P2S_EN together, so setting
P2S_EN once at probe would leave the parallel-to-serial converter off
after the first disable/enable cycle.
Use regmap_write() rather than regmap_update_bits() for the GRF. These
registers are write-masked - the upper 16 bits select which of the
lower 16 a write may change - so there is nothing to preserve and no
reason to read first. Passing a FIELD_PREP_WM16() value as both the
mask and the value of an update_bits() applies the masking twice and
only works by accident.
Between the two, nothing needs programming at probe at all: the GRF is
written entirely from the enable path, so px30_lvds_probe() is left
alone rather than being refactored into a shared phy helper.
[1] https://lore.kernel.org/all/20230119184807.171132-1-a1ba.omarov@gmail.com/
Co-developed-by: Alibek Omarov <a1ba.omarov@gmail.com>
Signed-off-by: Alibek Omarov <a1ba.omarov@gmail.com>
Signed-off-by: Rok Markovic <rok@kanardia.eu>
Assisted-by: Claude:claude-opus-4-8
---
drivers/gpu/drm/rockchip/rockchip_lvds.c | 161 +++++++++++++++++++++++
drivers/gpu/drm/rockchip/rockchip_lvds.h | 10 ++
2 files changed, 171 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c b/drivers/gpu/drm/rockchip/rockchip_lvds.c
index 95fa0a9..f45d04a 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.c
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -435,6 +435,133 @@ static void px30_lvds_encoder_disable(struct drm_encoder *encoder)
drm_panel_unprepare(lvds->panel);
}
+static int rk3568_lvds_poweron(struct rockchip_lvds *lvds)
+{
+ int ret;
+
+ ret = clk_enable(lvds->pclk);
+ if (ret < 0) {
+ DRM_DEV_ERROR(lvds->dev, "failed to enable lvds pclk %d\n", ret);
+ return ret;
+ }
+
+ ret = pm_runtime_get_sync(lvds->dev);
+ if (ret < 0) {
+ DRM_DEV_ERROR(lvds->dev, "failed to get pm runtime: %d\n", ret);
+ clk_disable(lvds->pclk);
+ return ret;
+ }
+
+ /*
+ * Enable LVDS mode and the parallel-to-serial converter. These are
+ * write-masked registers, so a plain write only touches the bits named
+ * here; there is nothing to preserve and no need to read first.
+ */
+ return regmap_write(lvds->grf, RK3568_GRF_VO_CON2,
+ RK3568_LVDS0_MODE_EN(1) |
+ RK3568_LVDS0_P2S_EN(1));
+}
+
+static void rk3568_lvds_poweroff(struct rockchip_lvds *lvds)
+{
+ regmap_write(lvds->grf, RK3568_GRF_VO_CON2,
+ RK3568_LVDS0_MODE_EN(0) | RK3568_LVDS0_P2S_EN(0));
+
+ pm_runtime_put(lvds->dev);
+ clk_disable(lvds->pclk);
+}
+
+static int rk3568_lvds_grf_config(struct drm_encoder *encoder,
+ struct drm_display_mode *mode)
+{
+ struct rockchip_lvds *lvds = encoder_to_lvds(encoder);
+ struct rockchip_crtc_state *s =
+ to_rockchip_crtc_state(encoder->crtc->state);
+ bool negedge = !!(s->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE);
+
+ if (lvds->output != DISPLAY_OUTPUT_LVDS) {
+ DRM_DEV_ERROR(lvds->dev, "Unsupported display output %d\n",
+ lvds->output);
+ return -EINVAL;
+ }
+
+ /*
+ * The LVDS block has its own dclk inversion select, separate from the
+ * VOP's pin polarity. Both have to agree with what the panel samples on.
+ */
+ regmap_write(lvds->grf, RK3568_GRF_VO_CON2,
+ RK3568_LVDS0_DCLK_INV_SEL(negedge));
+
+ /* Set format */
+ return regmap_write(lvds->grf, RK3568_GRF_VO_CON0,
+ RK3568_LVDS0_SELECT(lvds->format) |
+ RK3568_LVDS0_MSBSEL(1));
+}
+
+static void rk3568_lvds_encoder_enable(struct drm_encoder *encoder)
+{
+ struct rockchip_lvds *lvds = encoder_to_lvds(encoder);
+ struct drm_display_mode *mode = &encoder->crtc->state->adjusted_mode;
+ int ret;
+
+ drm_panel_prepare(lvds->panel);
+
+ ret = rk3568_lvds_poweron(lvds);
+ if (ret) {
+ DRM_DEV_ERROR(lvds->dev, "failed to power on LVDS: %d\n", ret);
+ drm_panel_unprepare(lvds->panel);
+ return;
+ }
+
+ ret = rk3568_lvds_grf_config(encoder, mode);
+ if (ret) {
+ DRM_DEV_ERROR(lvds->dev, "failed to configure LVDS: %d\n", ret);
+ drm_panel_unprepare(lvds->panel);
+ return;
+ }
+
+ /*
+ * Only now bring the D-PHY up. phy_power_on() runs the whole
+ * inno_dsidphy_lvds_mode_enable() sequence - PLL and bandgap power-on,
+ * a settle, PLL mode select, then a reset pulse of the serializer and
+ * the lane enables. All of that has to happen with the block already
+ * switched to LVDS mode in the GRF (above) and with the VOP's dclk
+ * running, because the serializer is clocked from dclk and latches its
+ * state out of that reset.
+ *
+ * Doing it at probe instead - as this driver used to - resets and
+ * enables the serializer against a block that is not in LVDS mode yet
+ * and has no input clock. Every register then reads back correct while
+ * the lanes sit at common mode forever. Rockchip's BSP orders it this
+ * way (GRF writes, then phy_set_mode + phy_power_on).
+ */
+ ret = phy_set_mode(lvds->dphy, PHY_MODE_LVDS);
+ if (ret) {
+ DRM_DEV_ERROR(lvds->dev, "failed to set phy mode: %d\n", ret);
+ drm_panel_unprepare(lvds->panel);
+ return;
+ }
+
+ ret = phy_power_on(lvds->dphy);
+ if (ret) {
+ DRM_DEV_ERROR(lvds->dev, "failed to power on phy: %d\n", ret);
+ drm_panel_unprepare(lvds->panel);
+ return;
+ }
+
+ drm_panel_enable(lvds->panel);
+}
+
+static void rk3568_lvds_encoder_disable(struct drm_encoder *encoder)
+{
+ struct rockchip_lvds *lvds = encoder_to_lvds(encoder);
+
+ drm_panel_disable(lvds->panel);
+ phy_power_off(lvds->dphy);
+ rk3568_lvds_poweroff(lvds);
+ drm_panel_unprepare(lvds->panel);
+}
+
static const
struct drm_encoder_helper_funcs rk3288_lvds_encoder_helper_funcs = {
.enable = rk3288_lvds_encoder_enable,
@@ -449,6 +576,13 @@ struct drm_encoder_helper_funcs px30_lvds_encoder_helper_funcs = {
.atomic_check = rockchip_lvds_encoder_atomic_check,
};
+static const
+struct drm_encoder_helper_funcs rk3568_lvds_encoder_helper_funcs = {
+ .enable = rk3568_lvds_encoder_enable,
+ .disable = rk3568_lvds_encoder_disable,
+ .atomic_check = rockchip_lvds_encoder_atomic_check,
+};
+
static int rk3288_lvds_probe(struct platform_device *pdev,
struct rockchip_lvds *lvds)
{
@@ -512,6 +646,22 @@ static int px30_lvds_probe(struct platform_device *pdev,
return phy_power_on(lvds->dphy);
}
+static int rk3568_lvds_probe(struct platform_device *pdev,
+ struct rockchip_lvds *lvds)
+{
+ /*
+ * Grab and init the phy, but do NOT power it on here - that is done in
+ * rk3568_lvds_encoder_enable() once the GRF is in LVDS mode and dclk is
+ * running. See the comment there. The GRF is not touched at probe
+ * either: every bit of it is programmed from the enable path.
+ */
+ lvds->dphy = devm_phy_get(&pdev->dev, "dphy");
+ if (IS_ERR(lvds->dphy))
+ return PTR_ERR(lvds->dphy);
+
+ return phy_init(lvds->dphy);
+}
+
static const struct rockchip_lvds_soc_data rk3288_lvds_data = {
.probe = rk3288_lvds_probe,
.helper_funcs = &rk3288_lvds_encoder_helper_funcs,
@@ -522,6 +672,11 @@ static const struct rockchip_lvds_soc_data px30_lvds_data = {
.helper_funcs = &px30_lvds_encoder_helper_funcs,
};
+static const struct rockchip_lvds_soc_data rk3568_lvds_data = {
+ .probe = rk3568_lvds_probe,
+ .helper_funcs = &rk3568_lvds_encoder_helper_funcs,
+};
+
static const struct of_device_id rockchip_lvds_dt_ids[] = {
{
.compatible = "rockchip,rk3288-lvds",
@@ -531,6 +686,10 @@ static const struct of_device_id rockchip_lvds_dt_ids[] = {
.compatible = "rockchip,px30-lvds",
.data = &px30_lvds_data
},
+ {
+ .compatible = "rockchip,rk3568-lvds",
+ .data = &rk3568_lvds_data
+ },
{}
};
MODULE_DEVICE_TABLE(of, rockchip_lvds_dt_ids);
@@ -601,6 +760,8 @@ static int rockchip_lvds_bind(struct device *dev, struct device *master,
encoder = &lvds->encoder.encoder;
encoder->possible_crtcs = drm_of_find_possible_crtcs(drm_dev,
dev->of_node);
+ rockchip_drm_encoder_set_crtc_endpoint_id(&lvds->encoder,
+ dev->of_node, 0, 0);
ret = drm_simple_encoder_init(drm_dev, encoder, DRM_MODE_ENCODER_LVDS);
if (ret < 0) {
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.h b/drivers/gpu/drm/rockchip/rockchip_lvds.h
index 2d92447..93d3415 100644
--- a/drivers/gpu/drm/rockchip/rockchip_lvds.h
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.h
@@ -121,4 +121,14 @@
#define PX30_LVDS_P2S_EN(val) FIELD_PREP_WM16(BIT(6), (val))
#define PX30_LVDS_VOP_SEL(val) FIELD_PREP_WM16(BIT(1), (val))
+#define RK3568_GRF_VO_CON0 0x0360
+#define RK3568_LVDS0_SELECT(val) FIELD_PREP_WM16(GENMASK(5, 4), (val))
+#define RK3568_LVDS0_MSBSEL(val) FIELD_PREP_WM16(BIT(3), (val))
+
+#define RK3568_GRF_VO_CON2 0x0368
+#define RK3568_LVDS0_DCLK_INV_SEL(val) FIELD_PREP_WM16(BIT(9), (val))
+#define RK3568_LVDS0_DCLK_DIV2_SEL(val) FIELD_PREP_WM16(BIT(8), (val))
+#define RK3568_LVDS0_MODE_EN(val) FIELD_PREP_WM16(BIT(1), (val))
+#define RK3568_LVDS0_P2S_EN(val) FIELD_PREP_WM16(BIT(0), (val))
+
#endif /* _ROCKCHIP_LVDS_ */
--
2.43.0
^ permalink raw reply related
* [PATCH 4/4] arm64: dts: rockchip: rk356x: add LVDS node
From: Rok Markovic @ 2026-07-17 12:00 UTC (permalink / raw)
To: Heiko Stuebner, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Alibek Omarov, Rok Markovic
In-Reply-To: <20260717120005.2087386-1-rok@kanardia.eu>
Add the LVDS transmitter node. It has no register block of its own -
it is programmed through the GRF and borrows the MIPI DSI0 D-PHY - so
it carries no reg, only the DSITX_0 pclk, the phy and the VO power
domain.
Disabled by default; boards that route LVDS enable it along with
dsi_dphy0 and wire lvds_in to a VOP2 video port.
Signed-off-by: Rok Markovic <rok@kanardia.eu>
Assisted-by: Claude:claude-opus-4-8
---
arch/arm64/boot/dts/rockchip/rk356x-base.dtsi | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
index 64bdd8b..9244b55 100644
--- a/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk356x-base.dtsi
@@ -878,6 +878,31 @@
};
};
+ lvds: lvds {
+ compatible = "rockchip,rk3568-lvds";
+ clocks = <&cru PCLK_DSITX_0>;
+ clock-names = "pclk_lvds";
+ phys = <&dsi_dphy0>;
+ phy-names = "dphy";
+ power-domains = <&power RK3568_PD_VO>;
+ rockchip,grf = <&grf>;
+ rockchip,output = "lvds";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ lvds_in: port@0 {
+ reg = <0>;
+ };
+
+ lvds_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
qos_gpu: qos@fe128000 {
compatible = "rockchip,rk3568-qos", "syscon";
reg = <0x0 0xfe128000 0x0 0x20>;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/4] dt-bindings: embedded-controller: Add Glymur QCB EC
From: Anvesh Jain P @ 2026-07-17 12:04 UTC (permalink / raw)
To: Gopikrishna Garmidi, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sibi Sankar, Pankaj Patil
Cc: Rajendra Nayak, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260717-glymur-qcb-v1-2-aaf1cff84aab@oss.qualcomm.com>
On 7/17/2026 5:24 PM, Gopikrishna Garmidi wrote:
> Add the qcom,glymur-qcb-ec compatible for the embedded controller on the
> Glymur QCB. It is the same EC used on the CRD.
>
> Signed-off-by: Gopikrishna Garmidi <gopikrishna.garmidi@oss.qualcomm.com>
> ---
> .../devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
> index ac5a08f8f76d..de416057063c 100644
> --- a/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
> +++ b/Documentation/devicetree/bindings/embedded-controller/qcom,hamoa-crd-ec.yaml
> @@ -21,6 +21,7 @@ properties:
> - items:
> - enum:
> - qcom,glymur-crd-ec
> + - qcom,glymur-qcb-ec
> - qcom,hamoa-iot-evk-ec
> - const: qcom,hamoa-crd-ec
> - enum:
>
Reviewed-by: Anvesh Jain P <anvesh.p@oss.qualcomm.com>
--
Best Regards,
Anvesh
^ permalink raw reply
* [PATCH v3 00/11] arm64: dts: describe the Lynx 10G and 28G SerDes blocks for Layerscape SoCs
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
This patch set adds the device tree nodes for the Lynx10G SerDes blocks
found on the LS1028A, LS1046A, LS1088A and LS2088A SoCs.
The first 5 patches slowly change the LX2160A DTS support to a new
structure which does not use any delete-node or delete-property
directives. This is a direct result of the discussion with Frank in the
v2 of this set:
https://lore.kernel.org/all/akwAmzAbtg0Ejey0@SMW015318/
Patches 5 and 6 transition the LX2160A and LX2162 SoC dtsi to use the
device-specific Lynx28G SerDes compatible while the remainder of the set
adds the SerDes block descriptions for the LS1028A, LS1046A, LS2088A and
LS1088A SoCs.
Changes in v3:
- Changes how the LX216XA based SoC dtsi files are structured.
- Split the enabling of serdes_1 into a separate patch
- Split the LX2162A changes to another patch
- Move the status property to be the last for serdes_3
- Move the changes to the new fsl-lx2160a-serdes.dtsi file
Changes in v2:
- Enable serdes_1 on all board DTs that has consumers for it.
- Use the proper name for serdes_3 in fsl-lx2162a.dtsi.
- Remove paragraph from commit message which mentioned some consumer
changes that are no longer needed nor part of the commit.
- Change the size of the SerDes region to 0x2000
Ioana Ciornei (8):
arm64: dts: lx2160a: explicitly enable serdes_1 node
arm64: dts: lx2160a: extract the PCIe nodes into a separate dtsi
arm64: dts: lx2160a: extract the SerDes nodes into a separate dtsi
arm64: dts: lx2160a: extract the PCIe from LX2160A Rev2 into a
separate file
arm64: dts: lx2160a: split the dtsi to avoid delete-property
arm64: dts: lx2160a: transition to device-specific SerDes compatible
strings
arm64: dts: lx2162a: transition to device-specific SerDes compatible
strings
arm64: dts: ls1088a: describe the Lynx 10G SerDes blocks
Vladimir Oltean (3):
arm64: dts: ls1028a: describe the Lynx 10G SerDes
arm64: dts: ls1046a: describe the Lynx 10G SerDes blocks
arm64: dts: ls208xa: describe the Lynx 10G SerDes blocks
.../arm64/boot/dts/freescale/fsl-ls1028a.dtsi | 29 ++
.../arm64/boot/dts/freescale/fsl-ls1046a.dtsi | 60 ++++
.../arm64/boot/dts/freescale/fsl-ls1088a.dtsi | 58 ++++
.../arm64/boot/dts/freescale/fsl-ls208xa.dtsi | 98 +++++++
.../dts/freescale/fsl-lx2160a-bluebox3.dts | 2 +-
.../dts/freescale/fsl-lx2160a-clearfog-cx.dts | 2 +-
.../freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 +
.../dts/freescale/fsl-lx2160a-half-twins.dts | 4 +
.../dts/freescale/fsl-lx2160a-honeycomb.dts | 2 +-
.../dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi | 176 ++++++++++++
.../boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 +
.../boot/dts/freescale/fsl-lx2160a-rev1.dtsi | 9 +
.../boot/dts/freescale/fsl-lx2160a-rev2.dtsi | 188 +------------
.../dts/freescale/fsl-lx2160a-serdes.dtsi | 167 ++++++++++++
.../dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 2 +-
.../dts/freescale/fsl-lx2162a-clearfog.dts | 6 +-
.../boot/dts/freescale/fsl-lx2162a-qds.dts | 2 +-
.../dts/freescale/fsl-lx2162a-serdes.dtsi | 86 ++++++
.../arm64/boot/dts/freescale/fsl-lx2162a.dtsi | 9 +
.../{fsl-lx2160a.dtsi => fsl-lx216x.dtsi} | 181 ------------
.../dts/freescale/fsl-lx216xa-pcie-gen3.dtsi | 257 ++++++++++++++++++
21 files changed, 974 insertions(+), 372 deletions(-)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-pcie-mbvl.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-rev1.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2160a-serdes.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a-serdes.dtsi
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx2162a.dtsi
rename arch/arm64/boot/dts/freescale/{fsl-lx2160a.dtsi => fsl-lx216x.dtsi} (86%)
create mode 100644 arch/arm64/boot/dts/freescale/fsl-lx216xa-pcie-gen3.dtsi
--
2.25.1
^ permalink raw reply
* [PATCH v3 01/11] arm64: dts: lx2160a: explicitly enable serdes_1 node
From: Ioana Ciornei @ 2026-07-17 12:06 UTC (permalink / raw)
To: Frank.Li, robh, krzk+dt, conor+dt, devicetree
Cc: vladimir.oltean, linux-arm-kernel, linux-kernel, imx, linux
In-Reply-To: <20260717120635.2118610-1-ioana.ciornei@nxp.com>
Explicitly enable the serdes_1 node in all board DT files. This is
needed in order to be able to change the default status of the node to
"disabled" from the SoC DT file.
Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
---
Changes in v3:
- new patch
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi | 4 ++++
arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts | 4 ++++
arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts | 4 ++++
arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts | 4 ++++
4 files changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
index 4bc151d721dd..1f946d3a4ec0 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-clearfog-itx.dtsi
@@ -135,6 +135,10 @@ &sata3 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
index d16e27307275..954b9955b1b3 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
@@ -805,6 +805,10 @@ &rgmii_phy1 {
status = "disabled";
};
+&serdes_1 {
+ status = "okay";
+};
+
&serdes_2 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
index 935f421475ac..39b2b04be532 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rdb.dts
@@ -325,6 +325,10 @@ &sata3 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
index 99ee2b1c0f13..df2568ec7f1a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2162a-clearfog.dts
@@ -367,6 +367,10 @@ &pcs_mdio18 {
status = "okay";
};
+&serdes_1 {
+ status = "okay";
+};
+
&serdes_2 {
status = "okay";
};
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox