* Re: [PATCH v2 2/2] hwmon: (pmbus/q54sj108a2) Add support for q50sn12072 and q54sn120a1
From: Brian Chiang @ 2026-04-01 7:38 UTC (permalink / raw)
To: Guenter Roeck
Cc: Cheng.JackHY, chiang.brian, conor+dt, devicetree, krzk+dt,
linux-hwmon, linux-kernel, robh
In-Reply-To: <79e3b8f1-f8ba-41af-96d4-b9a1b84ef810@roeck-us.net>
On Thu, Mar 26, 2026 at 09:29:38AM -0700, Guenter Roeck wrote:
>On Thu, Mar 26, 2026 at 01:48:06PM +0000, Brian Chiang wrote:
>> From: Jack Cheng <cheng.jackhy@inventec.com>
>>
>> The Q50SN12072 and Q54SN120A1 are high-efficiency, high-density DC-DC power
>> module from Delta Power Modules.
>>
>> The Q50SN12072, quarter brick, single output 12V. This product provides up
>> to 1200 watts of output power at 38~60V. The Q50SN12072 offers peak
>> efficiency up to 98.3%@54Vin.
>>
>> The Q54SN120A1, quarter brick, single output 12V. This product provides up
>> to 1300 watts of output power at 40~60V. The Q54SN120A1 offers peak
>> efficiency up to 98.1%@54Vin.
>>
>> Add support for them to q54sj108a2 driver.
>>
>> Signed-off-by: Jack Cheng <cheng.jackhy@inventec.com>
>> Co-developed-by: Brian Chiang <chiang.brian@inventec.com>
>> Signed-off-by: Brian Chiang <chiang.brian@inventec.com>
>> ---
>> drivers/hwmon/pmbus/q54sj108a2.c | 97 ++++++++++++++++++++++++++++------------
>> 1 file changed, 68 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/hwmon/pmbus/q54sj108a2.c b/drivers/hwmon/pmbus/q54sj108a2.c
>> index d5d60a9af8c5..cc2b32ad935c 100644
>> --- a/drivers/hwmon/pmbus/q54sj108a2.c
>> +++ b/drivers/hwmon/pmbus/q54sj108a2.c
>> @@ -22,7 +22,9 @@
>> #define PMBUS_FLASH_KEY_WRITE 0xEC
>>
>> enum chips {
>> - q54sj108a2
>> + q50sn12072,
>> + q54sj108a2,
>> + q54sn120a1
>> };
>>
>> enum {
>> @@ -55,10 +57,24 @@ struct q54sj108a2_data {
>> #define to_psu(x, y) container_of((x), struct q54sj108a2_data, debugfs_entries[(y)])
>>
>> static struct pmbus_driver_info q54sj108a2_info[] = {
>> - [q54sj108a2] = {
>> + [q50sn12072] = {
>> .pages = 1,
>> + /* Source : Delta Q50SN12072 */
>> + .format[PSC_VOLTAGE_OUT] = linear,
>> + .format[PSC_TEMPERATURE] = linear,
>> + .format[PSC_VOLTAGE_IN] = linear,
>> + .format[PSC_CURRENT_OUT] = linear,
>>
>> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_PIN |
>> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
>> + PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
>> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
>> + PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_POUT,
>> + },
>> + [q54sj108a2] = {
>> + .pages = 1,
>> /* Source : Delta Q54SJ108A2 */
>> + .format[PSC_VOLTAGE_OUT] = linear,
>> .format[PSC_TEMPERATURE] = linear,
>> .format[PSC_VOLTAGE_IN] = linear,
>> .format[PSC_CURRENT_OUT] = linear,
>> @@ -69,6 +85,20 @@ static struct pmbus_driver_info q54sj108a2_info[] = {
>> PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
>> PMBUS_HAVE_STATUS_INPUT,
>> },
>> + [q54sn120a1] = {
>> + .pages = 1,
>> + /* Source : Delta Q54SN120A1 */
>> + .format[PSC_VOLTAGE_OUT] = linear,
>> + .format[PSC_TEMPERATURE] = linear,
>> + .format[PSC_VOLTAGE_IN] = linear,
>> + .format[PSC_CURRENT_OUT] = linear,
>> +
>> + .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_IIN | PMBUS_HAVE_PIN |
>> + PMBUS_HAVE_VOUT | PMBUS_HAVE_STATUS_VOUT |
>> + PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
>> + PMBUS_HAVE_TEMP | PMBUS_HAVE_STATUS_TEMP |
>> + PMBUS_HAVE_STATUS_INPUT | PMBUS_HAVE_POUT,
>> + },
>> };
>>
>> static ssize_t q54sj108a2_debugfs_read(struct file *file, char __user *buf,
>> @@ -270,7 +300,9 @@ static const struct file_operations q54sj108a2_fops = {
>> };
>>
>> static const struct i2c_device_id q54sj108a2_id[] = {
>> + { "q50sn12072", q50sn12072 },
>> { "q54sj108a2", q54sj108a2 },
>> + { "q54sn120a1", q54sn120a1 },
>> { },
>> };
>>
>> @@ -280,6 +312,7 @@ static int q54sj108a2_probe(struct i2c_client *client)
>> {
>> struct device *dev = &client->dev;
>> u8 buf[I2C_SMBUS_BLOCK_MAX + 1];
>> + const struct i2c_device_id *mid;
>> enum chips chip_id;
>> int ret, i;
>> struct dentry *debugfs;
>> @@ -292,14 +325,9 @@ static int q54sj108a2_probe(struct i2c_client *client)
>> I2C_FUNC_SMBUS_BLOCK_DATA))
>> return -ENODEV;
>>
>> - if (client->dev.of_node)
>> - chip_id = (enum chips)(unsigned long)of_device_get_match_data(dev);
>> - else
>> - chip_id = i2c_match_id(q54sj108a2_id, client)->driver_data;
>> -
>> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_ID, buf);
>> if (ret < 0) {
>> - dev_err(&client->dev, "Failed to read Manufacturer ID\n");
>> + dev_err(dev, "Failed to read Manufacturer ID\n");
>> return ret;
>> }
>> if (ret != 6 || strncmp(buf, "DELTA", 5)) {
>> @@ -308,19 +336,25 @@ static int q54sj108a2_probe(struct i2c_client *client)
>> return -ENODEV;
>> }
>>
>> - /*
>> - * The chips support reading PMBUS_MFR_MODEL.
>> - */
>> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_MODEL, buf);
>> if (ret < 0) {
>> dev_err(dev, "Failed to read Manufacturer Model\n");
>> return ret;
>> }
>> - if (ret != 14 || strncmp(buf, "Q54SJ108A2", 10)) {
>> + for (mid = q54sj108a2_id; mid->name[0]; mid++) {
>> + if (ret == strlen(mid->name) && !strncasecmp(mid->name, buf, ret))
>> + break;
>> + }
>> + if (!mid->name[0]) {
>> buf[ret] = '\0';
>> dev_err(dev, "Unsupported Manufacturer Model '%s'\n", buf);
>> return -ENODEV;
>> }
>
>>From Sashiko feedback:
>
>In the original driver, the PMBUS_MFR_MODEL response length was explicitly
>expected to be 14 bytes (if (ret != 14 || strncmp(buf, "Q54SJ108A2", 10))),
>indicating the hardware returns the 10-character name padded with 4 extra
>bytes. The patch changes the detection logic to loop through supported
>devices and strictly require the returned length to match the device name's
>length exactly (`ret == strlen(mid->name)`). Since `ret` will be 14 for the
>original hardware, and strlen("q54sj108a2") is 10, the condition 14 == 10
>evaluates to false. This causes the loop to exit without matching,
>erroneously printing 'Unsupported Manufacturer Model' and returning -ENODEV.
>This completely breaks driver probing and hardware monitoring for the
>pre-existing Q54SJ108A2 device."
Thank you for the explanation. Maybe we should simply match the manufacturer
model and remove the strict length comparison to prevent it from breaking
the driver probing. I will add this change in v3.
>
>> + chip_id = mid->driver_data;
>> +
>> + if (strcmp(client->name, mid->name) != 0)
>> + dev_notice(dev, "Device mismatch: Configured %s, detected %s\n",
>> + client->name, mid->name);
>>
>> ret = i2c_smbus_read_block_data(client, PMBUS_MFR_REVISION, buf);
>> if (ret < 0) {
>> @@ -341,6 +375,7 @@ static int q54sj108a2_probe(struct i2c_client *client)
>> if (!psu)
>> return 0;
>>
>> + psu->chip = chip_id;
>> psu->client = client;
>>
>> debugfs = pmbus_get_debugfs_dir(client);
>> @@ -359,9 +394,6 @@ static int q54sj108a2_probe(struct i2c_client *client)
>> debugfs_create_file("write_protect", 0444, q54sj108a2_dir,
>> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_WRITEPROTECT],
>> &q54sj108a2_fops);
>> - debugfs_create_file("store_default", 0200, q54sj108a2_dir,
>> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_STOREDEFAULT],
>> - &q54sj108a2_fops);
>> debugfs_create_file("vo_ov_response", 0644, q54sj108a2_dir,
>> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_VOOV_RESPONSE],
>> &q54sj108a2_fops);
>> @@ -383,27 +415,34 @@ static int q54sj108a2_probe(struct i2c_client *client)
>> debugfs_create_file("mfr_location", 0444, q54sj108a2_dir,
>> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_MFR_LOCATION],
>> &q54sj108a2_fops);
>> - debugfs_create_file("blackbox_erase", 0200, q54sj108a2_dir,
>> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_ERASE],
>> - &q54sj108a2_fops);
>> debugfs_create_file("blackbox_read_offset", 0444, q54sj108a2_dir,
>> &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ_OFFSET],
>> &q54sj108a2_fops);
>
>What is the purpose/value of keeping this file outside the if() block ?
Thank you for catching this. It was an oversight in v2, the
`blackbox_read_offset` should have been kept inside of the block.
I'll add this change in v3.
>
>> - debugfs_create_file("blackbox_set_offset", 0200, q54sj108a2_dir,
>> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_SET_OFFSET],
>> - &q54sj108a2_fops);
>> - debugfs_create_file("blackbox_read", 0444, q54sj108a2_dir,
>> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ],
>> - &q54sj108a2_fops);
>> - debugfs_create_file("flash_key", 0444, q54sj108a2_dir,
>> - &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_FLASH_KEY],
>> - &q54sj108a2_fops);
>> + if (psu->chip == q54sj108a2) {
>> + debugfs_create_file("store_default", 0200, q54sj108a2_dir,
>> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_STOREDEFAULT],
>> + &q54sj108a2_fops);
>> + debugfs_create_file("blackbox_erase", 0200, q54sj108a2_dir,
>> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_ERASE],
>> + &q54sj108a2_fops);
>> + debugfs_create_file("blackbox_set_offset", 0200, q54sj108a2_dir,
>> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_SET_OFFSET],
>> + &q54sj108a2_fops);
>> + debugfs_create_file("blackbox_read", 0444, q54sj108a2_dir,
>> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_BLACKBOX_READ],
>> + &q54sj108a2_fops);
>> + debugfs_create_file("flash_key", 0444, q54sj108a2_dir,
>> + &psu->debugfs_entries[Q54SJ108A2_DEBUGFS_FLASH_KEY],
>> + &q54sj108a2_fops);
>> + }
>>
>> return 0;
>> }
>>
>> static const struct of_device_id q54sj108a2_of_match[] = {
>> - { .compatible = "delta,q54sj108a2", .data = (void *)q54sj108a2 },
>> + { .compatible = "delta,q50sn12072" },
>> + { .compatible = "delta,q54sj108a2" },
>> + { .compatible = "delta,q54sn120a1" },
>
>Why drop .data here ?
I would like to drop .data since it was previously consumed by
`of_device_get_match_data()`, which has been removed in v2 changes.
>
>Thanks,
>Guenter
>
>> { },
>> };
>>
>> @@ -421,6 +460,6 @@ static struct i2c_driver q54sj108a2_driver = {
>> module_i2c_driver(q54sj108a2_driver);
>>
>> MODULE_AUTHOR("Xiao.Ma <xiao.mx.ma@deltaww.com>");
>> -MODULE_DESCRIPTION("PMBus driver for Delta Q54SJ108A2 series modules");
>> +MODULE_DESCRIPTION("PMBus driver for Delta Q54SJ108A2 and compatibles");
>> MODULE_LICENSE("GPL");
>> MODULE_IMPORT_NS("PMBUS");
>>
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH v1 2/2] riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
From: 曹珊珊 @ 2026-04-01 7:38 UTC (permalink / raw)
To: Troy Mitchell
Cc: Yixun Lan, Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Troy Mitchell, Michael Opdenacker,
Guodong Xu, Hendrik Hamerlinck, Yangyu Chen, spacemit,
linux-riscv, devicetree, linux-kernel
In-Reply-To: <DHHM43F6TE9I.1F5A3O0VOS6ND@linux.spacemit.com>
Hi Troy,
> From: "Troy Mitchell"<troy.mitchell@linux.spacemit.com>
> Date: Wed, Apr 1, 2026, 14:42
> On Wed Apr 1, 2026 at 2:10 PM CST, 曹珊珊 wrote:
> > Hi Lan,
> >
> >> From: "Yixun Lan"<dlan@kernel.org>
> >> Hi Sandie,
> >>
> >> On 11:46 Tue 31 Mar , Sandie Cao wrote:
> >> > From: sandiecao <sandie.cao@deepcomputing.io>
> >> >
> >> > The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
> >> > SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
> >> > which has (Framework) SKU FRANHQ0001.
> >> >
> >> > The FML13V05 board features:
> >> > - SpacemiT K3 RISC-V SoC
> >> > - LPDDR5 16GB or 32GB
> >> > - eMMC 32GB ~128GB (Optional)
> >> > - UFS 3.1 256G (Optional)
> >> > - QSPI Flash
> >> > - MicroSD Slot
> >> > - PCIe-based Wi-Fi
> >> > - 4 USB-C Ports
> >> > - Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
> >> > - Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
> >> > - Port 3 & 4: USB 3.2 Gen 1
> >> >
> >> > This minimal device tree enables booting into a serial console with UART
> >> > output.
> >> >
> >> > Signed-off-by: sandiecao <sandie.cao@deepcomputing.io>
> >> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> >> > +&uart0 {
> >> Can you also add pinctrl data explicitly?
> >
> > To avoid conflict, the common pinctrl table "k3-pinctrl.dtsi" should be uploaded by spacemit.
> > Then we will add the pinctrl data after k3-pico-itx.dts. That should be another patch.
> > Sandie
> I think you don't understand what Yixun said.
> You should add pinctrl properties here like:
> pinctrl-0 = xxx;
> pinctrl-names = "default";
>
> While the bootloader is expected to initialize the UART pins, explicitly adding the pinctrl properties
> ensures hardware state consistency.
>
> - Troy
>
Yes, I know this.
If I add
pinctrl-names = "default";
pinctrl-0 = <&uart0_0_cfg>;
Then also need to add
&pinctrl {
uart0_0_cfg: uart0-0-cfg {
uart0-0-pins {
pinmux = <K3_PADCONF(149, 2)>, /* uart0 tx */
<K3_PADCONF(150, 2)>; /* uart0 rx */
bias-pull-up; /* normal pull-up */
drive-strength = <25>; /* DS8 */
};
};
};
But this part is common, it should be defined in common pinctrl table "k3-pinctrl.dtsi". And this part hasn't comed to Upstream.
If I add it currently, When k3-pinctrl.dtsi is accepted by Upstream, we need to remove it again.
So we just empty it for simple.
Sandie
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Krzysztof Kozlowski @ 2026-04-01 7:40 UTC (permalink / raw)
To: Guangliu Ding
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, devicetree,
linux-kernel, imx, linux-arm-kernel, Jiyu Yang
In-Reply-To: <20260331-master-v1-1-65c8e318d462@nxp.com>
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.
>
> 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?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: reset: imx8mq: Add _N suffix to IMX8MQ_RESET_MIPI_CSI*_RESET
From: Krzysztof Kozlowski @ 2026-04-01 7:41 UTC (permalink / raw)
To: Robby Cai
Cc: p.zabel, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam,
devicetree, kernel, imx, linux-arm-kernel, linux-kernel,
aisheng.dong
In-Reply-To: <20260331101331.1405588-2-robby.cai@nxp.com>
On Tue, Mar 31, 2026 at 06:13:30PM +0800, Robby Cai wrote:
> The assert logic of the MIPI CSI reset signals is active-low on i.MX8MQ,
> but the existing names do not indicate this explicitly. To improve
> consistency and clarity, append the _N suffix to all
> IMX8MQ_RESET_MIPI_CSI*_RESET definitions. The deprecated
> IMX8MQ_RESET_MIPI_CSI*_RESET versions remain temporarily for DT ABI
> compatibility and will be removed at an appropriate time in the future.
>
> Signed-off-by: Robby Cai <robby.cai@nxp.com>
> ---
> include/dt-bindings/reset/imx8mq-reset.h | 18 ++++++++++++------
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/include/dt-bindings/reset/imx8mq-reset.h b/include/dt-bindings/reset/imx8mq-reset.h
> index 705870693ec2..83a155dbbd4a 100644
> --- a/include/dt-bindings/reset/imx8mq-reset.h
> +++ b/include/dt-bindings/reset/imx8mq-reset.h
> @@ -46,12 +46,18 @@
> #define IMX8MQ_RESET_PCIEPHY2_PERST 35 /* i.MX8MM/i.MX8MN does NOT support */
> #define IMX8MQ_RESET_PCIE2_CTRL_APPS_EN 36 /* i.MX8MM/i.MX8MN does NOT support */
> #define IMX8MQ_RESET_PCIE2_CTRL_APPS_TURNOFF 37 /* i.MX8MM/i.MX8MN does NOT support */
> -#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET 38 /* i.MX8MM/i.MX8MN does NOT support */
> -#define IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET 39 /* i.MX8MM/i.MX8MN does NOT support */
> -#define IMX8MQ_RESET_MIPI_CSI1_ESC_RESET 40 /* i.MX8MM/i.MX8MN does NOT support */
> -#define IMX8MQ_RESET_MIPI_CSI2_CORE_RESET 41 /* i.MX8MM/i.MX8MN does NOT support */
> -#define IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET 42 /* i.MX8MM/i.MX8MN does NOT support */
> -#define IMX8MQ_RESET_MIPI_CSI2_ESC_RESET 43 /* i.MX8MM/i.MX8MN does NOT support */
> +#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET 38 /* Deprecated. Use *_RESET_N instead */
> +#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET_N 38 /* i.MX8MM/i.MX8MN does NOT support */
That's quite a churn for no need. The entire point of these values being
the binding is that it describes the ABI for SW and DTS, not your
hardware registers.
Whether signal is active low or high is kind of irrelevant. Linux uses
it exactly the same way.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v9 00/21] media: i2c: add Maxim GMSL2/3 serializer and deserializer drivers
From: Tomi Valkeinen @ 2026-04-01 7:46 UTC (permalink / raw)
To: Tomi Valkeinen, Ceclan Dumitru, Sakari Ailus, dumitru.ceclan
Cc: Mauro Carvalho Chehab, Laurent Pinchart, Julien Massot,
Rob Herring, Niklas Söderlund, Greg Kroah-Hartman,
Cosmin Tanislav, linux-media, linux-kernel, devicetree,
linux-staging, linux-gpio, Niklas Söderlund, Martin Hecht,
Cosmin Tanislav, Cory Keitz
In-Reply-To: <8e924699-e0ab-4e39-a1d1-b218d749672f@ideasonboard.com>
On 01/04/2026 09:47, Tomi Valkeinen wrote:
> Hi,
>
> On 30/03/2026 10:15, Ceclan Dumitru wrote:
>>
>>
>> On 3/11/26 9:58 AM, Sakari Ailus wrote:
>>> Hi Dumitru,
>>>
>>> On Wed, Mar 11, 2026 at 09:17:12AM +0200, Dumitru Ceclan via B4 Relay wrote:
>>
>> ...
>>
>>>
>>> ...
>>>
>>>> The following v4l2-compliance test still fails:
>>>> fail: v4l2-test-subdevs.cpp(371): fmt.code == 0 || fmt.code == ~0U
>>>> fail: v4l2-test-subdevs.cpp(418): checkMBusFrameFmt(node, fmt.format)
>>>> test Active VIDIOC_SUBDEV_G/S_FMT: FAIL
>>>
>>> Could you post the full report here, please?
>>>
> So why do these failures happen? It wasn't obvious to me from the full
> report either.
I made a quick test with FPD-Link, and I see something similar. It's
caused (for fpdlink, at least) by the serializer accepting any format,
as it's a pass-through device.
As a hack test, can you try adding something like this to the set_fmt op:
if (format->format.code == ~0)
format->format.code = MEDIA_BUS_FMT_UYVY8_1X16;
If all the compliance errors go away, then it's the same case for you.
Tomi
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: gpio: realtek: Add realtek,rtd1625-gpio
From: Krzysztof Kozlowski @ 2026-04-01 7:47 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, tychang,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai
In-Reply-To: <20260331113835.3510341-2-eleanor.lin@realtek.com>
On Tue, Mar 31, 2026 at 07:38:33PM +0800, Yu-Chun Lin wrote:
> + reg:
> + items:
> + - description: GPIO controller registers
> + - description: GPIO interrupt registers
> +
> + interrupts:
> + items:
> + - description: Interrupt number of the assert GPIO interrupt, which is
> + triggered when there is a rising edge.
> + - description: Interrupt number of the deassert GPIO interrupt, which is
> + triggered when there is a falling edge.
> + - description: Interrupt number of the level-sensitive GPIO interrupt,
> + triggered by a configured logic level.
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> + const: 2
> +
> + gpio-ranges: true
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> + const: 2
> +
> +required:
> + - compatible
> + - reg
> + - gpio-ranges
> + - gpio-controller
> + - "#gpio-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + gpio@89120 {
> + compatible = "realtek,rtd1625-isom-gpio";
> + reg = <0x89120 0x10>,
0x10 feels very short range.
> + <0x89100 0x20>;
And this means it's continuous. Are you sure these are two separate
address spaces?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: realtek: Add GPIO support for RTD1625
From: Krzysztof Kozlowski @ 2026-04-01 7:49 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, tychang,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-realtek-soc, cy.huang, stanley_chang, james.tai
In-Reply-To: <20260331113835.3510341-3-eleanor.lin@realtek.com>
On Tue, Mar 31, 2026 at 07:38:34PM +0800, Yu-Chun Lin wrote:
> Add the GPIO node for the Realtek RTD1625 SoC.
>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
> arch/arm64/boot/dts/realtek/kent.dtsi | 43 ++++++++++++++++++++++++
> arch/arm64/boot/dts/realtek/rtd1501.dtsi | 8 +++++
> arch/arm64/boot/dts/realtek/rtd1861.dtsi | 8 +++++
> arch/arm64/boot/dts/realtek/rtd1920.dtsi | 8 +++++
> 4 files changed, 67 insertions(+)
>
Why the DTS is in the middle? Drivers cannot depend on it. Please read
submitting patches (both documents).
> diff --git a/arch/arm64/boot/dts/realtek/kent.dtsi b/arch/arm64/boot/dts/realtek/kent.dtsi
> index 8d4293cd4c03..746932c26724 100644
> --- a/arch/arm64/boot/dts/realtek/kent.dtsi
> +++ b/arch/arm64/boot/dts/realtek/kent.dtsi
> @@ -151,6 +151,39 @@ uart0: serial@7800 {
> status = "disabled";
> };
>
> + gpio: gpio@31100 {
> + compatible = "realtek,rtd1625-iso-gpio";
> + reg = <0x31100 0x398>,
> + <0x31000 0x100>;
> + gpio-controller;
> + gpio-ranges = <&isom_pinctrl 0 0 2>,
> + <&ve4_pinctrl 2 0 6>,
> + <&iso_pinctrl 8 0 4>,
> + <&ve4_pinctrl 12 6 2>,
> + <&main2_pinctrl 14 0 2>,
> + <&ve4_pinctrl 16 8 4>,
> + <&main2_pinctrl 20 2 3>,
> + <&ve4_pinctrl 23 12 3>,
> + <&iso_pinctrl 26 4 2>,
> + <&isom_pinctrl 28 2 2>,
> + <&ve4_pinctrl 30 15 6>,
> + <&main2_pinctrl 36 5 6>,
> + <&ve4_pinctrl 42 21 3>,
> + <&iso_pinctrl 45 6 6>,
> + <&ve4_pinctrl 51 24 1>,
> + <&iso_pinctrl 52 12 1>,
> + <&ve4_pinctrl 53 25 11>,
> + <&main2_pinctrl 64 11 28>,
> + <&ve4_pinctrl 92 36 2>,
> + <&iso_pinctrl 94 13 19>,
> + <&iso_pinctrl 128 32 4>,
> + <&ve4_pinctrl 132 38 13>,
> + <&iso_pinctrl 145 36 19>,
> + <&ve4_pinctrl 164 51 2>;
> + #gpio-cells = <2>;
> + status = "disabled";
Why is it disabled? What is missing in the SoC? Which resources are
missing?
> + };
> +
> iso_pinctrl: pinctrl@4e000 {
> compatible = "realtek,rtd1625-iso-pinctrl";
> reg = <0x4e000 0x1a4>;
> @@ -161,6 +194,16 @@ main2_pinctrl: pinctrl@4f200 {
> reg = <0x4f200 0x50>;
> };
>
> + iso_m_gpio: gpio@89120 {
> + compatible = "realtek,rtd1625-isom-gpio";
> + reg = <0x89120 0x10>,
> + <0x89100 0x20>;
> + gpio-controller;
> + gpio-ranges = <&isom_pinctrl 0 0 4>;
> + #gpio-cells = <2>;
> + status = "disabled";
> + };
> +
> isom_pinctrl: pinctrl@146200 {
> compatible = "realtek,rtd1625-isom-pinctrl";
> reg = <0x146200 0x34>;
> diff --git a/arch/arm64/boot/dts/realtek/rtd1501.dtsi b/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> index 65f7ede3df73..ae246a01f126 100644
> --- a/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> +++ b/arch/arm64/boot/dts/realtek/rtd1501.dtsi
> @@ -10,3 +10,11 @@
> &uart0 {
> status = "okay";
> };
> +
> +&gpio {
Why aren't you following DTS coding style? What style is applicable for
Realtek?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: nvmem: qfprom: Add glymur compatible
From: Krzysztof Kozlowski @ 2026-04-01 7:49 UTC (permalink / raw)
To: Pankaj Patil
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <20260331-glymur-qfprom-v1-1-5b4284d23c80@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 07:24:20PM +0530, Pankaj Patil wrote:
> Document compatible string for the QFPROM on Glymur platform.
>
> Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/nvmem/qcom,qfprom.yaml | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 7/8] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Luca Ceresoli @ 2026-04-01 7:51 UTC (permalink / raw)
To: Liu Ying, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Kory Maincent (TI.com), Hervé Codina, Hui Pu, Ian Ray,
Thomas Petazzoni, dri-devel, imx, linux-arm-kernel, linux-kernel,
devicetree, Adam Ford, Alexander Stein, Anson Huang,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Joao Paulo Goncalves,
Josua Mayer, Kieran Bingham, Marco Felsch, Martyn Welch,
Oleksij Rempel, Peng Fan, Philippe Schenker, Richard Hu,
Shengjiu Wang, Stefan Eichenberger, Vitor Soares
In-Reply-To: <246ca728-1be6-4dd9-b228-7d99f28e1abe@nxp.com>
Hello Liu,
On Wed Apr 1, 2026 at 8:45 AM CEST, Liu Ying wrote:
>>>>>> Boards with a different connector should describe the connector in the
>>>>>> device tree, if they need to instantiate the exact type.
>>>>
>>>> I think this is the only valid solution. It's very easy to do, nothing new
>>>> to invent.
>>>>
>>>> Maybe on top of that we could add a warning when the overlay is applied,
>>>> e.g. "imx8mp-hdmi-tx used without a connector described in device tree;
>>>> adding a type A connector as a fallback; please add a valid description to
>>>> your device tree".
>>>
>>> I'd say this doesn't sound a bad idea but I hope the message is clear and
>>> short.
>>
>> What about:
>>
>> Connector description not found in device tree, please add one. Falling back to Type A.
>
> Maybe:
> Please add a hdmi-connector DT node for imx8mp-hdmi-tx. A fixup node in type a is added for now.
>
>>
>>>> Maybe pointing to a TODO entry in the documentation.
>>>
>>> To parameterize the HDMI connector type? If so, I'm okay with that.
>>
>> I was meaning a TODO entry to suggest people to add a connector description
>> to the dts. E.g., expanding on the above suggested warning:
>>
>> Connector description not found in device tree, please add one. See https://docs.kernel.org/gpu/todo.html#<...>
>>
>> And of course adding a TODO entry describing what one needs to do (add an
>> hdmi-connector node and link it to port@1 of the hdmi-tx).
>>
>> The drawback of the TODO is that items in todo.rst are supposed to be
>> removed eventually when done in the code, but this one cannot be removed
>> until some kernels printing the above logging message will be around,
>> i.e. potentially for decades.
>
> Not a big fan of adding a TODO entry, because those DT blobs without a
> hdmi-connector node could be out there forever, meaning the added TODO
> entry can never be removed.
>
>>
>> So maybe the simplest solution is just the first warning message + a
>> comment in the code right before the warning line, so it easily found with
>> grep or a web search by who sees the warning.
>
> +1.
Agreed. I've already sent v2, so I'll queue this for v3.
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] dt-bindings: media: hisilicon,hix5hd2-ir: convert to YAML
From: Krzysztof Kozlowski @ 2026-04-01 7:55 UTC (permalink / raw)
To: Andrea Poldi
Cc: Mauro Carvalho Chehab, Shawn Guo, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-media, devicetree,
linux-kernel
In-Reply-To: <20260331145748.39349-1-andrea@riposetti.com>
On Tue, Mar 31, 2026 at 02:58:35PM +0000, Andrea Poldi wrote:
> Convert the HiSilicon Hix5hd2 IR bindings to DT schema.
>
> Signed-off-by: Andrea Poldi <andrea@riposetti.com>
> ---
> .../bindings/media/hisilicon,hix5hd2-ir.yaml | 53 +++++++++++++++++++
> .../devicetree/bindings/media/hix5hd2-ir.txt | 26 ---------
Use dfn: on lore. It's your prerequisite for doing conversion.
Binding was already done for three days.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 2/2] riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
From: Troy Mitchell @ 2026-04-01 7:55 UTC (permalink / raw)
To: 曹珊珊, Troy Mitchell
Cc: Yixun Lan, Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel
In-Reply-To: <407ce3d77416bb2522b7906b0df3d5adf02c27ee.20e9d5ae.574e.4942.b529.0e22091ba551@feishu.cn>
On Wed Apr 1, 2026 at 3:38 PM CST, 曹珊珊 wrote:
> Hi Troy,
>
>> From: "Troy Mitchell"<troy.mitchell@linux.spacemit.com>
>> Date: Wed, Apr 1, 2026, 14:42
>
>> On Wed Apr 1, 2026 at 2:10 PM CST, 曹珊珊 wrote:
>> > Hi Lan,
>> >
>> >> From: "Yixun Lan"<dlan@kernel.org>
>> >> Hi Sandie,
>> >>
>> >> On 11:46 Tue 31 Mar , Sandie Cao wrote:
>> >> > From: sandiecao <sandie.cao@deepcomputing.io>
>> >> >
>> >> > The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
>> >> > SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
>> >> > which has (Framework) SKU FRANHQ0001.
>> >> >
>> >> > The FML13V05 board features:
>> >> > - SpacemiT K3 RISC-V SoC
>> >> > - LPDDR5 16GB or 32GB
>> >> > - eMMC 32GB ~128GB (Optional)
>> >> > - UFS 3.1 256G (Optional)
>> >> > - QSPI Flash
>> >> > - MicroSD Slot
>> >> > - PCIe-based Wi-Fi
>> >> > - 4 USB-C Ports
>> >> > - Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
>> >> > - Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
>> >> > - Port 3 & 4: USB 3.2 Gen 1
>> >> >
>> >> > This minimal device tree enables booting into a serial console with UART
>> >> > output.
>> >> >
>> >> > Signed-off-by: sandiecao <sandie.cao@deepcomputing.io>
>> >> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
>> >> > +&uart0 {
>> >> Can you also add pinctrl data explicitly?
>> >
>> > To avoid conflict, the common pinctrl table "k3-pinctrl.dtsi" should be uploaded by spacemit.
>> > Then we will add the pinctrl data after k3-pico-itx.dts. That should be another patch.
>> > Sandie
>> I think you don't understand what Yixun said.
>> You should add pinctrl properties here like:
>> pinctrl-0 = xxx;
>> pinctrl-names = "default";
>>
>> While the bootloader is expected to initialize the UART pins, explicitly adding the pinctrl properties
>> ensures hardware state consistency.
>>
>> - Troy
>>
>
> Yes, I know this.
> If I add
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_0_cfg>;
> Then also need to add
> &pinctrl {
> uart0_0_cfg: uart0-0-cfg {
> uart0-0-pins {
> pinmux = <K3_PADCONF(149, 2)>, /* uart0 tx */
> <K3_PADCONF(150, 2)>; /* uart0 rx */
>
> bias-pull-up; /* normal pull-up */
> drive-strength = <25>; /* DS8 */
> };
> };
> };
> But this part is common, it should be defined in common pinctrl table "k3-pinctrl.dtsi". And this part hasn't comed to Upstream.
This line exceeds 100 characters
> If I add it currently, When k3-pinctrl.dtsi is accepted by Upstream, we need to remove it again.
> So we just empty it for simple.
No, It looks like your base commit is wrong.
It has been merged here [1] that what you said.
By the way, I noticed that the name in your 'From' header for this reply doesn't match the one in
your patch submission. It would be better to keep them consistent to avoid any confusion for the
maintainers/reviewers regarding the authorship of the response.
Link:
https://lore.kernel.org/all/177340832523.17050.323606076175943251.b4-ty@kernel.org/ [1]
- Troy
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: timer: Add the Renesas RZ/N1 timer
From: Krzysztof Kozlowski @ 2026-04-01 7:57 UTC (permalink / raw)
To: Herve Codina (Schneider Electric)
Cc: Wolfram Sang, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-renesas-soc, linux-kernel, devicetree,
Pascal Eberhard, Miquel Raynal, Thomas Petazzoni
In-Reply-To: <20260331152616.197031-2-herve.codina@bootlin.com>
On Tue, Mar 31, 2026 at 05:26:12PM +0200, Herve Codina (Schneider Electric) wrote:
> +properties:
> + compatible:
> + items:
> + - const: renesas,r9a06g032-timer # RZ/N1D
> + - const: renesas,rzn1-timer
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + items:
> + - description: APB internal bus clock
> +
> + clock-names:
> + items:
> + - const: pclk
> +
> + power-domains:
> + maxItems: 1
> +
> + interrupts:
> + minItems: 8
Drop minItems
With this:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: imx8x-colibri: Correct SODIMM PAD settings
From: Alexander Stein @ 2026-04-01 8:02 UTC (permalink / raw)
To: Peng Fan (OSS), Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Philippe Schenker, Ernest Van Hoecke, linux-arm-kernel
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan,
Daniel Baluta
In-Reply-To: <40dcbb9c-15ad-4765-9f7e-40a571f98fb5@oss.nxp.com>
Am Mittwoch, 1. April 2026, 09:26:03 CEST schrieb Daniel Baluta:
> On 4/1/26 09:40, Peng Fan (OSS) wrote:
> > From: Peng Fan <peng.fan@nxp.com>
> >
> > SION is BIT(30), not BIT(26). Correct it.
> >
> > Fixes: 7ece3cbc8b1ef ("arm64: dts: colibri-imx8x: Add atmel pinctrl groups")
> > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
>
> What is the general attitude around using symbolic macros for pin config?
> Like here: https://www.spinics.net/lists/kernel/msg6072866.html
>
> I think there are useful to avoid this kind of bugs.
>
> If I get enough Ack's I can move forward and replace all magic numbers from imx dtses.
Somehow I completely missed these defines :-/ That's a good improvement,
especially as SION bit is "custom".
Best regards,
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v9 5/6] reset: rzv2h-usb2phy: Convert to regmap API
From: Tommaso Merciai @ 2026-04-01 8:04 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: <283a6336658045be8906ee219620c994e85c7fb8.camel@pengutronix.de>
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[] = {
{ .reg = 0xc10, .def = 0x67c },
{ .reg = 0xc14, .def = 0x1f },
{ .reg = 0x600, .def = 0x909 },
};
static const struct reg_sequence rzv2h_assert_seqs[] = {
{ .reg = 0xb04, .def = 0x303 },
{ .reg = 0x000, .def = 0x206 },
};
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);
return 0;
}
static int rzv2h_usbphy_reset_deassert(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->deassert_seqs,
priv->data->deassert_nseqs);
}
>
> > usleep_range(11, 20);
> >
> > @@ -71,11 +68,9 @@ static int rzv2h_usbphy_reset_deassert(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->reset_deassert_val, priv->base + data->reset_reg);
> > - writel(data->reset2_release_val, priv->base + data->reset2_reg);
> > - writel(data->reset_release_val, priv->base + data->reset_reg);
> > - }
> > + regmap_write(priv->regmap, data->reset_reg, data->reset_deassert_val);
> > + regmap_write(priv->regmap, data->reset2_reg, data->reset2_release_val);
> > + regmap_write(priv->regmap, data->reset_reg, data->reset_release_val);
>
> Same as above.
return regmap_multi_reg_write(priv->regmap, priv->data->deassert_seqs,
priv->data->deassert_nseqs);
>
> [...]
>
> > @@ -149,7 +153,7 @@ static int rzv2h_usb2phy_reset_probe(struct platform_device *pdev)
> > return dev_err_probe(dev, error, "unable to register cleanup action\n");
> >
> > for (unsigned int i = 0; i < data->init_val_count; i++)
> > - writel(data->init_vals[i].val, priv->base + data->init_vals[i].reg);
> > + regmap_write(priv->regmap, data->init_vals[i].reg, data->init_vals[i].val);
>
> Not required for locking, but this could use regmap_multi_reg_write()
> as well.
>
And here we can use:
error = regmap_multi_reg_write(priv->regmap, data->init_seqs, data->init_nseqs);
if (error)
return dev_err_probe(dev, error, "failed to initialize PHY registers\n");
Will send new version hope later today.
Thanks again for the hint!
Kind Regards,
Tommaso
> regards
> Philipp
^ permalink raw reply
* [PATCH v3 2/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-04-01 8:16 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-1-gakula@marvell.com>
The CN20K DRAM Subsystem exposes eight programmable
performance counters and two fixed counters for DDR
read and write traffic. Software selects events for
the programmable counters from traffic at the DDR PHY
interface, the CHI interconnect, or inside the DDR controller.
Add CN20K register offsets, event maps, and sysfs attributes;
match the device via OF (marvell,cn20k-ddr-pmu) and ACPI (MRVL000B).
Represent the SoC variant in platform data with bit flags so
CN20K can reuse the Odyssey PMU code path where appropriate.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
---
drivers/perf/marvell_cn10k_ddr_pmu.c | 187 ++++++++++++++++++++++++---
1 file changed, 171 insertions(+), 16 deletions(-)
diff --git a/drivers/perf/marvell_cn10k_ddr_pmu.c b/drivers/perf/marvell_cn10k_ddr_pmu.c
index 72ac17efd846..7e2e1823b009 100644
--- a/drivers/perf/marvell_cn10k_ddr_pmu.c
+++ b/drivers/perf/marvell_cn10k_ddr_pmu.c
@@ -13,31 +13,43 @@
#include <linux/hrtimer.h>
#include <linux/acpi.h>
#include <linux/platform_device.h>
+#include <linux/bits.h>
+
+/* SoC variant flags for struct ddr_pmu_platform_data (mutually exclusive in pdata) */
+#define IS_CN10K BIT(0)
+#define IS_ODY BIT(1)
+#define IS_CN20K BIT(2)
/* Performance Counters Operating Mode Control Registers */
#define CN10K_DDRC_PERF_CNT_OP_MODE_CTRL 0x8020
#define ODY_DDRC_PERF_CNT_OP_MODE_CTRL 0x20020
+#define CN20K_DDRC_PERF_CNT_OP_MODE_CTRL 0x20000
#define OP_MODE_CTRL_VAL_MANUAL 0x1
/* Performance Counters Start Operation Control Registers */
#define CN10K_DDRC_PERF_CNT_START_OP_CTRL 0x8028
#define ODY_DDRC_PERF_CNT_START_OP_CTRL 0x200A0
+#define CN20K_DDRC_PERF_CNT_START_OP_CTRL 0x20080
#define START_OP_CTRL_VAL_START 0x1ULL
#define START_OP_CTRL_VAL_ACTIVE 0x2
/* Performance Counters End Operation Control Registers */
#define CN10K_DDRC_PERF_CNT_END_OP_CTRL 0x8030
#define ODY_DDRC_PERF_CNT_END_OP_CTRL 0x200E0
+#define CN20K_DDRC_PERF_CNT_END_OP_CTRL 0x200C0
#define END_OP_CTRL_VAL_END 0x1ULL
/* Performance Counters End Status Registers */
#define CN10K_DDRC_PERF_CNT_END_STATUS 0x8038
#define ODY_DDRC_PERF_CNT_END_STATUS 0x20120
+#define CN20K_DDRC_PERF_CNT_END_STATUS 0x20100
#define END_STATUS_VAL_END_TIMER_MODE_END 0x1
/* Performance Counters Configuration Registers */
#define CN10K_DDRC_PERF_CFG_BASE 0x8040
#define ODY_DDRC_PERF_CFG_BASE 0x20160
+#define CN20K_DDRC_PERF_CFG_BASE 0x20140
+#define CN20K_DDRC_PERF_CFG1_BASE 0x20180
/* 8 Generic event counter + 2 fixed event counters */
#define DDRC_PERF_NUM_GEN_COUNTERS 8
@@ -61,6 +73,23 @@
* DO NOT change these event-id numbers, they are used to
* program event bitmap in h/w.
*/
+
+/* CN20K specific events */
+#define EVENT_PERF_OP_IS_RD16 61
+#define EVENT_PERF_OP_IS_RD32 60
+#define EVENT_PERF_OP_IS_WR16 59
+#define EVENT_PERF_OP_IS_WR32 58
+#define EVENT_OP_IS_ENTER_DSM 44
+#define EVENT_OP_IS_RFM 43
+
+#define EVENT_CN20K_OP_IS_TCR_MRR 50
+#define EVENT_CN20K_OP_IS_DQSOSC_MRR 49
+#define EVENT_CN20K_OP_IS_DQSOSC_MPC 48
+#define EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_WR 47
+#define EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_RD 46
+#define EVENT_CN20K_OP_IS_ZQLATCH 21
+#define EVENT_CN20K_OP_IS_ZQSTART 22
+
#define EVENT_DFI_CMD_IS_RETRY 61
#define EVENT_RD_UC_ECC_ERROR 60
#define EVENT_RD_CRC_ERROR 59
@@ -87,6 +116,9 @@
#define EVENT_OP_IS_SPEC_REF 41
#define EVENT_OP_IS_CRIT_REF 40
#define EVENT_OP_IS_REFRESH 39
+#define EVENT_OP_IS_CAS_WCK_SUS 38
+#define EVENT_OP_IS_CAS_WS_OFF 37
+#define EVENT_OP_IS_CAS_WS 36
#define EVENT_OP_IS_ENTER_MPSM 35
#define EVENT_OP_IS_ENTER_POWERDOWN 31
#define EVENT_OP_IS_ENTER_SELFREF 27
@@ -183,8 +215,8 @@ struct ddr_pmu_platform_data {
u64 cnt_freerun_clr;
u64 cnt_value_wr_op;
u64 cnt_value_rd_op;
- bool is_cn10k;
- bool is_ody;
+ u64 cfg1_base;
+ unsigned int silicon_flags; /* IS_CN10K, IS_ODY, or IS_CN20K */
};
static ssize_t cn10k_ddr_pmu_event_show(struct device *dev,
@@ -336,6 +368,80 @@ static struct attribute *odyssey_ddr_perf_events_attrs[] = {
NULL
};
+static struct attribute *cn20k_ddr_perf_events_attrs[] = {
+ /* Programmable */
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rd_or_wr_access, EVENT_HIF_RD_OR_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_wr_access, EVENT_HIF_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rd_access, EVENT_HIF_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_rmw_access, EVENT_HIF_RMW),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hif_pri_rdaccess, EVENT_HIF_HI_PRI_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rd_bypass_access, EVENT_READ_BYPASS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_act_bypass_access, EVENT_ACT_BYPASS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_wr_data_access,
+ EVENT_DFI_WR_DATA_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_rd_data_access,
+ EVENT_DFI_RD_DATA_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_hpri_sched_rd_crit_access,
+ EVENT_HPR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_lpri_sched_rd_crit_access,
+ EVENT_LPR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_wr_trxn_crit_access,
+ EVENT_WR_XACT_WHEN_CRITICAL),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_active_access, EVENT_OP_IS_ACTIVATE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_rd_or_wr_access,
+ EVENT_OP_IS_RD_OR_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_rd_active_access,
+ EVENT_OP_IS_RD_ACTIVATE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_read, EVENT_OP_IS_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_write, EVENT_OP_IS_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cam_mwr, EVENT_OP_IS_MWR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge, EVENT_OP_IS_PRECHARGE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge_for_rdwr,
+ EVENT_PRECHARGE_FOR_RDWR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_precharge_for_other,
+ EVENT_PRECHARGE_FOR_OTHER),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rdwr_transitions, EVENT_RDWR_TRANSITIONS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write_combine, EVENT_WRITE_COMBINE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_war_hazard, EVENT_WAR_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_raw_hazard, EVENT_RAW_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_waw_hazard, EVENT_WAW_HAZARD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_selfref, EVENT_OP_IS_ENTER_SELFREF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_powerdown,
+ EVENT_OP_IS_ENTER_POWERDOWN),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_ws, EVENT_OP_IS_CAS_WS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_ws_off, EVENT_OP_IS_CAS_WS_OFF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_cas_wck_sus, EVENT_OP_IS_CAS_WCK_SUS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_refresh, EVENT_OP_IS_REFRESH),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_crit_ref, EVENT_OP_IS_CRIT_REF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_spec_ref, EVENT_OP_IS_SPEC_REF),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_load_mode, EVENT_OP_IS_LOAD_MODE),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_rfm, EVENT_OP_IS_RFM),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_enter_dsm, EVENT_OP_IS_ENTER_DSM),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dfi_cycles, EVENT_DFI_CYCLES),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_win_limit_reached_rd,
+ EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_RD),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_win_limit_reached_wr,
+ EVENT_CN20K_VISIBLE_WIN_LIMIT_REACHED_WR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dqsosc_mpc, EVENT_CN20K_OP_IS_DQSOSC_MPC),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_dqsosc_mrr, EVENT_CN20K_OP_IS_DQSOSC_MRR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_tcr_mrr, EVENT_CN20K_OP_IS_TCR_MRR),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_zqstart, EVENT_CN20K_OP_IS_ZQSTART),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_zqlatch, EVENT_CN20K_OP_IS_ZQLATCH),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_read16, EVENT_PERF_OP_IS_RD16),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_read32, EVENT_PERF_OP_IS_RD32),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write16, EVENT_PERF_OP_IS_WR16),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_write32, EVENT_PERF_OP_IS_WR32),
+ /* Free run event counters */
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_ddr_reads, EVENT_DDR_READS),
+ CN10K_DDR_PMU_EVENT_ATTR(ddr_ddr_writes, EVENT_DDR_WRITES),
+ NULL
+};
+
+static struct attribute_group cn20k_ddr_perf_events_attr_group = {
+ .name = "events",
+ .attrs = cn20k_ddr_perf_events_attrs,
+};
+
static struct attribute_group odyssey_ddr_perf_events_attr_group = {
.name = "events",
.attrs = odyssey_ddr_perf_events_attrs,
@@ -393,6 +499,13 @@ static const struct attribute_group *odyssey_attr_groups[] = {
NULL
};
+static const struct attribute_group *cn20k_attr_groups[] = {
+ &cn20k_ddr_perf_events_attr_group,
+ &cn10k_ddr_perf_format_attr_group,
+ &cn10k_ddr_perf_cpumask_attr_group,
+ NULL
+};
+
/* Default poll timeout is 100 sec, which is very sufficient for
* 48 bit counter incremented max at 5.6 GT/s, which may take many
* hours to overflow.
@@ -412,7 +525,7 @@ static int ddr_perf_get_event_bitmap(int eventid, u64 *event_bitmap,
switch (eventid) {
case EVENT_DFI_PARITY_POISON ...EVENT_DFI_CMD_IS_RETRY:
- if (!ddr_pmu->p_data->is_ody) {
+ if (!(ddr_pmu->p_data->silicon_flags & IS_ODY)) {
err = -EINVAL;
break;
}
@@ -524,9 +637,9 @@ static void cn10k_ddr_perf_counter_enable(struct cn10k_ddr_pmu *pmu,
int counter, bool enable)
{
const struct ddr_pmu_platform_data *p_data = pmu->p_data;
+ unsigned int silicon_flags = pmu->p_data->silicon_flags;
u64 ctrl_reg = pmu->p_data->cnt_op_mode_ctrl;
const struct ddr_pmu_ops *ops = pmu->ops;
- bool is_ody = pmu->p_data->is_ody;
u32 reg;
u64 val;
@@ -546,7 +659,7 @@ static void cn10k_ddr_perf_counter_enable(struct cn10k_ddr_pmu *pmu,
writeq_relaxed(val, pmu->base + reg);
- if (is_ody) {
+ if (silicon_flags & IS_ODY) {
if (enable) {
/*
* Setup the PMU counter to work in
@@ -621,6 +734,7 @@ static int cn10k_ddr_perf_event_add(struct perf_event *event, int flags)
{
struct cn10k_ddr_pmu *pmu = to_cn10k_ddr_pmu(event->pmu);
const struct ddr_pmu_platform_data *p_data = pmu->p_data;
+ unsigned int silicon_flags = pmu->p_data->silicon_flags;
const struct ddr_pmu_ops *ops = pmu->ops;
struct hw_perf_event *hwc = &event->hw;
u8 config = event->attr.config;
@@ -642,10 +756,17 @@ static int cn10k_ddr_perf_event_add(struct perf_event *event, int flags)
if (counter < DDRC_PERF_NUM_GEN_COUNTERS) {
/* Generic counters, configure event id */
reg_offset = DDRC_PERF_CFG(p_data->cfg_base, counter);
- ret = ddr_perf_get_event_bitmap(config, &val, pmu);
- if (ret)
- return ret;
+ if (silicon_flags & IS_CN20K) {
+ val = (1ULL << (config - 1));
+ if (config == EVENT_CN20K_OP_IS_ZQSTART ||
+ config == EVENT_CN20K_OP_IS_ZQLATCH)
+ reg_offset = DDRC_PERF_CFG(p_data->cfg1_base, counter);
+ } else {
+ ret = ddr_perf_get_event_bitmap(config, &val, pmu);
+ if (ret)
+ return ret;
+ }
writeq_relaxed(val, pmu->base + reg_offset);
} else {
/* fixed event counter, clear counter value */
@@ -952,7 +1073,25 @@ static const struct ddr_pmu_platform_data cn10k_ddr_pmu_pdata = {
.cnt_freerun_clr = 0,
.cnt_value_wr_op = CN10K_DDRC_PERF_CNT_VALUE_WR_OP,
.cnt_value_rd_op = CN10K_DDRC_PERF_CNT_VALUE_RD_OP,
- .is_cn10k = TRUE,
+ .silicon_flags = IS_CN10K,
+};
+
+static const struct ddr_pmu_platform_data cn20k_ddr_pmu_pdata = {
+ .counter_overflow_val = 0,
+ .counter_max_val = GENMASK_ULL(63, 0),
+ .cnt_base = ODY_DDRC_PERF_CNT_VALUE_BASE,
+ .cfg_base = CN20K_DDRC_PERF_CFG_BASE,
+ .cfg1_base = CN20K_DDRC_PERF_CFG1_BASE,
+ .cnt_op_mode_ctrl = CN20K_DDRC_PERF_CNT_OP_MODE_CTRL,
+ .cnt_start_op_ctrl = CN20K_DDRC_PERF_CNT_START_OP_CTRL,
+ .cnt_end_op_ctrl = CN20K_DDRC_PERF_CNT_END_OP_CTRL,
+ .cnt_end_status = CN20K_DDRC_PERF_CNT_END_STATUS,
+ .cnt_freerun_en = 0,
+ .cnt_freerun_ctrl = ODY_DDRC_PERF_CNT_FREERUN_CTRL,
+ .cnt_freerun_clr = ODY_DDRC_PERF_CNT_FREERUN_CLR,
+ .cnt_value_wr_op = ODY_DDRC_PERF_CNT_VALUE_WR_OP,
+ .cnt_value_rd_op = ODY_DDRC_PERF_CNT_VALUE_RD_OP,
+ .silicon_flags = IS_CN20K,
};
#endif
@@ -979,7 +1118,7 @@ static const struct ddr_pmu_platform_data odyssey_ddr_pmu_pdata = {
.cnt_freerun_clr = ODY_DDRC_PERF_CNT_FREERUN_CLR,
.cnt_value_wr_op = ODY_DDRC_PERF_CNT_VALUE_WR_OP,
.cnt_value_rd_op = ODY_DDRC_PERF_CNT_VALUE_RD_OP,
- .is_ody = TRUE,
+ .silicon_flags = IS_ODY,
};
#endif
@@ -989,8 +1128,7 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
struct cn10k_ddr_pmu *ddr_pmu;
struct resource *res;
void __iomem *base;
- bool is_cn10k;
- bool is_ody;
+ unsigned int silicon_flags;
char *name;
int ret;
@@ -1014,10 +1152,9 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
ddr_pmu->base = base;
ddr_pmu->p_data = dev_data;
- is_cn10k = ddr_pmu->p_data->is_cn10k;
- is_ody = ddr_pmu->p_data->is_ody;
+ silicon_flags = ddr_pmu->p_data->silicon_flags;
- if (is_cn10k) {
+ if (silicon_flags & IS_CN10K) {
ddr_pmu->ops = &ddr_pmu_ops;
/* Setup the PMU counter to work in manual mode */
writeq_relaxed(OP_MODE_CTRL_VAL_MANUAL, ddr_pmu->base +
@@ -1039,7 +1176,7 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
};
}
- if (is_ody) {
+ if (silicon_flags & IS_ODY) {
ddr_pmu->ops = &ddr_pmu_ody_ops;
ddr_pmu->pmu = (struct pmu) {
@@ -1056,6 +1193,22 @@ static int cn10k_ddr_perf_probe(struct platform_device *pdev)
};
}
+ if (silicon_flags & IS_CN20K) {
+ ddr_pmu->ops = &ddr_pmu_ody_ops;
+
+ ddr_pmu->pmu = (struct pmu) {
+ .module = THIS_MODULE,
+ .capabilities = PERF_PMU_CAP_NO_EXCLUDE,
+ .task_ctx_nr = perf_invalid_context,
+ .attr_groups = cn20k_attr_groups,
+ .event_init = cn10k_ddr_perf_event_init,
+ .add = cn10k_ddr_perf_event_add,
+ .del = cn10k_ddr_perf_event_del,
+ .start = cn10k_ddr_perf_event_start,
+ .stop = cn10k_ddr_perf_event_stop,
+ .read = cn10k_ddr_perf_event_update,
+ };
+ }
/* Choose this cpu to collect perf data */
ddr_pmu->cpu = raw_smp_processor_id();
@@ -1098,6 +1251,7 @@ static void cn10k_ddr_perf_remove(struct platform_device *pdev)
#ifdef CONFIG_OF
static const struct of_device_id cn10k_ddr_pmu_of_match[] = {
{ .compatible = "marvell,cn10k-ddr-pmu", .data = &cn10k_ddr_pmu_pdata },
+ { .compatible = "marvell,cn20k-ddr-pmu", .data = &cn20k_ddr_pmu_pdata },
{ },
};
MODULE_DEVICE_TABLE(of, cn10k_ddr_pmu_of_match);
@@ -1107,6 +1261,7 @@ MODULE_DEVICE_TABLE(of, cn10k_ddr_pmu_of_match);
static const struct acpi_device_id cn10k_ddr_pmu_acpi_match[] = {
{"MRVL000A", (kernel_ulong_t)&cn10k_ddr_pmu_pdata },
{"MRVL000C", (kernel_ulong_t)&odyssey_ddr_pmu_pdata},
+ {"MRVL000B", (kernel_ulong_t)&cn20k_ddr_pmu_pdata},
{},
};
MODULE_DEVICE_TABLE(acpi, cn10k_ddr_pmu_acpi_match);
--
2.25.1
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: perf: marvell: Document CN20K DDR PMU
From: Geetha sowjanya @ 2026-04-01 8:16 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
In-Reply-To: <20260401081640.23740-1-gakula@marvell.com>
Add a devicetree binding for the Marvell CN20K DDR performance
monitor block, including the marvell,cn20k-ddr-pmu compatible
string and the required MMIO reg region.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
---
.../bindings/perf/marvell-cn20k-ddr.yaml | 39 +++++++++++++++++++
1 file changed, 39 insertions(+)
create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
diff --git a/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
new file mode 100644
index 000000000000..fa757017d66e
--- /dev/null
+++ b/Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
@@ -0,0 +1,39 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/perf/marvell-cn20k-ddr.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell CN20K DDR performance monitor
+
+description:
+ Performance Monitoring Unit (PMU) for the DDR controller
+ in Marvell CN20K SoCs.
+
+maintainers:
+ - Geetha sowjanya <gakula@marvell.com>
+
+properties:
+ compatible:
+ const: marvell,cn20k-ddr-pmu
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ bus {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ddr-pmu@c200000000 {
+ compatible = "marvell,cn20k-ddr-pmu";
+ reg = <0xc200 0x00000000 0x0 0x100000>;
+ };
+ };
--
2.25.1
^ permalink raw reply related
* [PATCH v3 0/2] perf: marvell: Add CN20K DDR PMU support
From: Geetha sowjanya @ 2026-04-01 8:16 UTC (permalink / raw)
To: linux-perf-users, linux-kernel, linux-arm-kernel, devicetree
Cc: mark.rutland, will, krzk+dt
This series adds support for the Marvell CN20K DRAM Subsystem (DSS)
performance monitor in the existing marvell_cn10k_ddr_pmu driver, and
documents the device tree binding for the new compatible string.
The CN20K PMU provides eight programmable counters and two fixed
counters (DDR reads and writes). Patch 1 adds the devicetree schema for
"marvell,cn20k-ddr-pmu". Patch 2 wires OF and ACPI (MRVL000B) match
entries, adds CN20K register offsets and event maps, and refactors
platform data to use silicon variant flags.
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Changes in v2:
- Fixed YAML syntax error triggered by a tab character in the examples
section, which caused dt_binding_check to fail.
Changes in v1:
- Added a description field to the binding.
- Simplified the compatible property using 'const' instead of 'items/enum'.
- Updated the example node name to include a unit-address matching the reg base.
Geetha sowjanya (2):
dt-bindings: perf: marvell: Document CN20K DDR PMU
perf: marvell: Add CN20K DDR PMU support
.../bindings/perf/marvell-cn20k-ddr.yaml | 37 ++++
drivers/perf/marvell_cn10k_ddr_pmu.c | 186 ++++++++++++++++--
2 files changed, 207 insertions(+), 16 deletions(-)
create mode 100644 Documentation/devicetree/bindings/perf/marvell-cn20k-ddr.yaml
--
2.25.1
^ permalink raw reply
* Re: [PATCH net-next v2 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
From: Jens Emil Schulz Ostergaard @ 2026-04-01 8:16 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195625.2789069-1-kuba@kernel.org>
On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> dt-bindings: net: lan9645x: add LAN9645X switch bindings
>
> Add bindings for LAN9645X switch. We use a fallback compatible for the
> smallest SKU microchip,lan96455s-switch.
>
> > diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > new file mode 100644
> > index 000000000000..0282e25c05d4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
>
> [ ... ]
>
> > +patternProperties:
> > + "^(ethernet-)?ports$":
> > + type: object
> > + additionalProperties: true
> > + patternProperties:
> > + "^(ethernet-)?port@[0-8]$":
>
> Does having additionalProperties set to true bypass the port number
> restriction?
>
> Since dsa.yaml allows port@[0-9a-f]+, it seems port@9 would silently pass
> validation as an additional property. Should this be unevaluatedProperties
> set to false instead?
>
Yes it is true the port regex has no effect, but I do not think
unevaluatedProperties: false
is what I want here. That rejects other properties from the parent. I can
remove the explicit additionalProperties: true. This is similar to
Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
and the port number restriction still serves as documentation, even if it is
not applied during validation.
> > + type: object
> > + description: Ethernet switch ports
> > +
> > + $ref: dsa-port.yaml#
> > +
> > + properties:
> > + rx-internal-delay-ps:
> > + const: 2000
> > +
> > + tx-internal-delay-ps:
> > + const: 2000
>
> Does enforcing a 2000ps delay conflict with standard rgmii bindings?
>
> As documented in net/ethernet-controller.yaml, a full 2ns delay is
> typically modeled using phy-mode set to rgmii-id rather than hardcoding the
> delay properties with a base rgmii mode.
>
No this was explicitly requested on v1 to enable adding a delay with mac2mac links.
I enforce 2000ps because that is the only supported value.
> [ ... ]
>
> > +required:
> > + - compatible
> > + - reg
> > +
> > +unevaluatedProperties: false
>
> How are the five integrated 10/100/1000Base-T phys mentioned in the
> description modeled?
>
> Since unevaluatedProperties is false at the top level and there is no
> definition or reference for an mdio node, wouldn't adding an mdio subnode
> to configure these phys fail schema validation?
>
> Should there be a reference to /schemas/net/mdio.yaml#?
No, the MDIO busses will be part of a parent MFD device node, not the switch node.
^ permalink raw reply
* Re: [PATCH v9 5/6] reset: rzv2h-usb2phy: Convert to regmap API
From: Philipp Zabel @ 2026-04-01 8:23 UTC (permalink / raw)
To: Tommaso Merciai
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: <aczRo8HVUFqXKfG_@tom-desktop>
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.
> { .reg = 0xc10, .def = 0x67c },
> { .reg = 0xc14, .def = 0x1f },
0x01f for consistency?
> { .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.
> };
>
> 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.
regards
Philipp
^ permalink raw reply
* Re: [PATCH v1 2/2] riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
From: Sandie Cao @ 2026-04-01 8:25 UTC (permalink / raw)
To: Troy Mitchell
Cc: Troy Mitchell, Yixun Lan, Conor Dooley, Emil Renner Berthing,
Rob Herring, Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel
In-Reply-To: <DHHNO3MKPLX6.10BU0B83KT0GV@linux.spacemit.com>
Hi Troy,
> From: "Troy Mitchell"<troy.mitchell@linux.spacemit.com>
> Date: Wed, Apr 1, 2026, 15:55
> On Wed Apr 1, 2026 at 3:38 PM CST, 曹珊珊 wrote:
> > Hi Troy,
> >
> >> From: "Troy Mitchell"<troy.mitchell@linux.spacemit.com>
> >> Date: Wed, Apr 1, 2026, 14:42
> >
> >> On Wed Apr 1, 2026 at 2:10 PM CST, 曹珊珊 wrote:
> >> > Hi Lan,
> >> >
> >> >> From: "Yixun Lan"<dlan@kernel.org>
> >> >> Hi Sandie,
> >> >>
> >> >> On 11:46 Tue 31 Mar , Sandie Cao wrote:
> >> >> > From: sandiecao <sandie.cao@deepcomputing.io>
> >> >> >
> >> >> > The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
> >> >> > SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
> >> >> > which has (Framework) SKU FRANHQ0001.
> >> >> >
> >> >> > The FML13V05 board features:
> >> >> > - SpacemiT K3 RISC-V SoC
> >> >> > - LPDDR5 16GB or 32GB
> >> >> > - eMMC 32GB ~128GB (Optional)
> >> >> > - UFS 3.1 256G (Optional)
> >> >> > - QSPI Flash
> >> >> > - MicroSD Slot
> >> >> > - PCIe-based Wi-Fi
> >> >> > - 4 USB-C Ports
> >> >> > - Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
> >> >> > - Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
> >> >> > - Port 3 & 4: USB 3.2 Gen 1
> >> >> >
> >> >> > This minimal device tree enables booting into a serial console with UART
> >> >> > output.
> >> >> >
> >> >> > Signed-off-by: sandiecao <sandie.cao@deepcomputing.io>
> >> >> > Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> >> >> > +&uart0 {
> >> >> Can you also add pinctrl data explicitly?
> >> >
> >> > To avoid conflict, the common pinctrl table "k3-pinctrl.dtsi" should be uploaded by spacemit.
> >> > Then we will add the pinctrl data after k3-pico-itx.dts. That should be another patch.
> >> > Sandie
> >> I think you don't understand what Yixun said.
> >> You should add pinctrl properties here like:
> >> pinctrl-0 = xxx;
> >> pinctrl-names = "default";
> >>
> >> While the bootloader is expected to initialize the UART pins, explicitly adding the pinctrl properties
> >> ensures hardware state consistency.
> >>
> >> - Troy
> >>
> >
> > Yes, I know this.
> > If I add
> > pinctrl-names = "default";
> > pinctrl-0 = <&uart0_0_cfg>;
> > Then also need to add
> > &pinctrl {
> > uart0_0_cfg: uart0-0-cfg {
> > uart0-0-pins {
> > pinmux = <K3_PADCONF(149, 2)>, /* uart0 tx */
> > <K3_PADCONF(150, 2)>; /* uart0 rx */
> >
> > bias-pull-up; /* normal pull-up */
> > drive-strength = <25>; /* DS8 */
> > };
> > };
> > };
> > But this part is common, it should be defined in common pinctrl table "k3-pinctrl.dtsi". And this part hasn't comed to Upstream.
> This line exceeds 100 characters
>
> > If I add it currently, When k3-pinctrl.dtsi is accepted by Upstream, we need to remove it again.
> > So we just empty it for simple.
> No, It looks like your base commit is wrong.
> It has been merged here [1] that what you said.
>
Got it. I will use https://github.com/spacemit-com/linux/tree/k1/dt-for-next to rebase my patch.
> By the way, I noticed that the name in your 'From' header for this reply doesn't match the one in
> your patch submission. It would be better to keep them consistent to avoid any confusion for the
> maintainers/reviewers regarding the authorship of the response.
>
Already fixed it.
Thanks a lot.
Sandie
> Link:
> https://lore.kernel.org/all/177340832523.17050.323606076175943251.b4-ty@kernel.org/ [1]
>
>
> - Troy
>
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: imx8m-kontron: Revert reading SD_VSEL signal
From: Frieder Schrempf @ 2026-04-01 8:28 UTC (permalink / raw)
To: Peng Fan (OSS), Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260401-imx8m-ldo5-v1-0-1b1c1381babd@nxp.com>
On 01.04.26 04:05, Peng Fan (OSS) wrote:
> When MUX is configured as SDHC VSELECT, enabling SION is not able
> to read back the SD_VSEL value. SION is used for force input path,
> not to redirect the PAD value to GPIO(the other mux).
>
> This has been confirmed by reading i.MX8MP RTL. we have not check
> i.MX8MM RTL, but it should be same.
It seems like you are right and I misinterpreted the documentation and
also misinterpreted my test results. So I was probably basing my work on
wrong assumptions.
>
> Not sure whether need to add Fixes commit for the patches, just revert
> patches.
This was introduced in 6.15. I would like to add Fixes tags for the
reverts. And can we add patches in this series that switch to GPIO
control as done in [1] and also tag them as fixes? This should allow to
read back the correct voltage from the regulator.
>
> For the U-Boot support, either drop vqmmc-supply or switch to use gpio
> control to replace vselect control.
>
> And below patch should also be revisited.
I think we can revert this, too.
> commit 3ce6f4f943ddd9edc03e450a2a0d89cb025b165b
> Author: Frieder Schrempf <frieder.schrempf@kontron.de>
> Date: Wed Dec 18 16:27:27 2024 +0100
>
> regulator: pca9450: Fix control register for LDO5
>
> To supporting read back signal, need the MUX set as GPIO and support
> in/out, not set mux as VSELECT.
>
> TBH: I have not test setting MUX as GPIO, anyway we need to fix DT.
If we mux as GPIO, then we don't need to read back. I think in this case
the best solution is the one used in [1].
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=5245dc5
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Peng Fan (2):
> Revert "arm64: dts: imx8mm-kontron: Add support for reading SD_VSEL signal"
> Revert "arm64: dts: imx8mp-kontron: Add support for reading SD_VSEL signal"
>
> arch/arm64/boot/dts/freescale/imx8mm-kontron-bl.dts | 10 +++-------
> arch/arm64/boot/dts/freescale/imx8mm-kontron-osm-s.dtsi | 7 +++----
> arch/arm64/boot/dts/freescale/imx8mp-kontron-osm-s.dtsi | 7 +++----
> 3 files changed, 9 insertions(+), 15 deletions(-)
> ---
> base-commit: 3b058d1aeeeff27a7289529c4944291613b364e9
> change-id: 20260329-imx8m-ldo5-90e369066213
>
> Best regards,
^ permalink raw reply
* [PATCH v2 1/3] ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
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>
Reorganize the DTS file for consistency with other msm8960 board files.
Assisted-by: Claude:claude-opus-4.6
Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
---
.../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 400 ++++++++++-----------
1 file changed, 200 insertions(+), 200 deletions(-)
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 35514fd53e3d..ed913ca5b825 100644
--- a/arch/arm/boot/dts/qcom/qcom-msm8960-samsung-expressatt.dts
+++ b/arch/arm/boot/dts/qcom/qcom-msm8960-samsung-expressatt.dts
@@ -1,13 +1,13 @@
// SPDX-License-Identifier: GPL-2.0
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
#include <dt-bindings/reset/qcom,gcc-msm8960.h>
#include "qcom-msm8960.dtsi"
#include "pm8921.dtsi"
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
-#include <dt-bindings/input/gpio-keys.h>
/ {
model = "Samsung Galaxy Express SGH-I437";
@@ -27,8 +27,8 @@ chosen {
gpio-keys {
compatible = "gpio-keys";
- pinctrl-names = "default";
pinctrl-0 = <&gpio_keys_pin_a>;
+ pinctrl-names = "default";
key-home {
label = "Home";
@@ -54,48 +54,14 @@ key-volume-down {
};
};
- touchkey_enable: touchkey-enable {
- compatible = "regulator-fixed";
- regulator-name = "touchkey_enable";
- gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- regulator-boot-on;
- };
-
- 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 {
- compatible = "richtek,rt8515";
- enf-gpios = <&tlmm 3 GPIO_ACTIVE_HIGH>;
- vin-supply = <&vreg_flash>;
- richtek,rfs-ohms = <16000>;
- pinctrl-0 = <&cam_flash_en>;
- pinctrl-names = "default";
-
- led {
- function = LED_FUNCTION_FLASH;
- color = <LED_COLOR_ID_WHITE>;
- flash-max-timeout-us = <250000>;
- };
- };
-
i2c-gpio-touchkey {
compatible = "i2c-gpio";
#address-cells = <1>;
#size-cells = <0>;
sda-gpios = <&tlmm 71 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
scl-gpios = <&tlmm 72 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
- pinctrl-names = "default";
pinctrl-0 = <&touchkey_i2c_pins>;
+ pinctrl-names = "default";
status = "okay";
i2c-gpio,delay-us = <2>;
@@ -104,8 +70,8 @@ touchkey@20 {
reg = <0x20>;
interrupts-extended = <&tlmm 52 IRQ_TYPE_EDGE_FALLING>;
- pinctrl-names = "default";
pinctrl-0 = <&touchkey_irq_pin>;
+ pinctrl-names = "default";
vddio-supply = <&touchkey_enable>;
vdd-supply = <&pm8921_l29>;
@@ -114,6 +80,51 @@ touchkey@20 {
linux,keycodes = <KEY_MENU KEY_BACK>;
};
};
+
+ led-controller {
+ compatible = "richtek,rt8515";
+ enf-gpios = <&tlmm 3 GPIO_ACTIVE_HIGH>;
+ vin-supply = <&vreg_flash>;
+ richtek,rfs-ohms = <16000>;
+ pinctrl-0 = <&cam_flash_en>;
+ pinctrl-names = "default";
+
+ led {
+ function = LED_FUNCTION_FLASH;
+ color = <LED_COLOR_ID_WHITE>;
+ flash-max-timeout-us = <250000>;
+ };
+ };
+
+ 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";
+ };
+
+ touchkey_enable: touchkey-enable {
+ compatible = "regulator-fixed";
+ regulator-name = "touchkey_enable";
+ gpio = <&tlmm 51 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ regulator-boot-on;
+ };
+};
+
+&gsbi1 {
+ qcom,mode = <GSBI_PROT_SPI>;
+ pinctrl-0 = <&spi1_default>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&gsbi1_spi {
+ status = "okay";
};
&gsbi2 {
@@ -141,42 +152,6 @@ light-sensor@39 {
};
};
-&gsbi5 {
- qcom,mode = <GSBI_PROT_I2C_UART>;
- status = "okay";
-};
-
-&gsbi5_serial {
- status = "okay";
-};
-
-&sdcc1 {
- vmmc-supply = <&pm8921_l5>;
- status = "okay";
-};
-
-&sdcc3 {
- vmmc-supply = <&pm8921_l6>;
- vqmmc-supply = <&pm8921_l7>;
-
- pinctrl-0 = <&sdcc3_default_state>;
- pinctrl-1 = <&sdcc3_sleep_state>;
- pinctrl-names = "default", "sleep";
-
- status = "okay";
-};
-
-&gsbi1 {
- qcom,mode = <GSBI_PROT_SPI>;
- pinctrl-0 = <&spi1_default>;
- pinctrl-names = "default";
- status = "okay";
-};
-
-&gsbi1_spi {
- status = "okay";
-};
-
&gsbi3 {
qcom,mode = <GSBI_PROT_I2C>;
status = "okay";
@@ -193,93 +168,68 @@ touchscreen@4a {
interrupts = <11 IRQ_TYPE_EDGE_FALLING>;
vdda-supply = <&pm8921_lvs6>;
vdd-supply = <&pm8921_l17>;
- pinctrl-names = "default";
pinctrl-0 = <&touchscreen>;
+ pinctrl-names = "default";
};
};
-&tlmm {
- cam_flash_en: cam-flash-en-state {
- pins = "gpio3";
- function = "gpio";
- drive-strength = <16>;
- bias-pull-down;
- };
+&gsbi5 {
+ qcom,mode = <GSBI_PROT_I2C_UART>;
+ status = "okay";
+};
- spi1_default: spi1-default-state {
- mosi-pins {
- pins = "gpio6";
- function = "gsbi1";
- drive-strength = <12>;
- bias-disable;
- };
+&gsbi5_serial {
+ status = "okay";
+};
- miso-pins {
- pins = "gpio7";
- function = "gsbi1";
- drive-strength = <12>;
- bias-disable;
- };
+&gsbi7 {
+ qcom,mode = <GSBI_PROT_I2C>;
- cs-pins {
- pins = "gpio8";
- function = "gsbi1";
- drive-strength = <12>;
- bias-disable;
- output-low;
- };
+ status = "okay";
+};
- clk-pins {
- pins = "gpio9";
- function = "gsbi1";
- drive-strength = <12>;
- bias-disable;
- };
- };
+&gsbi7_i2c {
+ status = "okay";
- gpio_keys_pin_a: gpio-keys-active-state {
- pins = "gpio40", "gpio50", "gpio81";
- function = "gpio";
- drive-strength = <8>;
- bias-disable;
- };
+ nfc@2b {
+ compatible = "nxp,pn544-i2c";
+ reg = <0x2b>;
+ interrupts-extended = <&tlmm 106 IRQ_TYPE_EDGE_RISING>;
+ enable-gpios = <&pm8921_gpio 21 GPIO_ACTIVE_HIGH>;
+ firmware-gpios = <&tlmm 92 GPIO_ACTIVE_HIGH>;
- touchscreen: touchscreen-int-state {
- pins = "gpio11";
- function = "gpio";
- output-enable;
- bias-disable;
- drive-strength = <2>;
+ pinctrl-0 = <&nfc_default &nfc_enable>;
+ pinctrl-names = "default";
};
+};
- nfc_default: nfc-default-state {
- irq-pins {
- pins = "gpio106";
- function = "gpio";
- drive-strength = <2>;
- bias-pull-down;
- };
+&gsbi12 {
+ qcom,mode = <GSBI_PROT_I2C>;
- firmware-pins {
- pins = "gpio92";
- function = "gpio";
- drive-strength = <2>;
- bias-disable;
- };
- };
+ status = "okay";
+};
- touchkey_i2c_pins: touchkey-i2c-state {
- pins = "gpio71", "gpio72";
- function = "gpio";
- drive-strength = <2>;
- bias-disable;
+&gsbi12_i2c {
+ status = "okay";
+
+ accelerometer@18 {
+ compatible = "bosch,bma254";
+ reg = <0x18>;
+ vdd-supply = <&pm8921_l9>;
+ vddio-supply = <&pm8921_lvs4>;
+
+ mount-matrix = "-1", "0", "0",
+ "0", "-1", "0",
+ "0", "0", "1";
};
- touchkey_irq_pin: touchkey-irq-state {
- pins = "gpio52";
- function = "gpio";
- drive-strength = <2>;
- bias-disable;
+ magnetometer@2e {
+ compatible = "yamaha,yas532";
+ reg = <0x2e>;
+ vdd-supply = <&pm8921_l9>;
+ iovdd-supply = <&pm8921_lvs4>;
+
+ /* TODO: Figure out Mount Matrix */
};
};
@@ -288,18 +238,27 @@ &pm8921 {
};
&pm8921_gpio {
+ nfc_enable: nfc-enable-state {
+ pins = "gpio21";
+ function = "normal";
+ bias-disable;
+ qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+ power-source = <PM8921_GPIO_S4>;
+ };
+
prox_sensor_int: prox-sensor-int-state {
pins = "gpio6";
function = "normal";
input-enable;
bias-disable;
};
+};
- nfc_enable: nfc-enable-state {
- pins = "gpio21";
- function = "normal";
- bias-disable;
- qcom,drive-strength = <PMIC_GPIO_STRENGTH_LOW>;
+&pm8921_mpps {
+ flash_led_unlock: flash-led-unlock-state {
+ pins = "mpp4";
+ function = "digital";
+ output-low;
power-source = <PM8921_GPIO_S4>;
};
};
@@ -546,72 +505,113 @@ pm8921_ncp: ncp {
};
};
-&usb_hs1_phy {
- v3p3-supply = <&pm8921_l3>;
- v1p8-supply = <&pm8921_l4>;
-};
-
-&usb1 {
- dr_mode = "otg";
+&sdcc1 {
+ vmmc-supply = <&pm8921_l5>;
status = "okay";
};
-&gsbi7 {
- qcom,mode = <GSBI_PROT_I2C>;
+&sdcc3 {
+ vmmc-supply = <&pm8921_l6>;
+ vqmmc-supply = <&pm8921_l7>;
+
+ pinctrl-0 = <&sdcc3_default_state>;
+ pinctrl-1 = <&sdcc3_sleep_state>;
+ pinctrl-names = "default", "sleep";
status = "okay";
};
-&gsbi7_i2c {
- status = "okay";
+&tlmm {
+ cam_flash_en: cam-flash-en-state {
+ pins = "gpio3";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-pull-down;
+ };
- nfc@2b {
- compatible = "nxp,pn544-i2c";
- reg = <0x2b>;
- interrupts-extended = <&tlmm 106 IRQ_TYPE_EDGE_RISING>;
- enable-gpios = <&pm8921_gpio 21 GPIO_ACTIVE_HIGH>;
- firmware-gpios = <&tlmm 92 GPIO_ACTIVE_HIGH>;
+ spi1_default: spi1-default-state {
+ mosi-pins {
+ pins = "gpio6";
+ function = "gsbi1";
+ drive-strength = <12>;
+ bias-disable;
+ };
- pinctrl-0 = <&nfc_default &nfc_enable>;
- pinctrl-names = "default";
- };
-};
+ miso-pins {
+ pins = "gpio7";
+ function = "gsbi1";
+ drive-strength = <12>;
+ bias-disable;
+ };
-&gsbi12 {
- qcom,mode = <GSBI_PROT_I2C>;
+ cs-pins {
+ pins = "gpio8";
+ function = "gsbi1";
+ drive-strength = <12>;
+ bias-disable;
+ output-low;
+ };
- status = "okay";
-};
+ clk-pins {
+ pins = "gpio9";
+ function = "gsbi1";
+ drive-strength = <12>;
+ bias-disable;
+ };
+ };
-&gsbi12_i2c {
- status = "okay";
+ touchscreen: touchscreen-int-state {
+ pins = "gpio11";
+ function = "gpio";
+ output-enable;
+ bias-disable;
+ drive-strength = <2>;
+ };
- accelerometer@18 {
- compatible = "bosch,bma254";
- reg = <0x18>;
- vdd-supply = <&pm8921_l9>;
- vddio-supply = <&pm8921_lvs4>;
+ gpio_keys_pin_a: gpio-keys-active-state {
+ pins = "gpio40", "gpio50", "gpio81";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
- mount-matrix = "-1", "0", "0",
- "0", "-1", "0",
- "0", "0", "1";
+ touchkey_irq_pin: touchkey-irq-state {
+ pins = "gpio52";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
};
- magnetometer@2e {
- compatible = "yamaha,yas532";
- reg = <0x2e>;
- vdd-supply = <&pm8921_l9>;
- iovdd-supply = <&pm8921_lvs4>;
+ touchkey_i2c_pins: touchkey-i2c-state {
+ pins = "gpio71", "gpio72";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
- /* TODO: Figure out Mount Matrix */
+ nfc_default: nfc-default-state {
+ firmware-pins {
+ pins = "gpio92";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ irq-pins {
+ pins = "gpio106";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-down;
+ };
};
};
-&pm8921_mpps {
- flash_led_unlock: flash-led-unlock-state {
- pins = "mpp4";
- function = "digital";
- output-low;
- power-source = <PM8921_GPIO_S4>;
- };
+&usb_hs1_phy {
+ v3p3-supply = <&pm8921_l3>;
+ v1p8-supply = <&pm8921_l4>;
+};
+
+&usb1 {
+ dr_mode = "otg";
+ status = "okay";
};
--
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
* [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 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
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