* [PATCH v2 1/2] dt-bindings: display: panel: Add compatibles for Zhunyi Z40046
From: Luca Leonardo Scorcia @ 2026-04-17 10:46 UTC (permalink / raw)
To: dri-devel
Cc: Luca Leonardo Scorcia, Jagan Teki, Neil Armstrong, Jessica Zhang,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Marek Vasut, Kael D'Alcamo, Lad Prabhakar,
devicetree, linux-kernel
In-Reply-To: <20260417104740.259689-1-l.scorcia@gmail.com>
The Zhunyi Z40046 is a 480x800 24-bit WVGA DSI panel based on the
Fitipower JD9161Z DSI controller found in the Xiaomi Mi Smart Clock
x04g, apparently in two different variants.
The Fitipower JD9161Z LCD driver IC is very similar to the Jadard
JD9365DA-H3, it just uses a different initialization sequence.
Since this is the first supported device from this vendor, document its
name to the vendor-prefixes.yaml file as well.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
.../devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml | 2 ++
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
index e39efb44ed42..158388a284d9 100644
--- a/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
+++ b/Documentation/devicetree/bindings/display/panel/jadard,jd9365da-h3.yaml
@@ -24,6 +24,8 @@ properties:
- radxa,display-10hd-ad001
- radxa,display-8hd-ad002
- taiguanck,xti05101-01a
+ - zhunyikeji,z40046-ctc
+ - zhunyikeji,z40046-boe
- const: jadard,jd9365da-h3
reg:
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6339988e3805..debaec59e9a0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1923,6 +1923,8 @@ patternProperties:
description: Zealz
"^zeitec,.*":
description: ZEITEC Semiconductor Co., LTD.
+ "^zhunyikeji,.*":
+ description: Shenzhen Zhunyi Technology Co., Ltd.
"^zidoo,.*":
description: Shenzhen Zidoo Technology Co., Ltd.
"^zii,.*":
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] Add support for Zhunyi Z40046 LCD panel
From: Luca Leonardo Scorcia @ 2026-04-17 10:46 UTC (permalink / raw)
To: dri-devel
Cc: Luca Leonardo Scorcia, Jagan Teki, Neil Armstrong, Jessica Zhang,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Marek Vasut, Lad Prabhakar, Kael D'Alcamo,
devicetree, linux-kernel
The Zhunyi Z40046 is a 480x800 24-bit WVGA DSI panel based on the
Fitipower JD9161Z DSI controller found in the Xiaomi Mi Smart Clock
x04g, apparently in two different variants.
The Fitipower JD9161Z LCD driver IC is very similar to the Jadard
JD9365DA-H3, it just uses different initialization sequences. A
partial data sheet is available at [1].
The two initialization sequences for the panel have been extracted from
Android original firmware for the Xiaomi Smart Clock.
Variant -ctc tested on device. Variant -boe not tested.
Changes in v2:
- Double checked and fixed some mistakes in the reverse engineered
initialization sequences
- Changed the generic variant names -v1, -v2 into -ctc and -boe, as
they're described in the Android logs
- Fix alphabetical order in bindings and correct company name
v1:
https://lore.kernel.org/all/20260305195650.119196-1-l.scorcia@gmail.com/
[1] https://github.com/QuecPython/QuecPython_lib_bundles/blob/master/libraries/LCD/JD91651z/JD9161Z_DS_Preliminary_V0.01_20180803(1).pdf
Luca Leonardo Scorcia (2):
dt-bindings: display: panel: Add compatibles for Zhunyi Z40046
drm/panel: jd9365da: Support for Zhunyi Z40046 panels
.../display/panel/jadard,jd9365da-h3.yaml | 2 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
.../gpu/drm/panel/panel-jadard-jd9365da-h3.c | 313 ++++++++++++++++++
3 files changed, 317 insertions(+)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 4/5] media: dt-bindings: add NXP i.MX95 compatible string
From: Frank Li @ 2026-04-17 10:30 UTC (permalink / raw)
To: G.N. Zhou (OSS)
Cc: Krzysztof Kozlowski, Michael Riesch, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org
In-Reply-To: <DU2PR04MB9081CE0130B8924A2B3C9E14FA222@DU2PR04MB9081.eurprd04.prod.outlook.com>
On Wed, Apr 15, 2026 at 09:21:44AM +0000, G.N. Zhou (OSS) wrote:
> Hi Krzysztof Kozlowski
>
> Thanks for your review.
>
> > -----Original Message-----
> > From: Krzysztof Kozlowski <krzk@kernel.org>
> > Sent: Wednesday, April 15, 2026 4:10 PM
> > To: G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> > Cc: Michael Riesch <michael.riesch@collabora.com>; Mauro Carvalho Chehab
> > <mchehab@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> > <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Heiko Stuebner
> > <heiko@sntech.de>; Laurent Pinchart <laurent.pinchart@ideasonboard.com>;
> > Frank Li <frank.li@nxp.com>; linux-media@vger.kernel.org; linux-
> > kernel@vger.kernel.org; devicetree@vger.kernel.org; imx@lists.linux.dev; linux-
> > arm-kernel@lists.infradead.org; linux-rockchip@lists.infradead.org
> > Subject: Re: [PATCH 4/5] media: dt-bindings: add NXP i.MX95 compatible string
> >
> > On Wed, Apr 15, 2026 at 11:46:55AM +0800, Guoniu Zhou wrote:
> > > The i.MX95 CSI-2 controller is nearly identical to i.MX93, with the
> > > only difference being the use of IDI (Image Data Interface) instead of
> > > IPI (Image Pixel Interface). The binding constraints are otherwise the
> > > same.
> >
> > Nearly identical with some difference really, really suggests they are
> > compatible. Express compatibility or explain why they are not compatible
> > (difference between IDI and IPI unfortunately does not help me).
>
> You're right that they are very similar. The key difference between IDI and IPI
> is in the software interface:
>
> - IPI (Image Pixel Interface) on i.MX93 requires software configuration through
> a set of registers to enable the interface and configure data routing.
>
> - IDI (Image Data Interface) on i.MX95 is software transparent - it requires no
> register configuration and the data routing is handled automatically by hardware.
>
> Because of this difference in register layout and initialization requirements,
> they cannot share the same compatible string. The driver needs to know which
> interface is present
Just include these key information into commit message to do judgement
it is not compatible with imx93.
Frank
>
> >
> > Best regards,
> > Krzysztof
>
^ permalink raw reply
* Re: [PATCH RFC 3/4] clk: qcom: tcsrcc-glymur: Migrate tcsr_pcie_N_clkref_en to clk_ref common helper
From: Konrad Dybcio @ 2026-04-17 10:30 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Qiang Yu, Bjorn Andersson, Taniya Das, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, johan, linux-arm-msm, linux-clk, devicetree,
linux-kernel
In-Reply-To: <z4h53al3dcy5u63zglu4rdavm3cse6sy2bbha2kxxepplawnho@4pwg7fx3cmnj>
On 4/17/26 11:39 AM, Manivannan Sadhasivam wrote:
> On Mon, Apr 13, 2026 at 01:18:16PM +0200, Konrad Dybcio wrote:
>> On 4/13/26 9:06 AM, Qiang Yu wrote:
>>> On Thu, Apr 09, 2026 at 08:19:41AM -0500, Bjorn Andersson wrote:
>>>> On Wed, Apr 01, 2026 at 09:47:38PM -0700, Qiang Yu wrote:
>>>>> On Wed, Apr 01, 2026 at 10:05:12PM +0530, Taniya Das wrote:
>>>>>> On 4/1/2026 12:05 PM, Qiang Yu wrote:
>>>>>>> diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
>>>> [..]
>>>>>>> +static const char * const tcsr_pcie_4_regulators[] = {
>>>>>>> + "vdda-refgen-0p9",
>>>>>>> + "vdda-refgen-1p2",
>>>>>>> + "vdda-qreftx1-0p9",
>>>>>>> + "vdda-qrefrpt0-0p9",
>>>>>>> + "vdda-qrefrpt1-0p9",
>>>>>>> + "vdda-qrefrpt2-0p9",
>>>>>>> + "vdda-qrefrx2-0p9",
>>>>>>> +};
>>>>>>> +
>>>>>>
>>>>>> TCSR clock refs are just not for PCIe alone, they would have supplies
>>>>>> for all the ref clocks. These supplies can also be shared across other
>>>>>> clock refs. I think it is not the correct way to handle the supplies, as
>>>>>> TCSR does not have the complete supplies map.
>>>>>>
>>>>> We have complete supplies map. You can get it on ipcatlog. Here is example
>>>>> for other instances eg USB and EDP:
>>>>> - Glymur (eDP): CXO PAD -> TX0 -> RPT0 -> RX0 -> eDP
>>>>> - Glymur (USB4_2): CXO PAD -> TX0 -> RPT0 -> RPT1 -> RX1 -> USB4_2
>>>>> - Glymur (USB3): CXO PAD -> TX0 -> RPT3 -> RPT4 -> RX4 -> USB3_SS3
>>>>>
>>>>> I only add supplies for PCIe in this series because USB and EDP vote these
>>>>> LDO in their PHY driver. They can remove them in PHY dts node and add same
>>>>> regulator list here.
>>>>>
>>>>
>>>> The regulators are reference counted. Can't we add the USB and eDP
>>>> handling here as well now, and then after they are voted here we remove
>>>> them from the PHY?
>>>>
>>>
>>> For USB, I’m not yet sure which tcsr_*_clkref_en each USB instance in the
>>> QREF diagram is tied to. I need to confirm that mapping first, I'm
>>> checking with Wesley Cheng.
>>
>> I think on at least some platforms the reference clock for the primary
>> USB controller is not sw-controllable (so we wouldn't get a handle to
>> toggle the regulator this way).. please check that
>>
>
> I would suggest we move forward with atleast PCIe regulators for now. Since USB
> and eDP are voting for these regulators on their own, we can work with relevant
> teams later to switch to this model and this is not going to cause any
> regression for them.
I think we can do that, yeah
Konrad
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: qcs6490-rb3gen2: Add WCD headset playback and record for qcs6490-rb3gen2 industrial mezzanine
From: Krzysztof Kozlowski @ 2026-04-17 10:12 UTC (permalink / raw)
To: Karthik S, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <b6600312-3667-472b-9b76-c9977355115a@kernel.org>
On 17/04/2026 11:42, Krzysztof Kozlowski wrote:
>
> And finally:
>
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
As you pointed correctly after offline talk, checkpatch does not report
undocumented compatible for the sound card qcs6490-rb3gen2-ia-snd-card.
Unfortunately this patch did not go through internal toolset fully
(PatchWise), which could have flag the issue. Let's discuss it
internally next week.
>
> Undocumented ABI (without any reference in changelog where to find
> posted patch).
You still need to solve the undocumented sound card ABI - new
compatible. If it is already sent to mailing lists, then provide link in
patch changelog (---).
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v7 0/3] Mediatek MT8189 JPEG support
From: Jianhua Lin @ 2026-04-17 10:05 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
This series is based on tag: next-20260410, linux-next/master
Changes compared with v6:
- Patches 1/3 (dt-bindings: decoder):
update the existing `allOf` condition for mediatek,mt8189-jpgdec to
make the 'mediatek,larb' property strictly required for MT8189 SoC.
- Patches 2/3 (dt-bindings: encoder):
Add an `allOf` condition to enforce that the `mediatek,larb` property
is strictly required when the compatible string contains
mediatek,mt8189-jpgenc.
Changes compared with v5:
- Patches 1/3 (dt-bindings: decoder):
- Drop top-level minItems/maxItems for clock-names per Krzysztof's
review.
- Refine allOf block to strictly enforce clock constraints.
Changes compared with v4:
- Refines the device tree bindings for JPEG decoder and encoder.
- Patches 1/3 (dt-bindings: decoder):
Moved the standalone compatible string mediatek,mt8189-jpgdec
into the first oneOf entry along with mt2701 and mt8173, as
suggested by Rob Herring. This correctly groups all independent
ICs and removes the redundant items wrapper.
- Patches 2/3 (dt-bindings: encoder):
Applied the same logic suggested by Rob Herring to the encoder
binding. Restructured the compatible property to clearly
distinguish between the standalone IC (mediatek,mt8189-jpgenc)
and the ICs that must fallback to mediatek,mtk-jpgenc.
Changes compared with v3:
- The v4 is resending the cover-letter, because the v3 cover-letter was
not sent successfully.
Changes compared with v2:
- Dropped the dts patch (arm64: dts: mt8188: update JPEG encoder/decoder
compatible) as it belongs to a different tree/series.
- Patches 1/3 (dt-bindings: decoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum`.
- Added an `allOf` block with conditional checks to enforce the single
clock ("jpgdec") requirement for MT8189, while preserving the
two-clock requirement for older SoCs.
- Updated commit message to reflect the schema structure changes and
hardware differences.
- Patches 2/3 (dt-bindings: encoder):
- Changed the MT8189 compatible to be a standalone `const` instead of
an `enum` inside the `items` list, as it does not fallback to
"mediatek,mtk-jpgenc" due to 34-bit IOVA requirements.
- Updated commit message to explain the standalone compatible design.
- Patches 3/3 (media: mediatek: jpeg):
- Refined commit message for better clarity regarding 34-bit IOVA and
single clock configuration.
Changes compared with v1:
- Patches 1/4:
- Updating commit message
- Patches 2/4, 3/4:
- Updating commit message
- Adjusted property descriptions acorrding to hardware requirements
- Improved formatting for better readability and consistency
- Patches 4/4:
- Updating commit message
Jianhua Lin (3):
dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible
string
dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible
string
media: mediatek: jpeg: add compatible for MT8189 SoC
.../bindings/media/mediatek-jpeg-decoder.yaml | 48 +++++++++++++++----
.../bindings/media/mediatek-jpeg-encoder.yaml | 29 ++++++++---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++
3 files changed, 107 insertions(+), 14 deletions(-)
--
2.45.2
^ permalink raw reply
* [PATCH v7 1/3] dt-bindings: media: mediatek-jpeg-decoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-04-17 10:05 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260417100519.1043-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG decoder block found in the
MediaTek MT8189 SoC.
Compared to previous generation ICs, the MT8189 JPEG decoder requires
34-bit IOVA address space support and only needs a single clock
("jpgdec") instead of two. Therefore, it is added as a standalone
compatible string without falling back to older SoCs.
Update the binding schema to include the new compatible string and add
an `allOf` block with conditional checks. This enforces the single clock
requirement for MT8189 while preserving the two-clock requirement
("jpgdec-smi", "jpgdec") for older SoCs.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-decoder.yaml | 48 +++++++++++++++----
1 file changed, 40 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
index a4aacd3eb189..fd895688a038 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml
@@ -15,10 +15,10 @@ description: |-
properties:
compatible:
oneOf:
- - items:
- - enum:
- - mediatek,mt8173-jpgdec
- - mediatek,mt2701-jpgdec
+ - enum:
+ - mediatek,mt2701-jpgdec
+ - mediatek,mt8173-jpgdec
+ - mediatek,mt8189-jpgdec
- items:
- enum:
- mediatek,mt7623-jpgdec
@@ -32,13 +32,20 @@ properties:
maxItems: 1
clocks:
+ minItems: 1
maxItems: 2
- minItems: 2
clock-names:
- items:
- - const: jpgdec-smi
- - const: jpgdec
+ oneOf:
+ - items:
+ - const: jpgdec
+ - items:
+ - const: jpgdec-smi
+ - const: jpgdec
+
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
power-domains:
maxItems: 1
@@ -60,6 +67,31 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgdec
+ then:
+ properties:
+ clocks:
+ minItems: 1
+ maxItems: 1
+ clock-names:
+ minItems: 1
+ maxItems: 1
+ required:
+ - mediatek,larb
+ else:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+ clock-names:
+ minItems: 2
+ maxItems: 2
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* [PATCH v7 3/3] media: mediatek: jpeg: add compatible for MT8189 SoC
From: Jianhua Lin @ 2026-04-17 10:05 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260417100519.1043-1-jianhua.lin@mediatek.com>
Compared to the previous generation ICs, the MT8189 uses a 34-bit IOVA
address space (16GB) and requires a single clock configuration.
Therefore, add new compatible strings ("mediatek,mt8189-jpgenc" and
"mediatek,mt8189-jpgdec") along with their specific driver data to
support the JPEG encoder and decoder of the MT8189 SoC.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../platform/mediatek/jpeg/mtk_jpeg_core.c | 44 +++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
index 8c684756d5fc..786cc2942c3a 100644
--- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
@@ -1867,6 +1867,10 @@ static struct clk_bulk_data mt8173_jpeg_dec_clocks[] = {
{ .id = "jpgdec" },
};
+static struct clk_bulk_data mtk_jpeg_dec_clocks[] = {
+ { .id = "jpgdec" },
+};
+
static const struct mtk_jpeg_variant mt8173_jpeg_drvdata = {
.clks = mt8173_jpeg_dec_clocks,
.num_clks = ARRAY_SIZE(mt8173_jpeg_dec_clocks),
@@ -1898,6 +1902,38 @@ static const struct mtk_jpeg_variant mtk_jpeg_drvdata = {
.multi_core = false,
};
+static const struct mtk_jpeg_variant mtk8189_jpegenc_drvdata = {
+ .clks = mtk_jpeg_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_clocks),
+ .formats = mtk_jpeg_enc_formats,
+ .num_formats = MTK_JPEG_ENC_NUM_FORMATS,
+ .qops = &mtk_jpeg_enc_qops,
+ .irq_handler = mtk_jpeg_enc_irq,
+ .hw_reset = mtk_jpeg_enc_reset,
+ .m2m_ops = &mtk_jpeg_enc_m2m_ops,
+ .dev_name = "mtk-jpeg-enc",
+ .ioctl_ops = &mtk_jpeg_enc_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_YUYV,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .support_34bit = true,
+};
+
+static const struct mtk_jpeg_variant mtk8189_jpegdec_drvdata = {
+ .clks = mtk_jpeg_dec_clocks,
+ .num_clks = ARRAY_SIZE(mtk_jpeg_dec_clocks),
+ .formats = mtk_jpeg_dec_formats,
+ .num_formats = MTK_JPEG_DEC_NUM_FORMATS,
+ .qops = &mtk_jpeg_dec_qops,
+ .irq_handler = mtk_jpeg_dec_irq,
+ .hw_reset = mtk_jpeg_dec_reset,
+ .m2m_ops = &mtk_jpeg_dec_m2m_ops,
+ .dev_name = "mtk-jpeg-dec",
+ .ioctl_ops = &mtk_jpeg_dec_ioctl_ops,
+ .out_q_default_fourcc = V4L2_PIX_FMT_JPEG,
+ .cap_q_default_fourcc = V4L2_PIX_FMT_YUV420M,
+ .support_34bit = true,
+};
+
static struct mtk_jpeg_variant mtk8195_jpegenc_drvdata = {
.formats = mtk_jpeg_enc_formats,
.num_formats = MTK_JPEG_ENC_NUM_FORMATS,
@@ -1937,6 +1973,14 @@ static const struct of_device_id mtk_jpeg_match[] = {
.compatible = "mediatek,mtk-jpgenc",
.data = &mtk_jpeg_drvdata,
},
+ {
+ .compatible = "mediatek,mt8189-jpgenc",
+ .data = &mtk8189_jpegenc_drvdata,
+ },
+ {
+ .compatible = "mediatek,mt8189-jpgdec",
+ .data = &mtk8189_jpegdec_drvdata,
+ },
{
.compatible = "mediatek,mt8195-jpgenc",
.data = &mtk8195_jpegenc_drvdata,
--
2.45.2
^ permalink raw reply related
* [PATCH v7 2/3] dt-bindings: media: mediatek-jpeg-encoder: add MT8189 compatible string
From: Jianhua Lin @ 2026-04-17 10:05 UTC (permalink / raw)
To: nicolas, mchehab, robh, krzk+dt, conor+dt, matthias.bgg,
angelogioacchino.delregno
Cc: devicetree, linux-kernel, linux-media, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group, sirius.wang,
vince-wl.liu, jh.hsu, Jianhua Lin
In-Reply-To: <20260417100519.1043-1-jianhua.lin@mediatek.com>
Add the compatible string for the JPEG encoder block found in the
MediaTek MT8189 SoC.
Unlike some previous SoCs, the MT8189 JPEG encoder requires 34-bit IOVA
address space support. Therefore, it is added as a standalone compatible
string without falling back to the generic "mediatek,mtk-jpgenc" to
ensure the driver applies the correct hardware-specific configurations.
Signed-off-by: Jianhua Lin <jianhua.lin@mediatek.com>
---
.../bindings/media/mediatek-jpeg-encoder.yaml | 29 +++++++++++++++----
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
index 5b15f8977f67..690775dbb1ec 100644
--- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
+++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml
@@ -14,13 +14,16 @@ description: |-
properties:
compatible:
- items:
+ oneOf:
- enum:
- - mediatek,mt2701-jpgenc
- - mediatek,mt8183-jpgenc
- - mediatek,mt8186-jpgenc
- - mediatek,mt8188-jpgenc
- - const: mediatek,mtk-jpgenc
+ - mediatek,mt8189-jpgenc
+ - items:
+ - enum:
+ - mediatek,mt2701-jpgenc
+ - mediatek,mt8183-jpgenc
+ - mediatek,mt8186-jpgenc
+ - mediatek,mt8188-jpgenc
+ - const: mediatek,mtk-jpgenc
reg:
maxItems: 1
@@ -34,6 +37,10 @@ properties:
items:
- const: jpgenc
+ mediatek,larb:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: a phandle to the smi_larb node.
+
power-domains:
maxItems: 1
@@ -54,6 +61,16 @@ required:
- power-domains
- iommus
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: mediatek,mt8189-jpgenc
+ then:
+ required:
+ - mediatek,larb
+
additionalProperties: false
examples:
--
2.45.2
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Glymur crypto engine
From: Harshal Dev @ 2026-04-17 9:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov, Neeraj Soni, Kuldeep Singh, Abel Vesa,
linux-arm-msm, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260417-portable-proud-dragonfly-6bdd9a@quoll>
On 4/17/2026 3:17 PM, Krzysztof Kozlowski wrote:
> On Thu, Apr 16, 2026 at 06:37:20PM +0530, Harshal Dev wrote:
>> Document the crypto engine on Glymur platform.
>>
>> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
>> 1 file changed, 1 insertion(+)
>>
>
> Poor commit msg, but none of previous patches were doing it better, so:
Noted, I'll try to do better next time.
Regards,
Harshal
>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 4/4] arm64: dts: amlogic: t7: Add clk measure support
From: Ronald Claveau @ 2026-04-17 9:48 UTC (permalink / raw)
To: Jian Hu
Cc: devicetree, linux-arm-kernel, linux-amlogic, linux-kernel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl
In-Reply-To: <20260415-clkmsr_a1_t7-v2-4-02b6314427e6@amlogic.com>
Hello Jian,
On 4/15/26 10:33 AM, Jian Hu via B4 Relay wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Add the clock measure device to the T7 SoC family.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> ---
> arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> index 7fe72c94ed62..cec2ea74850d 100644
> --- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
> @@ -701,6 +701,11 @@ pwm_ao_cd: pwm@60000 {
> status = "disabled";
> };
>
> + clock-measurer@48000 {
> + compatible = "amlogic,t7-clk-measure";
> + reg = <0x0 0x48000 0x0 0x1c>;
> + };
> +
Can you please order by reg, it should be between pwm_ao_gh and pwm_ab.
Thank you.
> sd_emmc_a: mmc@88000 {
> compatible = "amlogic,t7-mmc", "amlogic,meson-axg-mmc";
> reg = <0x0 0x88000 0x0 0x800>;
>
--
Best regards,
Ronald
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: crypto: qcom-qce: Document the Glymur crypto engine
From: Krzysztof Kozlowski @ 2026-04-17 9:47 UTC (permalink / raw)
To: Harshal Dev
Cc: Thara Gopinath, Herbert Xu, David S. Miller, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Dmitry Baryshkov, Neeraj Soni, Kuldeep Singh, Abel Vesa,
linux-arm-msm, linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260416-glymur_crypto_enablement-v1-1-75e768c1417c@oss.qualcomm.com>
On Thu, Apr 16, 2026 at 06:37:20PM +0530, Harshal Dev wrote:
> Document the crypto engine on Glymur platform.
>
> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/crypto/qcom-qce.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Poor commit msg, but none of previous patches were doing it better, so:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 5/5] media: synopsys: Add support for i.MX95
From: Frank Li @ 2026-04-17 9:45 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260415-csi2_imx95-v1-5-7d63f3508719@oss.nxp.com>
On Wed, Apr 15, 2026 at 11:46:56AM +0800, Guoniu Zhou wrote:
> Add support for the i.MX95 MIPI CSI-2 receiver. The i.MX95 variant is
> nearly identical to i.MX93, with the main difference being the use of
> IDI (Image Data Interface) instead of IPI (Image Pixel Interface).
> However, the IDI interface is transparent to software, requiring only
> a different register map definition while sharing the same PHY control
> functions with i.MX93.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 22 ++++++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> index 27e4c1027816..bbb41baf789e 100644
> --- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> +++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> @@ -154,6 +154,17 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX] = {
> [DW_MIPI_CSI2RX_IPI_SOFTRSTN] = DW_REG(0xa0),
> };
>
> +static const u32 imx95_regs[DW_MIPI_CSI2RX_MAX] = {
> + [DW_MIPI_CSI2RX_N_LANES] = DW_REG(0x4),
> + [DW_MIPI_CSI2RX_RESETN] = DW_REG(0x8),
> + [DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
> + [DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
> + [DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
> + [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
> + [DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
> + [DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
> +};
> +
> static const struct v4l2_mbus_framefmt default_format = {
> .width = 3840,
> .height = 2160,
> @@ -901,11 +912,22 @@ static const struct dw_mipi_csi2rx_drvdata imx93_drvdata = {
> .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
> };
>
> +static const struct dw_mipi_csi2rx_drvdata imx95_drvdata = {
> + .regs = imx95_regs,
> + .dphy_assert_reset = imx93_csi2rx_dphy_assert_reset,
> + .dphy_deassert_reset = imx93_csi2rx_dphy_deassert_reset,
> + .wait_for_phy_stopstate = imx93_csi2rx_wait_for_phy_stopstate,
> +};
> +
> static const struct of_device_id dw_mipi_csi2rx_of_match[] = {
> {
> .compatible = "fsl,imx93-mipi-csi2",
> .data = &imx93_drvdata,
> },
> + {
> + .compatible = "fsl,imx95-mipi-csi2",
> + .data = &imx95_drvdata,
> + },
> {
> .compatible = "rockchip,rk3568-mipi-csi2",
> .data = &rk3568_drvdata,
>
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH v6 2/2] leds: ltc3220: Add Support for LTC3220 18 channel LED Driver
From: Edelweise Escala @ 2026-04-17 9:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-leds, devicetree, linux-kernel, Edelweise Escala
In-Reply-To: <20260417-ltc3220-driver-v6-0-18157871eddd@analog.com>
Add driver for the LTC3220 18-channel LED driver
with I2C interface, individual brightness control, and hardware-assisted
blink/gradation features.
Signed-off-by: Edelweise Escala <edelweise.escala@analog.com>
---
MAINTAINERS | 1 +
drivers/leds/Kconfig | 12 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-ltc3220.c | 418 ++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 432 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5c10cc3e3022..7467537938bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14961,6 +14961,7 @@ L: linux-leds@vger.kernel.org
S: Maintained
W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
+F: drivers/leds/leds-ltc3220.c
LTC4282 HARDWARE MONITOR DRIVER
M: Nuno Sa <nuno.sa@analog.com>
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 597d7a79c988..f00cdc11c978 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -1001,6 +1001,18 @@ config LEDS_ST1202
Say Y to enable support for LEDs connected to LED1202
LED driver chips accessed via the I2C bus.
+config LEDS_LTC3220
+ tristate "LED Driver for Analog Devices Inc. LTC3220"
+ depends on I2C && LEDS_CLASS
+ help
+ Say Y to enable support for the Analog Devices LTC3220
+ 18-channel LED controller with I2C interface.
+ The driver supports individual LED brightness control (64 steps),
+ hardware-assisted blinking and gradation effects.
+
+ To compile this driver as a module, choose M here: the module will
+ be called leds-ltc3220.
+
config LEDS_TPS6105X
tristate "LED support for TI TPS6105X"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8fdb45d5b439..5301568d9e00 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_LEDS_LP8788) += leds-lp8788.o
obj-$(CONFIG_LEDS_LP8860) += leds-lp8860.o
obj-$(CONFIG_LEDS_LP8864) += leds-lp8864.o
obj-$(CONFIG_LEDS_LT3593) += leds-lt3593.o
+obj-$(CONFIG_LEDS_LTC3220) += leds-ltc3220.o
obj-$(CONFIG_LEDS_MAX5970) += leds-max5970.o
obj-$(CONFIG_LEDS_MAX77650) += leds-max77650.o
obj-$(CONFIG_LEDS_MAX77705) += leds-max77705.o
diff --git a/drivers/leds/leds-ltc3220.c b/drivers/leds/leds-ltc3220.c
new file mode 100644
index 000000000000..5e1f994cc35b
--- /dev/null
+++ b/drivers/leds/leds-ltc3220.c
@@ -0,0 +1,418 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * LTC3220 18-Channel LED Driver
+ *
+ * Copyright 2026 Analog Devices Inc.
+ *
+ * Author: Edelweise Escala <edelweise.escala@analog.com>
+ */
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/gpio/consumer.h>
+#include <linux/i2c.h>
+#include <linux/leds.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+#include <linux/types.h>
+
+/* LTC3220 Registers */
+#define LTC3220_COMMAND_REG 0x00
+#define LTC3220_QUICK_WRITE_MASK BIT(0)
+#define LTC3220_SHUTDOWN_MASK BIT(3)
+
+#define LTC3220_ULED_REG(x) (0x01 + (x))
+#define LTC3220_LED_CURRENT_MASK GENMASK(5, 0)
+#define LTC3220_LED_MODE_MASK GENMASK(7, 6)
+
+#define LTC3220_GRAD_BLINK_REG 0x13
+#define LTC3220_GRADATION_MASK GENMASK(2, 0)
+#define LTC3220_GRADATION_DIRECTION_MASK BIT(0)
+#define LTC3220_GRADATION_PERIOD_MASK GENMASK(2, 1)
+#define LTC3220_BLINK_MASK GENMASK(4, 3)
+
+#define LTC3220_NUM_LEDS 18
+
+#define LTC3220_GRADATION_START_VALUE 128
+#define LTC3220_GRADATION_RAMP_TIME_240MS 240
+#define LTC3220_GRADATION_RAMP_TIME_480MS 480
+
+#define LTC3220_BLINK_ON_156MS 156
+#define LTC3220_BLINK_ON_625MS 625
+#define LTC3220_BLINK_PERIOD_1250MS 1250
+#define LTC3220_BLINK_PERIOD_2500MS 2500
+
+#define LTC3220_BLINK_SHORT_ON_TIME BIT(0)
+#define LTC3220_BLINK_LONG_PERIOD BIT(1)
+
+enum ltc3220_blink_mode {
+ LTC3220_BLINK_MODE_625MS_1250MS,
+ LTC3220_BLINK_MODE_156MS_1250MS,
+ LTC3220_BLINK_MODE_625MS_2500MS,
+ LTC3220_BLINK_MODE_156MS_2500MS
+};
+
+enum ltc3220_gradation_mode {
+ LTC3220_GRADATION_MODE_DISABLED,
+ LTC3220_GRADATION_MODE_240MS_RAMP_TIME,
+ LTC3220_GRADATION_MODE_480MS_RAMP_TIME,
+ LTC3220_GRADATION_MODE_960MS_RAMP_TIME
+};
+
+static const struct regmap_config ltc3220_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = LTC3220_GRAD_BLINK_REG,
+};
+
+struct ltc3220_uled_cfg {
+ struct ltc3220_state *ltc3220_state;
+ struct led_classdev led_cdev;
+ u8 reg_value;
+ u8 led_index;
+};
+
+struct ltc3220_state {
+ struct ltc3220_uled_cfg uled_cfg[LTC3220_NUM_LEDS];
+ struct regmap *regmap;
+ bool is_aggregated;
+};
+
+static int ltc3220_shutdown(struct ltc3220_state *ltc3220_state)
+{
+ return regmap_update_bits(ltc3220_state->regmap, LTC3220_COMMAND_REG,
+ LTC3220_SHUTDOWN_MASK, LTC3220_SHUTDOWN_MASK);
+}
+
+static int ltc3220_resume_from_shutdown(struct ltc3220_state *ltc3220_state)
+{
+ return regmap_update_bits(ltc3220_state->regmap, LTC3220_COMMAND_REG,
+ LTC3220_SHUTDOWN_MASK, 0);
+}
+
+/*
+ * Set LED brightness and mode.
+ * The brightness value determines both the LED current and operating mode:
+ * 0-63: Normal mode - LED current from 0-63 (off to full brightness)
+ * 64-127: Blink mode - LED blinks with current level (brightness - 64)
+ * 128-191: Gradation mode - LED gradually changes brightness (brightness - 128)
+ * 192-255: GPO mode - LED operates as general purpose output (brightness - 192)
+ */
+static int ltc3220_set_led_data(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+ struct ltc3220_state *ltc3220_state;
+ struct ltc3220_uled_cfg *uled_cfg;
+ int ret;
+ int i;
+
+ uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg, led_cdev);
+ ltc3220_state = uled_cfg->ltc3220_state;
+
+ ret = regmap_write(ltc3220_state->regmap, LTC3220_ULED_REG(uled_cfg->led_index),
+ brightness);
+ if (ret < 0)
+ return ret;
+
+ uled_cfg->reg_value = brightness;
+
+ /*
+ * When aggregated LED mode is enabled, writing to LED 1 updates all
+ * LEDs simultaneously via quick-write mode. Update cached values for
+ * all LEDs to reflect the synchronized state.
+ * See Documentation/devicetree/bindings/leds/adi,ltc3220.yaml for how
+ * to configure aggregated LED mode.
+ */
+ if (ltc3220_state->is_aggregated && uled_cfg->led_index == 0) {
+ for (i = 0; i < LTC3220_NUM_LEDS; i++)
+ ltc3220_state->uled_cfg[i].reg_value = brightness;
+ }
+
+ return 0;
+}
+
+static enum led_brightness ltc3220_get_led_data(struct led_classdev *led_cdev)
+{
+ struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev,
+ struct ltc3220_uled_cfg, led_cdev);
+
+ return uled_cfg->reg_value;
+}
+
+/*
+ * LTC3220 pattern support for hardware-assisted breathing/gradation.
+ * The hardware supports 3 gradation ramp time 240ms, 480ms, 960ms)
+ * and can ramp up or down.
+ *
+ * Pattern array interpretation:
+ * pattern[0].brightness = start brightness (0-63)
+ * pattern[0].delta_t = ramp time in milliseconds
+ * pattern[1].brightness = end brightness (0-63)
+ * pattern[1].delta_t = (optional, can be 0 or same as pattern[0].delta_t)
+ */
+static int ltc3220_pattern_set(struct led_classdev *led_cdev,
+ struct led_pattern *pattern,
+ u32 len, int repeat)
+{
+ struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg,
+ led_cdev);
+ struct ltc3220_state *ltc3220_state = uled_cfg->ltc3220_state;
+ u8 gradation_period;
+ u8 start_brightness;
+ u8 end_brightness;
+ u8 reg_val;
+ bool is_increasing;
+ int ret;
+
+ if (len != 2)
+ return -EINVAL;
+
+ start_brightness = pattern[0].brightness & LTC3220_LED_CURRENT_MASK;
+ end_brightness = pattern[1].brightness & LTC3220_LED_CURRENT_MASK;
+
+ is_increasing = end_brightness > start_brightness;
+
+ if (pattern[0].delta_t == 0)
+ gradation_period = LTC3220_GRADATION_MODE_DISABLED;
+ else if (pattern[0].delta_t <= LTC3220_GRADATION_RAMP_TIME_240MS)
+ gradation_period = LTC3220_GRADATION_MODE_240MS_RAMP_TIME;
+ else if (pattern[0].delta_t <= LTC3220_GRADATION_RAMP_TIME_480MS)
+ gradation_period = LTC3220_GRADATION_MODE_480MS_RAMP_TIME;
+ else
+ gradation_period = LTC3220_GRADATION_MODE_960MS_RAMP_TIME;
+
+ reg_val = FIELD_PREP(LTC3220_GRADATION_PERIOD_MASK, gradation_period);
+ reg_val |= FIELD_PREP(LTC3220_GRADATION_DIRECTION_MASK, is_increasing);
+
+ ret = regmap_update_bits(ltc3220_state->regmap, LTC3220_GRAD_BLINK_REG,
+ LTC3220_GRADATION_MASK, reg_val);
+ if (ret < 0)
+ return ret;
+
+ ret = ltc3220_set_led_data(led_cdev, start_brightness);
+ if (ret < 0)
+ return ret;
+
+ return ltc3220_set_led_data(led_cdev, LTC3220_GRADATION_START_VALUE + end_brightness);
+}
+
+static int ltc3220_pattern_clear(struct led_classdev *led_cdev)
+{
+ struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg,
+ led_cdev);
+ struct ltc3220_state *ltc3220_state = uled_cfg->ltc3220_state;
+
+ return regmap_update_bits(ltc3220_state->regmap, LTC3220_GRAD_BLINK_REG,
+ LTC3220_GRADATION_MASK, 0);
+}
+
+/*
+ * LTC3220 has a global blink configuration that affects all LEDs.
+ * This implementation allows per-LED blink requests, but the blink timing
+ * will be shared across all LEDs. The delay values are mapped to the
+ * hardware's discrete blink rates.
+ */
+static int ltc3220_blink_set(struct led_classdev *led_cdev,
+ unsigned long *delay_on,
+ unsigned long *delay_off)
+{
+ struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct ltc3220_uled_cfg,
+ led_cdev);
+ struct ltc3220_state *ltc3220_state = uled_cfg->ltc3220_state;
+ u8 blink_mode = 0;
+
+ if (*delay_on <= LTC3220_BLINK_ON_156MS)
+ blink_mode = LTC3220_BLINK_SHORT_ON_TIME;
+
+ if (*delay_on + *delay_off > LTC3220_BLINK_PERIOD_1250MS)
+ blink_mode |= LTC3220_BLINK_LONG_PERIOD;
+
+ switch (blink_mode) {
+ case LTC3220_BLINK_MODE_625MS_1250MS:
+ *delay_on = LTC3220_BLINK_ON_625MS;
+ *delay_off = LTC3220_BLINK_PERIOD_1250MS - LTC3220_BLINK_ON_625MS;
+ break;
+ case LTC3220_BLINK_MODE_156MS_1250MS:
+ *delay_on = LTC3220_BLINK_ON_156MS;
+ *delay_off = LTC3220_BLINK_PERIOD_1250MS - LTC3220_BLINK_ON_156MS;
+ break;
+ case LTC3220_BLINK_MODE_625MS_2500MS:
+ *delay_on = LTC3220_BLINK_ON_625MS;
+ *delay_off = LTC3220_BLINK_PERIOD_2500MS - LTC3220_BLINK_ON_625MS;
+ break;
+ case LTC3220_BLINK_MODE_156MS_2500MS:
+ *delay_on = LTC3220_BLINK_ON_156MS;
+ *delay_off = LTC3220_BLINK_PERIOD_2500MS - LTC3220_BLINK_ON_156MS;
+ break;
+ }
+
+ return regmap_update_bits(ltc3220_state->regmap, LTC3220_GRAD_BLINK_REG,
+ LTC3220_BLINK_MASK, blink_mode);
+}
+
+static void ltc3220_reset_gpio_action(void *data)
+{
+ struct gpio_desc *reset_gpio = data;
+
+ gpiod_set_value_cansleep(reset_gpio, 1);
+}
+
+static int ltc3220_reset(struct ltc3220_state *ltc3220_state, struct i2c_client *client)
+{
+ struct gpio_desc *reset_gpio;
+ int ret;
+ int i;
+
+ reset_gpio = devm_gpiod_get_optional(&client->dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(reset_gpio))
+ return dev_err_probe(&client->dev, PTR_ERR(reset_gpio), "Failed on reset GPIO\n");
+
+ if (reset_gpio) {
+ gpiod_set_value_cansleep(reset_gpio, 0);
+
+ return devm_add_action_or_reset(&client->dev, ltc3220_reset_gpio_action,
+ reset_gpio);
+ }
+
+ ret = regmap_write(ltc3220_state->regmap, LTC3220_COMMAND_REG, 0);
+ if (ret < 0)
+ return ret;
+
+ for (i = 0; i < LTC3220_NUM_LEDS; i++) {
+ ret = regmap_write(ltc3220_state->regmap, LTC3220_ULED_REG(i), 0);
+ if (ret < 0)
+ return ret;
+ }
+
+ return regmap_write(ltc3220_state->regmap, LTC3220_GRAD_BLINK_REG, 0);
+}
+
+static int ltc3220_suspend(struct device *dev)
+{
+ struct ltc3220_state *ltc3220_state = i2c_get_clientdata(to_i2c_client(dev));
+
+ return ltc3220_shutdown(ltc3220_state);
+}
+
+static int ltc3220_resume(struct device *dev)
+{
+ struct ltc3220_state *ltc3220_state = i2c_get_clientdata(to_i2c_client(dev));
+
+ return ltc3220_resume_from_shutdown(ltc3220_state);
+}
+
+static DEFINE_SIMPLE_DEV_PM_OPS(ltc3220_pm_ops, ltc3220_suspend, ltc3220_resume);
+
+static int ltc3220_probe(struct i2c_client *client)
+{
+ struct ltc3220_state *ltc3220_state;
+ bool aggregated_led_found = false;
+ int num_leds = 0;
+ u8 led_index = 0;
+ int ret;
+
+ ltc3220_state = devm_kzalloc(&client->dev, sizeof(*ltc3220_state), GFP_KERNEL);
+ if (!ltc3220_state)
+ return -ENOMEM;
+
+ ltc3220_state->regmap = devm_regmap_init_i2c(client, <c3220_regmap_config);
+ if (IS_ERR(ltc3220_state->regmap))
+ return dev_err_probe(&client->dev, PTR_ERR(ltc3220_state->regmap),
+ "Failed to initialize regmap\n");
+
+ i2c_set_clientdata(client, ltc3220_state);
+
+ ret = ltc3220_reset(ltc3220_state, client);
+ if (ret)
+ return dev_err_probe(&client->dev, ret, "Failed to reset device\n");
+
+ device_for_each_child_node_scoped(&client->dev, child) {
+ struct led_init_data init_data = {};
+ struct ltc3220_uled_cfg *led;
+ u32 source;
+
+ ret = fwnode_property_read_u32(child, "reg", &source);
+ if (ret)
+ return dev_err_probe(&client->dev, ret, "Couldn't read LED address\n");
+
+ if (!source || source > LTC3220_NUM_LEDS)
+ return dev_err_probe(&client->dev, -EINVAL, "LED address out of range\n");
+
+ init_data.fwnode = child;
+ init_data.devicename = "ltc3220";
+
+ if (fwnode_property_present(child, "led-sources")) {
+ if (source != 1)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "Aggregated LED out of range\n");
+
+ if (aggregated_led_found)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "One Aggregated LED only\n");
+
+ aggregated_led_found = true;
+ ltc3220_state->is_aggregated = true;
+
+ ret = regmap_update_bits(ltc3220_state->regmap,
+ LTC3220_COMMAND_REG,
+ LTC3220_QUICK_WRITE_MASK,
+ LTC3220_QUICK_WRITE_MASK);
+ if (ret < 0)
+ return dev_err_probe(&client->dev, ret,
+ "Failed to set quick write mode\n");
+ }
+
+ num_leds++;
+
+ /* LED node reg/index/address goes from 1 to 18 */
+ led_index = source - 1;
+ led = <c3220_state->uled_cfg[led_index];
+ led->led_index = led_index;
+ led->reg_value = 0;
+ led->ltc3220_state = ltc3220_state;
+ led->led_cdev.brightness_set_blocking = ltc3220_set_led_data;
+ led->led_cdev.brightness_get = ltc3220_get_led_data;
+ led->led_cdev.max_brightness = 255;
+ led->led_cdev.blink_set = ltc3220_blink_set;
+ led->led_cdev.pattern_set = ltc3220_pattern_set;
+ led->led_cdev.pattern_clear = ltc3220_pattern_clear;
+
+ ret = devm_led_classdev_register_ext(&client->dev, &led->led_cdev, &init_data);
+ if (ret)
+ return dev_err_probe(&client->dev, ret, "Failed to register LED class\n");
+ }
+
+ /*
+ * Aggregated LED mode uses hardware quick-write to control all 18 LEDs
+ * simultaneously. This is mutually exclusive with individual LED control.
+ * See Documentation/devicetree/bindings/leds/adi,ltc3220.yaml for details
+ * on how to configure aggregated LED mode.
+ */
+ if (aggregated_led_found && num_leds > 1)
+ return dev_err_probe(&client->dev, -EINVAL,
+ "Aggregated LED must be the only LED node\n");
+
+ return 0;
+}
+
+static const struct of_device_id ltc3220_of_match[] = {
+ { .compatible = "adi,ltc3220" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ltc3220_of_match);
+
+static struct i2c_driver ltc3220_led_driver = {
+ .driver = {
+ .name = "ltc3220",
+ .of_match_table = ltc3220_of_match,
+ .pm = pm_sleep_ptr(<c3220_pm_ops),
+ },
+ .probe = ltc3220_probe,
+};
+module_i2c_driver(ltc3220_led_driver);
+
+MODULE_AUTHOR("Edelweise Escala <edelweise.escala@analog.com>");
+MODULE_DESCRIPTION("LED driver for LTC3220 controllers");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v6 1/2] dt-bindings: leds: Add LTC3220 18 channel LED Driver
From: Edelweise Escala @ 2026-04-17 9:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-leds, devicetree, linux-kernel, Edelweise Escala,
Conor Dooley
In-Reply-To: <20260417-ltc3220-driver-v6-0-18157871eddd@analog.com>
LTC3220 is a multi-display LED driver with I2C interface.
The LTC3220 provides individual brightness control (64-step),
blinking, and gradation features for up to 18 LED outputs.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Edelweise Escala <edelweise.escala@analog.com>
---
.../devicetree/bindings/leds/adi,ltc3220.yaml | 120 +++++++++++++++++++++
MAINTAINERS | 7 ++
2 files changed, 127 insertions(+)
diff --git a/Documentation/devicetree/bindings/leds/adi,ltc3220.yaml b/Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
new file mode 100644
index 000000000000..62f760d517aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/adi,ltc3220.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices LTC3220 LED Driver
+
+maintainers:
+ - Edelweise Escala <edelweise.escala@analog.com>
+
+description:
+ The LTC3220 is a multi-display LED driver, which contains a high-efficiency,
+ low-noise charge pump to provide power to up to 18 LED current sources.
+ The LEDs are individually configurable to 64-step linear brightness control,
+ blinking and gradation control via 2-wire I2C interface.
+
+ For more product information please see the link below
+ https://www.analog.com/en/products/ltc3220.html
+
+properties:
+ compatible:
+ const: adi,ltc3220
+
+ reg:
+ maxItems: 1
+
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 0
+
+ reset-gpios:
+ maxItems: 1
+
+patternProperties:
+ '^led@([1-9]|1[0-8])$':
+ type: object
+ $ref: /schemas/leds/common.yaml#
+ unevaluatedProperties: false
+ properties:
+ reg:
+ description:
+ Output channel for the LED (1-18 maps to LED outputs D1-D18).
+ For aggregated LED control, define only one LED node with reg = <1>
+ and use led-sources to list all controlled outputs. Only reg 1 should
+ be present when using led-sources.
+ minimum: 1
+ maximum: 18
+
+ required:
+ - reg
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ // Independent LEDs
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@1c {
+ compatible = "adi,ltc3220";
+ reg = <0x1c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reset-gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+
+ led@1 {
+ reg = <1>;
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <1>;
+ };
+
+ led@2 {
+ reg = <2>;
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <2>;
+ };
+
+ led@3 {
+ reg = <3>;
+ function = LED_FUNCTION_INDICATOR;
+ function-enumerator = <3>;
+ };
+ };
+ };
+
+ - |
+ // Aggregated LED
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led-controller@1c {
+ compatible = "adi,ltc3220";
+ reg = <0x1c>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ led-sources = <1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18>;
+ function = LED_FUNCTION_BACKLIGHT;
+ };
+ };
+ };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index 327d74ca7ecb..5c10cc3e3022 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14955,6 +14955,13 @@ W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/temperature/adi,ltc2983.yaml
F: drivers/iio/temperature/ltc2983.c
+LTC3220 LED DRIVER
+M: Edelweise Escala <edelweise.escala@analog.com>
+L: linux-leds@vger.kernel.org
+S: Maintained
+W: https://ez.analog.com/linux-software-drivers
+F: Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
+
LTC4282 HARDWARE MONITOR DRIVER
M: Nuno Sa <nuno.sa@analog.com>
L: linux-hwmon@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH v6 0/2] Add Support for LTC3220 18 Channel LED Driver
From: Edelweise Escala @ 2026-04-17 9:42 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-leds, devicetree, linux-kernel, Edelweise Escala,
Conor Dooley
The LTC3220/LTC3220-1 is a multi-display LED driver, which contains a
high-efficiency, low-noise charge pump to provide power to up to
18 LED current sources. The LEDs are individually configurable to
64-step linear brightness control, blinking and gradation control
via 2-wire I2C interface. The blinking and gradation configuration
is shared across all LED.
LTC3220 has a quick write function which allows changing the brightness
on all LEDS simultaneously when the brightness is changed on led 1.
For this leds are aggregated in the device tree and on probe we check
if led-sources exist to enable quick write.
We would like to know if this approach is alright?
Another way we might want to know is, is it alright to just make a
virtual led for the quick write function. Changing brightness on
the virtual led will change the brightness for all.
Signed-off-by: Edelweise Escala <edelweise.escala@analog.com>
---
Changes in v6:
- Fix commit message
- Add manufacturer on Kconfig and improve description
- Rearrange register map and bitmask and improve naming
- Use regmap, also use update bits of regmap to avoid unnecessary
structs
- Alignment and spacing fixes
- Use Define for magic naumbers
- Fix blink calculation
- Add comments on aggregated LED
- Fix variable name to something more understandable like i to led_index
- Link to v5: https://lore.kernel.org/r/20260126-ltc3220-driver-v5-0-152a30e98ab7@analog.com
Changes in v5:
- Missed rename on bindings filename in MAINTAINERS file
- Link to v4: https://lore.kernel.org/linux-leds/20260126-ltc3220-driver-v4-0-c59517206c24@analog.com
Changes in v4:
- Rename leds-ltc3220.yaml to adi,ltc3220.yaml
- Add Reviewed-by: Conor Dooley <conor.dooley@microchip.com> on
adi,ltc3220.yaml
Other V1 comments I think already addressed
- Subject commit message was already changed to match hardware
- Fixed wrapping after description
- Dropped "Bindings for" in descriptions and improved description to match hardware
- Dropped adi,ltc3220-1
- Dropped redundant description on reset-gpios
- Dropped adi,force-cpo-level
- Dropped adi,quick-write in favor of aggregated LED
- Used consistent quotes ^led@([1-9]|1[0-8])$
- Fixed wrapping on error messages
- Link to v3: https://lore.kernel.org/r/20260120-ltc3220-driver-v3-0-fef612ec4faa@analog.com
Changes in v3:
- Dropped quick-write on bindings and added aggregated led instead.
- Add aggregated led example.
- Modify quick write to check if there is aggregated led, if there is
aggregated led enable quick write.
- Use DEFINE_SIMPLE_DEV_PM_OPS instead of SIMPLE_DEV_PM_OPS.
- Link to v2: https://lore.kernel.org/r/20260112-ltc3220-driver-v2-0-d043058fc4df@analog.com
Changes in v2:
leds-ltc3220.yaml changes
- Fix wrapping on description
- Improve description and commit messge to describe hardware
- Drop ltc3220-1
- Drop charge pump
ltc3220.c changes
- Fix wrapping
- Drop ltc3220-1
- Drop devname_mandatory
- Link to v1: https://lore.kernel.org/r/20260106-ltc3220-driver-v1-0-73601d6f1649@analog.com
---
Edelweise Escala (2):
dt-bindings: leds: Add LTC3220 18 channel LED Driver
leds: ltc3220: Add Support for LTC3220 18 channel LED Driver
.../devicetree/bindings/leds/adi,ltc3220.yaml | 120 ++++++
MAINTAINERS | 8 +
drivers/leds/Kconfig | 12 +
drivers/leds/Makefile | 1 +
drivers/leds/leds-ltc3220.c | 418 +++++++++++++++++++++
5 files changed, 559 insertions(+)
---
base-commit: 8856d7fe1758937ac528770f552ec58c388c255b
change-id: 20260106-ltc3220-driver-f9ab6cc9d1e4
Best regards,
--
Edelweise Escala <edelweise.escala@analog.com>
^ permalink raw reply
* Re: [PATCH v1] arm64: dts: qcom: qcs6490-rb3gen2: Add WCD headset playback and record for qcs6490-rb3gen2 industrial mezzanine
From: Krzysztof Kozlowski @ 2026-04-17 9:42 UTC (permalink / raw)
To: Karthik S, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260417093327.3251203-1-karthik.s@qss.qualcomm.com>
On 17/04/2026 11:33, Karthik S wrote:
> Add WCD playback and capture DAI link to sound node. Add WCD
> codec node and corresponding soundwire nodes to perform
> headset playback and record.
>
> Signed-off-by: Karthik S <karthik.s@qss.qualcomm.com>
> ---
> .../qcs6490-rb3gen2-industrial-mezzanine.dtso | 133 ++++++++++++++++++
> 1 file changed, 133 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
> index 83908db335af..d2503fce352c 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
> @@ -6,6 +6,7 @@
> /dts-v1/;
> /plugin/;
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/sound/qcom,q6afe.h>
> #include <dt-bindings/clock/qcom,gcc-sc7280.h>
> #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
>
> @@ -30,6 +31,29 @@ vreg_1p8: regulator-1v8 {
> regulator-always-on;
> regulator-boot-on;
> };
> +
> + wcd9370: audio-codec-0 {
Why 'audio-codec' goes after 'regulator'? And is there audio-codec-1? If
so, where?
> + compatible = "qcom,wcd9370-codec";
> +
> + pinctrl-0 = <&wcd_default>;
> + pinctrl-names = "default";
> +
> + reset-gpios = <&tlmm 83 GPIO_ACTIVE_LOW>;
> + vdd-buck-supply = <&vph_pwr>;
> + vdd-rxtx-supply = <&vph_pwr>;
> + vdd-px-supply = <&vph_pwr>;
> + vdd-mic-bias-supply = <&vph_pwr>;
> + qcom,micbias1-microvolt = <1800000>;
> + qcom,micbias2-microvolt = <1800000>;
> + qcom,micbias3-microvolt = <1800000>;
> + qcom,micbias4-microvolt = <1800000>;
> + qcom,hphl-jack-type-normally-closed = <1>;
> + qcom,ground-jack-type-normally-closed = <1>;
> + qcom,rx-device = <&wcd937x_rx>;
> + qcom,tx-device = <&wcd937x_tx>;
> +
> + #sound-dai-cells = <1>;
> + };
> };
>
> &remoteproc_wpss {
> @@ -283,8 +307,117 @@ pcie1_tc9563_resx_n: pcie1-tc9563-resx-state {
> output-enable;
> };
>
> + wcd_default: wcd-reset-n-active-state {
Messed indentation.
> + pins = "gpio83";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + };
> +
> };
>
> &wifi {
> status = "disabled";
> };
> +
> +&swr0 {
What sort of sorting is this?
> + status = "okay";
> +
> + wcd937x_rx: codec@0,4 {
> + compatible = "sdw20217010a00";
> + reg = <0 4>;
Even worse here.
And finally:
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
Undocumented ABI (without any reference in changelog where to find
posted patch).
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] input: misc: Add PixArt PAJ7620 gesture sensor driver
From: Krzysztof Kozlowski @ 2026-04-17 9:39 UTC (permalink / raw)
To: Harpreet Saini
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, devicetree, linux-input, linux-kernel
In-Reply-To: <20260417052527.62535-3-sainiharpreet29@yahoo.com>
On Fri, Apr 17, 2026 at 01:25:27AM -0400, Harpreet Saini wrote:
> +
> +static int paj7620_init(struct paj7620_data *data)
> +{
> + int state = 0, ret, i;
> +
> + /* 1. Wake-up sequence: Read register 0x00 until it returns 0x20 */
> + for (i = 0; i < 10; i++) {
> + ret = regmap_read(data->regmap, 0x00, &state);
> + if (ret >= 0 && state == 0x20)
> + break;
> + usleep_range(1000, 2000);
> + }
> +
> + if (state != 0x20) {
> + dev_err(&data->client->dev, "Sensor wake-up failed (0x%02x)\n", state);
> + return -ENODEV;
> + }
> +
> + /* 2. Blast full register array into PAJ7620 instantly */
> + ret = regmap_multi_reg_write(data->regmap, Init_Register,
> + ARRAY_SIZE(Init_Register));
> + if (ret < 0) {
> + dev_err(&data->client->dev, "Multi-reg write failed (%d)\n", ret);
> + return ret;
> + }
> +
> + ret = regmap_write(data->regmap, PAJ7620_REG_BANK_SEL, 0x00);
> + if (ret < 0)
> + return ret;
> +
> + ret = regmap_multi_reg_write(data->regmap, Init_Gesture_Array,
> + ARRAY_SIZE(Init_Gesture_Array));
> + if (ret < 0) {
> + dev_err(&data->client->dev, "Multi-reg write failed (%d)\n", ret);
> + return ret;
> + }
> +
> + dev_info(&data->client->dev, "Gesture Sensor Registers Initialized\n");
Drop, driver should be silent.
...
> + data->client = client;
> + i2c_set_clientdata(client, data);
> +
> + data->supplies[0].supply = "vdd";
> + data->supplies[1].supply = "vbus";
> + data->supplies[2].supply = "vled";
> +
> + ret = devm_regulator_bulk_get(&client->dev, ARRAY_SIZE(data->supplies), data->supplies);
> + if (ret)
> + return dev_err_probe(&client->dev, ret, "Failed to get regulators\n");
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(data->supplies), data->supplies);
> + if (ret)
> + return ret;
> +
> + data->regmap = devm_regmap_init_i2c(client, &paj7620_reg_config);
> + if (IS_ERR(data->regmap))
> + return PTR_ERR(data->regmap);
Leaking regulator enable.
> +
> + ret = paj7620_init(data);
> + if (ret)
> + goto err_reg;
> +
> + data->idev = devm_input_allocate_device(&client->dev);
> + if (!data->idev) {
> + ret = -ENOMEM; goto err_reg;
Messed syntax/wrapped lines.
And you must not print error msg on ENOMEM error.
> + }
> +
> + data->idev->name = "PAJ7620 Gesture Sensor";
> + data->idev->id.bustype = BUS_I2C;
> +
> + input_set_capability(data->idev, EV_KEY, KEY_UP);
> + input_set_capability(data->idev, EV_KEY, KEY_DOWN);
> + input_set_capability(data->idev, EV_KEY, KEY_LEFT);
> + input_set_capability(data->idev, EV_KEY, KEY_RIGHT);
> + input_set_capability(data->idev, EV_KEY, KEY_ENTER);
> + input_set_capability(data->idev, EV_KEY, KEY_BACK);
> + input_set_capability(data->idev, EV_KEY, KEY_NEXT);
> + input_set_capability(data->idev, EV_KEY, KEY_PREVIOUS);
> + input_set_capability(data->idev, EV_KEY, KEY_MENU);
> +
> + ret = input_register_device(data->idev);
> + if (ret)
> + goto err_reg;
> +
> + pm_runtime_set_active(&client->dev);
> + pm_runtime_enable(&client->dev);
> + pm_runtime_set_autosuspend_delay(&client->dev, 2000);
> + pm_runtime_use_autosuspend(&client->dev);
> +
> + ret = devm_request_threaded_irq(&client->dev, client->irq, NULL,
> + paj7620_irq_thread, IRQF_ONESHOT,
> + "paj7620", data);
> + if (ret)
> + goto err_reg;
> +
> + dev_info(&client->dev, "Gesture Sensor Initialized\n");
Pointless message, drop. Driver should be silent on success.
> + return 0;
> +
> +err_reg:
> + dev_err_probe(&client->dev, ret, "%s: failed with error %d\n", __func__, ret);
No, move it to individual errors, but only where applicable. For example
devm_request_threaded_irq() must not have it.
Neither devm_input_allocate_device.
> + if (pm_runtime_enabled(&client->dev)) {
> + pm_runtime_disable(&client->dev);
> + pm_runtime_dont_use_autosuspend(&client->dev);
> + }
> + regulator_bulk_disable(ARRAY_SIZE(data->supplies), data->supplies);
> + return ret;
> +}
> +
> +static void paj7620_remove(struct i2c_client *client)
> +{
> + int ret;
> + struct paj7620_data *data = i2c_get_clientdata(client);
> +
> + pm_runtime_get_sync(&client->dev);
> + pm_runtime_disable(&client->dev);
> + pm_runtime_dont_use_autosuspend(&client->dev);
> + pm_runtime_put_noidle(&client->dev);
> +
> + ret = paj7620_power_down(data);
> + if (ret)
> + dev_err(&data->client->dev, "Sensor power down failed\n");
> +
> + ret = regulator_bulk_disable(ARRAY_SIZE(data->supplies), data->supplies);
> + if (ret)
> + dev_err(&data->client->dev, "Sensor regulator disable failed\n");
> +}
> +
> +static const struct of_device_id paj7620_of_match[] = {
> + { .compatible = "pixart,paj7620" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, paj7620_of_match);
> +
> +static struct i2c_driver paj7620_driver = {
> + .driver = {
> + .name = "paj7620",
> + .of_match_table = paj7620_of_match,
> + .pm = &paj7620_pm_ops,
> + },
> + .probe = paj7620_probe,
> + .remove = paj7620_remove,
> +};
> +module_i2c_driver(paj7620_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Harpreet Saini");
> +MODULE_DESCRIPTION("PAJ7620 Gesture Input Driver");
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH RFC 3/4] clk: qcom: tcsrcc-glymur: Migrate tcsr_pcie_N_clkref_en to clk_ref common helper
From: Manivannan Sadhasivam @ 2026-04-17 9:39 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Qiang Yu, Bjorn Andersson, Taniya Das, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, johan, linux-arm-msm, linux-clk, devicetree,
linux-kernel
In-Reply-To: <3d4a12f1-a9ba-4955-b018-f1c271aab766@oss.qualcomm.com>
On Mon, Apr 13, 2026 at 01:18:16PM +0200, Konrad Dybcio wrote:
> On 4/13/26 9:06 AM, Qiang Yu wrote:
> > On Thu, Apr 09, 2026 at 08:19:41AM -0500, Bjorn Andersson wrote:
> >> On Wed, Apr 01, 2026 at 09:47:38PM -0700, Qiang Yu wrote:
> >>> On Wed, Apr 01, 2026 at 10:05:12PM +0530, Taniya Das wrote:
> >>>> On 4/1/2026 12:05 PM, Qiang Yu wrote:
> >>>>> diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
> >> [..]
> >>>>> +static const char * const tcsr_pcie_4_regulators[] = {
> >>>>> + "vdda-refgen-0p9",
> >>>>> + "vdda-refgen-1p2",
> >>>>> + "vdda-qreftx1-0p9",
> >>>>> + "vdda-qrefrpt0-0p9",
> >>>>> + "vdda-qrefrpt1-0p9",
> >>>>> + "vdda-qrefrpt2-0p9",
> >>>>> + "vdda-qrefrx2-0p9",
> >>>>> +};
> >>>>> +
> >>>>
> >>>> TCSR clock refs are just not for PCIe alone, they would have supplies
> >>>> for all the ref clocks. These supplies can also be shared across other
> >>>> clock refs. I think it is not the correct way to handle the supplies, as
> >>>> TCSR does not have the complete supplies map.
> >>>>
> >>> We have complete supplies map. You can get it on ipcatlog. Here is example
> >>> for other instances eg USB and EDP:
> >>> - Glymur (eDP): CXO PAD -> TX0 -> RPT0 -> RX0 -> eDP
> >>> - Glymur (USB4_2): CXO PAD -> TX0 -> RPT0 -> RPT1 -> RX1 -> USB4_2
> >>> - Glymur (USB3): CXO PAD -> TX0 -> RPT3 -> RPT4 -> RX4 -> USB3_SS3
> >>>
> >>> I only add supplies for PCIe in this series because USB and EDP vote these
> >>> LDO in their PHY driver. They can remove them in PHY dts node and add same
> >>> regulator list here.
> >>>
> >>
> >> The regulators are reference counted. Can't we add the USB and eDP
> >> handling here as well now, and then after they are voted here we remove
> >> them from the PHY?
> >>
> >
> > For USB, I’m not yet sure which tcsr_*_clkref_en each USB instance in the
> > QREF diagram is tied to. I need to confirm that mapping first, I'm
> > checking with Wesley Cheng.
>
> I think on at least some platforms the reference clock for the primary
> USB controller is not sw-controllable (so we wouldn't get a handle to
> toggle the regulator this way).. please check that
>
I would suggest we move forward with atleast PCIe regulators for now. Since USB
and eDP are voting for these regulators on their own, we can work with relevant
teams later to switch to this model and this is not going to cause any
regression for them.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: Add PixArt PAJ7620 gesture sensor
From: Krzysztof Kozlowski @ 2026-04-17 9:34 UTC (permalink / raw)
To: Harpreet Saini
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Lechner, devicetree, linux-input, linux-kernel
In-Reply-To: <20260417052527.62535-2-sainiharpreet29@yahoo.com>
On Fri, Apr 17, 2026 at 01:25:26AM -0400, Harpreet Saini wrote:
> Signed-off-by: Harpreet Saini <sainiharpreet29@yahoo.com>
> ---
> .../bindings/input/pixart,paj7620.yaml | 70 +++++++++++++++++++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> 2 files changed, 72 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/pixart,paj7620.yaml
>
Comments from v1 apply. Respond to the instead of ignoring.
> diff --git a/Documentation/devicetree/bindings/input/pixart,paj7620.yaml b/Documentation/devicetree/bindings/input/pixart,paj7620.yaml
> new file mode 100644
> index 000000000000..d4f58b712810
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/pixart,paj7620.yaml
> @@ -0,0 +1,70 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org
> +$schema: http://devicetree.org
There is no such syntax. Don't invent own coding style.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v1] arm64: dts: qcom: qcs6490-rb3gen2: Add WCD headset playback and record for qcs6490-rb3gen2 industrial mezzanine
From: Karthik S @ 2026-04-17 9:33 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Karthik S
Add WCD playback and capture DAI link to sound node. Add WCD
codec node and corresponding soundwire nodes to perform
headset playback and record.
Signed-off-by: Karthik S <karthik.s@qss.qualcomm.com>
---
.../qcs6490-rb3gen2-industrial-mezzanine.dtso | 133 ++++++++++++++++++
1 file changed, 133 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
index 83908db335af..d2503fce352c 100644
--- a/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
+++ b/arch/arm64/boot/dts/qcom/qcs6490-rb3gen2-industrial-mezzanine.dtso
@@ -6,6 +6,7 @@
/dts-v1/;
/plugin/;
#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/sound/qcom,q6afe.h>
#include <dt-bindings/clock/qcom,gcc-sc7280.h>
#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
@@ -30,6 +31,29 @@ vreg_1p8: regulator-1v8 {
regulator-always-on;
regulator-boot-on;
};
+
+ wcd9370: audio-codec-0 {
+ compatible = "qcom,wcd9370-codec";
+
+ pinctrl-0 = <&wcd_default>;
+ pinctrl-names = "default";
+
+ reset-gpios = <&tlmm 83 GPIO_ACTIVE_LOW>;
+ vdd-buck-supply = <&vph_pwr>;
+ vdd-rxtx-supply = <&vph_pwr>;
+ vdd-px-supply = <&vph_pwr>;
+ vdd-mic-bias-supply = <&vph_pwr>;
+ qcom,micbias1-microvolt = <1800000>;
+ qcom,micbias2-microvolt = <1800000>;
+ qcom,micbias3-microvolt = <1800000>;
+ qcom,micbias4-microvolt = <1800000>;
+ qcom,hphl-jack-type-normally-closed = <1>;
+ qcom,ground-jack-type-normally-closed = <1>;
+ qcom,rx-device = <&wcd937x_rx>;
+ qcom,tx-device = <&wcd937x_tx>;
+
+ #sound-dai-cells = <1>;
+ };
};
&remoteproc_wpss {
@@ -283,8 +307,117 @@ pcie1_tc9563_resx_n: pcie1-tc9563-resx-state {
output-enable;
};
+ wcd_default: wcd-reset-n-active-state {
+ pins = "gpio83";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
};
&wifi {
status = "disabled";
};
+
+&swr0 {
+ status = "okay";
+
+ wcd937x_rx: codec@0,4 {
+ compatible = "sdw20217010a00";
+ reg = <0 4>;
+
+ /*
+ * WCD9370 RX Port 1 (HPH_L/R) <==> SWR1 Port 1 (HPH_L/R)
+ * WCD9370 RX Port 2 (CLSH) <==> SWR1 Port 2 (CLSH)
+ * WCD9370 RX Port 3 (COMP_L/R) <==> SWR1 Port 3 (COMP_L/R)
+ * WCD9370 RX Port 4 (LO) <==> SWR1 Port 4 (LO)
+ * WCD9370 RX Port 5 (DSD_L/R) <==> SWR1 Port 5 (DSD)
+ */
+ qcom,rx-port-mapping = <1 2 3 4 5>;
+
+ /*
+ * Static channels mapping between slave and master rx port channels.
+ * In the order of slave port channels, which is
+ * hph_l, hph_r, clsh, comp_l, comp_r, lo, dsd_r, dsd_l.
+ */
+ qcom,rx-channel-mapping = /bits/ 8 <1 2 1 1 2 1 1 2>;
+ };
+};
+
+&swr1 {
+ status = "okay";
+ wcd937x_tx: codec@0,3 {
+ compatible = "sdw20217010a00";
+ reg = <0 3>;
+
+ /*
+ * WCD9370 TX Port 1 (ADC1) <=> SWR2 Port 2
+ * WCD9370 TX Port 2 (ADC2, 3) <=> SWR2 Port 2
+ * WCD9370 TX Port 3 (DMIC0,1,2,3 & MBHC) <=> SWR2 Port 3
+ * WCD9370 TX Port 4 (DMIC4,5,6,7) <=> SWR2 Port 4
+ */
+ qcom,tx-port-mapping = <1 1 2 3>;
+
+ /*
+ * Static channel mapping between slave and master tx port channels.
+ * In the order of slave port channels which is adc1, adc2, adc3,
+ * mic0, dmic1, mbhc, dmic2, dmic3, dmci4, dmic5, dmic6, dmic7.
+ */
+ qcom,tx-channel-mapping = /bits/ 8 <1 2 1 1 2 3 3 4 1 2 3 4>;
+ };
+};
+
+&lpass_tx_macro {
+ status = "okay";
+};
+
+&lpass_rx_macro {
+ status = "okay";
+};
+
+&sound {
+ model = "qcs6490-rb3gen2-ia-snd-card";
+ audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
+ "SpkrRight IN", "WSA_SPK2 OUT",
+ "IN1_HPHL", "HPHL_OUT",
+ "IN2_HPHR", "HPHR_OUT",
+ "AMIC2", "MIC BIAS2",
+ "TX SWR_ADC1", "ADC2_OUTPUT",
+ "VA DMIC0", "vdd-micb",
+ "VA DMIC1", "vdd-micb",
+ "VA DMIC2", "vdd-micb",
+ "VA DMIC3", "vdd-micb";
+
+ wcd-capture-dai-link {
+ link-name = "WCD Capture";
+
+ codec {
+ sound-dai = <&wcd9370 1>, <&swr1 0>, <&lpass_tx_macro 0>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai TX_CODEC_DMA_TX_3>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+
+ wcd-playback-dai-link {
+ link-name = "WCD Playback";
+
+ codec {
+ sound-dai = <&wcd9370 0>, <&swr0 0>, <&lpass_rx_macro 0>;
+ };
+
+ cpu {
+ sound-dai = <&q6apmbedai RX_CODEC_DMA_RX_0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
+};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Ronald Claveau @ 2026-04-17 9:31 UTC (permalink / raw)
To: Neil Armstrong, Rob Herring
Cc: Lee Jones, Krzysztof Kozlowski, Conor Dooley, Andi Shyti,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <6758aaa2-ac1a-4751-aece-2b445b84f2bc@linaro.org>
On 4/17/26 9:53 AM, Neil Armstrong wrote:
> On 4/16/26 10:25, Ronald Claveau wrote:
>> On 4/15/26 11:48 PM, Rob Herring wrote:
>>> On Fri, Apr 03, 2026 at 06:08:34PM +0200, Ronald Claveau wrote:
>>>> The Khadas VIM4 MCU register is slightly different
>>>> from previous boards' MCU.
>>>> This board also features a switchable power source for its fan.
>>>>
>>>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>>>> ---
>>>> Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
>>>> 1 file changed, 5 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> index 084960fd5a1fd..67769ef5d58b1 100644
>>>> --- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>>> @@ -18,6 +18,7 @@ properties:
>>>> compatible:
>>>> enum:
>>>> - khadas,mcu # MCU revision is discoverable
>>>
>>> The revision is no longer discoverable as was claimed?
>>>
>>
>> The firmware revision is still discoverable, and via the same register,
>> but the VIM4 MCU has a different register layout (eg: no DEVICE_NO
>> register). The new compatible is needed to describe a different MCU
>> variant, not a different revision of the same MCU.
>> I will remove the comment as it is confusing with new boards.
>
> Yes basically it was discoverable for earlier MCU version, but is not
> for this particular board version.
>
> Keep the comment, but add a comment on the vim4 entry saying this variant
> is not discoverable.
>
> Neil
>
Ok make sense, I will do that.
>>
>>>> + - khadas,vim4-mcu
>>>> "#cooling-cells": # Only needed for boards having FAN control
>>>> feature
>>>> const: 2
>>>> @@ -25,6 +26,10 @@ properties:
>>>> reg:
>>>> maxItems: 1
>>>> + fan-supply:
>>>> + description: Phandle to the regulator that powers the fan.
>>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>>> +
>>>> required:
>>>> - compatible
>>>> - reg
>>>>
>>>> --
>>>> 2.49.0
>>>>
>>
>>
>
--
Best regards,
Ronald
^ permalink raw reply
* [PATCH 40/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5c
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B6 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
index 7fe42f4ff827..8ffbbc5f9b6c 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5c.dts
@@ -262,7 +262,9 @@ &hdmi0 {
pinctrl-0 = <&hdmim0_tx0_cec
&hdmim1_tx0_hpd
&hdmim0_tx0_scl
- &hdmim0_tx0_sda>;
+ &hdmim0_tx0_sda
+ &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -461,6 +463,12 @@ &pd_gpu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
leds {
led_pins: led-pins {
rockchip,pins = <3 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>,
--
2.53.0
^ permalink raw reply related
* [PATCH 39/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-rock-5a
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B6 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
index 0991f6a21190..b3afbdd7119d 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-rock-5a.dts
@@ -327,7 +327,9 @@ &hdmi0 {
pinctrl-0 = <&hdmim0_tx0_cec
&hdmim1_tx0_hpd
&hdmim0_tx0_scl
- &hdmim0_tx0_sda>;
+ &hdmim0_tx0_sda
+ &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -373,6 +375,12 @@ &pd_gpu {
};
&pinctrl {
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
leds {
io_led: io-led {
rockchip,pins = <3 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>;
--
2.53.0
^ permalink raw reply related
* [PATCH 38/40] arm64: dts: rockchip: Add frl-enable-gpios to rk3588s-roc-pc
From: Cristian Ciocaltea @ 2026-04-17 9:25 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260417-dts-rk-frl-enable-gpios-v1-0-a19c0dd8c9f6@collabora.com>
The board exposes the GPIO4_B2 line to control the voltage bias on the
HDMI0 data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the HDMI0 node to the GPIO line using the frl-enable-gpios
property to allow adjusting the bias when transitioning between TMDS and
FRL operating modes.
While at it, move hym8563 down to fix the ordering of &pinctrl entries.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts | 15 ++++++++++++---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts b/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts
index 7e179862da6e..a54d1aac284f 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-roc-pc.dts
@@ -224,6 +224,9 @@ &gpu {
};
&hdmi0 {
+ pinctrl-0 = <&hdmim0_tx0_cec &hdmim0_tx0_hpd
+ &hdmim0_tx0_scl &hdmim0_tx0_sda &hdmi0_frl_en>;
+ frl-enable-gpios = <&gpio4 RK_PB2 GPIO_ACTIVE_LOW>;
status = "okay";
};
@@ -367,9 +370,9 @@ &pd_gpu {
};
&pinctrl {
- hym8563 {
- hym8563_int: hym8563-int {
- rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+ hdmi {
+ hdmi0_frl_en: hdmi0-frl-en {
+ rockchip,pins = <4 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
};
};
@@ -379,6 +382,12 @@ hp_detect: hp-detect {
};
};
+ hym8563 {
+ hym8563_int: hym8563-int {
+ rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
leds {
led_pins: led-pins {
rockchip,pins = <1 RK_PD5 RK_FUNC_GPIO &pcfg_pull_none>,
--
2.53.0
^ 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