* [PATCH 1/3] dt-bindings: power: qcom,rpmpd: Add Hawi RPMh power domain
From: Fenglin Wu @ 2026-04-01 9:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu
In-Reply-To: <20260401-haw-rpmhpd-v1-0-c830c79ed8f9@oss.qualcomm.com>
Document the RPMh power domain for Hawi SoC.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
Documentation/devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
index 27af5b8aa134..35a0e01c2015 100644
--- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
+++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml
@@ -18,6 +18,7 @@ properties:
oneOf:
- enum:
- qcom,glymur-rpmhpd
+ - qcom,hawi-rpmhpd
- qcom,kaanapali-rpmhpd
- qcom,mdm9607-rpmpd
- qcom,milos-rpmhpd
--
2.43.0
^ permalink raw reply related
* [PATCH 0/3] power: qcom,rpmpd: add RPMh power doamins support for Hawi SoC
From: Fenglin Wu @ 2026-04-01 9:15 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio
Cc: Subbaraman Narayanamurthy, linux-arm-msm, devicetree,
linux-kernel, linux-pm, kernel, Fenglin Wu
Add constant definitions for the new power domains and new voltage
levels present in Hawi SoC. Also add RPMH power domain support for
Hawi SoC.
Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
---
Fenglin Wu (3):
dt-bindings: power: qcom,rpmpd: Add Hawi RPMh power domain
dt-bindings: power: qcom,rpmhpd: Add new power domains and new levels
pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
.../devicetree/bindings/power/qcom,rpmpd.yaml | 1 +
drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++
include/dt-bindings/power/qcom,rpmhpd.h | 12 +++++++
3 files changed, 51 insertions(+)
---
base-commit: 33b1a2ee3a3df63e7a08e51e6de2b2d28ddf257f
change-id: 20260401-haw-rpmhpd-b40a68a3ce79
Best regards,
--
Fenglin Wu <fenglin.wu@oss.qualcomm.com>
^ permalink raw reply
* RE: Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 9:11 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <20260401-weightless-mule-of-opportunity-57f45e@quoll>
Hi Krzysztof
This is my first upstream contribution. I will improve the patch in v2.
> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
> > Add compatible string of Mali G310 GPU on i.MX952 board.
>
> We see this from the diff. Say something useful.
I will improve the description in v2.
>
> >
> > Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
>
> And the review should tell you that. Did that review even happen? That's a v1
> and a single liner patch, so how basics could be missed?
Yes, it's v1. I will remove the Reviewed-by tag in v2.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v9 5/6] reset: rzv2h-usb2phy: Convert to regmap API
From: Tommaso Merciai @ 2026-04-01 9:10 UTC (permalink / raw)
To: Philipp Zabel
Cc: tomm.merciai, peda, linux-renesas-soc, biju.das.jz,
Fabrizio Castro, Lad Prabhakar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Magnus Damm, Greg Kroah-Hartman,
Josua Mayer, Ulf Hansson, devicetree, linux-kernel
In-Reply-To: <0bad9579a953cc069e17a7075a45c9eb9c7a6d8d.camel@pengutronix.de>
Hi Philipp,
Thanks for your comments.
On Wed, Apr 01, 2026 at 10:23:51AM +0200, Philipp Zabel wrote:
> On Mi, 2026-04-01 at 10:04 +0200, Tommaso Merciai wrote:
> > Hi Philipp,
> > Thanks for your review.
> >
> > On Tue, Mar 31, 2026 at 06:36:45PM +0200, Philipp Zabel wrote:
> > > On Fr, 2026-03-27 at 19:08 +0100, Tommaso Merciai wrote:
> > > > Replace raw MMIO accesses (void __iomem *, readl/writel) with
> > > > regmap_read/regmap_write via devm_regmap_init_mmio(). Regmap
> > > > provides its own internal locking, so the manual spinlock and
> > > > scoped_guard() wrappers are no longer needed.
> > > >
> > > > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > > > ---
> > > > v8->v9:
> > > > - New patch
> > > >
> > > > drivers/reset/Kconfig | 1 +
> > > > drivers/reset/reset-rzv2h-usb2phy.c | 42 ++++++++++++++++-------------
> > > > 2 files changed, 24 insertions(+), 19 deletions(-)
> > > >
> > > > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> > > > index 5165006be693..c539ca88518f 100644
> > > > --- a/drivers/reset/Kconfig
> > > > +++ b/drivers/reset/Kconfig
> > > > @@ -257,6 +257,7 @@ config RESET_RZG2L_USBPHY_CTRL
> > > > config RESET_RZV2H_USB2PHY
> > > > tristate "Renesas RZ/V2H(P) (and similar SoCs) USB2PHY Reset driver"
> > > > depends on ARCH_RENESAS || COMPILE_TEST
> > > > + select REGMAP_MMIO
> > > > help
> > > > Support for USB2PHY Port reset Control found on the RZ/V2H(P) SoC
> > > > (and similar SoCs).
> > > > diff --git a/drivers/reset/reset-rzv2h-usb2phy.c b/drivers/reset/reset-rzv2h-usb2phy.c
> > > > index 5bdd39274612..4014eff0f017 100644
> > > > --- a/drivers/reset/reset-rzv2h-usb2phy.c
> > > > +++ b/drivers/reset/reset-rzv2h-usb2phy.c
> > > > @@ -5,13 +5,13 @@
> > > > * Copyright (C) 2025 Renesas Electronics Corporation
> > > > */
> > > >
> > > > -#include <linux/cleanup.h>
> > > > #include <linux/delay.h>
> > > > #include <linux/io.h>
> > > > #include <linux/module.h>
> > > > #include <linux/of.h>
> > > > #include <linux/platform_device.h>
> > > > #include <linux/pm_runtime.h>
> > > > +#include <linux/regmap.h>
> > > > #include <linux/reset.h>
> > > > #include <linux/reset-controller.h>
> > > >
> > > > @@ -37,10 +37,9 @@ struct rzv2h_usb2phy_reset_of_data {
> > > >
> > > > struct rzv2h_usb2phy_reset_priv {
> > > > const struct rzv2h_usb2phy_reset_of_data *data;
> > > > - void __iomem *base;
> > > > + struct regmap *regmap;
> > > > struct device *dev;
> > > > struct reset_controller_dev rcdev;
> > > > - spinlock_t lock; /* protects register accesses */
> > > > };
> > > >
> > > > static inline struct rzv2h_usb2phy_reset_priv
> > > > @@ -55,10 +54,8 @@ static int rzv2h_usbphy_reset_assert(struct reset_controller_dev *rcdev,
> > > > struct rzv2h_usb2phy_reset_priv *priv = rzv2h_usbphy_rcdev_to_priv(rcdev);
> > > > const struct rzv2h_usb2phy_reset_of_data *data = priv->data;
> > > >
> > > > - scoped_guard(spinlock, &priv->lock) {
> > > > - writel(data->reset2_acquire_val, priv->base + data->reset2_reg);
> > > > - writel(data->reset_assert_val, priv->base + data->reset_reg);
> > > > - }
> > > > + regmap_write(priv->regmap, data->reset2_reg, data->reset2_acquire_val);
> > > > + regmap_write(priv->regmap, data->reset_reg, data->reset_assert_val);
> > >
> > > What is the spinlock protecting? acquire/assert registers being set
> > > together, without another acquire/assert or deassert/release register
> > > access pair interleaving?
> > > In that case you still need the lock. Or use regmap_multi_reg_write().
> > > You could even directly store the sequences as struct reg_sequence in
> > > rzv2h_usb2phy_reset_of_data.
> >
> > You are correct. Thank you.
> > As per your suggestion I'm planning to use regmap_multi_reg_write().
> >
> > Plan is to have the:
> >
> > static const struct reg_sequence rzv2h_init_seqs[] = {
>
> Even though the struct is called req_sequence, the whole array is the
> sequence. Let's call these _seq, singular.
Ack.
>
> > { .reg = 0xc10, .def = 0x67c },
> > { .reg = 0xc14, .def = 0x1f },
>
> 0x01f for consistency?
Ouch, thank you!
>
> > { .reg = 0x600, .def = 0x909 },
> > };
> >
> > static const struct reg_sequence rzv2h_assert_seqs[] = {
> > { .reg = 0xb04, .def = 0x303 },
> > { .reg = 0x000, .def = 0x206 },
>
> Consider setting .delay_us = 11, see below.
Thanks for the hint.
>
> > };
> >
> > static const struct reg_sequence rzv2h_deassert_seqs[] = {
> > { .reg = 0x000, .def = 0x200 },
> > { .reg = 0xb04, .def = 0x003 },
> > { .reg = 0x000, .def = 0x000 },
> > };
> >
> > static const struct rzv2h_usb2phy_reset_of_data rzv2h_reset_of_data = {
> > .init_seqs = rzv2h_init_seqs,
> > .init_nseqs = ARRAY_SIZE(rzv2h_init_seqs),
> > .assert_seqs = rzv2h_assert_seqs,
> > .assert_nseqs = ARRAY_SIZE(rzv2h_assert_seqs),
> > .deassert_seqs = rzv2h_deassert_seqs,
> > .deassert_nseqs = ARRAY_SIZE(rzv2h_deassert_seqs),
> > .reset_reg = 0,
> > .reset_status_bits = BIT(2),
> > };
> >
> > With that I can use:
> >
> > static int rzv2h_usbphy_reset_assert(struct reset_controller_dev *rcdev,
> > unsigned long id)
> > {
> > struct rzv2h_usb2phy_reset_priv *priv = rzv2h_usbphy_rcdev_to_priv(rcdev);
> > const struct rzv2h_usb2phy_reset_of_data *data = priv->data;
> > int ret;
> >
> > ret = regmap_multi_reg_write(priv->regmap, data->assert_seqs,
> > data->assert_nseqs);
> > if (ret)
> > return ret;
> >
> > usleep_range(11, 20);
>
> Specifying a delay in rzv2h_assert_seqs[] and setting
> rzv2h_usb2phy_reset_regconf.can_sleep = true would have the same
> effect.
Then we can have:
static const struct reg_sequence rzv2h_init_seq[] = {
{ .reg = 0xc10, .def = 0x67c },
{ .reg = 0xc14, .def = 0x01f },
{ .reg = 0x600, .def = 0x909 },
};
static const struct reg_sequence rzv2h_assert_seq[] = {
{ .reg = 0xb04, .def = 0x303 },
{ .reg = 0x000, .def = 0x206, .delay_us = 20 },
};
static const struct reg_sequence rzv2h_deassert_seq[] = {
{ .reg = 0x000, .def = 0x200 },
{ .reg = 0xb04, .def = 0x003 },
{ .reg = 0x000, .def = 0x000 },
};
static const struct rzv2h_usb2phy_reset_of_data rzv2h_reset_of_data = {
.init_seq = rzv2h_init_seq,
.init_nseq = ARRAY_SIZE(rzv2h_init_seq),
.assert_seq = rzv2h_assert_seq,
.assert_nseq = ARRAY_SIZE(rzv2h_assert_seq),
.deassert_seq = rzv2h_deassert_seq,
.deassert_nseq = ARRAY_SIZE(rzv2h_deassert_seq),
.reset_reg = 0,
.reset_status_bits = BIT(2),
};
And I'll add:
static const struct regmap_config rzv2h_usb2phy_reset_regconf = {
.reg_bits = 32,
.val_bits = 32,
.reg_stride = 4,
.can_sleep = true,
};
In this way as you suggested we can drop usleep_range() into
rzv2h_usbphy_reset_assert() in thi way I think we can have
simply:
static int rzv2h_usbphy_reset_assert(struct reset_controller_dev *rcdev,
unsigned long id)
{
struct rzv2h_usb2phy_reset_priv *priv = rzv2h_usbphy_rcdev_to_priv(rcdev);
return regmap_multi_reg_write(priv->regmap, priv->data->assert_seq,
priv->data->assert_nseq);
}
What do you think? Thanks.
Kind Regards,
Tommaso
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH 12/16] irqchip/eip201-aic: Add support for Safexcel EIP-201 AIC
From: Miquel Raynal @ 2026-04-01 9:10 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Olivia Mackall, Herbert Xu, Jayesh Choudhary,
David S. Miller, Christian Marangi, Antoine Tenart,
Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc
In-Reply-To: <87pl4oayll.ffs@tglx>
Hello Thomas,
>> +struct eip201_aic {
>> + struct device *dev;
>> + void __iomem *regs;
>> + struct irq_domain *domain;
>> + struct irq_chip_generic *gc;
>> + u32 type;
>> + u32 pol;
>> +};
>
> Please follow:
>
> https://www.kernel.org/doc/html/latest/process/maintainer-tip.html#struct-declarations-and-initializers
Ah, I didn't know about this document, I'll go through it and fix the style.
Thanks for the feedback,
Miquèl
^ permalink raw reply
* Re: [PATCH 00/16] Add support for Inside-Secure EIP-150 crypto block
From: Miquel Raynal @ 2026-04-01 9:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc, Herve Codina
In-Reply-To: <CAMuHMdX23LQYFFzs9STykFVECb4uv1u3DmEMCh453GBK=4XbYQ@mail.gmail.com>
Hi Geert,
On 30/03/2026 at 15:33:30 +02, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Miquel,
>
> On Fri, 27 Mar 2026 at 21:10, Miquel Raynal (Schneider Electric)
> <miquel.raynal@bootlin.com> wrote:
>> This is a series adding support for the EIP-150, which is a crypto block
>> containing:
>> - a public key accelerator
>> - a random number generator
>> - an interrupt controller
>
> Thanks for your series!
>
>> irqchip/eip201-aic: Add support for Safexcel EIP-201 AIC
> [...]
>> crypto: eip28: Add support for SafeXcel EIP-28 Public Key Accelerator
>
> My OCD tells me to ask for using "SafeXcel" consistently, ;-)
Ah, yeah :) I initially wrote "Safexcel" everywhere, and at some point I
realized the marketing department had put a capital letter in the middle
of the word. My anti kamel-case heart fought back, but not enough, ending
up with a mix of both.
> drivers/crypto/inside-secure/eip28.c: .name = "Safexcel EIP28 PKA",
> drivers/irqchip/Kconfig: tristate "Safexcel EIP201 AIC"
> drivers/irqchip/Kconfig: inside Safexcel EIP150 IPs, gathering
> Public Key Accelerator
I'll address these.
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH 06/16] clk: tests: Add clk_parse_clkspec() Kunit testing
From: Miquel Raynal @ 2026-04-01 8:59 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc, Chen-Yu Tsai
In-Reply-To: <acqNRVLrPxABvecZ@redhat.com>
Hi Brian,
>> @@ -5312,6 +5312,7 @@ struct clk_hw *of_clk_get_hw(struct device_node *np, int index,
>>
>> return hw;
>> }
>> +EXPORT_SYMBOL_GPL(of_clk_get_hw);
>
> So that we don't unnecessarily broaden the API that's available to the
> clk providers, you can use EXPORT_SYMBOL_IF_KUNIT so that this is only
> available to the kunit tests.
Ah, good idea.
> Note that Chen-Yu posted a separate patch to add the includes for a
> separate test. The two patches will conflict since Stephen hasn't picked
> this up yet.
>
> https://lore.kernel.org/linux-clk/20260225083413.3384950-1-wenst@chromium.org/
Thanks for the warning, I will synchronize with Chen-Yu.
>> static struct clk *__of_clk_get(struct device_node *np,
>> int index, const char *dev_id,
>> diff --git a/drivers/clk/clk_test.c b/drivers/clk/clk_test.c
>> index a268d7b5d4cb..b814b45f1f7e 100644
>> --- a/drivers/clk/clk_test.c
>> +++ b/drivers/clk/clk_test.c
>> @@ -3541,10 +3541,134 @@ static struct kunit_suite clk_hw_get_dev_of_node_test_suite = {
>> .test_cases = clk_hw_get_dev_of_node_test_cases,
>> };
>>
>> +static const struct clk_init_data clk_parse_clkspec_1_init_data = {
>> + .name = "clk_parse_clkspec_1",
>> + .ops = &empty_clk_ops,
>> +};
>> +
>> +static const struct clk_init_data clk_parse_clkspec_2_init_data = {
>> + .name = "clk_parse_clkspec_2",
>> + .ops = &empty_clk_ops,
>> +};
>> +
>> +static struct clk_hw *kunit_clk_get(struct of_phandle_args *clkspec, void *data)
>> +{
>> + return (struct clk_hw *)data;
>> +}
>> +
>> +struct clk_parse_clkspec_ctx {
>> + struct device_node *prov1_np;
>> + struct device_node *prov2_np;
>> + struct device_node *cons_np;
>> +};
>> +
>> +static int clk_parse_clkspec_init(struct kunit *test)
>> +{
>> + struct clk_parse_clkspec_ctx *ctx;
>> + struct clk_hw *hw1, *hw2;
>> +
>> + ctx = kunit_kzalloc(test, sizeof(*ctx), GFP_KERNEL);
>> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, ctx);
>> + test->priv = ctx;
>> +
>> + KUNIT_ASSERT_EQ(test, 0, of_overlay_apply_kunit(test, kunit_clk_parse_clkspec));
>> +
>> + /* Register provider 1 */
>> + hw1 = kunit_kzalloc(test, sizeof(*hw1), GFP_KERNEL);
>> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, hw1);
>> + hw1->init = &clk_parse_clkspec_1_init_data;
>> +
>> + ctx->prov1_np = of_find_compatible_node(NULL, NULL, "test,clock-provider1");
>> + KUNIT_ASSERT_NOT_NULL(test, ctx->prov1_np);
>> +
>> + KUNIT_ASSERT_EQ(test, 0, of_clk_hw_register_kunit(test, ctx->prov1_np, hw1));
>> + of_clk_add_hw_provider(ctx->prov1_np, kunit_clk_get, hw1);
>
> Can you just use of_clk_hw_simple_get() and drop kunit_clk_get()
> above?
I will try.
>> + of_node_put(ctx->prov1_np);
>> +
>> + /* Register provider 2 */
>> + hw2 = kunit_kzalloc(test, sizeof(*hw2), GFP_KERNEL);
>> + KUNIT_ASSERT_NOT_ERR_OR_NULL(test, hw2);
>> + hw2->init = &clk_parse_clkspec_2_init_data;
>> +
>> + ctx->prov2_np = of_find_compatible_node(NULL, NULL, "test,clock-provider2");
>> + KUNIT_ASSERT_NOT_NULL(test, ctx->prov2_np);
>> +
>> + KUNIT_ASSERT_EQ(test, 0, of_clk_hw_register_kunit(test, ctx->prov2_np, hw2));
>> + of_clk_add_hw_provider(ctx->prov2_np, kunit_clk_get, hw2);
>> + of_node_put(ctx->prov2_np);
>> +
>> + ctx->cons_np = of_find_compatible_node(NULL, NULL, "test,clock-consumer");
>> + KUNIT_ASSERT_NOT_NULL(test, ctx->cons_np);
>> +
>> + return 0;
>> +}
>> +
>> +static void clk_parse_clkspec_exit(struct kunit *test)
>> +{
>> + struct clk_parse_clkspec_ctx *ctx = test->priv;
>> +
>> + of_node_put(ctx->prov1_np);
>> + of_node_put(ctx->prov2_np);
>
> Is there a double free of prov1_np and prov2_np? If this is dropped from
> the test exit, then they should't need to be in the ctx struct.
These two calls increment the refcount on the node:
- of_find_compatible_node()
- of_clk_add_hw_provider()
However this makes me realize maybe I should call of_clk_del_provider()
in the exit() function. In any case, I believe keeping a reference over
the nodes during the test is correct and if there is an of_node_put()
call to remove, it should be the on in the _init().
Thanks for pointing this out!
Miquèl
^ permalink raw reply
* Re: [PATCH] arm64: dts: renesas: rzt2h-n2h-evk: Configure eMMC/SDHI pins
From: Lad, Prabhakar @ 2026-04-01 8:56 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-renesas-soc, devicetree, linux-kernel,
Biju Das, Lad Prabhakar
In-Reply-To: <20260331145221.7974-1-fabrizio.castro.jz@renesas.com>
On Tue, Mar 31, 2026 at 3:55 PM Fabrizio Castro
<fabrizio.castro.jz@renesas.com> wrote:
>
> The HW user manual for the Renesas RZ/T2H and the RZ/N2H state
> that for SDR104, SDR50, and HS200 to work properly the eMMC/SDHI
> interface pins have to be configured as specified below:
> * SDn_CLK pin - drive strength: Ultra High, slew rate: fast
> * Other SDn_* pins: drive strength: High, slew rate: fast,
> Schmitt trigger: disabled (not applicable to SDn_RST pins).
>
> Adjust the pin definitions accordingly.
>
> Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
> ---
> .../dts/renesas/rzt2h-n2h-evk-common.dtsi | 54 ++++++++++++++++---
> 1 file changed, 46 insertions(+), 8 deletions(-)
>
Reviewed-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Cheers,
Prabhakar
> diff --git a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
> index f87c2492f414..3fae950db603 100644
> --- a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
> @@ -275,12 +275,28 @@ data-pins {
> <RZT2H_PORT_PINMUX(12, 7, 0x29)>, /* SD0_DATA5 */
> <RZT2H_PORT_PINMUX(13, 0, 0x29)>, /* SD0_DATA6 */
> <RZT2H_PORT_PINMUX(13, 1, 0x29)>; /* SD0_DATA7 */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> };
>
> - ctrl-pins {
> - pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>, /* SD0_CLK */
> - <RZT2H_PORT_PINMUX(12, 1, 0x29)>, /* SD0_CMD */
> - <RZT2H_PORT_PINMUX(13, 2, 0x29)>; /* SD0_RST# */
> + clk-pins {
> + pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>; /* SD0_CLK */
> + drive-strength-microamp = <11800>;
> + slew-rate = <1>;
> + };
> +
> + cmd-pins {
> + pinmux = <RZT2H_PORT_PINMUX(12, 1, 0x29)>; /* SD0_CMD */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> + };
> +
> + rst-pins {
> + pinmux = <RZT2H_PORT_PINMUX(13, 2, 0x29)>; /* SD0_RST# */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> };
> };
>
> @@ -299,12 +315,23 @@ data-pins {
> <RZT2H_PORT_PINMUX(12, 3, 0x29)>, /* SD0_DATA1 */
> <RZT2H_PORT_PINMUX(12, 4, 0x29)>, /* SD0_DATA2 */
> <RZT2H_PORT_PINMUX(12, 5, 0x29)>; /* SD0_DATA3 */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> + };
> +
> + clk-pins {
> + pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>; /* SD0_CLK */
> + drive-strength-microamp = <11800>;
> + slew-rate = <1>;
> };
>
> ctrl-pins {
> - pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>, /* SD0_CLK */
> - <RZT2H_PORT_PINMUX(12, 1, 0x29)>, /* SD0_CMD */
> + pinmux = <RZT2H_PORT_PINMUX(12, 1, 0x29)>, /* SD0_CMD */
> <RZT2H_PORT_PINMUX(22, 5, 0x29)>; /* SD0_CD */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> };
> };
>
> @@ -323,12 +350,23 @@ data-pins {
> <RZT2H_PORT_PINMUX(17, 0, 0x29)>, /* SD1_DATA1 */
> <RZT2H_PORT_PINMUX(17, 1, 0x29)>, /* SD1_DATA2 */
> <RZT2H_PORT_PINMUX(17, 2, 0x29)>; /* SD1_DATA3 */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> + };
> +
> + clk-pins {
> + pinmux = <RZT2H_PORT_PINMUX(16, 5, 0x29)>; /* SD1_CLK */
> + drive-strength-microamp = <11800>;
> + slew-rate = <1>;
> };
>
> ctrl-pins {
> - pinmux = <RZT2H_PORT_PINMUX(16, 5, 0x29)>, /* SD1_CLK */
> - <RZT2H_PORT_PINMUX(16, 6, 0x29)>, /* SD1_CMD */
> + pinmux = <RZT2H_PORT_PINMUX(16, 6, 0x29)>, /* SD1_CMD */
> <RZT2H_PORT_PINMUX(17, 4, 0x29)>; /* SD1_CD */
> + drive-strength-microamp = <9000>;
> + slew-rate = <1>;
> + input-schmitt-disable;
> };
> };
> };
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [EXT] Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-01 8:56 UTC (permalink / raw)
To: Guangliu Ding, Liviu Dudau
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <AM0PR04MB47073E9E8B5C704BCF5D9F72F350A@AM0PR04MB4707.eurprd04.prod.outlook.com>
On 01/04/2026 10:48, Guangliu Ding wrote:
> Hi Liviu
>
> Thanks for your review. Please refer to my comments below:
>
>> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
>>> Add compatible string of Mali G310 GPU on i.MX952 board.
>>>
>>> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
>>> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
>>> ---
>>> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
>>> 1 file changed, 1 insertion(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> index 8eccd4338a2b..6a10843a26e2 100644
>>> --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
>>> @@ -20,6 +20,7 @@ properties:
>>> - enum:
>>> - mediatek,mt8196-mali
>>> - nxp,imx95-mali # G310
>>> + - nxp,imx952-mali # G310
>>
>> Can you explain why this is needed? Can it not be covered by the existing
>> compatible?
>
> There are functional differences in GPU module (GPUMIX) between i.MX95
> and i.MX952. So they cannot be fully covered by a single existing compatible.
> On i.MX952, The GPU clock is controlled by hardware GPU auto clock-gating
> mechanism, while the GPU clock is managed explicitly by the driver on i.MX95.
> Because of these behavioral differences, separate compatible strings
> "nxp,imx95-mali" and "nxp,imx952-mali" are needed to allow the driver to handle
> the two variants independently and to keep room for future divergence.
That's pretty arguable statement considering there is no driver code
using it, so basically this patchset admits openly devices are fully
compatible.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: glymur: Add qfprom efuse node
From: Konrad Dybcio @ 2026-04-01 8:56 UTC (permalink / raw)
To: Pankaj Patil, Srinivas Kandagatla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260331-glymur-qfprom-v1-2-5b4284d23c80@oss.qualcomm.com>
On 3/31/26 3:54 PM, Pankaj Patil wrote:
> Add the qfprom (Qualcomm Fuse ROM) efuse node and gpu speed bin child
> node for Glymur SoC
>
> Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v5 5/9] riscv: dts: spacemit: k1: add SD card controller and pinctrl support
From: Iker Pedrosa @ 2026-04-01 8:53 UTC (permalink / raw)
To: Troy Mitchell
Cc: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Adrian Hunter, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Michael Opdenacker,
Javier Martinez Canillas, linux-mmc, devicetree, linux-riscv,
spacemit, linux-kernel, Anand Moon, Trevor Gamblin
In-Reply-To: <aco9oLumPh4OZtIo@kernel.org>
El lun, 30 mar 2026 a las 11:08, Troy Mitchell
(<troy.mitchell@linux.dev>) escribió:
>
> On Mon, Mar 30, 2026 at 16:38:06 CST, Iker Pedrosa wrote:
> > Add SD card controller infrastructure for SpacemiT K1 SoC with complete
> > pinctrl support for both standard and UHS modes.
> >
> > - Add sdhci0 controller definition with clocks, resets and interrupts
> > - Add mmc1_cfg pinctrl for 3.3V standard SD operation
> > - Add mmc1_uhs_cfg pinctrl for 1.8V UHS high-speed operation
> > - Configure appropriate drive strength and power-source properties
> >
> > This provides complete SD card infrastructure that K1-based boards can
> > enable.
> >
> > Tested-by: Anand Moon <linux.amoon@gmail.com>
> > Tested-by: Trevor Gamblin <tgamblin@baylibre.com>
> > Signed-off-by: Iker Pedrosa <ikerpedrosam@gmail.com>
> > ---
> > arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi | 40 ++++++++++++++++++++++++++++
> > arch/riscv/boot/dts/spacemit/k1.dtsi | 13 +++++++++
> > 2 files changed, 53 insertions(+)
> >
> > diff --git a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
> > index b13dcb10f4d66022d27307de73a6ea3287e97441..8d82011f1af666fb78c282a2abcc0cb88f962053 100644
> > --- a/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
> > +++ b/arch/riscv/boot/dts/spacemit/k1-pinctrl.dtsi
> > @@ -570,4 +570,44 @@ pwm14-1-pins {
> > drive-strength = <32>;
> > };
> > };
> > +
> > + mmc1_cfg: mmc1-cfg {
> > + mmc1-data-cmd-pins {
> > + pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
> > + <K1_PADCONF(105, 0)>, /* mmc1_d2 */
> > + <K1_PADCONF(106, 0)>, /* mmc1_d1 */
> > + <K1_PADCONF(107, 0)>, /* mmc1_d0 */
> > + <K1_PADCONF(108, 0)>; /* mmc1_cmd */
> > + bias-pull-up = <1>;
> > + drive-strength = <7>;
> I'm a bit concerned about this value. Looking at the downstream 6.6 code, 3.3V uses DS4,
> which equals 13mA. Since 7mA maps to DS0, what's the reasoning for using it here?
> Do we have any documentation or measurement to back this up?
Thank you for catching this! You're absolutely right to question these
drive strength values.
Looking back at my development process, I remember hitting signal
integrity issues in the early stages of this driver development. As a
quick solution, I lowered the drive strength values, which seemed to
resolve the immediate problems, and I moved on without revisiting the
electrical characteristics.
After your feedback, I investigated this properly by comparing with
the vendor kernel. It uses:
- 3.3V mode: PAD_3V_DS4 (19mA)
- 1.8V UHS mode: PAD_1V8_DS3 (42mA)
My original values were indeed backwards from both electrical theory
and proven vendor implementation. Testing with the corrected values
(19mA/42mA) confirms SD card is working.
I'll send v6 with the corrected drive strength values: drive-strength
= <19> for 3.3V and drive-strength = <42> for 1.8V UHS modes.
> > + power-source = <3300>;
> > + };
> > +
> > + mmc1-clk-pins {
> > + pinmux = <K1_PADCONF(109, 0)>; /* mmc1_clk */
> > + bias-pull-down = <1>;
> > + drive-strength = <7>;
> > + power-source = <3300>;
> > + };
> > + };
> > +
> > + mmc1_uhs_cfg: mmc1-uhs-cfg {
> > + mmc1-data-cmd-pins {
> > + pinmux = <K1_PADCONF(104, 0)>, /* mmc1_d3 */
> > + <K1_PADCONF(105, 0)>, /* mmc1_d2 */
> > + <K1_PADCONF(106, 0)>, /* mmc1_d1 */
> > + <K1_PADCONF(107, 0)>, /* mmc1_d0 */
> > + <K1_PADCONF(108, 0)>; /* mmc1_cmd */
> > + bias-pull-up = <1>;
> > + drive-strength = <13>;
> See above.
>
> - Troy
^ permalink raw reply
* Re: [PATCH 18/19] dt-bindings: gpio: describe Waveshare GPIO controller
From: Rob Herring (Arm) @ 2026-04-01 8:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Javier Martinez Canillas, Jagan Teki, Maarten Lankhorst,
Ondrej Jirman, Bartosz Golaszewski, Linus Walleij,
Thomas Zimmermann, Krzysztof Kozlowski, Cong Yang, Liam Girdwood,
Simona Vetter, David Airlie, Maxime Ripard, Mark Brown,
linux-kernel, Conor Dooley, Neil Armstrong, Jessica Zhang,
devicetree, linux-gpio, dri-devel
In-Reply-To: <20260401-waveshare-dsi-touch-v1-18-5e9119b5a014@oss.qualcomm.com>
On Wed, 01 Apr 2026 10:26:37 +0300, Dmitry Baryshkov wrote:
> The Waveshare DSI TOUCH family of panels has separate on-board GPIO
> controller, which controls power supplies to the panel and the touch
> screen and provides reset pins for both the panel and the touchscreen.
> Also it provides a simple PWM controller for panel backlight.
>
> Add bindings for these GPIO controllers. As overall integration might be
> not very obvious (and it differs significantly from the bindings used by
> the original drivers), provide complete example with the on-board
> regulators and the DSI panel.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> .../bindings/gpio/waveshare,dsi-touch-gpio.yaml | 100 +++++++++++++++++++++
> 1 file changed, 100 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.example.dtb: dsi_panel@0 (waveshare,8.0-dsi-touch-a): 'iovcc-supply', 'reset-gpio' do not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/display/panel/jadard,jd9365da-h3.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.example.dtb: dsi_panel@0 (waveshare,8.0-dsi-touch-a): 'vccio-supply' is a required property
from schema $id: http://devicetree.org/schemas/display/panel/jadard,jd9365da-h3.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/gpio/waveshare,dsi-touch-gpio.example.dtb: dsi_panel@0 (waveshare,8.0-dsi-touch-a): 'reset-gpios' is a required property
from schema $id: http://devicetree.org/schemas/display/panel/jadard,jd9365da-h3.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260401-waveshare-dsi-touch-v1-18-5e9119b5a014@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 05/19] dt-bindings: dipslay/panel: describe panels using Focaltech OTA7290B
From: Rob Herring (Arm) @ 2026-04-01 8:52 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: devicetree, Thomas Zimmermann, linux-kernel, Linus Walleij,
linux-gpio, Krzysztof Kozlowski, Jessica Zhang, Liam Girdwood,
Javier Martinez Canillas, Maarten Lankhorst, Cong Yang,
David Airlie, dri-devel, Ondrej Jirman, Conor Dooley, Mark Brown,
Simona Vetter, Neil Armstrong, Maxime Ripard, Bartosz Golaszewski,
Jagan Teki
In-Reply-To: <20260401-waveshare-dsi-touch-v1-5-5e9119b5a014@oss.qualcomm.com>
On Wed, 01 Apr 2026 10:26:24 +0300, Dmitry Baryshkov wrote:
> Add schema for the panels using Focaltech OTA7290B controller. For now
> there is only one such panel, from the Waveshare 8.8 DSI TOUCH-A kit.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> .../bindings/display/panel/focaltech,ota7290b.yaml | 70 ++++++++++++++++++++++
> 1 file changed, 70 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml: ignoring, error in schema: properties: compatible
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml: properties:compatible: [{'const': 'waveshare,8.88-dsi-touch-a'}] is not of type 'object', 'boolean'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml: properties:compatible: [{'const': 'waveshare,8.88-dsi-touch-a'}] is not of type 'object', 'boolean'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml: properties:compatible: [{'const': 'waveshare,8.88-dsi-touch-a'}] is not of type 'object', 'boolean'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml: properties:compatible: [{'const': 'waveshare,8.88-dsi-touch-a'}] is not of type 'object', 'boolean'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml: properties:compatible: [{'const': 'waveshare,8.88-dsi-touch-a'}] is not of type 'object', 'boolean'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml: properties:compatible: [{'const': 'waveshare,8.88-dsi-touch-a'}] is not of type 'object', 'boolean'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml: properties:compatible: [{'const': 'waveshare,8.88-dsi-touch-a'}] is not of type 'object', 'boolean'
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.yaml: properties:compatible: [{'const': 'waveshare,8.88-dsi-touch-a'}] is not of type 'object', 'boolean'
Traceback (most recent call last):
File "/usr/local/bin/dt-doc-validate", line 8, in <module>
sys.exit(main())
~~~~^^
File "/usr/local/lib/python3.13/dist-packages/dtschema/doc_validate.py", line 66, in main
ret |= check_doc(f)
~~~~~~~~~^^^
File "/usr/local/lib/python3.13/dist-packages/dtschema/doc_validate.py", line 37, in check_doc
dtsch.check_schema_refs()
~~~~~~~~~~~~~~~~~~~~~~~^^
File "/usr/local/lib/python3.13/dist-packages/dtschema/schema.py", line 241, in check_schema_refs
self._check_schema_refs(resolver, self)
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/dist-packages/dtschema/schema.py", line 212, in _check_schema_refs
self._check_schema_refs(resolver, v, parent=k, is_common=is_common,
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
has_constraint=has_constraint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/dist-packages/dtschema/schema.py", line 216, in _check_schema_refs
self._check_schema_refs(resolver, schema[i], parent=parent, is_common=is_common,
~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
has_constraint=has_constraint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/dist-packages/dtschema/schema.py", line 203, in _check_schema_refs
ref_sch = resolver.lookup(schema['$ref']).contents
~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 682, in lookup
retrieved = self._registry.get_or_retrieve(uri)
File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 422, in get_or_retrieve
registry = self.crawl()
File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 500, in crawl
id = resource.id()
File "/usr/local/lib/python3.13/dist-packages/referencing/_core.py", line 231, in id
id = self._specification.id_of(self.contents)
File "/usr/local/lib/python3.13/dist-packages/referencing/jsonschema.py", line 50, in _dollar_id
return contents.get("$id")
^^^^^^^^^^^^
AttributeError: 'list' object has no attribute 'get'
Documentation/devicetree/bindings/display/panel/focaltech,ota7290b.example.dtb: /example-0/dsi/panel@0: failed to match any schema with compatible: ['waveshare,8.8-dsi-touch-a']
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260401-waveshare-dsi-touch-v1-5-5e9119b5a014@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH 09/16] clk: Use the generic OF phandle parsing in only one place
From: Miquel Raynal @ 2026-04-01 8:49 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc
In-Reply-To: <acqQZ5sx_WZrr4KJ@redhat.com>
On 30/03/2026 at 11:01:59 -04, Brian Masney <bmasney@redhat.com> wrote:
> On Fri, Mar 27, 2026 at 09:09:31PM +0100, Miquel Raynal (Schneider Electric) wrote:
>> There should be one single entry in the OF world, so that the way we
>> parse the DT is always the same. make sure this is the case by avoid
>> calling of_parse_phandle_with_args() from of_clk_get_parent_name(). This
>> is even more relevant as we currently fail to parse clock-ranges. As a
>> result, it seems to be safer to directly call of_parse_clkspec() there.
>>
>> Suggested-by: Stephen Boyd <sboyd@kernel.org>
>> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
>> ---
>> drivers/clk/clk.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
>> index 591c0780b61e..93e33ff30f3a 100644
>> --- a/drivers/clk/clk.c
>> +++ b/drivers/clk/clk.c
>> @@ -5375,8 +5375,7 @@ const char *of_clk_get_parent_name(const struct device_node *np, int index)
>> int count;
>> struct clk *clk;
>>
>> - rc = of_parse_phandle_with_args(np, "clocks", "#clock-cells", index,
>> - &clkspec);
>> + rc = of_parse_clkspec(np, index, NULL, &clkspec);
>> if (rc)
>> return NULL;
>
> Reviewed-by: Brian Masney <bmasney@redhat.com>
>
> In case a Fixes tag is warranted, it's not exactly clear what should be
> used. This was introduced in commit 766e6a4ec602 ("clk: add DT clock
> binding support") in 2012. However of_parse_clkspec was introduced in
> commit 4472287a3b2f5 ("clk: Introduce of_clk_get_hw_from_clkspec()") in
> 2018.
I didn't plan to add a Fixes here, but I can. In this case I would go
for:
commit 4472287a3b2f5 ("clk: Introduce of_clk_get_hw_from_clkspec()")
Thanks,
Miquèl
^ permalink raw reply
* RE: [EXT] Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-04-01 8:48 UTC (permalink / raw)
To: Liviu Dudau
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
dri-devel@lists.freedesktop.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, Jiyu Yang
In-Reply-To: <acva1Xt8V4k9-uG8@e142607>
Hi Liviu
Thanks for your review. Please refer to my comments below:
> On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
> > Add compatible string of Mali G310 GPU on i.MX952 board.
> >
> > Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> > Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> > ---
> > Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > index 8eccd4338a2b..6a10843a26e2 100644
> > --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> > @@ -20,6 +20,7 @@ properties:
> > - enum:
> > - mediatek,mt8196-mali
> > - nxp,imx95-mali # G310
> > + - nxp,imx952-mali # G310
>
> Can you explain why this is needed? Can it not be covered by the existing
> compatible?
There are functional differences in GPU module (GPUMIX) between i.MX95
and i.MX952. So they cannot be fully covered by a single existing compatible.
On i.MX952, The GPU clock is controlled by hardware GPU auto clock-gating
mechanism, while the GPU clock is managed explicitly by the driver on i.MX95.
Because of these behavioral differences, separate compatible strings
"nxp,imx95-mali" and "nxp,imx952-mali" are needed to allow the driver to handle
the two variants independently and to keep room for future divergence.
>
> Best regards,
> Liviu
>
> > - rockchip,rk3588-mali
> > - const: arm,mali-valhall-csf # Mali Valhall GPU
> model/revision is fully discoverable
> >
> >
> > --
> > 2.34.1
> >
>
> --
> ====================
> | I would like to |
> | fix the world, |
> | but they're not |
> | giving me the |
> \ source code! /
> ---------------
> ¯\_(ツ)_/¯
^ permalink raw reply
* Re: [PATCH 10/16] clk: Add support for clock nexus dt bindings
From: Miquel Raynal @ 2026-04-01 8:47 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc, Herve Codina
In-Reply-To: <acqT3Dh03y3JiLLc@redhat.com>
Hello Brian,
First, thanks for the whole review.
On 30/03/2026 at 11:16:44 -04, Brian Masney <bmasney@redhat.com> wrote:
>> - ret = of_parse_phandle_with_args(np, "clocks", "#clock-cells",
>> - index, out_args);
>> + ret = of_parse_phandle_with_args_map(np, "clocks", "clock",
>> + index, out_args);
>
> Before I left my Reviewed-by, I should have double checked Sashiko. It
> has several questions about this patch. The first is:
>
> Are there other places in the clock framework that need to transition to the
> new map API to ensure assigned clocks work?
>
> For instance, assigned-clocks and assigned-clock-parents are parsed in
> drivers/clk/clk-conf.c using of_parse_phandle_with_args(). If a device
> specifies an assigned clock that routes through a nexus node, will it fail
> to configure because the map is not traversed?
The goal of the nexus node is to isolate what is behind. Are
assigned-clocks et al. supposed to traverse a nexus node? I am tempted
to say "no", but I'm open to discussing this ofc.
> https://sashiko.dev/#/patchset/20260327-schneider-v7-0-rc1-crypto-v1-0-5e6ff7853994%40bootlin.com?patch=12563
I have mixed feelings concerning Sashiko's feedback. I will go through
that page nevertheless, there are interesting comments in there.
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH v16 0/7] coresight: ctcu: Enable byte-cntr function for TMC ETR
From: Jie Gan @ 2026-04-01 8:47 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Bjorn Andersson, Konrad Dybcio
Cc: coresight, linux-arm-kernel, linux-kernel, linux-arm-msm,
devicetree, Konrad Dybcio, Krzysztof Kozlowski
In-Reply-To: <20260323-enable-byte-cntr-for-ctcu-v16-0-7a413d211b8d@oss.qualcomm.com>
On 3/23/2026 5:49 PM, Jie Gan wrote:
> The byte-cntr function provided by the CTCU device is used to count the
> trace data entering the ETR. An interrupt is triggered if the data size
> exceeds the threshold set in the BYTECNTRVAL register. The interrupt
> handler counts the number of triggered interruptions.
>
> Based on this concept, the irq_cnt can be used to determine whether
> the etr_buf is full. The ETR device will be disabled when the active
> etr_buf is nearly full or a timeout occurs. The nearly full buffer will
> be switched to background after synced. A new buffer will be picked from
> the etr_buf_list, then restart the ETR device.
>
> The byte-cntr reading functions can access data from the synced and
> deactivated buffer, transferring trace data from the etr_buf to userspace
> without stopping the ETR device.
>
> The byte-cntr read operation has integrated with the file node tmc_etr,
> for example:
> /dev/tmc_etr0
> /dev/tmc_etr1
>
> There are two scenarios for the tmc_etr file node with byte-cntr function:
> 1. BYTECNTRVAL register is configured and byte-cntr is enabled -> byte-cntr read
> 2. BYTECNTRVAL register is reset or byte-cntr is disabled -> original behavior
>
> Shell commands to enable byte-cntr reading for etr0:
> echo 1 > /sys/bus/coresight/devices/ctcu0/irq_enabled0
> echo 1 > /sys/bus/coresight/devices/tmc_etr0/enable_sink
> echo 1 > /sys/bus/coresight/devices/etm0/enable_source
> cat /dev/tmc_etr0
>
> Reset the BYTECNTR register for etr0:
> echo 0 > /sys/bus/coresight/devices/ctcu0/irq_enabled0
>
> ---
> Changes in v16:
> 1. Remove lock/unlock processes in patch "coresight: tmc: add create/clean
> functions for etr_buf_list" because we are allocating/freeing memory.
> - Link to v15: https://lore.kernel.org/r/20260313-enable-byte-cntr-for-ctcu-v15-0-1777f14ed319@oss.qualcomm.com
>
Gentle ping
> Changes in v15:
> 1. add lockdep_assert_held in patch "coresight: tmc: add create/clean
> functions for etr_buf_list"
> 2. optimize tmc_clean_etr_buf_list function
> 3. optimize the patch "enable byte-cntr for TMC ETR devices" according
> to Suzuki's comments
> - call byte_cntr_sysfs_ops from etr_sysfs_ops
> - optimize the lock usage in all functions
> - remove the buf_node parameter in etr_drvdata, move it to
> byte_cntr_data
> - move the tmc_reset_sysfs_buf function to tmc-etr.c
> - add a read flag to struct etr_buf_node to allow updating pos while
> traversing etr_buf_list during data reads.
> Link to v14: https://lore.kernel.org/r/20260309-enable-byte-cntr-for-ctcu-v14-0-c08823e5a8e6@oss.qualcomm.com
>
> Changes in V14:
> 1. Drop the patch: integrate byte-cntr's sysfs_ops with tmc sysfs file_ops
> 2. Replace tmc_sysfs_ops with byte_cntr_sysfs_ops in byte_cntr_start
> function and restore etr_sysfs_ops in byte_cntr_unprepare function.
> 3. Remove redundant checks in byte‑cntr functions.
> Link to V13: https://lore.kernel.org/all/20260223-enable-byte-cntr-for-ctcu-v13-0-9cb44178b250@oss.qualcomm.com/
>
> Changes in v13:
> 1. initilize the byte_cntr_data->raw_spin_lock before using.
> 2. replace kzalloc with kzalloc_obj.
> Link to V12: https://lore.kernel.org/all/20260203-enable-byte-cntr-for-ctcu-v12-0-7bf81b86b70e@oss.qualcomm.com/
>
> Changes in v12:
> 1. Add a new function for retrieving the CTCU's coresight_dev instead of
> refactor the existing function.
> Link to v11: https://lore.kernel.org/r/20260126-enable-byte-cntr-for-ctcu-v11-0-c0af66ba15cf@oss.qualcomm.com
>
> Changes in v11:
> 1. Correct the description in patch1 for the function coresight_get_in_port.
> 2. Renaming the sysfs_ops to tmc_sysfs_ops per Suzuki's suggestion.
> Link to v10: https://lore.kernel.org/r/20260122-enable-byte-cntr-for-ctcu-v10-0-22978e3c169f@oss.qualcomm.com
>
> Changes in v10:
> 1. fix a free memory issue that is reported by robot for patch 2.
> Link to v9: https://lore.kernel.org/r/20251224-enable-byte-cntr-for-ctcu-v9-0-886c4496fed4@oss.qualcomm.com
>
> Changes in v9:
> 1. Drop the patch: add a new API to retrieve the helper device
> 2. Add a new patch to refactor the tmc_etr_get_catu_device function,
> making it generic to support all types of helper devices associated with ETR.
> 3. Optimizing the code for creating irq_threshold sysfs node.
> 4. Remove interrupt-name property and obtain the IRQ based on the
> in-port number.
> Link to v8: https://lore.kernel.org/r/20251211-enable-byte-cntr-for-ctcu-v8-0-3e12ff313191@oss.qualcomm.com
>
> Changes in V8:
> 1. Optimizing the patch 1 and patch 2 according to Suzuki's comments.
> 2. Combine the patch 3 and patch 4 together.
> 3. Rename the interrupt-name to prevent confusion, for example:etr0->etrirq0.
> Link to V7 - https://lore.kernel.org/all/20251013-enable-byte-cntr-for-ctcu-v7-0-e1e8f41e15dd@oss.qualcomm.com/
>
> Changes in V7:
> 1. rebased on tag next-20251010
> 2. updated info for sysfs node document
> Link to V6 - https://lore.kernel.org/all/20250908-enable-byte-cntr-for-tmc-v6-0-1db9e621441a@oss.qualcomm.com/
>
> Changes in V6:
> 1. rebased on next-20250905.
> 2. fixed the issue that the dtsi file has re-named from sa8775p.dtsi to
> lemans.dtsi.
> 3. fixed some minor issues about comments.
> Link to V5 - https://lore.kernel.org/all/20250812083731.549-1-jie.gan@oss.qualcomm.com/
>
> Changes in V5:
> 1. Add Mike's reviewed-by tag for patchset 1,2,5.
> 2. Remove the function pointer added to helper_ops according to Mike's
> comment, it also results the patchset has been removed.
> 3. Optimizing the paired create/clean functions for etr_buf_list.
> 4. Remove the unneeded parameter "reading" from the etr_buf_node.
> Link to V4 - https://lore.kernel.org/all/20250725100806.1157-1-jie.gan@oss.qualcomm.com/
>
> Changes in V4:
> 1. Rename the function to coresight_get_in_port_dest regarding to Mike's
> comment (patch 1/10).
> 2. Add lock to protect the connections regarding to Mike's comment
> (patch 2/10).
> 3. Move all byte-cntr functions to coresight-ctcu-byte-cntr file.
> 4. Add tmc_read_ops to wrap all read operations for TMC device.
> 5. Add a function in helper_ops to check whether the byte-cntr is
> enabkled.
> 6. Call byte-cntr's read_ops if byte-cntr is enabled when reading data
> from the sysfs node.
> Link to V3 resend - https://lore.kernel.org/all/20250714063109.591-1-jie.gan@oss.qualcomm.com/
>
> Changes in V3 resend:
> 1. rebased on next-20250711.
> Link to V3 - https://lore.kernel.org/all/20250624060438.7469-1-jie.gan@oss.qualcomm.com/
>
> Changes in V3:
> 1. The previous solution has been deprecated.
> 2. Add a etr_buf_list to manage allcated etr buffers.
> 3. Add a logic to switch buffer for ETR.
> 4. Add read functions to read trace data from synced etr buffer.
> Link to V2 - https://lore.kernel.org/all/20250410013330.3609482-1-jie.gan@oss.qualcomm.com/
>
> Changes in V2:
> 1. Removed the independent file node /dev/byte_cntr.
> 2. Integrated the byte-cntr's file operations with current ETR file
> node.
> 3. Optimized the driver code of the CTCU that associated with byte-cntr.
> 4. Add kernel document for the export API tmc_etr_get_rwp_offset.
> 5. Optimized the way to read the rwp_offset according to Mike's
> suggestion.
> 6. Removed the dependency of the dts patch.
> Link to V1 - https://lore.kernel.org/all/20250310090407.2069489-1-quic_jiegan@quicinc.com/
>
> To: Suzuki K Poulose <suzuki.poulose@arm.com>
> To: Mike Leach <mike.leach@arm.com>
> To: James Clark <james.clark@linaro.org>
> To: Alexander Shishkin <alexander.shishkin@linux.intel.com>
> To: Rob Herring <robh@kernel.org>
> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> To: Conor Dooley <conor+dt@kernel.org>
> To: Tingwei Zhang <tingwei.zhang@oss.qualcomm.com>
> To: Bjorn Andersson <andersson@kernel.org>
> To: Konrad Dybcio <konradybcio@kernel.org>
> Cc: coresight@lists.linaro.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-arm-msm@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
>
> ---
> Jie Gan (7):
> coresight: core: refactor ctcu_get_active_port and make it generic
> coresight: tmc: add create/clean functions for etr_buf_list
> coresight: tmc: introduce tmc_sysfs_ops to wrap sysfs read operations
> coresight: etr: add a new function to retrieve the CTCU device
> dt-bindings: arm: add an interrupt property for Coresight CTCU
> coresight: ctcu: enable byte-cntr for TMC ETR devices
> arm64: dts: qcom: lemans: add interrupts to CTCU device
>
> .../ABI/testing/sysfs-bus-coresight-devices-ctcu | 9 +
> .../bindings/arm/qcom,coresight-ctcu.yaml | 10 +
> arch/arm64/boot/dts/qcom/lemans.dtsi | 3 +
> drivers/hwtracing/coresight/Makefile | 2 +-
> drivers/hwtracing/coresight/coresight-core.c | 24 ++
> .../hwtracing/coresight/coresight-ctcu-byte-cntr.c | 286 +++++++++++++++++++++
> drivers/hwtracing/coresight/coresight-ctcu-core.c | 123 +++++++--
> drivers/hwtracing/coresight/coresight-ctcu.h | 79 +++++-
> drivers/hwtracing/coresight/coresight-priv.h | 2 +
> drivers/hwtracing/coresight/coresight-tmc-core.c | 55 ++--
> drivers/hwtracing/coresight/coresight-tmc-etr.c | 226 +++++++++++++++-
> drivers/hwtracing/coresight/coresight-tmc.h | 42 +++
> 12 files changed, 789 insertions(+), 72 deletions(-)
> ---
> base-commit: a0ae2a256046c0c5d3778d1a194ff2e171f16e5f
> change-id: 20260309-enable-byte-cntr-for-ctcu-ff86e6198b7f
>
> Best regards,
^ permalink raw reply
* Re: [PATCH 3/6] drm/msm/adreno: set cx_mmio regardless of if platform has LLCC
From: Konrad Dybcio @ 2026-04-01 8:46 UTC (permalink / raw)
To: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Akhil P Oommen, Bjorn Andersson
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel
In-Reply-To: <20260331-adreno-810-v1-3-725801dbb12b@pm.me>
On 4/1/26 4:17 AM, Alexander Koskovich wrote:
> Platforms without a LLCC (e.g. milos) still need to be able to read and
> write to the cx_mem region. Previously if LLCC slices were unavailable
> the cx_mmio mapping was overwritten with ERR_PTR, causing a crash when
> the GMU later accessed cx_mem.
>
> Move the cx_mmio mapping out of a6xx_llc_slices_init() into
> a6xx_gpu_init() so that cx_mem mapping is independent of LLCC.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/6] drm/msm/adreno: rename llc_mmio to cx_mmio
From: Konrad Dybcio @ 2026-04-01 8:40 UTC (permalink / raw)
To: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Akhil P Oommen, Bjorn Andersson
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel
In-Reply-To: <20260331-adreno-810-v1-2-725801dbb12b@pm.me>
On 4/1/26 4:17 AM, Alexander Koskovich wrote:
> This region is used for more than just LLCC, it also provides access to
> software fuse values (raytracing, etc).
>
> Rename relevant symbols from _llc to _cx for use in a follow up change
> that decouples this from LLCC.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
I think this would be better named 'cx_misc', but maybe Akhil or Rob have
a preference.
(VDD_)CX is name of the power rail that powers most non-multimedia parts
of the SoC and in the Adreno team's lingo that roughly refers to
GPU-adjacent HW that does not need the VDD_GX ("Graphics") rail to be on
CX_MISC is a specific region within the GPUSS
Konrad
^ permalink raw reply
* Re: [PATCH v3 0/6] drm/sun4i: Support LVDS on D1s/T113 combo D-PHY
From: Parthiban @ 2026-04-01 8:39 UTC (permalink / raw)
To: Kuba Szczodrzyński, Maxime Ripard, Samuel Holland,
Chen-Yu Tsai, Jernej Skrabec, Maarten Lankhorst,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: parthiban, David Airlie, Simona Vetter, linux-arm-kernel,
linux-sunxi, linux-kernel, linux-riscv, linux-phy, devicetree,
dri-devel, paulk
In-Reply-To: <a5f6aeb1-b038-462e-8989-c4da65966134@linumiz.com>
Dear Kuba,
On 2/7/26 2:34 PM, Parthiban wrote:
> On 11/16/25 2:46 PM, Kuba Szczodrzyński wrote:
>> Some Allwinner chips (notably the D1s/T113 and the A100) have a "combo
>> MIPI DSI D-PHY" which is required when using single-link LVDS0. The same
>> PD0..PD9 pins are used for either DSI or LVDS.
>>
>> Other than having to use the combo D-PHY, LVDS output is configured in
>> the same way as on older chips.
>>
>> This series enables the sun6i MIPI D-PHY to also work in LVDS mode. It
>> is then configured by the LCD TCON, which allows connecting a
>> single-link LVDS display panel.
Now I also have the MIPI and LVDS working together on A133. Can I pick your
changes and post a combined series for the display support for A133? This will
also address D1s/T114 as well.
--
Thanks,
Parthiban
https://linumiz.com
https://www.linkedin.com/company/linumiz
^ permalink raw reply
* Re: [PATCH v4 3/3] ARM: dts: qcom: msm8960: expressatt: Add camera flash
From: Rudraksha Gupta @ 2026-04-01 8:37 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Linus Walleij, Bjorn Andersson, Konrad Dybcio,
Liam Girdwood, Mark Brown, linux-leds, devicetree, linux-kernel,
linux-arm-msm, phone-devel, David Heidelberg, Konrad Dybcio
In-Reply-To: <3435895a-ffd9-4dd3-b21a-4466791183ca@gmail.com>
Hello Dmitry,
>>> + vreg_flash: regulator-flash {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "VREG_FLASH_3P3";
>>> + regulator-min-microvolt = <3300000>;
>>> + regulator-max-microvolt = <3300000>;
>>> + gpio = <&pm8921_mpps 4 GPIO_ACTIVE_HIGH>;
>>> + enable-active-high;
>>> + pinctrl-0 = <&flash_led_unlock>;
>>> + pinctrl-names = "default";
>>> + };
>>> +
>>> + led-controller {
>> It looks like the nodes are not sorted. Could you please make sure that
>> they are sorted alphanumerically (if there is no node address)?
>
> Thanks for your feedback! Could I request this comment/change be noted
> in
> https://lore.kernel.org/all/20260331-expressatt_fuel_guage-v1-1-23d1d8526b69@gmail.com/
> instead? As this seems to be the only comment remaining, it will be
> easier for me to reorganize the DTS in the fuel gauge patch series
> rather than this one, as the fuel gauge patch series depends on this
> one. It also won't spam others in the mailing list who don't care
> about the reorganization of the DTS.
>
I have made the changes here:
https://lore.kernel.org/all/20260401-expressatt_fuel_guage-v2-1-947922834df1@gmail.com/
> Thanks,
>
> Rudraksha
>
^ permalink raw reply
* Re: [PATCH v5 1/2] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Konrad Dybcio @ 2026-04-01 8:30 UTC (permalink / raw)
To: Richard Acayan
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, linux-arm-msm, devicetree,
linux-pm
In-Reply-To: <acwH6N56W_ULNe2q@rdacayan>
On 3/31/26 7:44 PM, Richard Acayan wrote:
> On Tue, Mar 31, 2026 at 10:30:29AM +0200, Konrad Dybcio wrote:
>> On 3/30/26 6:52 PM, Richard Acayan wrote:
>>> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
>>> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
>>> the first 6 CPUs are in the little cluster and the next 2 are in the big
>>> cluster. Define the clusters in the match data and define the different
>>> cluster configuration for SDM670.
>>>
>>> Currently, this tolerates linking to any CPU in a given cluster.
>>>
>>> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
>>> ---
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>>
>> [...]
>>> + if (cpu_id < 0) {
>>> + dev_err(dev, "Wrong CPU id associated with LMh node\n");
>>> + return -EINVAL;
>>> + }
>>
>> nit: try to use 'return dev_err_probe(dev, ret, "....") in the future
>
> Does "in the future" apply to the inevitable next revision? This would
> be the first occurrence of dev_err_probe in this driver and the error
> path was just cut-and-paste.
Not necessarily, 'in the future' meaning 'in your future patches'
Konrad
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: qcom: msm8960: expressatt: Add MAX17048 fuel gauge
From: Rudraksha Gupta via B4 Relay @ 2026-04-01 8:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Rudraksha Gupta
In-Reply-To: <20260401-expressatt_fuel_guage-v2-0-947922834df1@gmail.com>
From: Rudraksha Gupta <guptarud@gmail.com>
Add MAX17048 fuel gauge support.
Tested by comparing battery capacity readings between upstream (mainline
max17040 driver) and downstream (Samsung max17048_fuelgauge driver)
across a full discharge cycle. Upstream reads ~3% lower throughout. Both
track the discharge curve correctly:
Upstream: 95 92 88 87 86 87 83 82 80 68 60 55 50 45 40 35 30 20 16 10 10 5 5 1
Downstream: 95 94 92 91 91 89 87 86 84 73 64 59 51 48 43 38 33 23 17 14 12 8 6 3
Each pair of readings was collected by checking the upstream capacity
first, then moving the battery to a second expressatt running downstream
Android to check its capacity. The battery was then moved back to the
upstream device for the next reading. This swap occasionally caused the
upstream capacity to read slightly higher than the previous value
(e.g. 86 -> 87). When this happened, the reading was retaken after the
value settled.
Link: https://github.com/LineageOS/android_kernel_samsung_d2/blob/stable/cm-11.0-XNG3C/arch/arm/mach-msm/board-apexq-battery.c
Link: https://github.com/LineageOS/android_kernel_samsung_d2/blob/stable/cm-11.0-XNG3C/drivers/battery/Makefile#L5
Link: https://github.com/LineageOS/android_kernel_samsung_d2/blob/stable/cm-11.0-XNG3C/arch/arm/mach-msm/Makefile#L308
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
.../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 24 ++++++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960-samsung-expressatt.dts b/arch/arm/boot/dts/qcom/qcom-msm8960-samsung-expressatt.dts
index ed913ca5b825..bc976008ae45 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960-samsung-expressatt.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960-samsung-expressatt.dts
@@ -182,6 +182,23 @@ &gsbi5_serial {
status = "okay";
};
+&gsbi5_i2c {
+ status = "okay";
+
+ fuel-gauge@36 {
+ compatible = "maxim,max17048";
+ reg = <0x36>;
+ maxim,double-soc;
+ maxim,rcomp = /bits/ 8 <0x62>;
+ maxim,alert-low-soc-level = <2>;
+ interrupt-parent = <&tlmm>;
+ interrupts = <67 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-0 = <&fuelgauge_alert_pin>;
+ pinctrl-names = "default";
+ wakeup-source;
+ };
+};
+
&gsbi7 {
qcom,mode = <GSBI_PROT_I2C>;
@@ -582,6 +599,13 @@ touchkey_irq_pin: touchkey-irq-state {
bias-disable;
};
+ fuelgauge_alert_pin: fuelgauge-alert-state {
+ pins = "gpio67";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
touchkey_i2c_pins: touchkey-i2c-state {
pins = "gpio71", "gpio72";
function = "gpio";
--
2.53.0
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: qcom: msm8960: Add GSBI5 I2C controller
From: Rudraksha Gupta via B4 Relay @ 2026-04-01 8:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Rudraksha Gupta
In-Reply-To: <20260401-expressatt_fuel_guage-v2-0-947922834df1@gmail.com>
From: Rudraksha Gupta <guptarud@gmail.com>
Add the I2C controller node for GSBI5 (gpio24/gpio25) alongside
its pinctrl default and sleep states.
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 35 ++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
index fd28401cebb5..2088baef6c30 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960.dtsi
@@ -185,6 +185,24 @@ i2c3-pins {
};
};
+ i2c5_default_state: i2c5-default-state {
+ i2c5-pins {
+ pins = "gpio24", "gpio25";
+ function = "gsbi5";
+ drive-strength = <8>;
+ bias-disable;
+ };
+ };
+
+ i2c5_sleep_state: i2c5-sleep-state {
+ i2c5-pins {
+ pins = "gpio24", "gpio25";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-bus-hold;
+ };
+ };
+
i2c7_default_state: i2c7-default-state {
i2c7-pins {
pins = "gpio32", "gpio33";
@@ -664,6 +682,23 @@ gsbi5_serial: serial@16440000 {
status = "disabled";
};
+
+ gsbi5_i2c: i2c@16480000 {
+ compatible = "qcom,i2c-qup-v1.1.1";
+ reg = <0x16480000 0x1000>;
+ pinctrl-0 = <&i2c5_default_state>;
+ pinctrl-1 = <&i2c5_sleep_state>;
+ pinctrl-names = "default", "sleep";
+ interrupts = <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&gcc GSBI5_QUP_CLK>,
+ <&gcc GSBI5_H_CLK>;
+ clock-names = "core",
+ "iface";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ status = "disabled";
+ };
};
gsbi7: gsbi@16600000 {
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/3] Reorganize DTS and add fuel-gauge to samsung-expressatt
From: Rudraksha Gupta via B4 Relay @ 2026-04-01 8:28 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Rudraksha Gupta
Reorganized the samsung-expressatt DTS to be more in line with mainline
standards.
Tested battery by doing `cat /sys/class/power_supply/battery/capacity`
in upstream Linux and comparing the value with downstream Linux. Booted
on upstream Linux first, as the upstream Linux seems to use a lot
more battery than downstream, and then put the battery into another
expressatt running downstream Android to compare values. There are
some slight differences, but overall seems to line up pretty well with
downstream.
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
Changes in v2:
- Previous changes were based on some outdated dependencies. Update them
- Reorganized expressatt DTS
- Switch to GSBI5
- Link to v1: https://lore.kernel.org/r/20260331-expressatt_fuel_guage-v1-1-23d1d8526b69@gmail.com
---
Rudraksha Gupta (3):
ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
ARM: dts: qcom: msm8960: Add GSBI5 I2C controller
ARM: dts: qcom: msm8960: expressatt: Add MAX17048 fuel gauge
.../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 420 +++++++++++----------
arch/arm/boot/dts/qcom/qcom-msm8960.dtsi | 35 ++
2 files changed, 257 insertions(+), 198 deletions(-)
---
base-commit: e9ec05addd1a067fc7cb218f20ecdc1b1b0898c0
change-id: 20260331-expressatt_fuel_guage-465dfb3f87ab
prerequisite-patch-id: 6fdd0efa5eda512b442b885df80774d1a7037df7
prerequisite-patch-id: 12d296f83ccb1bdfb8d06a72e476bf51ae5f4e6c
prerequisite-patch-id: a970acf2080143f41ae0935dd2c57bb71f5bf338
prerequisite-patch-id: fd25fef58503c5e5cf742e79b124948c7f6b98d9
prerequisite-patch-id: 68603a680b24921759425fc289e61fc4435e5ccd
prerequisite-message-id: <20251205-expressatt-touchkey-v1-1-1444b927c9f3@gmail.com>
prerequisite-patch-id: 8de4de7909722ccaf385c4224f25a623eaa72c28
prerequisite-message-id: <20260331-expressatt_camera_flash-v4-0-f1e99f474513@gmail.com>
prerequisite-patch-id: ab8b8d87fd2d518c4c5b5dace3f22238d1abbe49
prerequisite-patch-id: 47e32e653e520a27770bb05d99135694b0128ba0
prerequisite-patch-id: 7ef7df61e7ef6476a35811d765f522f793d9ecc7
Best regards,
--
Rudraksha Gupta <guptarud@gmail.com>
^ permalink raw reply
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