* Re: [PATCH v2 1/4] dt-bindings: platform: introduce EC for Dell XPS 13 9345
From: Aleksandrs Vinarskis @ 2026-04-05 20:50 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans de Goede, Ilpo Järvinen, linux-arm-msm,
devicetree, linux-kernel, platform-driver-x86, laurentiu.tudor1,
Abel Vesa, Tobias Heider, Val Packett, Krzysztof Kozlowski
In-Reply-To: <e69ebf4a-126e-48c7-970b-1ba2a40a4492@linaro.org>
On Sunday, April 5th, 2026 at 02:05, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
> On 04/04/2026 13:55, Aleksandrs Vinarskis wrote:
> > Add bindings for Embedded Controller (EC) in Dell XPS 13 9345 (platform
> > codename 'tributo'). It may be partially or fully compatible with EC
> > found in Snapdragon-based Dell Latitude, Inspiron ('thena').
> >
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> > ---
> > .../embedded-controller/dell,xps13-9345-ec.yaml | 91 ++++++++++++++++++++++
> > MAINTAINERS | 5 ++
> > 2 files changed, 96 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml b/Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..e14dbf2f1a6af8cc7511890fbef08c6c717c0aa6
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
>
> I believe the part name of this embedded controller is the "mec5200" so
> instead of calling it dell,xps13-9345-ec suggest "dell,mec5200"
Correct, its Microchip MEC5200. I remember reading some series discussion
about not naming driver after IC its based on, but rather platform its
used for since driver depends on firmware which is platform specific...
cannot find that discussion now.
>
> > @@ -0,0 +1,91 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/embedded-controller/dell,xps13-9345-ec.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Dell XPS 13 9345 Embedded Controller
> > +
> > +maintainers:
> > + - Aleksandrs Vinarskis <alex@vinarskis.com>
> > +
> > +description:
> > + The Dell XPS 13 9345 has an Embedded Controller (EC) which handles thermal
> > + and power management. It is communicating with SoC over multiple i2c busses.
> > + Among other things, it handles fan speed control, thermal shutdown, peripheral
> > + power supply including trackpad, touch-row, display. For these functions, it
> > + requires frequently updated thermal readings from onboard thermistors.
> > +
> > +properties:
> > + compatible:
> > + const: dell,xps13-9345-ec
>
> Ditto the compat - name it after the IC not the laptop its a "mec5200"
> or "mec5200-ec" - I suspect the -ec postfix is a tautology the ec bit in
> "mec" probably captures.
I'm not sure I agree regarding the compatible, its supposed to be as exact as
possible. "dell,mec5200" will not allow us to differentiate between EC drivers
of "tributo" and "thena" for example.
Suggestion:
- Schema filename to be generalized "dell,mec5200-ec.yaml"
- Driver filename to be generalized "dell-mec5200-ec.c"
- Config to be generalized "EC_DELL_MEC5200"
- Compatible to stay specific "dell,xps13-9345-ec", with fallback to
"dell,mec5200-ec".
I would also keep "-ec" to stay consistent with naming convention of
existing drivers and bindings.
Let me know if this would work for you.
Alex
>
> > +
> > + reg:
> > + const: 0x3b
> > +
> > + interrupts:
> > + maxItems: 1
> > +
> > + io-channels:
> > + description:
> > + ADC channels connected to the 7 onboard thermistors on PMK8550.
> > + EC requires frequent thermal readings of these channels to perform
> > + automated fan speed control.
> > + items:
> > + - description: ADC channel for sys_therm0
> > + - description: ADC channel for sys_therm1
> > + - description: ADC channel for sys_therm2
> > + - description: ADC channel for sys_therm3
> > + - description: ADC channel for sys_therm4
> > + - description: ADC channel for sys_therm5
> > + - description: ADC channel for sys_therm6
> > +
> > + io-channel-names:
> > + items:
> > + - const: sys_therm0
> > + - const: sys_therm1
> > + - const: sys_therm2
> > + - const: sys_therm3
> > + - const: sys_therm4
> > + - const: sys_therm5
> > + - const: sys_therm6
>
>
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - interrupts
> > + - io-channels
> > + - io-channel-names
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/interrupt-controller/irq.h>
> > + #include <dt-bindings/iio/qcom,spmi-adc7-pm8350.h>
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + embedded-controller@3b {
> > + compatible = "dell,xps13-9345-ec";
> > + reg = <0x3b>;
> > + interrupts-extended = <&tlmm 66 IRQ_TYPE_LEVEL_LOW>;
> > +
> > + io-channels = <&pmk8550_vadc PM8350_ADC7_GPIO3_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_GPIO4_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM1_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM2_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM3_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM4_100K_PU(1)>,
> > + <&pmk8550_vadc PM8350_ADC7_AMUX_THM5_100K_PU(1)>;
> > + io-channel-names = "sys_therm0",
> > + "sys_therm1",
> > + "sys_therm2",
> > + "sys_therm3",
> > + "sys_therm4",
> > + "sys_therm5",
> > + "sys_therm6";
> > + };
> > + };
> > +...
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 96e0781f2201b41b976dfa69efd44d62c4ff0058..a5d175559f4468dfe363b319a1b08d3425f4d712 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7236,6 +7236,11 @@ S: Maintained
> > F: Documentation/ABI/testing/sysfs-class-firmware-attributes
> > F: drivers/platform/x86/dell/dell-wmi-sysman/
> >
> > +DELL XPS EMBEDDED CONTROLLER DRIVER
> > +M: Aleksandrs Vinarskis <alex@vinarskis.com>
> > +S: Maintained
> > +F: Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
> > +
> > DELTA AHE-50DC FAN CONTROL MODULE DRIVER
> > M: Zev Weiss <zev@bewilderbeest.net>
> > L: linux-hwmon@vger.kernel.org
> >
>
>
^ permalink raw reply
* Re: [net-next,PATCH v5 3/3] net: phy: realtek: Add property to enable SSC
From: Aleksander Jan Bajkowski @ 2026-04-05 20:23 UTC (permalink / raw)
To: Marek Vasut, netdev
Cc: David S. Miller, Andrew Lunn, Conor Dooley, Eric Dumazet,
Florian Fainelli, Heiner Kallweit, Ivan Galkin, Jakub Kicinski,
Krzysztof Kozlowski, Michael Klein, Paolo Abeni, Rob Herring,
Russell King, Vladimir Oltean, devicetree
In-Reply-To: <20260326210704.58912-3-marek.vasut@mailbox.org>
Hi Marek,
On 26/03/2026 22:06, Marek Vasut wrote:
> Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
> RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
> follows EMI improvement application note Rev. 1.2 for these PHYs.
>
> The current implementation enables SSC for both RXC and SYSCLK clock
> signals. Introduce DT properties 'realtek,clkout-ssc-enable',
> 'realtek,rxc-ssc-enable' and 'realtek,sysclk-ssc-enable' which control
> CLKOUT, RXC and SYSCLK SSC spread spectrum clocking enablement on these
> signals.
>
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: Ivan Galkin <ivan.galkin@axis.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Klein <michael@fossekall.de>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
> V2: Split SSC clock control for each CLKOUT, RXC, SYSCLK signal
> V3: Update RTL8211FVD PHYCR2 comment to state this PHY has PHYCR2 register,
> but SSC configuration is not supported due to different layout.
> V4: - Perform all SSC configuration before disabling CLKOUT
> - Perform all SSC configuration in the same order as in the SSC appnote
> - Rebase on current next, retest using spectrum analyzer again
> V5: s@SCC@SSC@ typo
> ---
> drivers/net/phy/realtek/realtek_main.c | 131 +++++++++++++++++++++++++
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> index 023e47ad605bd..0b5d35841fdd4 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -75,10 +75,18 @@
>
> #define RTL8211F_PHYCR2 0x19
> #define RTL8211F_CLKOUT_EN BIT(0)
> +#define RTL8211F_SYSCLK_SSC_EN BIT(3)
> #define RTL8211F_PHYCR2_PHY_EEE_ENABLE BIT(5)
> +#define RTL8211F_CLKOUT_SSC_EN BIT(7)
>
> #define RTL8211F_INSR 0x1d
>
> +/* RTL8211F SSC settings */
> +#define RTL8211F_SSC_PAGE 0xc44
> +#define RTL8211F_SSC_RXC 0x13
> +#define RTL8211F_SSC_SYSCLK 0x17
> +#define RTL8211F_SSC_CLKOUT 0x19
> +
> /* RTL8211F LED configuration */
> #define RTL8211F_LEDCR_PAGE 0xd04
> #define RTL8211F_LEDCR 0x10
> @@ -215,6 +223,9 @@ MODULE_LICENSE("GPL");
> struct rtl821x_priv {
> bool enable_aldps;
> bool disable_clk_out;
> + bool enable_clkout_ssc;
> + bool enable_rxc_ssc;
> + bool enable_sysclk_ssc;
> struct clk *clk;
> /* rtl8211f */
> u16 iner;
> @@ -278,6 +289,12 @@ static int rtl821x_probe(struct phy_device *phydev)
> "realtek,aldps-enable");
> priv->disable_clk_out = of_property_read_bool(dev->of_node,
> "realtek,clkout-disable");
> + priv->enable_clkout_ssc = of_property_read_bool(dev->of_node,
> + "realtek,clkout-ssc-enable");
> + priv->enable_rxc_ssc = of_property_read_bool(dev->of_node,
> + "realtek,rxc-ssc-enable");
> + priv->enable_sysclk_ssc = of_property_read_bool(dev->of_node,
> + "realtek,sysclk-ssc-enable");
>
> phydev->priv = priv;
>
> @@ -707,6 +724,108 @@ static int rtl8211f_config_phy_eee(struct phy_device *phydev)
> RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
> }
>
> +static int rtl8211f_config_clkout_ssc(struct phy_device *phydev)
> +{
> + struct rtl821x_priv *priv = phydev->priv;
> + struct device *dev = &phydev->mdio.dev;
> + int ret;
> +
> + /* The value is preserved if the device tree property is absent */
> + if (!priv->enable_clkout_ssc)
> + return 0;
> +
> + /* RTL8211FVD has PHYCR2 register, but configuration of CLKOUT SSC
> + * is not currently supported by this driver due to different bit
> + * layout.
> + */
> + if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
> + return 0;
> +
> + /* Unnamed registers from EMI improvement parameters application note 1.2 */
> + ret = phy_write_paged(phydev, 0xd09, 0x10, 0xcf00);
> + if (ret < 0) {
> + dev_err(dev, "CLKOUT SSC initialization failed: %pe\n", ERR_PTR(ret));
> + return ret;
> + }
> +
> + ret = phy_write(phydev, RTL8211F_SSC_CLKOUT, 0x38c3);
Only registers 0x10–0x17 require paged operations. The remaining registers
are mapped directly into the PHY address space. This is mentioned in commit
650e55f224a575cdb18c984b95036109519502d1. Paged and direct access return
the same results. With this in mind, I believe that RTL8211F_SSC_CLKOUT is
an alias for RTL8211F_PHYCR2 and is described on page 45 of the
datasheet[1].
1. RTL8211F(I)-CG/RTL8211FD(I)-CG Datasheet
Best Regards,
Aleksander
^ permalink raw reply
* Re: [PATCH v2 2/4] platform: arm64: dell-xps-ec: new driver
From: Aleksandrs Vinarskis @ 2026-04-05 20:48 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Hans de Goede, Ilpo Järvinen, linux-arm-msm,
devicetree, linux-kernel, platform-driver-x86, laurentiu.tudor1,
Abel Vesa, Tobias Heider, Val Packett
In-Reply-To: <6be0cefb-72e4-4a8a-8668-45994db6c5d8@linaro.org>
On Sunday, April 5th, 2026 at 02:29, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
> On 04/04/2026 13:55, Aleksandrs Vinarskis wrote:
> > Introduce EC driver for Dell XPS 13 9345 (codename 'tributo') which may
> > partially of fully compatible with Snapdragon-based Dell Latitude,
> > Inspiron ('thena'). Primary function of this driver is unblock EC's
> > thermal management, specifically to provide it with necessary
> > information to control device fans, peripherals power.
> >
> > The driver was developed primarily by analyzing ACPI DSDT's _DSM and
> > i2c dumps of communication between SoC and EC. Changes to Windows
> > driver's behavior include increasing temperature feed loop from ~50ms
> > to 100ms here.
> >
> > While Xps's EC is rather complex and controls practically all device
> > peripherals including touch row's brightness and special keys such as
> > mic mute, these do not go over this particular i2c interface.
> >
> > Not yet implemented features:
> > - On lid-close IRQ event is registered. Windows performs what to
> > appears to be thermistor constants readout, though its not obvious
> > what it used for.
> > - According to ACPI's _DSM there is a method to readout fans' RPM.
> > - Initial thermistor constants were sniffed from Windows, these can be
> > likely fine tuned for better cooling performance.
> > - There is additional temperature reading that Windows sents to EC but
> > more rare than others, likely SoC T_j / TZ98 or TZ4. This is the only
> > thermal zone who's reading can exceed 115C without triggering thermal
> > shutdown.
> > - Given similarities between 'tributo' and 'thena' platforms, including
> > EC i2c address, driver can be potentially extended to support both.
> >
> > Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/platform/arm64/Kconfig | 12 ++
> > drivers/platform/arm64/Makefile | 1 +
> > drivers/platform/arm64/dell-xps-ec.c | 267 +++++++++++++++++++++++++++++++++++
> > 4 files changed, 281 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index a5d175559f4468dfe363b319a1b08d3425f4d712..c150f57b60706224e5b24b0dfb3d8a9b81f36398 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -7240,6 +7240,7 @@ DELL XPS EMBEDDED CONTROLLER DRIVER
> > M: Aleksandrs Vinarskis <alex@vinarskis.com>
> > S: Maintained
> > F: Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
> > +F: drivers/platform/arm64/dell-xps-ec.c
> >
> > DELTA AHE-50DC FAN CONTROL MODULE DRIVER
> > M: Zev Weiss <zev@bewilderbeest.net>
> > diff --git a/drivers/platform/arm64/Kconfig b/drivers/platform/arm64/Kconfig
> > index 10f905d7d6bfa5fad30a0689d3a20481268c781e..0bc8f016032bb05cb3a7cc50bdf1092da04153bc 100644
> > --- a/drivers/platform/arm64/Kconfig
> > +++ b/drivers/platform/arm64/Kconfig
> > @@ -33,6 +33,18 @@ config EC_ACER_ASPIRE1
> > laptop where this information is not properly exposed via the
> > standard ACPI devices.
> >
> > +config EC_DELL_XPS
> > + tristate "Dell XPS 9345 Embedded Controller driver"
> > + depends on ARCH_QCOM || COMPILE_TEST
> > + depends on I2C
> > + depends on IIO
> > + help
> > + Driver for the Embedded Controller in the Qualcomm Snapdragon-based
> > + Dell XPS 13 9345, which handles thermal management and fan speed
> > + control.
> > +
> > + Say M or Y here to include this support.
> > +
> > config EC_HUAWEI_GAOKUN
> > tristate "Huawei Matebook E Go Embedded Controller driver"
> > depends on ARCH_QCOM || COMPILE_TEST
> > diff --git a/drivers/platform/arm64/Makefile b/drivers/platform/arm64/Makefile
> > index 60c131cff6a15bb51a49c9edab95badf513ee0f6..6768dc6c2310837374e67381cfc729bed1fdaaef 100644
> > --- a/drivers/platform/arm64/Makefile
> > +++ b/drivers/platform/arm64/Makefile
> > @@ -6,6 +6,7 @@
> > #
> >
> > obj-$(CONFIG_EC_ACER_ASPIRE1) += acer-aspire1-ec.o
> > +obj-$(CONFIG_EC_DELL_XPS) += dell-xps-ec.o
> > obj-$(CONFIG_EC_HUAWEI_GAOKUN) += huawei-gaokun-ec.o
> > obj-$(CONFIG_EC_LENOVO_YOGA_C630) += lenovo-yoga-c630.o
> > obj-$(CONFIG_EC_LENOVO_THINKPAD_T14S) += lenovo-thinkpad-t14s.o
> > diff --git a/drivers/platform/arm64/dell-xps-ec.c b/drivers/platform/arm64/dell-xps-ec.c
> > new file mode 100644
> > index 0000000000000000000000000000000000000000..bf1495fbe473ccdb82b95a66b56e8525f782cc8e
> > --- /dev/null
> > +++ b/drivers/platform/arm64/dell-xps-ec.c
> > @@ -0,0 +1,267 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (c) 2026, Aleksandrs Vinarskis <alex@vinarskis.com>
> > + */
> > +
> > +#include <linux/array_size.h>
> > +#include <linux/dev_printk.h>
> > +#include <linux/device.h>
> > +#include <linux/devm-helpers.h>
> > +#include <linux/err.h>
> > +#include <linux/i2c.h>
> > +#include <linux/iio/consumer.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/jiffies.h>
> > +#include <linux/module.h>
> > +#include <linux/pm.h>
> > +#include <linux/unaligned.h>
> > +#include <linux/workqueue.h>
> > +
> > +#define DELL_XPS_EC_SUSPEND_CMD 0xb9
> > +#define DELL_XPS_EC_SUSPEND_MSG_LEN 64
> > +
> > +#define DELL_XPS_EC_TEMP_CMD0 0xfb
> > +#define DELL_XPS_EC_TEMP_CMD1 0x20
> > +#define DELL_XPS_EC_TEMP_CMD3 0x02
> > +#define DELL_XPS_EC_TEMP_MSG_LEN 6
> > +#define DELL_XPS_EC_TEMP_POLL_JIFFIES msecs_to_jiffies(100)
> > +
> > +/*
> > + * Format:
> > + * - header/unknown (2 bytes)
> > + * - per-thermistor entries (3 bytes): thermistor_id, param1, param2
> > + */
> > +static const u8 dell_xps_ec_thermistor_profile[] = {
> > + 0xff, 0x54,
> > + 0x01, 0x00, 0x2b, /* sys_therm0 */
> > + 0x02, 0x44, 0x2a, /* sys_therm1 */
> > + 0x03, 0x44, 0x2b, /* sys_therm2 */
> > + 0x04, 0x44, 0x28, /* sys_therm3 */
> > + 0x05, 0x55, 0x2a, /* sys_therm4 */
> > + 0x06, 0x44, 0x26, /* sys_therm5 */
> > + 0x07, 0x44, 0x2b, /* sys_therm6 */
> > +};
> > +
> > +/*
> > + * Mapping from IIO channel name to EC command byte
> > + */
> > +static const struct {
> > + const char *name;
> > + u8 cmd;
> > +} dell_xps_ec_therms[] = {
> > + /* TODO: 0x01 is sent only occasionally, likely TZ98 or TZ4 */
> > + { "sys_therm0", 0x02 },
> > + { "sys_therm1", 0x03 },
> > + { "sys_therm2", 0x04 },
> > + { "sys_therm3", 0x05 },
> > + { "sys_therm4", 0x06 },
> > + { "sys_therm5", 0x07 },
> > + { "sys_therm6", 0x08 },
> > +};
>
> You could probably retrieve these strings from the dt if you really need
> them.
>
> I don't think you need static consts in your driver though you could
> just as easily do `sprintf("sys_therm%d\n", i) where you use
> ec_therms[i].name - the name is only used to print errors and you have
> the index of the channel when you do.
>
> It would be nicer to get the strings from DT - certainly make the string
> names mandatory but, then let the DT specify those names.
>
> Either that or just do the sprintf("sys_therm%d\n", i); for the index,
> whichever you wish yourself.
Hi Bryan,
Will answer here to all three comments about `sys_thermX`.
The reason I have added them as static consts here, and defined them in
the schema is because the order of the channels matters:
1. On my XPS (UEFI v2.11.0) changes in sys_therm2 immediately result in
changes in fan speeds. Other channels seemingly have no affect, at
least when spoofed one by one, implying that EC cares which value
is which.
2. As I do not know internals of the EC firmware, even if today the other
thermistor channels ordering is seemingly not relevant, we cannot be
sure it will not change with EC firmware upgrade.
I have reconstructed the order of channels by comparing i2c data dumps
and real-time temps on Windows, eg. sys_therm0 is sent to EC under id 0x02
and represents the TZ71 (around dram on XPS). There is no other reason to
have the names of the channels in this driver except for enforcing the
channel mapping, so `sprintf("sys_therm%d\n", i)` wouldn't be useful.
By allowing source and sink to define the names and not enforcing it in
schema we lose ability to force the correct order, there is no way of
knowing whether "lpddr5-therm" or "ssd-therm" goes first. By forcing
"sys_thermX" convention, one would need to figure which one is which,
for example by referring to laptop schematics. I assume, "thena"'s
schematics has thermistors labeled as "sys_thermX"?
I do agree that labels of the ADC nodes could be more useful for the
user. So far I followed the example of sc8280xp platforms that define
ADC channels with "sys_thermX". Perhaps, we could separate the
io-channel-names and ADC node labels then? eg:
+ io-channel-names = "sys_therm0",
+ "sys_therm1",
...
+ &pmk8550_vadc {
+ sys_therm0: channel@14c {
+ reg = <PM8350_ADC7_GPIO3_100K_PU(1)>;
+ qcom,hw-settle-time = <200>;
+ qcom,ratiometric;
+ label = "lpddr5x-therm";
Though not sure if such approach is 'legal'?
Alex
>
> > +
> > +struct dell_xps_ec {
> > + struct device *dev;
> > + struct i2c_client *client;
> > + struct iio_channel *therm_channels[ARRAY_SIZE(dell_xps_ec_therms)];
> > + struct delayed_work temp_work;
> > +};
> > +
> > +static int dell_xps_ec_suspend_cmd(struct dell_xps_ec *ec, bool suspend)
> > +{
> > + u8 buf[DELL_XPS_EC_SUSPEND_MSG_LEN] = {};
> > + int ret;
> > +
> > + buf[0] = DELL_XPS_EC_SUSPEND_CMD;
> > + buf[1] = suspend ? 0x01 : 0x00;
> > + /* bytes 2..63 remain zero */
> > +
> > + ret = i2c_master_send(ec->client, buf, sizeof(buf));
> > + if (ret < 0)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > +static int dell_xps_ec_send_temp(struct dell_xps_ec *ec, u8 cmd_byte,
> > + int milli_celsius)
> > +{
> > + u8 buf[DELL_XPS_EC_TEMP_MSG_LEN];
> > + u16 deci_celsius;
> > + int ret;
> > +
> > + /* Convert milli-Celsius to deci-Celsius (Celsius * 10) */
> > + deci_celsius = milli_celsius / 100;
> > +
> > + buf[0] = DELL_XPS_EC_TEMP_CMD0;
> > + buf[1] = DELL_XPS_EC_TEMP_CMD1;
> > + buf[2] = cmd_byte;
> > + buf[3] = DELL_XPS_EC_TEMP_CMD3;
> > + put_unaligned_le16(deci_celsius, &buf[4]);
> > +
> > + ret = i2c_master_send(ec->client, buf, sizeof(buf));
> > + if (ret < 0)
> > + return ret;
> > +
> > + return 0;
> > +}
> > +
> > +static void dell_xps_ec_temp_work_fn(struct work_struct *work)
> > +{
> > + struct dell_xps_ec *ec = container_of(work, struct dell_xps_ec,
> > + temp_work.work);
> > + int val, ret, i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(dell_xps_ec_therms); i++) {
> > + if (!ec->therm_channels[i])
> > + continue;
> > +
> > + ret = iio_read_channel_processed(ec->therm_channels[i], &val);
> > + if (ret < 0) {
> > + dev_err_ratelimited(ec->dev,
> > + "Failed to read thermistor %s: %d\n",
> > + dell_xps_ec_therms[i].name, ret);
> > + continue;
> > + }
> > +
> > + ret = dell_xps_ec_send_temp(ec, dell_xps_ec_therms[i].cmd, val);
> > + if (ret < 0) {
> > + dev_err_ratelimited(ec->dev,
> > + "Failed to send temp for %s: %d\n",
> > + dell_xps_ec_therms[i].name, ret);
> > + }
> > + }
> > +
> > + schedule_delayed_work(&ec->temp_work, DELL_XPS_EC_TEMP_POLL_JIFFIES);
> > +}
> > +
> > +static irqreturn_t dell_xps_ec_irq_handler(int irq, void *data)
> > +{
> > + struct dell_xps_ec *ec = data;
> > +
> > + /*
> > + * TODO: IRQ is fired on lid-close. Follow Windows example to read out
> > + * the thermistor thresholds and potentially fan speeds.
> > + */
> > + dev_info_ratelimited(ec->dev, "IRQ triggered! (irq=%d)\n", irq);
> > +
> > + return IRQ_HANDLED;
> > +}
> > +
> > +static int dell_xps_ec_probe(struct i2c_client *client)
> > +{
> > + struct device *dev = &client->dev;
> > + struct dell_xps_ec *ec;
> > + int ret, i;
> > +
> > + ec = devm_kzalloc(dev, sizeof(*ec), GFP_KERNEL);
> > + if (!ec)
> > + return -ENOMEM;
> > +
> > + ec->dev = dev;
> > + ec->client = client;
> > + i2c_set_clientdata(client, ec);
> > +
> > + /* Set default thermistor profile */
> > + ret = i2c_master_send(client, dell_xps_ec_thermistor_profile,
> > + sizeof(dell_xps_ec_thermistor_profile));
> > + if (ret < 0)
> > + return dev_err_probe(dev, ret, "Failed to set thermistor profile\n");
> > +
> > + /* Get IIO channels for thermistors */
> > + for (i = 0; i < ARRAY_SIZE(dell_xps_ec_therms); i++) {
> > + ec->therm_channels[i] =
> > + devm_iio_channel_get(dev, dell_xps_ec_therms[i].name);
> > + if (IS_ERR(ec->therm_channels[i])) {
> > + ret = PTR_ERR(ec->therm_channels[i]);
> > + ec->therm_channels[i] = NULL;
> > + if (ret == -EPROBE_DEFER)
> > + return ret;
> > + dev_warn(dev, "Thermistor %s not available: %d\n",
> > + dell_xps_ec_therms[i].name, ret);
> > + }
> > + }
> > +
> > + /* Start periodic temperature reporting */
> > + ret = devm_delayed_work_autocancel(dev, &ec->temp_work,
> > + dell_xps_ec_temp_work_fn);
> > + if (ret)
> > + return ret;
> \n
> > + schedule_delayed_work(&ec->temp_work, DELL_XPS_EC_TEMP_POLL_JIFFIES);
> > + dev_dbg(dev, "Started periodic temperature reporting to EC every %d ms\n",
> > + jiffies_to_msecs(DELL_XPS_EC_TEMP_POLL_JIFFIES));
> > +
> > + /* Request IRQ for EC events */
> > + ret = devm_request_threaded_irq(dev, client->irq, NULL,
> > + dell_xps_ec_irq_handler,
> > + IRQF_ONESHOT, dev_name(dev), ec);
> > + if (ret < 0)
> > + return dev_err_probe(dev, ret, "Failed to request IRQ\n");
> > +
> > + return 0;
> > +}
> > +
> > +/*
> > + * Notify EC of suspend
> > + *
> > + * This will:
> > + * - Cut power to display/trackpad/keyboard/touchrow, wake-up source still works
> > + */
> > +static int dell_xps_ec_suspend(struct device *dev)
> > +{
> > + struct dell_xps_ec *ec = dev_get_drvdata(dev);
> > +
> > + cancel_delayed_work_sync(&ec->temp_work);
> > +
> > + return dell_xps_ec_suspend_cmd(ec, true);
> > +}
> > +
> > +/*
> > + * Notify EC of resume
> > + *
> > + * This will undo the suspend actions
> > + * Without the resume signal, device would wake up but be forced back into
> > + * suspend by EC within seconds
> > + */
> > +static int dell_xps_ec_resume(struct device *dev)
> > +{
> > + struct dell_xps_ec *ec = dev_get_drvdata(dev);
> > + int ret;
> > +
> > + ret = dell_xps_ec_suspend_cmd(ec, false);
> > + if (ret)
> > + return ret;
> > +
> > + schedule_delayed_work(&ec->temp_work, DELL_XPS_EC_TEMP_POLL_JIFFIES);
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id dell_xps_ec_of_match[] = {
> > + { .compatible = "dell,xps13-9345-ec" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(of, dell_xps_ec_of_match);
> > +
> > +static const struct i2c_device_id dell_xps_ec_i2c_id[] = {
> > + { "dell-xps-ec" },
> > + {}
> > +};
> > +MODULE_DEVICE_TABLE(i2c, dell_xps_ec_i2c_id);
> > +
> > +static const struct dev_pm_ops dell_xps_ec_pm_ops = {
> > + SYSTEM_SLEEP_PM_OPS(dell_xps_ec_suspend, dell_xps_ec_resume)
> > +};
> > +
> > +static struct i2c_driver dell_xps_ec_driver = {
> > + .driver = {
> > + .name = "dell-xps-ec",
> > + .of_match_table = dell_xps_ec_of_match,
> > + .pm = &dell_xps_ec_pm_ops,
> > + },
> > + .probe = dell_xps_ec_probe,
> > + .id_table = dell_xps_ec_i2c_id,
> > +};
> > +module_i2c_driver(dell_xps_ec_driver);
> > +
> > +MODULE_AUTHOR("Aleksandrs Vinarskis <alex@vinarskis.com>");
> > +MODULE_DESCRIPTION("Dell XPS 13 9345 Embedded Controller");
> > +MODULE_LICENSE("GPL");
> >
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support
From: Laurent Pinchart @ 2026-04-05 20:47 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Loic Poulain, vladimir.zapolskiy, kieran.bingham, robh, krzk+dt,
andersson, konradybcio, linux-media, linux-arm-msm, devicetree,
linux-kernel, johannes.goede, mchehab
In-Reply-To: <d5bb1f75-f55f-43e6-8160-bacc4088b0a2@kernel.org>
On Sun, Apr 05, 2026 at 08:55:00PM +0100, Bryan O'Donoghue wrote:
> On 05/04/2026 20:48, Laurent Pinchart wrote:
> > I don't necessarily agree with that. There are pros and cons for using
> > HFI on platforms that have an ICP. If correctly written, a firmware can
> > improve the throughput in multi-camera use cases by reprogramming the
> > time-multiplexed OPE faster. On the other hand, in use cases that don't
> > require pushing the platform to its limits, dealing with a closed-source
> > firmware often causes lots of issues.
> >
> > We should aim at supporting both direct ISP access and HFI with the same
> > userspace API, even on a single platform. Which option to start with is
> > an open question that we should discuss.
>
> I think - for IPE and BPS ICP/HFI is the way to go.
>
> However thinking about it - inline pixel processing IPP inside of the
> IFE is superior to BPS/IPE for virtually every scenario i.e. why deliver
> a frame to user-space and then submit it directly to BPS via CDM or via
> a firmware interface HFI, if you can do the same processing in the IFE -
> which on the majority of qcom platforms, you can.
As always, it depends. Offline processing consumes more memory bandwidth
and introduces latency, *but* if the statistics are computed by the IFE,
then the OPE can process frames using statistics coming from the same
frame instead of previous frames. It can improve the reactivity of the
algorithms.
Some processing is also badly suited for inline pipelines. In
particular, DOL HDR stitching in an inline pipeline requires a large
amoung of line buffers, so many ISP vendors implement it in offline ISPs
only. Temporal denoising can also be more tricky in an inline ISP.
Processing is sometimes split between the inline and offline parts, with
inline processing in Bayer domain, covering processing algorithms that
don't benefit much from using stats from the same frame, and offline
processing taking over for the rest.
> Agatti is an outlier in that sense.
>
> So actually I've shifted my focus on Hamoa to IFE/IPP.
I'd love to get stats out of the IFE :-)
> You still BTW do want HFI for BPS/IPE - but to get 3a going on the vast
> majority of qcom platforms - you want the PIX/IPP path in the IFE.
>
> OTOH if you want to do offline bayer processing - taking say a saved
> file from the filesystem - then BPS/IPE is the way to do it and IMO HFI
> is the way to do that.
>
> But ICP/BPS/IPE is a nice to have.
We need a glossary :-)
> I realise that's a word-soup of TLAs but yeah, TL;DR IFE/IPP is the way
> to go on !Agatti and once we get a nice 3a loop going there a fun
> side-project would be offline bayer processing via HFI.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Bryan O'Donoghue @ 2026-04-05 20:28 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Loic Poulain, vladimir.zapolskiy, kieran.bingham, robh, krzk+dt,
andersson, konradybcio, linux-media, linux-arm-msm, devicetree,
linux-kernel, johannes.goede, mchehab
In-Reply-To: <20260405202431.GE1213462@killaraus.ideasonboard.com>
On 05/04/2026 21:24, Laurent Pinchart wrote:
>> We make the buffer in user-space which could be used by CDM but stage
>> the implementation.
> My proposal is to use an abstraction for the ISP parameters buffer, with
> logical parameters, and translate that to the CDM buffer in kernelspace,
> but in userspace context instead of IRQ handler context.
As I understand it, the parameters buffers can top out at nearly 2.5
megabytes.
However I haven't looked into the CDM format in detail so - it needs
anaylsis.
TBH I'm happy enough to follow a precedent, let's discuss further with
an analysis of CDM in hand.
---
bod
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Laurent Pinchart @ 2026-04-05 20:24 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Loic Poulain, vladimir.zapolskiy, kieran.bingham, robh, krzk+dt,
andersson, konradybcio, linux-media, linux-arm-msm, devicetree,
linux-kernel, johannes.goede, mchehab
In-Reply-To: <3bcd8500-ff6c-4a1f-8b7e-3e7c474f6345@kernel.org>
On Sun, Apr 05, 2026 at 09:15:47PM +0100, Bryan O'Donoghue wrote:
> On 05/04/2026 21:11, Laurent Pinchart wrote:
> > The mali-c55 driver does this, it translates the ISP parameters buffers
> > to a list of register values in userspace context, when the buffer is
> > queued. In the IRQ handler, it then either copies those values to
> > registers with MMIO writes, or use a DMA engine, depending on the
> > platform. The rppx1 driver does something similar, with a different
> > format for the buffer containing the register values.
> >
> > I think this architecture could be replicated here. This translation in
> > userspace context ensures that work at IRQ time is limited. The driver
> > can use whatever DMA engine is available depending on the platform, and
> > we can also force usage of MMIO for debugging or development purpose.
> > That way, development of ISP features is decoupled from development of
> > CDM support, enabling parallel development if desired, and faster
> > plaform enablement that allows starting the userspace side of the work
> > quicker.
>
> I think that's a reasonable plan.
>
> We make the buffer in user-space which could be used by CDM but stage
> the implementation.
My proposal is to use an abstraction for the ISP parameters buffer, with
logical parameters, and translate that to the CDM buffer in kernelspace,
but in userspace context instead of IRQ handler context.
> That way if CDM proves too hard, we can do MMIO for a while, and then
> transition to CDM if/when.
>
> For me though I really think translating between formats is storing up pain.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Laurent Pinchart @ 2026-04-05 20:23 UTC (permalink / raw)
To: Loic Poulain
Cc: Bryan O'Donoghue, johannes.goede, Dmitry Baryshkov,
vladimir.zapolskiy, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
mchehab
In-Reply-To: <CAFEp6-2EjvEogSdVNCEY-XwgYe7Bg_2d1me2EWhzDp8Cr=ZeLg@mail.gmail.com>
On Mon, Mar 30, 2026 at 09:07:59PM +0200, Loic Poulain wrote:
> On Mon, Mar 30, 2026 at 4:33 PM Bryan O'Donoghue wrote:
> > On 30/03/2026 15:27, johannes.goede@oss.qualcomm.com wrote:
> > >> That's another reason I bring up CDM again and again. We probably
> > >> don't want to fix to the wrong format for OPE, introduce the CDM
> > >> and then find we have to map from one format to another for large
> > >> and complex data over and over again for each frame or every N
> > >> frames.
> > >
> > > CDM is a much lower-level API then what is expected from
> > > a media-controller centric V4L2 driver. Basically the OPE
> > > driver will export:
> >
> > My concern is about wrappering one thing inside of another thing and
> > then stuffing it again back into CDM and doing the same on the way out.
>
> I think there will always be some level of copying involved. That
> said, we can pre‑build the CDM sequence in the drivers and only update
> the variable values, which should avoid significant overhead.
>
> If we start handling CDM formats directly on the user side, it would
> require exposing a lot of low‑level knowledge there (such as register
> layouts and offsets), and that would diverge from how other ISP
> implementations are structured. I’m concerned this would increase
> complexity and reduce portability.
Agreed, I don't think we should go in that direction. Translating the
parameters buffer to the format expecting by the CDM can be done in the
kernel in userspace context, and work in the IRQ handler will then
become minimal. As far as I understand the CDM expects a buffer that
contains register address and value pairs. This is exactly what the
R-Car V4H does, the rppx1 driver translates the parameters buffer to the
same register addresses and values format, and then passes it to the
VSP (which has the same role as the CDM here).
As mentioned in a separate e-mail, we also support programming the ISP
through MMIO. This creates more work in IRQ context, but is very useful
during development. Switching to MMIO just requires a different code
path in the IRQ handler that iterates over the registers
addresses/values in the VSP buffer, and writes to registers directly.
The architecture is very modular.
> > There are already 50 MMIO writes in the OPE ISR, I don't believe it is
> > sustainable to keep adding MMIO into that.
>
> Yes, I understand the concern. From our testing so far, however, this
> has not shown to be an issue. In addition, a full reconfiguration
> would only happen in specific cases, such as on explicit full
> configuration changes or during context switching. We can certainly
> look at implementing CDM, but at this stage it didn't seem to bring
> significant benefits, so I prefered to focus on other functional
> aspects, and revisit CDM once there is a clearer need, measurable
> gain, or if it becomes part of the uAPI as discussed here.
I agree. Let's design the driver with CDM in mind to have the right
abstraction layers, and work on CDM support in a second step. If someone
believes this should be done urgently, they can even help by working in
parallel with ISP features enablement.
> > I'm aware of a project in qcom that did something with making the CDM
> > format in libcamera and handed that off to kernel, recommend looking
> > into that.
>
> I will, thanks, I'm however, concerned about how acceptable this
> approach would be to the wider community and to the maintainers.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Bryan O'Donoghue @ 2026-04-05 20:15 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Loic Poulain, vladimir.zapolskiy, kieran.bingham, robh, krzk+dt,
andersson, konradybcio, linux-media, linux-arm-msm, devicetree,
linux-kernel, johannes.goede, mchehab
In-Reply-To: <20260405201129.GB1213462@killaraus.ideasonboard.com>
On 05/04/2026 21:11, Laurent Pinchart wrote:
> The mali-c55 driver does this, it translates the ISP parameters buffers
> to a list of register values in userspace context, when the buffer is
> queued. In the IRQ handler, it then either copies those values to
> registers with MMIO writes, or use a DMA engine, depending on the
> platform. The rppx1 driver does something similar, with a different
> format for the buffer containing the register values.
>
> I think this architecture could be replicated here. This translation in
> userspace context ensures that work at IRQ time is limited. The driver
> can use whatever DMA engine is available depending on the platform, and
> we can also force usage of MMIO for debugging or development purpose.
> That way, development of ISP features is decoupled from development of
> CDM support, enabling parallel development if desired, and faster
> plaform enablement that allows starting the userspace side of the work
> quicker.
I think that's a reasonable plan.
We make the buffer in user-space which could be used by CDM but stage
the implementation.
That way if CDM proves too hard, we can do MMIO for a while, and then
transition to CDM if/when.
For me though I really think translating between formats is storing up pain.
---
bod
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Laurent Pinchart @ 2026-04-05 20:14 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Bryan O'Donoghue, johannes.goede, Loic Poulain,
vladimir.zapolskiy, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
mchehab
In-Reply-To: <4hasliun3wkook2pvfkntjlzs7elu67ine5q7nd7ptjthx5qvw@rntvb7lnajpc>
On Mon, Mar 30, 2026 at 09:55:23PM +0300, Dmitry Baryshkov wrote:
> On Mon, Mar 30, 2026 at 03:11:58PM +0100, Bryan O'Donoghue wrote:
> > On 30/03/2026 14:46, johannes.goede@oss.qualcomm.com wrote:
> > > > > And then your CCMv1 or CCMv2 helper will get called with
> > > > > the matching parameter-data.
> > > >
> > > > This leads to userspace having to know exact format for each hardware
> > > > version, which is not nice. At the very least it should be possible to
> > > > accept CCMv1 buffers and covert them to CCMv2 when required.
> > >
> > > Yes, but a new ISP may also have a different pipeline altogether
> > > with e.g. more then one preview/viewfinder output vs one viewfinder
> > > output for current hw, etc.
> >
> > My scoping on HFI shows that the IQ structures between Kona and later
> > versions have pretty stable data-structures.
> >
> > It might be worthwhile for the non-HFI version to implement those
> > structures.
> >
> > I keep mentioning CDM. Its also possible to construct the buffer in the
> > format the CDM would require and hand that from user-space into the kernel.
> >
> > That would save alot of overhead translating from one format to another.
> >
> > That's another reason I bring up CDM again and again. We probably don't want
> > to fix to the wrong format for OPE, introduce the CDM and then find we have
> > to map from one format to another for large and complex data over and over
> > again for each frame or every N frames.
> >
> > TBH I think the CDM should happen for this system and in that vein is there
> > any reason not to pack the data in the order the CDM will want ?
>
> This sounds like the most horrible idea: letting userspace directly
> program any registers in a way that is not visible to the kernel.
ISP hardware is typically not designed to make this safe, so I would be
really, really careful about going in that direction. It also seems a
dangerous idea to me.
> > So probably in fact IQ structs are not the right thing for OPE+IFE.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC PATCH 2/3] media: qcom: camss: Add CAMSS Offline Processing Engine driver
From: Laurent Pinchart @ 2026-04-05 20:11 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Loic Poulain, vladimir.zapolskiy, kieran.bingham, robh, krzk+dt,
andersson, konradybcio, linux-media, linux-arm-msm, devicetree,
linux-kernel, johannes.goede, mchehab
In-Reply-To: <12194cc0-0960-486c-be7e-1a22d95de340@kernel.org>
On Tue, Mar 24, 2026 at 11:00:21AM +0000, Bryan O'Donoghue wrote:
> On 23/03/2026 15:31, Loic Poulain wrote:
[snip]
> >>> +static void ope_prog_stripe(struct ope_ctx *ctx, struct ope_stripe *stripe)
> >>> +{
> >>> + struct ope_dev *ope = ctx->ope;
> >>> + int i;
> >>> +
> >>> + dev_dbg(ope->dev, "Context %p - Programming S%u\n", ctx, ope_stripe_index(ctx, stripe));
> >>> +
> >>> + /* Fetch Engine */
> >>> + ope_write_rd(ope, OPE_BUS_RD_CLIENT_0_UNPACK_CFG_0, stripe->src.format);
> >>> + ope_write_rd(ope, OPE_BUS_RD_CLIENT_0_RD_BUFFER_SIZE,
> >>> + (stripe->src.width << 16) + stripe->src.height);
> >>> + ope_write_rd(ope, OPE_BUS_RD_CLIENT_0_ADDR_IMAGE, stripe->src.addr);
> >>> + ope_write_rd(ope, OPE_BUS_RD_CLIENT_0_RD_STRIDE, stripe->src.stride);
> >>> + ope_write_rd(ope, OPE_BUS_RD_CLIENT_0_CCIF_META_DATA,
> >>> + FIELD_PREP(OPE_BUS_RD_CLIENT_0_CCIF_MD_PIX_PATTERN, stripe->src.pattern));
> >>> + ope_write_rd(ope, OPE_BUS_RD_CLIENT_0_CORE_CFG, OPE_BUS_RD_CLIENT_0_CORE_CFG_EN);
> >>> +
> >>> + /* Write Engines */
> >>> + for (i = 0; i < OPE_WR_CLIENT_MAX; i++) {
> >>> + if (!stripe->dst[i].enabled) {
> >>> + ope_write_wr(ope, OPE_BUS_WR_CLIENT_CFG(i), 0);
> >>> + continue;
> >>> + }
> >>> +
> >>> + ope_write_wr(ope, OPE_BUS_WR_CLIENT_ADDR_IMAGE(i), stripe->dst[i].addr);
> >>> + ope_write_wr(ope, OPE_BUS_WR_CLIENT_IMAGE_CFG_0(i),
> >>> + (stripe->dst[i].height << 16) + stripe->dst[i].width);
> >>> + ope_write_wr(ope, OPE_BUS_WR_CLIENT_IMAGE_CFG_1(i), stripe->dst[i].x_init);
> >>> + ope_write_wr(ope, OPE_BUS_WR_CLIENT_IMAGE_CFG_2(i), stripe->dst[i].stride);
> >>> + ope_write_wr(ope, OPE_BUS_WR_CLIENT_PACKER_CFG(i), stripe->dst[i].format);
> >>> + ope_write_wr(ope, OPE_BUS_WR_CLIENT_CFG(i),
> >>> + OPE_BUS_WR_CLIENT_CFG_EN + OPE_BUS_WR_CLIENT_CFG_AUTORECOVER);
> >>> + }
> >>> +
> >>> + /* Downscalers */
> >>> + for (i = 0; i < OPE_DS_MAX; i++) {
> >>> + struct ope_dsc_config *dsc = &stripe->dsc[i];
> >>> + u32 base = ope_ds_base[i];
> >>> + u32 cfg = 0;
> >>> +
> >>> + if (dsc->input_width != dsc->output_width) {
> >>> + dsc->phase_step_h |= DS_RESOLUTION(dsc->input_width,
> >>> + dsc->output_width) << 30;
> >>> + cfg |= OPE_PP_CLC_DOWNSCALE_MN_DS_CFG_H_SCALE_EN;
> >>> + }
> >>> +
> >>> + if (dsc->input_height != dsc->output_height) {
> >>> + dsc->phase_step_v |= DS_RESOLUTION(dsc->input_height,
> >>> + dsc->output_height) << 30;
> >>> + cfg |= OPE_PP_CLC_DOWNSCALE_MN_DS_CFG_V_SCALE_EN;
> >>> + }
> >>> +
> >>> + ope_write_pp(ope, OPE_PP_CLC_DOWNSCALE_MN_DS_CFG(base), cfg);
> >>> + ope_write_pp(ope, OPE_PP_CLC_DOWNSCALE_MN_DS_IMAGE_SIZE_CFG(base),
> >>> + ((dsc->input_width - 1) << 16) + dsc->input_height - 1);
> >>> + ope_write_pp(ope, OPE_PP_CLC_DOWNSCALE_MN_DS_MN_H_CFG(base), dsc->phase_step_h);
> >>> + ope_write_pp(ope, OPE_PP_CLC_DOWNSCALE_MN_DS_MN_V_CFG(base), dsc->phase_step_v);
> >>> + ope_write_pp(ope, OPE_PP_CLC_DOWNSCALE_MN_CFG(base),
> >>> + cfg ? OPE_PP_CLC_DOWNSCALE_MN_CFG_EN : 0);
> >>> + }
> >>> +}
> >>
> >> So - this is where the CDM should be used - so that you don't have to do
> >> all of these MMIO writes inside of your ISR.
> >
> > Indeed, and that also the reason stripes are computed ahead of time,
> > so that they can be further 'queued' in a CDM.
> >
> >> Is that and additional step after the RFC ?
> > The current implementation (without CDM) already provides good results
> > and performance, so CDM can be viewed as a future enhancement.
>
> That's true but then the number of MMIO writes per ISR is pretty small
> right now. You have about 50 writes here.
>
> > As far as I understand, CDM could also be implemented in a generic way
> > within CAMSS, since other CAMSS blocks make use of CDM as well.
> > This is something we should discuss further.
>
> My concern is even conservatively if each module adds another 10 ?
> writes by the time we get to denoising, sharpening, lens shade
> correction, those writes could easily look more like 100.
>
> What user-space should submit is well documented data-structures which
> then get translated into CDM buffers by the OPE and IFE for the various
> bits of the pipeline.
The mali-c55 driver does this, it translates the ISP parameters buffers
to a list of register values in userspace context, when the buffer is
queued. In the IRQ handler, it then either copies those values to
registers with MMIO writes, or use a DMA engine, depending on the
platform. The rppx1 driver does something similar, with a different
format for the buffer containing the register values.
I think this architecture could be replicated here. This translation in
userspace context ensures that work at IRQ time is limited. The driver
can use whatever DMA engine is available depending on the platform, and
we can also force usage of MMIO for debugging or development purpose.
That way, development of ISP features is decoupled from development of
CDM support, enabling parallel development if desired, and faster
plaform enablement that allows starting the userspace side of the work
quicker.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v7 00/15] arm64: dts: qcom: sdm845-lg: Improve hardware support in devicetree
From: Paul Sajna @ 2026-04-05 20:00 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Konrad Dybcio, Dmitry Baryshkov, Pavel Machek
In-Reply-To: <177541802142.2061229.9094394728986735362.b4-ty@kernel.org>
April 5, 2026 at 7:40 PM, "Bjorn Andersson" <andersson@kernel.org mailto:andersson@kernel.org?to=%22Bjorn%20Andersson%22%20%3Candersson%40kernel.org%3E > wrote:
> Applied, thanks!
>
> [01/15] arm64: dts: qcom: sdm845-lg-common: Sort nodes and properties
> commit: 6a9e8df732014c1c758bd3cd6254b5b4cb273c7f
> [02/15] arm64: dts: qcom: sdm845-lg-judyln: Add firmware nodes, change path
> commit: b9afe8581c0e14b7b56e2314dc7f9597bf23ef67
> [03/15] arm64: dts: qcom: sdm845-lg-judyp: Define firmware paths for judyp
> commit: 8f4c53ae286bd6a113245ad53ce957e623374cf0
> [04/15] arm64: dts: qcom: sdm845-lg-common: Enable venus
> commit: e9f611de7ab51540c0cf246df6b7d4d99f4cec64
> [05/15] arm64: dts: qcom: sdm845-lg-common: Enable qups and their dma controllers
> commit: 4ec3045c969a326c458c53ca65bde5749e575d52
> [06/15] arm64: dts: qcom: sdm845-lg: Add uarts and Bluetooth
> commit: e746ed5af3084e9534135679c55e69eced0c657f
> [07/15] arm64: dts: qcom: sdm845-lg-judyln: Add battery and charger
> commit: 995c258982429db93db103fc26fcb3a0acd6a5ee
> [08/15] arm64: dts: qcom: sdm845-lg-common: Add LEDs
> commit: b49722c8a18cdd11f49357f3b8be23549f76a506
> [09/15] arm64: dts: qcom: sdm845-lg-judyln: Add lab/ibb
> commit: 2e7cdd400b6a4e67c27fc3e839342824b51d01ff
> [10/15] arm64: dts: qcom: sdm845-lg-judyln: Add display panel
> commit: c6c66aa3ef33dc3076c6dac64003b29bd9515b58
> [11/15] arm64: dts: qcom: sdm845-lg: Add wifi nodes
> commit: eb8fa32085261a07d763e9d616b3c206d0be82ff
> [12/15] arm64: dts: qcom: sdm845-lg-common: Add chassis-type
> commit: a5a5ad9848980e1019ca841fe057afb83debecfa
I'm new at this, so there might be some mistakes/misunderstandings, but I sent a v8 with 1 tiny change for Konrad you might want to apply that instead.
And also the last 3 patches that got stuck in my mailserver didn't apply? I resent them manually with git send-email.
^ permalink raw reply
* Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support
From: Laurent Pinchart @ 2026-04-05 19:57 UTC (permalink / raw)
To: Loic Poulain
Cc: bod, vladimir.zapolskiy, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
johannes.goede, mchehab
In-Reply-To: <20260323125824.211615-1-loic.poulain@oss.qualcomm.com>
Hi Loic,
I'm really happy to see this on the list :-)
On Mon, Mar 23, 2026 at 01:58:21PM +0100, Loic Poulain wrote:
> This RFC series introduces initial support for the Qualcomm CAMSS
> Offline Processing Engine (OPE), as found on Agatti-based platforms.
> Boards such as Arduino UNO-Q use this SoC family and will benefit
> from hardware-assisted image processing enabled by this work.
>
> This represents the first step toward enabling image processing beyond
> raw capture on Qualcomm platforms by using hardware blocks for
> operations such as debayering, 3A, and scaling.
I assume you mean colour gains instead of 3A, based on what I can see in
the driver. I'm looking forward to hardware support for the rest of the
3A :-)
> The OPE sits outside the live capture pipeline. It operates on frames
> fetched from system memory and writes processed results back to memory.
> Because of this design, the OPE is not tied to any specific capture
> interface: frames may come from CAMSS RDI or PIX paths, or from any
> other producer capable of providing memory-backed buffers.
>
> The hardware can sustain up to 580 megapixels per second, which is
> sufficient to process a 10MPix stream at 60 fps or to handle four
> parallel 2MPix (HD) streams at 60 fps.
Isn't 10 MPix/frame * 60 fps = 600 MPix/s, higher than 580 MPix/s ?
> The initial driver implementation relies on the V4L2 m2m framework
> to keep the design simple while already enabling practical offline
> processing workflows. This model also provides time-sharing across
> multiple contexts through its built-in scheduling.
I understand this decision, but that will need to change. In order to
enable support for more ISP processing blocks, we will need to introduce
parameter buffers. The rkisp1 and mali-c55 drivers are two examples of
how it can be done. If you need any help, please don't hesitate to reach
out.
> This first version is intentionally minimalistic. It provides a working
> configuration using a fixed set of static processing parameters, mainly
> to achieve correct and good-quality debayering.
>
> Support for more advanced use-cases (dynamic parameters, statistics
> outputs, additional data endpoints) will require evolving the driver
> model beyond a pure m2m design. This may involve either moving away
> from m2m, as other ISP drivers do, or extending it to support auxiliary
> endpoints for parameters and statistics.
Ah, I should have read this before writing the above :-) Let's align the
userspace API of driver with the other ISP drivers.
> This series includes:
> - dt-binding schema for CAMSS OPE
> - initial CAMSS OPE driver
> - QCM2290 device tree node describing the hardware block.
>
> Feedback on the architecture and expected uAPI direction is especially
> welcome.
>
> Loic Poulain (3):
> dt-bindings: media: qcom: Add CAMSS Offline Processing Engine (OPE)
> media: qcom: camss: Add CAMSS Offline Processing Engine driver
> arm64: dts: qcom: qcm2290: Add CAMSS OPE node
>
> .../bindings/media/qcom,camss-ope.yaml | 87 +
> arch/arm64/boot/dts/qcom/agatti.dtsi | 72 +
> drivers/media/platform/qcom/camss/Makefile | 4 +
> drivers/media/platform/qcom/camss/camss-ope.c | 2058 +++++++++++++++++
> 4 files changed, 2221 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/qcom,camss-ope.yaml
> create mode 100644 drivers/media/platform/qcom/camss/camss-ope.c
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support
From: Bryan O'Donoghue @ 2026-04-05 19:55 UTC (permalink / raw)
To: Laurent Pinchart, Loic Poulain
Cc: vladimir.zapolskiy, kieran.bingham, robh, krzk+dt, andersson,
konradybcio, linux-media, linux-arm-msm, devicetree, linux-kernel,
johannes.goede, mchehab
In-Reply-To: <20260405194851.GA3972481@killaraus.ideasonboard.com>
On 05/04/2026 20:48, Laurent Pinchart wrote:
> I don't necessarily agree with that. There are pros and cons for using
> HFI on platforms that have an ICP. If correctly written, a firmware can
> improve the throughput in multi-camera use cases by reprogramming the
> time-multiplexed OPE faster. On the other hand, in use cases that don't
> require pushing the platform to its limits, dealing with a closed-source
> firmware often causes lots of issues.
>
> We should aim at supporting both direct ISP access and HFI with the same
> userspace API, even on a single platform. Which option to start with is
> an open question that we should discuss.
I think - for IPE and BPS ICP/HFI is the way to go.
However thinking about it - inline pixel processing IPP inside of the
IFE is superior to BPS/IPE for virtually every scenario i.e. why deliver
a frame to user-space and then submit it directly to BPS via CDM or via
a firmware interface HFI, if you can do the same processing in the IFE -
which on the majority of qcom platforms, you can.
Agatti is an outlier in that sense.
So actually I've shifted my focus on Hamoa to IFE/IPP.
You still BTW do want HFI for BPS/IPE - but to get 3a going on the vast
majority of qcom platforms - you want the PIX/IPP path in the IFE.
OTOH if you want to do offline bayer processing - taking say a saved
file from the filesystem - then BPS/IPE is the way to do it and IMO HFI
is the way to do that.
But ICP/BPS/IPE is a nice to have.
I realise that's a word-soup of TLAs but yeah, TL;DR IFE/IPP is the way
to go on !Agatti and once we get a nice 3a loop going there a fun
side-project would be offline bayer processing via HFI.
---
bod
^ permalink raw reply
* Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support
From: Laurent Pinchart @ 2026-04-05 19:48 UTC (permalink / raw)
To: Loic Poulain
Cc: Bryan O'Donoghue, vladimir.zapolskiy, kieran.bingham, robh,
krzk+dt, andersson, konradybcio, linux-media, linux-arm-msm,
devicetree, linux-kernel, johannes.goede, mchehab
In-Reply-To: <CAFEp6-2NniQquVrw_V8P_cyUayMMY0SPC8hgczjB3ef5zx7e5A@mail.gmail.com>
On Tue, Mar 24, 2026 at 05:16:21PM +0100, Loic Poulain wrote:
> On Tue, Mar 24, 2026 at 1:54 PM Bryan O'Donoghue wrote:
> > On 23/03/2026 12:58, Loic Poulain wrote:
> > > This first version is intentionally minimalistic. It provides a working
> > > configuration using a fixed set of static processing parameters, mainly
> > > to achieve correct and good-quality debayering.
> >
> > You need the other 50% of the kernel side - the generation of bayer
> > statistics in the IFE, as well as generation of parameters to feed back
> > into the OPE - which requires a user-space implementation too, so a lot
> > of work there too.
> >
> > I'd also say when we have an ICP we should be using it via the HFI
> > protocol, thus burying all of the IPE/OPE BPS and CDM complexity in the
> > firmware.
> >
> > Understood Agatti has no ICP so you're limited to direct OPE/IFE
> > register access here. For HFI capable platforms - the majority - HFI is
> > the way to go.
>
> Fully agree, this is exactly the point where we should sync and work
> together on a proper solution.
I don't necessarily agree with that. There are pros and cons for using
HFI on platforms that have an ICP. If correctly written, a firmware can
improve the throughput in multi-camera use cases by reprogramming the
time-multiplexed OPE faster. On the other hand, in use cases that don't
require pushing the platform to its limits, dealing with a closed-source
firmware often causes lots of issues.
We should aim at supporting both direct ISP access and HFI with the same
userspace API, even on a single platform. Which option to start with is
an open question that we should discuss.
> As a follow‑up to this RFC, I already have several ongoing pieces that
> aim to generalize the CAMSS ISP support, and I’d very much like to
> discuss them with you:
>
> - camss-isp-m2m: Generic M2M scheduling framework handling job dispatch
> based on buffer readiness and enabled endpoints (frame input, output,
> statistics, parameters).
This should be generic, not limited to camss. v4l2-isp is a good
candidate.
> - camss-isp-pipeline: Helper layer to construct complex media/ISP graphs
> from a structural description (endpoints, links, etc.).
That also doesn't seem specific to camss.
> - camss-isp-params: Generic helper for handling ISP parameter buffers
> (using v4l2-isp-params).
I'm curious to know what camss-specific helpers you envision there.
> - camss-isp-stats: Generic helper framework for CAMSS statistics devices.
Same.
> - camss-(isp-)ope: OPE‑specific logic only (register configuration, IRQ
> handling, parameter‑to‑register translation).
>
> This approach should significantly reduce the amount of
> platform‑specific code required for future ISP blocks. It should also
> allow you to integrate a camss-isp-hamoa (or similar) backend, or even
> a camss-isp-hfi implementation for the M2M functions, without
> duplicating the infrastructure.
>
> So yes, let’s sync and agree on a shared/open development model and an
> overall direction, possibly even a common tree, to ensure we stay
> aligned and can collaborate effectively.
Let's schedule a call to kickstart those discussions. Many people are on
Easter vacation this week, next week could be a good candidate.
> > I'll publish an RFC for Hamoa for that soonish so we can make sure both
> > coexist.
>
> Ack.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: (subset) [PATCH v6 0/5] Add CCI and imx577 sensor support for Talos evk
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Loic Poulain, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Robert Foss, Todor Tomov,
Bryan O'Donoghue, Vladimir Zapolskiy, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Frank Li, Wenmeng Liu
Cc: linux-i2c, linux-arm-msm, devicetree, linux-kernel, linux-media,
imx, linux-arm-kernel, Krzysztof Kozlowski, Konrad Dybcio,
Dmitry Baryshkov
In-Reply-To: <20260305-sm6150_evk-v6-0-38ce4360d5e0@oss.qualcomm.com>
On Thu, 05 Mar 2026 17:48:11 +0800, Wenmeng Liu wrote:
> Talos EVK is based on the Qualcomm SM6150 SoC.
> It lacks a camera sensor in its default configuration.
> This series adds CCI support and enables the IMX577 sensor via CSIPHY1
> through device tree overlay.
>
> We have tested IMX577 Sensor on CCI1 with following commands:
> - media-ctl -d /dev/media0 --reset
> - media-ctl -d /dev/media0 -V '"imx577 1-001a":0[fmt:SRGGB10/4056x3040 field:none]'
> - media-ctl -d /dev/media0 -V '"msm_csiphy1":0[fmt:SRGGB10/4056x3040]'
> - media-ctl -d /dev/media0 -V '"msm_csid0":0[fmt:SRGGB10/4056x3040]'
> - media-ctl -d /dev/media0 -V '"msm_vfe0_rdi0":0[fmt:SRGGB10/4056x3040]'
> - media-ctl -d /dev/media0 -l '"msm_csiphy1":1->"msm_csid0":0[1]'
> - media-ctl -d /dev/media0 -l '"msm_csid0":1->"msm_vfe0_rdi0":0[1]'
> - yavta -B capture-mplane -n 5 -f SRGGB10P -s 4056x3040 -F /dev/video0 --capture=5
>
> [...]
Applied, thanks!
[2/5] arm64: dts: qcom: talos: Add camss node
commit: c0b357d5d059812e5b48fab81270d8f4c8f62162
[3/5] arm64: dts: qcom: talos: Add CCI definitions
commit: 17ba0a3c874684c9ca5a41ddf9f167648b10aad2
[4/5] arm64: dts: qcom: talos: Add camera MCLK pinctrl
commit: fd3850cde71f284ca69f70b904df78f561ece103
[5/5] arm64: dts: qcom: talos-evk-camera: Add DT overlay
commit: 594be93cdc9dcfec5d10882ed3fccce1e3af9015
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v4 0/3] media: qcom: camss: Add sm6150 camss support
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Robert Foss, Todor Tomov, Bryan O'Donoghue,
Vladimir Zapolskiy, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Wenmeng Liu
Cc: linux-media, linux-arm-msm, devicetree, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260112-sm6150-camss-v4-0-0cd576d627f7@oss.qualcomm.com>
On Mon, 12 Jan 2026 16:04:51 +0800, Wenmeng Liu wrote:
> SM6150 is a Qualcomm flagship SoC. This series adds support to
> the CSIPHY, CSID, VFE/RDI interfaces in SM6150.
>
> The SM6150 platform provides:
> - 2 x VFE (version 170), each with 3 RDI
> - 1 x VFE Lite (version 170), each with 4 RDI
> - 2 x CSID (version 170)
> - 1 x CSID Lite (version 170)
> - 3 x CSIPHY (version 2.0.0)
> - 1 x BPS (Bayer Processing Segment)
> - 1 x ICP (Imaging Control Processor)
> - 1 x IPE (Image Postprocessing Engine)
> - 1 x JPEG Encoder/Decoder
> - 1 x LRME (Low Resolution Motion Estimation)
>
> [...]
Applied, thanks!
[3/3] arm64: dts: qcom: talos: Add camss node
commit: c0b357d5d059812e5b48fab81270d8f4c8f62162
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v16 0/3] Add Qualcomm Technologies, Inc. Talos EVK SMARC support
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: konradybcio, Sudarshan Shetty
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260331060107.501561-1-tessolveupstream@gmail.com>
On Tue, 31 Mar 2026 11:31:04 +0530, Sudarshan Shetty wrote:
> This patch series adds device tree binding and board support for the
> Qualcomm Technologies, Inc. Talos EVK SMARC platform based on the
> QCS615 SoC.
>
> The first patch introduces the DT binding entry for the Talos EVK
> SMARC board, and the next patches adds the corresponding DTS
> files for the platform.
>
> [...]
Applied, thanks!
[1/3] dt-bindings: arm: qcom: talos-evk: Add QCS615 Talos EVK SMARC platform
commit: 44a47bd49a574bd6365f64d5d6f724c2e8d466df
[2/3] arm64: dts: qcom: talos/qcs615-ride: Fix inconsistent USB PHY node naming
commit: 83a679d61e8d18787ddc6c2f406546bb80dd2a8d
[3/3] arm64: dts: qcom: talos-evk: Add support for QCS615 talos evk board
commit: 0f9e6db8a2237e41209322017e2e9c45729d6d45
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v7 00/15] arm64: dts: qcom: sdm845-lg: Improve hardware support in devicetree
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
David Heidelberg, Paul Sajna
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Amir Dahan, Christopher Brown,
Konrad Dybcio, Dmitry Baryshkov, Pavel Machek
In-Reply-To: <20260331-judyln-dts-v7-0-87217b15fefb@postmarketos.org>
On Tue, 31 Mar 2026 20:15:05 -0700, Paul Sajna wrote:
> Rollup of improved hardware support via devicetree for LG G7 ThinQ
> (judyln) from sdm845-mainline kernel fork
>
> Notably, this patch-series enables full DRM acceleration and wifi,
> among other small improvements in individual commits
>
> after this patch-series the main things that remain to be worked
> on include touchscreen, audio, and modem.
>
> [...]
Applied, thanks!
[01/15] arm64: dts: qcom: sdm845-lg-common: Sort nodes and properties
commit: 6a9e8df732014c1c758bd3cd6254b5b4cb273c7f
[02/15] arm64: dts: qcom: sdm845-lg-judyln: Add firmware nodes, change path
commit: b9afe8581c0e14b7b56e2314dc7f9597bf23ef67
[03/15] arm64: dts: qcom: sdm845-lg-judyp: Define firmware paths for judyp
commit: 8f4c53ae286bd6a113245ad53ce957e623374cf0
[04/15] arm64: dts: qcom: sdm845-lg-common: Enable venus
commit: e9f611de7ab51540c0cf246df6b7d4d99f4cec64
[05/15] arm64: dts: qcom: sdm845-lg-common: Enable qups and their dma controllers
commit: 4ec3045c969a326c458c53ca65bde5749e575d52
[06/15] arm64: dts: qcom: sdm845-lg: Add uarts and Bluetooth
commit: e746ed5af3084e9534135679c55e69eced0c657f
[07/15] arm64: dts: qcom: sdm845-lg-judyln: Add battery and charger
commit: 995c258982429db93db103fc26fcb3a0acd6a5ee
[08/15] arm64: dts: qcom: sdm845-lg-common: Add LEDs
commit: b49722c8a18cdd11f49357f3b8be23549f76a506
[09/15] arm64: dts: qcom: sdm845-lg-judyln: Add lab/ibb
commit: 2e7cdd400b6a4e67c27fc3e839342824b51d01ff
[10/15] arm64: dts: qcom: sdm845-lg-judyln: Add display panel
commit: c6c66aa3ef33dc3076c6dac64003b29bd9515b58
[11/15] arm64: dts: qcom: sdm845-lg: Add wifi nodes
commit: eb8fa32085261a07d763e9d616b3c206d0be82ff
[12/15] arm64: dts: qcom: sdm845-lg-common: Add chassis-type
commit: a5a5ad9848980e1019ca841fe057afb83debecfa
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v3 0/3] Enable QoS configuration on QCS615
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Odelu Kukatla
Cc: Raviteja Laggyshetty, Dmitry Baryshkov, linux-arm-msm, linux-pm,
devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260311103548.1823044-1-odelu.kukatla@oss.qualcomm.com>
On Wed, 11 Mar 2026 16:05:45 +0530, Odelu Kukatla wrote:
> This series enables QoS configuration for QNOC type device which
> can be found on QCS615 platform. It enables QoS configuration
> for master ports with predefined priority and urgency forwarding.
> This helps in prioritizing the traffic originating from different
> interconnect masters at NOC (Network On Chip).
>
> The system may function normally without this feature. However,
> enabling QoS helps optimize latency and bandwidth across subsystems
> like CPU, GPU, and multimedia engines, which becomes important in
> high-throughput scenarios. This is a feature aimed at performance
> enhancement to improve system performance under concurrent workloads.
>
> [...]
Applied, thanks!
[3/3] arm64: dts: qcom: talos: Add clocks for QoS configuration
commit: 9b7d6b6c5cef6c578e976a1a605985c255779327
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/3] arm64: dts: qcom: Add EL2 overlay support
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Mukesh Ojha
Cc: linux-arm-msm, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260127-talos-el2-overlay-v2-0-b6a2266532c4@oss.qualcomm.com>
On Tue, 27 Jan 2026 17:13:47 +0530, Mukesh Ojha wrote:
> We have recently added initial EL2 overlay support for Lemans and there
> it was not disabling zap-shader as GPU changes were not available. Lets
> disables the zap-shader there. And in the similar lines add support for
> Monaco and Talos SoC variants as well which support EL2 configuration.
>
> Talos GPU changes are not merged so its overlay file has dependency
> on https://lore.kernel.org/lkml/20260121-qcs615-spin-2-v7-0-52419b263e92@oss.qualcomm.com/#t
>
> [...]
Applied, thanks!
[3/3] arm64: dts: qcom: talos: Add EL2 overlay
commit: 1bb533d644a2c56a3314351721445ea43fac9ff1
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 0/3] SHIFT 6MQ SD-card support, improved responsivness of touchscreen, and codec
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Dylan Van Assche, David Heidelberg
Cc: linux-arm-msm, Petr Hodina, Casey Connolly, Dmitry Baryshkov,
Alexander Martinz, Konrad Dybcio, devicetree, linux-kernel,
phone-devel
In-Reply-To: <20260402-axolotl-misc-p1-v3-0-8934e9db6831@ixit.cz>
On Thu, 02 Apr 2026 11:54:05 +0200, David Heidelberg wrote:
> I've tested that SD card and touchscreen works well, the codec does too,
> but for complete enablement needs soundcard support which isn't fully
> finished.
>
>
Applied, thanks!
[1/3] arm64: dts: qcom: sdm845-shift-axolotl: Enable sdcard
commit: 338b4158e877f116d404262098bbdcd1eaf6fd88
[2/3] arm64: dts: qcom: sdm845-shift-axolotl: Set higher touchscreen i2c clock
commit: 8a53d5aa0d1179ac14aa7da58351848c2e709dcc
[3/3] arm64: dts: qcom: sdm845-shift-axolotl: Enable TFA9890 codec
commit: 2b676b5a13d28eb038b4e54dae8e161a7be58d96
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v2 0/3] arm64: dts: qcom: Add the Lenovo IdeaCentre Mini X
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson
Cc: linux-arm-msm, devicetree, linux-kernel, Krzysztof Kozlowski,
Konrad Dybcio, Dmitry Baryshkov
In-Reply-To: <20260401-ideacentre-v2-0-5745fe2c764e@oss.qualcomm.com>
On Wed, 01 Apr 2026 21:31:24 -0500, Bjorn Andersson wrote:
>
Applied, thanks!
[3/3] firmware: qcom: scm: Allow QSEECOM on Lenovo IdeaCentre Mini X
commit: a31ad9339eff4ce401dec816b01a94b4e3c47898
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v8 0/4] Support for Adreno 612 GPU - Respin
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jessica Zhang, Gaurav Kohli,
Akhil P Oommen
Cc: Dan Carpenter, linux-arm-msm, dri-devel, freedreno, linux-kernel,
devicetree, Jie Zhang, Qingqing Zhou, Dmitry Baryshkov,
Konrad Dybcio, Jie Zhang
In-Reply-To: <20260312-qcs615-spin-2-v8-0-fca38edcd6e6@oss.qualcomm.com>
On Thu, 12 Mar 2026 04:39:52 +0530, Akhil P Oommen wrote:
> This is a respin of an old series [1] that aimed to add support for
> Adreno 612 GPU found in SM6150/QCS615 chipsets. In this version, we
> have consolidated the previously separate series for DT and driver
> support, along with some significant rework.
>
> Regarding A612 GPU, it falls under ADRENO_6XX_GEN1 family and is a cut
> down version of A615 GPU. A612 has a new IP called Reduced Graphics
> Management Unit or RGMU, a small state machine which helps to toggle
> GX GDSC (connected to CX rail) to implement the IFPC feature. Unlike a
> full-fledged GMU, the RGMU does not support features such as clock
> control, resource voting via RPMh, HFI etc. Therefore, we require linux
> clock driver support similar to gmu-wrapper implementations to control
> gpu core clock and GX GDSC.
>
> [...]
Applied, thanks!
[1/4] arm64: dts: qcom: talos: add the GPU SMMU node
commit: 1d5c82f19b8a079767622191fa7478028a6ce79f
[2/4] arm64: dts: qcom: talos: Add gpu and rgmu nodes
commit: 8de397a5618aaea810e447946a1f1d19c610fdc2
[3/4] arm64: dts: qcom: talos: Add GPU cooling
commit: a74c7b347d7e1094bf16e5053889c9ba4d9a3ac5
[4/4] arm64: dts: qcom: qcs615-ride: Enable Adreno 612 GPU
commit: ed5ee207bc075d774ecc837acc90d02548cd5061
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH v6 0/8] Support for Adreno 612 GPU - Respin
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Rob Clark, Sean Paul, Konrad Dybcio, Dmitry Baryshkov,
Abhinav Kumar, Marijn Suijten, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jessica Zhang, Gaurav Kohli,
Akhil P Oommen
Cc: Dan Carpenter, linux-arm-msm, dri-devel, freedreno, linux-kernel,
devicetree, Jie Zhang, Dmitry Baryshkov, Krzysztof Kozlowski,
Krzysztof Kozlowski, Qingqing Zhou, Konrad Dybcio, Jie Zhang
In-Reply-To: <20251231-qcs615-spin-2-v6-0-da87debf6883@oss.qualcomm.com>
On Wed, 31 Dec 2025 14:15:21 +0530, Akhil P Oommen wrote:
> This is a respin of an old series [1] that aimed to add support for
> Adreno 612 GPU found in SM6150/QCS615 chipsets. In this version, we
> have consolidated the previously separate series for DT and driver
> support, along with some significant rework.
>
> Regarding A612 GPU, it falls under ADRENO_6XX_GEN1 family and is a cut
> down version of A615 GPU. A612 has a new IP called Reduced Graphics
> Management Unit or RGMU, a small state machine which helps to toggle
> GX GDSC (connected to CX rail) to implement the IFPC feature. Unlike a
> full-fledged GMU, the RGMU does not support features such as clock
> control, resource voting via RPMh, HFI etc. Therefore, we require linux
> clock driver support similar to gmu-wrapper implementations to control
> gpu core clock and GX GDSC.
>
> [...]
Applied, thanks!
[5/8] arm64: dts: qcom: talos: add the GPU SMMU node
commit: 1d5c82f19b8a079767622191fa7478028a6ce79f
[6/8] arm64: dts: qcom: talos: Add gpu and rgmu nodes
commit: 8de397a5618aaea810e447946a1f1d19c610fdc2
[7/8] arm64: dts: qcom: talos: Add GPU cooling
commit: a74c7b347d7e1094bf16e5053889c9ba4d9a3ac5
[8/8] arm64: dts: qcom: qcs615-ride: Enable Adreno 612 GPU
commit: ed5ee207bc075d774ecc837acc90d02548cd5061
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: glymur-crd: Enable DisplayPort support
From: Bjorn Andersson @ 2026-04-05 19:40 UTC (permalink / raw)
To: Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Abel Vesa
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260330-glymur-enable-displayport-v1-1-1543ad6dac3a@oss.qualcomm.com>
On Mon, 30 Mar 2026 17:24:08 +0300, Abel Vesa wrote:
> The two Type-C ports found on Glymur CRD are DisplayPort alternate mode
> capable. Everything is in place already for the USB, but for DisplayPort
> the controllers need to be enabled.
>
> So enable the related DisplayPort controller for each of these two
> ports. Also define the supported link frequencies for each output.
>
> [...]
Applied, thanks!
[1/1] arm64: dts: qcom: glymur-crd: Enable DisplayPort support
commit: b4cfbee0df3540b36b78e9d8e3c6d93f3206fecc
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox