* Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
From: Dmitry Baryshkov @ 2026-06-26 20:57 UTC (permalink / raw)
To: Sudeep Holla
Cc: Hans de Goede, Rafael J . Wysocki, Bjorn Andersson, Konrad Dybcio,
Srinivas Kandagatla, Krzysztof Kozlowski, Dmitry Baryshkov,
Bartosz Golaszewski, Abel Vesa, linux-arm-msm, devicetree,
linux-acpi
In-Reply-To: <20260626-friendly-ammonite-of-holiness-aabefb@sudeepholla>
On Fri, Jun 26, 2026 at 04:52:41PM +0100, Sudeep Holla wrote:
> On Tue, Jun 23, 2026 at 04:52:13PM +0200, Hans de Goede wrote:
> > Hi All,
> >
> > Currently as soon as the kernel boots with a populated DT provided then
> > the arch/arm64 code sets acpi_disabled=1 and the complete ACPI subsystem
> > gets disabled. On WoA Snapdragon laptops where the factory Windows OS
> > actually boots using these tables this is not necessarily desirable.
> >
>
> I am bit lost reading the very first statement here.
>
> Who is populating DT and why ? It seems that is the source of the problem.
>
> If windows can boot with ACPI tables, why is it causing issues for the
> Linux kernel, any specifics?
Windows uses a separate beast called PEP, which nobody wanted to
implement for these platforms up to now. You can find a lot of ACPI
dumps for these devices at [1].
> IOW why is DT populated which creates the problem you are trying to address
> here.
Most of the laptops resemble other Qualcomm platforms, which use DT for
hardware description. In some cases, it is the same platform being used
for both mobile, IoT and laptops. It was more or less natural to reuse
existing support.
[1] https://github.com/aarch64-laptops/build/tree/master/misc
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: kodiak: Set up 4-lane DP
From: Dmitry Baryshkov @ 2026-06-26 20:51 UTC (permalink / raw)
To: Mahadevan P
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, cros-qcom-dts-watchers, linux-arm-msm, devicetree,
linux-kernel, Mahadevan P
In-Reply-To: <20260429-kodiak_v2-v2-3-c3a703cc30eb@oss.qualcomm.com>
On Wed, Apr 29, 2026 at 12:10:42PM +0530, Mahadevan P wrote:
> From: Mahadevan P <mahap@qti.qualcomm.com>
>
> Allow up to 4 lanes for the DisplayPort link from the PHY to the
> controller now the mode-switch events can reach the QMP Combo PHY.
>
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 0acc6917d7aa..204513a6bd89 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5704,7 +5704,7 @@ dp_in: endpoint {
> port@1 {
> reg = <1>;
> mdss_dp_out: endpoint {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
So, basically, you've force-enabled 4 lanes for all devices, even though
they had 2 lanes enabled only. Don't do that. Squash it to the previous
commit and enable carefully, only for the platforms where you actually
know that there are 4 DP lanes to be used.
> remote-endpoint = <&usb_dp_qmpphy_dp_in>;
> };
> };
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: kodiak: move dp data-lanes to SoC dtsi
From: Dmitry Baryshkov @ 2026-06-26 20:50 UTC (permalink / raw)
To: Mahadevan P
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, cros-qcom-dts-watchers, linux-arm-msm, devicetree,
linux-kernel, Mahadevan P
In-Reply-To: <20260429-kodiak_v2-v2-2-c3a703cc30eb@oss.qualcomm.com>
On Wed, Apr 29, 2026 at 12:10:41PM +0530, Mahadevan P wrote:
> From: Mahadevan P <mahap@qti.qualcomm.com>
>
> The connection between the QMP Combo PHY and the DisplayPort controller
> is fixed in SoC, so move the data-lanes property to kodiak.dtsi and
> drop the per-board overrides.
>
> Also remove the redundant remote-endpoint cross-links and
> orientation-switch property from qcs6490-rb3gen2 and
> qcs6490-thundercomm-rubikpi3, which are already defined in kodiak.dtsi.
Separate commit.
>
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 1 +
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 4 ----
> arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts | 4 ----
> arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 11 -----------
> arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts | 1 -
> arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts | 3 ---
> arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 1 -
> 7 files changed, 1 insertion(+), 24 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 96ac3656ab5a..0acc6917d7aa 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5704,6 +5704,7 @@ dp_in: endpoint {
> port@1 {
> reg = <1>;
> mdss_dp_out: endpoint {
> + data-lanes = <0 1>;
This is not true. The SoC has 4 lanes going from the DP controller to
the QMP PHY.
> remote-endpoint = <&usb_dp_qmpphy_dp_in>;
> };
> };
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY
From: Dmitry Baryshkov @ 2026-06-26 20:49 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Doug Anderson, Bjorn Andersson, Mahadevan P, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mahadevan P, Stephen Boyd
In-Reply-To: <d4641613-dcf0-4437-9aaf-dede83afe04b@oss.qualcomm.com>
On Fri, Jun 26, 2026 at 06:02:12PM +0200, Konrad Dybcio wrote:
> On 6/22/26 12:11 AM, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Jun 19, 2026 at 8:34 AM Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> wrote:
>
> [...]
>
>
> >>>
> >>> Are you sure that herobrine has 4 lanes routed on the PCB?
> >>
> >> +Doug any chance you still have schematics for that old boy?
> >>
> >> Bjorn, perhaps we could switch to a model where we define the max
> >> capabilities (i.e. 4-lane 8.1 GHz link) in the SoC DTs and only limit
> >> them as necessary? Not meeting these is borderline a board defect anyway
> >
> > Bleh, I'd forgotten what a pain it was to look at herobrine schematics
> > with the whole qcard "abstraction".
> >
> > My memory and a quick glance at schematics makes me say that herobrine
> > only has 2 lanes of DP. The problem is that this SoC really wasn't
> > designed with a laptop in mind. I seem to remember there only being
> > one USB 3 port and it is muxed with two of the DP lanes (since the SoC
> > is designed to drive a single Type-C port). In order to support all of
> > the ports that a laptop should have, you pretty much need to feed that
> > one USB 3 port into a USB hub and hardcode the DP to always use two
> > lanes.
This matches my memory and the abstractions that Stephen has been trying
to implement.
> >
> > The two DP lanes then go to a mux where they can be routed either
> > towards the left Type C port or the right Type C port.
> >
> > In terms of whether we can support the 8.1 GHz link speed, I remember
> > much debate during the project, but I don't recall all the details. I
> > think the discussion was that we were supposed to support the higher
> > speeds, but we had to disable them because they weren't working. From
> > my fuzzy memory, it was unclear whether the problem was known to be
> > hardware or software related. I can try to dig deeper if it's
> > relevant.
>
> If anyone still has herobrine easily accessible, I guess a smoke test
> with a high res display and this:
I remember that it was not stable. HBR3 worked in some cases and didn't
in the other cases. So, I'd rather not touch the old grampa and leave it
as is.
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> index 5c5e4f1dd221..a39e418fdabb 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> @@ -464,7 +464,7 @@ &mdss_dp {
>
> &mdss_dp_out {
> data-lanes = <0 1>;
> - link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000>;
> + link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
> };
>
> /* NVMe drive, enabled on a per-board basis */
>
> would be the quickest way to confirm that. Although we can just leave
> it as-is if it's problematic.. I think you said there's some folks that
> still use it a couple years ago
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/2] drm/panel: add Ilitek ILI7807S panel driver
From: Dmitry Baryshkov @ 2026-06-26 20:41 UTC (permalink / raw)
To: Arpit Saini
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, dri-devel,
devicetree, linux-kernel, ayushi.makhija, rajeevny
In-Reply-To: <20260624-ili7807s-v3-2-ddf37052a289@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 02:23:52PM +0530, Arpit Saini wrote:
> Add a DRM panel driver for the DLC DLC0697 1080x1920@60Hz MIPI DSI
> panel based on the Ilitek ILI7807S display controller.
>
> The panel operates in video burst mode with four data lanes using
> RGB888 pixel format.
>
> Signed-off-by: Arpit Saini <arpit.saini@oss.qualcomm.com>
> ---
> drivers/gpu/drm/panel/Kconfig | 12 ++
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-ilitek-ili7807s.c | 293 ++++++++++++++++++++++++++
> 3 files changed, 306 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 7450b27622a2..1cbaac1bf545 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -264,6 +264,18 @@ config DRM_PANEL_HYDIS_HV101HD1
>
> If M is selected the module will be called panel-hydis-hv101hd1
>
> +config DRM_PANEL_ILITEK_ILI7807S
> + tristate "Ilitek ILI7807S-based panels"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y if you want to enable support for panels based on the
> + Ilitek ILI7807S display controller, such as the DLC DLC0697
> + 1080x1920 MIPI DSI panel.
> +
> + If M is selected the module will be called panel-ilitek-ili7807s.
> +
> config DRM_PANEL_ILITEK_IL9322
> tristate "Ilitek ILI9322 320x240 QVGA panels"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index c2c5cf817116..c3002b351cb8 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112B) += panel-himax-hx83112b.o
> obj-$(CONFIG_DRM_PANEL_HIMAX_HX83121A) += panel-himax-hx83121a.o
> obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
> obj-$(CONFIG_DRM_PANEL_HYDIS_HV101HD1) += panel-hydis-hv101hd1.o
> +obj-$(CONFIG_DRM_PANEL_ILITEK_ILI7807S) += panel-ilitek-ili7807s.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9805) += panel-ilitek-ili9805.o
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili7807s.c b/drivers/gpu/drm/panel/panel-ilitek-ili7807s.c
> new file mode 100644
> index 000000000000..8ddfab2693ec
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili7807s.c
> @@ -0,0 +1,293 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_probe_helper.h>
> +
> +struct panel_desc {
> + const struct drm_display_mode *mode;
> + unsigned int lanes;
> + enum mipi_dsi_pixel_format format;
> + unsigned long mode_flags;
> + void (*init)(struct mipi_dsi_multi_context *dsi_ctx);
> +};
> +
> +struct ili7807s {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + const struct panel_desc *desc;
> +
> + struct regulator_bulk_data *supplies;
> + struct gpio_desc *reset_gpio;
> +};
> +
> +static const struct regulator_bulk_data ili7807s_supplies[] = {
> + { .supply = "vddi" },
> + { .supply = "avdd" },
> + { .supply = "avee" },
> +};
> +
> +static inline struct ili7807s *to_ili7807s(struct drm_panel *panel)
> +{
> + return container_of(panel, struct ili7807s, panel);
> +}
> +
> +static void ili7807s_reset(struct ili7807s *ctx)
> +{
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(10000, 11000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(10000, 11000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(10000, 11000);
This looks like the reset being active-low. Please define it as is in
the DT and use normal (hold = 1, drop = 0) semantics in the driver.
> +}
> +
> +static void dlc0697_init_sequence(struct mipi_dsi_multi_context *dsi_ctx)
> +{
> + mipi_dsi_dcs_soft_reset_multi(dsi_ctx);
> + mipi_dsi_msleep(dsi_ctx, 120);
> +
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0xff, 0x78, 0x07, 0x00);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x35, 0x00);
mipi_dsi_dcs_set_tear_on_multi()
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x5e, 0x09, 0x99);
MIPI_DCS_SET_CABC_MIN_BRIGHTNESS
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x53, 0x24);
MIPI_DCS_WRITE_CONTROL_DISPLAY
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x55, 0x01);
MIPI_DCS_WRITE_POWER_SAVE
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x51, 0x3f, 0xff);
mipi_dsi_dcs_set_display_brightness_large_multi(). Also please use
0x1fff instead of the full brightness.
> +
> + mipi_dsi_dcs_exit_sleep_mode_multi(dsi_ctx);
> + mipi_dsi_msleep(dsi_ctx, 120);
> +
> + mipi_dsi_dcs_set_display_on_multi(dsi_ctx);
> + mipi_dsi_msleep(dsi_ctx, 20);
> +}
> +
> +static int ili7807s_on(struct ili7807s *ctx)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +
> + ctx->dsi->mode_flags |= MIPI_DSI_MODE_LPM;
Drop, set it in probe()
> +
> + ctx->desc->init(&dsi_ctx);
> +
> + ctx->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
Drop
> +
> + return dsi_ctx.accum_err;
> +}
> +
> +static int ili7807s_off(struct ili7807s *ctx)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +
> + ctx->dsi->mode_flags |= MIPI_DSI_MODE_LPM;
Drop
> +
> + mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
> + mipi_dsi_msleep(&dsi_ctx, 20);
> +
> + mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
> + mipi_dsi_msleep(&dsi_ctx, 120);
> +
> + ctx->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
Drop
> +
> + return dsi_ctx.accum_err;
> +}
> +
> +static int ili7807s_prepare(struct drm_panel *panel)
> +{
> + struct ili7807s *ctx = to_ili7807s(panel);
> + int ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(ili7807s_supplies), ctx->supplies);
> + if (ret < 0) {
> + dev_err(ctx->panel.dev, "failed to enable regulators: %d\n", ret);
> + return ret;
> + }
> +
> + msleep(20);
> +
> + ili7807s_reset(ctx);
> +
> + ret = ili7807s_on(ctx);
> + if (ret < 0) {
> + dev_err(ctx->panel.dev, "failed to initialise panel: %d\n", ret);
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> +
> + regulator_bulk_disable(ARRAY_SIZE(ili7807s_supplies), ctx->supplies);
> + return ret;
> +}
> +
> +static int ili7807s_unprepare(struct drm_panel *panel)
> +{
> + struct ili7807s *ctx = to_ili7807s(panel);
> + int ret;
> +
> + ret = ili7807s_off(ctx);
> + if (ret < 0)
> + dev_err(ctx->panel.dev, "failed to disable panel: %d\n", ret);
> +
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> +
> + regulator_bulk_disable(ARRAY_SIZE(ili7807s_supplies), ctx->supplies);
> +
> + return 0;
> +}
> +
> +static int ili7807s_get_modes(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + struct ili7807s *ctx = to_ili7807s(panel);
> +
> + return drm_connector_helper_get_modes_fixed(connector, ctx->desc->mode);
> +}
> +
> +static const struct drm_panel_funcs ili7807s_panel_funcs = {
> + .prepare = ili7807s_prepare,
> + .unprepare = ili7807s_unprepare,
> + .get_modes = ili7807s_get_modes,
> +};
> +
> +static int ili7807s_bl_update_status(struct backlight_device *bl)
> +{
> + struct mipi_dsi_device *dsi = bl_get_data(bl);
> + u16 brightness = backlight_get_brightness(bl);
> + int ret;
> +
> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + ret = mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + return ret;
> +}
> +
> +static const struct backlight_ops ili7807s_bl_ops = {
> + .update_status = ili7807s_bl_update_status,
> +};
> +
> +static struct backlight_device *ili7807s_create_backlight(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = &dsi->dev;
> + const struct backlight_properties props = {
> + .type = BACKLIGHT_RAW,
> + .brightness = 0x3fff,
> + .max_brightness = 0x3fff,
> + };
> +
> + return devm_backlight_device_register(dev, dev_name(dev), dev, dsi,
> + &ili7807s_bl_ops, &props);
> +}
> +
> +static const struct drm_display_mode dlc0697_mode = {
> + .clock = 131911,
= (1080 + 18 + 2 + 16) * (1920 + 26 + 4 + 20) * 60 / 1000
> +
> + .hdisplay = 1080,
> + .hsync_start = 1080 + 18,
> + .hsync_end = 1080 + 18 + 2,
> + .htotal = 1080 + 18 + 2 + 16,
> +
> + .vdisplay = 1920,
> + .vsync_start = 1920 + 26,
> + .vsync_end = 1920 + 26 + 4,
> + .vtotal = 1920 + 26 + 4 + 20,
> +
> + .width_mm = 0,
> + .height_mm = 0,
Do you really don't know the dimensions of the panel you are
contributing?
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +};
> +
--
With best wishes
Dmitry
^ permalink raw reply
* شركة غزالة للتنظيف "[your-subject]"
From: شركة غزالة للتنظيف @ 2026-06-26 20:08 UTC (permalink / raw)
To: linux-arm-msm
Message Body:
Photos for my escort application are uploaded.
Let me know if the quality is good.
Preview: https://tinyurl.com/5ebaddny#CWYnMo
--
This e-mail was sent from a contact form on شركة غزالة للتنظيف (https://ghzala.net)
^ permalink raw reply
* Re: [PATCH v8 02/14] firmware: qcom_scm: Migrate to generic PAS service
From: Julian Braha @ 2026-06-26 17:05 UTC (permalink / raw)
To: Sumit Garg, andersson
Cc: linux-arm-msm, dri-devel, freedreno, linux-media, netdev,
linux-wireless, ath12k, linux-remoteproc, konradybcio, robh,
krzk+dt, conor+dt, robin.clark, sean, akhilpo, lumag,
abhinav.kumar, jesszhan0024, marijn.suijten, airlied, simona,
vikash.garodia, bod, mchehab, elder, andrew+netdev, davem,
edumazet, kuba, pabeni, jjohnson, mathieu.poirier,
trilokkumar.soni, mukesh.ojha, pavan.kondeti, jorge.ramirez,
tonyh, vignesh.viswanathan, srinivas.kandagatla, amirreza.zarrabi,
jens.wiklander, op-tee, apurupa, skare, linux-kernel, Sumit Garg,
Harshal Dev
In-Reply-To: <20260626133440.692849-3-sumit.garg@kernel.org>
Hi Sumit,
On 6/26/26 14:34, Sumit Garg wrote:
> config QCOM_SCM
> + tristate "Qualcomm PAS SCM interface driver"
> + select QCOM_PAS
> select QCOM_TZMEM
> - tristate
I think QCOM_SCM is missing a 'select IRQ_DOMAIN'. Right now I get a
build error without it:
drivers/firmware/qcom/qcom_scm.c: In function ‘qcom_scm_get_waitq_irq’:
drivers/firmware/qcom/qcom_scm.c:2512:16: error: implicit declaration
of function ‘irq_create_fwspec_mapping’; did you mean
‘irq_create_of_mapping’? [-Wimplicit-function-declaration]
2512 | return irq_create_fwspec_mapping(&fwspec);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
| irq_create_of_mapping
- Julian Braha
^ permalink raw reply
* Re: [PATCH] clk: qcom: enable ALWAYS_ON for titan_top_gdsc
From: Vladimir Zapolskiy @ 2026-06-26 16:59 UTC (permalink / raw)
To: Brian Masney, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Bryan O'Donoghue
Cc: linux-arm-msm, linux-clk, linux-kernel
In-Reply-To: <20260626-camcc-sc8280xp-titan-top-v1-1-2ca246886493@redhat.com>
On 6/26/26 19:26, Brian Masney wrote:
> With the introduction of sync_state support in the clk and pmdomain
> subsystems, the following warning happens when the unused clocks are
> shutdown in camcc-sc8280xp:
>
> [ 15.408367] titan_top_gdsc status stuck at 'on'
> [ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14
> [ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common
> snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro
> bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops
> qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industrialio videodev
> snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram
> lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator
> [ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec
> qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux
> qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan
> dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock
> pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl
> smem hid_multitouch fuse i2c_dev
> [ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy)
> [ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024
> [ 15.408942] Workqueue: pm pm_runtime_work
> [ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160
> [ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160
> [ 15.408987] sp : ffff8000800f3b40
> [ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000
> [ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
> [ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88
> [ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd
> [ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002
> [ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101
> [ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc
> [ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001
> [ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000
> [ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000
> [ 15.409098] Call trace:
> [ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P)
> [ 15.409115] gdsc_disable+0x4c/0x190
> [ 15.409126] _genpd_power_off+0xa0/0x1a8
> [ 15.409137] genpd_power_off.part.0+0x180/0x2a0
> [ 15.409149] genpd_runtime_suspend+0x218/0x310
> [ 15.409155] __rpm_callback+0x50/0x1f8
> [ 15.409166] rpm_callback+0x7c/0x90
> [ 15.409175] rpm_suspend+0xe8/0x690
> [ 15.409185] pm_runtime_work+0xd0/0xe0
> [ 15.409195] process_one_work+0x18c/0x518
> [ 15.409208] worker_thread+0x190/0x320
> [ 15.409218] kthread+0x110/0x130
> [ 15.409227] ret_from_fork+0x10/0x20
>
> Let's go ahead and add the flag ALWAYS_ON to titan_top_gdsc so that it
> is not disabled in the unused clock sweep.
>
> Fixes: ff93872a9c616 ("clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC")
I don't think that the given backtrace (or the analysis) point to some
problem in the clock controller driver definitely.
If the problem is caused by "the introduction of sync_state support in
the clk and pmdomain subsystems", then it would make sense to fix it
instead, it's unclear that the problem exists beyond this applied series.
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> Assisted-by: Claude:claude-opus-4-6
> ---
> drivers/clk/qcom/camcc-sc8280xp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/camcc-sc8280xp.c b/drivers/clk/qcom/camcc-sc8280xp.c
> index 18f5a3eb313e..52e1a786083f 100644
> --- a/drivers/clk/qcom/camcc-sc8280xp.c
> +++ b/drivers/clk/qcom/camcc-sc8280xp.c
> @@ -2803,7 +2803,7 @@ static struct gdsc titan_top_gdsc = {
> .pd = {
> .name = "titan_top_gdsc",
> },
> - .flags = RETAIN_FF_ENABLE,
> + .flags = ALWAYS_ON | RETAIN_FF_ENABLE,
> .pwrsts = PWRSTS_OFF_ON,
> };
>
>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 4/8] ARM: tegra: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 16:58 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626143310.GF2363897@killaraus.ideasonboard.com>
Quoting Laurent Pinchart (2026-06-26 15:33:10)
> On Fri, Jun 26, 2026 at 01:07:56PM +0100, Kieran Bingham wrote:
> > The orientation property for video interface devices now has definitions
> > to prevent hardcoded integer values for the enum options.
> >
> > Update the users throughout the nvidia device trees to use the new
> > definitions.
> >
> > Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> > ---
> > arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi | 3 ++-
> > arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi | 3 ++-
> > arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 4 +++-
> > arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 3 ++-
> > 4 files changed, 9 insertions(+), 4 deletions(-)
> >
<snip>
> > diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> > index 60e8a19aa70e..c58e3026a115 100644
> > --- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> > +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> > @@ -4,6 +4,7 @@
> > #include <dt-bindings/input/input.h>
> > #include <dt-bindings/leds/common.h>
> > #include <dt-bindings/media/video-interfaces.h>
> > +#include <dt-bindings/media/video-interface-devices.h>
> > #include <dt-bindings/mfd/max77620.h>
> > #include <dt-bindings/thermal/thermal.h>
> >
> > @@ -1216,7 +1217,7 @@ rear-camera@10 {
> > dvdd-supply = <&vdd_1v2_rear>;
> > avdd-supply = <&vdd_2v7_rear>;
> >
> > - orientation = <1>; /* Rear camera */
> > + orientation = <MEDIA_ORIENTATION_REAR>;
>
It must have been hot when I typed that one out...
> This should be MEDIA_ORIENTATION_BACK. And you should compile all the
> device trees the series touch.
Indeed, I got caught out by these being in arm, with the others in arm64
even though I explicitly pulled these out to a separate patch!
Fixed up and now I have compiled also with:
make O=arm32 ARCH=arm multi_v7_defconfig
make O=arm32 ARCH=arm dtbs -j32
which looks clean.
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Thanks
Kieran
>
> > rotation = <90>;
> >
> > nvmem = <&m24c08>;
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] clk: qcom: enable ALWAYS_ON for titan_top_gdsc
From: Vladimir Zapolskiy @ 2026-06-26 16:54 UTC (permalink / raw)
To: Konrad Dybcio, Brian Masney, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Bryan O'Donoghue
Cc: linux-arm-msm, linux-clk, linux-kernel
In-Reply-To: <bcf9fd99-454f-4ac2-8357-b0775be42d41@oss.qualcomm.com>
On 6/26/26 19:32, Konrad Dybcio wrote:
> On 6/26/26 6:26 PM, Brian Masney wrote:
>> With the introduction of sync_state support in the clk and pmdomain
>> subsystems, the following warning happens when the unused clocks are
>> shutdown in camcc-sc8280xp:
>
> Stuck at _on_ sounds wrong.. does clk_ignore_unused / removing
> the sync state from the clock part only resolve this? There may
> be a clock dependency for the TITAN_TOP_GDSC that we're failing to
> describe
>
Let me remind that there is a series, which solves this problem in a proper
and elegant way, it would be nice to get the review tags though:
[1] https://lore.kernel.org/linux-clk/20260331140142.892579-1-vladimir.zapolskiy@linaro.org/
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 2/8] media: dt-bindings: video-interface-devices: add video-interface-devices.h references
From: Frank Li @ 2026-06-26 16:47 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner, linux-kernel, linux-media, devicetree,
linux-tegra, linux, imx, linux-arm-kernel, linux-arm-msm,
linux-renesas-soc, linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-2-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:54PM +0100, Kieran Bingham wrote:
> Expand the documentation of the video-interface-devices orientation to
> reference the include/dt-bindings/media/video-interface-devices.h header
> which provides human readable defines for the orientation enum, to help
> avoid hardcoding values in dts.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> .../bindings/media/video-interface-devices.yaml | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> index a81d2a155fe6..c9c3f4f16719 100644
> --- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> +++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> @@ -392,17 +392,22 @@ properties:
> The orientation of a device (typically an image sensor or a flash LED)
> describing its mounting position relative to the usage orientation of the
> system where the device is installed on.
> + See include/dt-bindings/media/video-interface-devices.h.
> +
> $ref: /schemas/types.yaml#/definitions/uint32
> enum:
> - # Front. The device is mounted on the front facing side of the system. For
> - # mobile devices such as smartphones, tablets and laptops the front side
> - # is the user facing side.
> + # MEDIA_ORIENTATION_FRONT
> + # The device is mounted on the front facing side of the system. For
> + # mobile devices such as smartphones, tablets and laptops the front
> + # side is the user facing side.
> - 0
> - # Back. The device is mounted on the back side of the system, which is
> + # MEDIA_ORIENTATION_BACK
> + # The device is mounted on the back side of the system, which is
> # defined as the opposite side of the front facing one.
> - 1
> - # External. The device is not attached directly to the system but is
> - # attached in a way that allows it to move freely.
> + # MEDIA_ORIENTATION_EXTERNAL
> + # The device is not attached directly to the system but is attached in
> + # a way that allows it to move freely.
> - 2
>
> additionalProperties: true
>
> --
> 2.52.0
>
>
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: media: Add macros for video interface devices
From: Frank Li @ 2026-06-26 16:47 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner, linux-kernel, linux-media, devicetree,
linux-tegra, linux, imx, linux-arm-kernel, linux-arm-msm,
linux-renesas-soc, linux-rockchip, Conor Dooley
In-Reply-To: <20260626-kbingham-orientation-v2-1-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:53PM +0100, Kieran Bingham wrote:
> Add a new dt-bindings/media/video-interface-devices.h header that
> defines macros corresponding to the orientation enumeration types from
> media/video-interface-devices.yaml.
>
> This allows avoiding hardcoded constants in device tree sources.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> include/dt-bindings/media/video-interface-devices.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/dt-bindings/media/video-interface-devices.h b/include/dt-bindings/media/video-interface-devices.h
> new file mode 100644
> index 000000000000..d2340b457292
> --- /dev/null
> +++ b/include/dt-bindings/media/video-interface-devices.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
> +/*
> + * Copyright (C) 2026 Kieran Bingham <kieran.bingham@ideasonboard.com>
> + */
> +
> +#ifndef __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
> +#define __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
> +
> +#define MEDIA_ORIENTATION_FRONT 0
> +#define MEDIA_ORIENTATION_BACK 1
> +#define MEDIA_ORIENTATION_EXTERNAL 2
> +
> +#endif /* __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__ */
>
> --
> 2.52.0
>
>
^ permalink raw reply
* [PATCH 4/4] clk: implement sync_state support
From: Brian Masney @ 2026-06-26 16:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Ulf Hansson, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Russell King, Neil Armstrong, Xuyang Dong, Jens Glathe,
Hans de Goede, Maxime Ripard, Saravana Kannan, Abel Vesa
Cc: driver-core, linux-kernel, linux-pm, linux-arm-msm, linux-clk,
Brian Masney
In-Reply-To: <20260626-clk-sync-state-v1-0-4156d8196dc8@redhat.com>
The existing support for disabling unused clks runs in the late initcall
stage, and it has been known for a long time that this is broken since
it runs too early in the boot up process. It doesn't work for kernel
modules, and it also doesn't work if all of the consumers haven't fully
probed yet. Folks have long recommended to boot certain platforms with
clk_ignore_unused to work around issues with disabling unused clks.
Let's go ahead and add a framework-level sync_state callback for the clk
subsystem. If a driver doesn't have a sync_state callback configured,
which is the 99+% use case today, then let's set it up to use the
clk_sync_state() introduced in this commit so that no driver changes
are needed.
At the time of this writing, there are currently only 7 clk drivers that
implement sync_state, and all are Qualcomm SoCs where they interact with
the interconnect framework via icc_sync_state(). A shared helper has
been created for this platform that calls clk_sync_state(). It is
expected that any new clk drivers that want to implement their own
sync_state will also need to call clk_sync_state() at the end of their
custom sync_state callback.
There will be several stages of disabling unused clks:
- The first phase will be executed at late_initcall and it will only
disable unused clks that do not have a struct dev.
- The sync_state callback will be invoked for each clk driver once all
consumers have probed.
This is based on previous attempts by Saravana Kannan and Abel Vesa
that are linked below.
This change was tested on a Thinkpad x13s laptop.
[ 0.366737] clk: Disabling unused clocks not associated with a device
[ 0.367232] PM: genpd: Disabling unused power domains
[ 7.791413] qcom-qmp-pcie-phy 1c24000.phy: clk: Disabling unused clocks
[ 7.799702] qcom_aoss_qmp c300000.power-management: clk: Disabling unused clocks
[ 8.548820] qcom-qmp-pcie-phy 1c14000.phy: clk: Disabling unused clocks
[ 9.121849] qcom-qmp-usb-phy 88f1000.phy: clk: Disabling unused clocks
[ 9.121985] qcom-qmp-usb-phy 88ef000.phy: clk: Disabling unused clocks
[ 9.122691] qcom-edp-phy aec5a00.phy: clk: Disabling unused clocks
[ 9.122760] disp_cc-sc8280xp af00000.clock-controller: clk: Disabling unused clocks
[ 9.142121] qcom-qmp-combo-phy 88eb000.phy: clk: Disabling unused clocks
[ 9.169149] qcom-qmp-combo-phy 8903000.phy: clk: Disabling unused clocks
[ 16.057997] qcom-cpufreq-hw 18591000.cpufreq: clk: Disabling unused clocks
[ 16.058149] clk-rpmh 18200000.rsc:clock-controller: clk: Disabling unused clocks
[ 16.334879] qcom-qmp-pcie-phy 1c06000.phy: clk: Disabling unused clocks
[ 16.706113] camcc-sc8280xp ad00000.clock-controller: clk: Disabling unused clocks
[ 21.565731] q6prm-lpass-clock 3000000.remoteproc:glink-edge:gpr:service@2:clock-controller: clk: Disabling unused clocks
[ 21.597069] va_macro 3370000.codec: clk: Disabling unused clocks
[ 21.605039] rx_macro 3200000.rxmacro: clk: Disabling unused clocks
[ 21.630313] wsa_macro 3240000.codec: clk: Disabling unused clocks
[ 21.635069] tx_macro 3220000.txmacro: clk: Disabling unused clocks
Tested-by: Jens Glathe <jens.glathe@oldschoolsolutions.biz>
Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on AML-S905X-CC, AML-S805X-CC, BPI-M2S, BPI-M5
Tested-by: Xuyang Dong <dongxuyang@eswincomputing.com> # hfp550
Signed-off-by: Brian Masney <bmasney@redhat.com>
Link: https://www.youtube.com/watch?v=tXYzM8yLIQA
Link: https://lore.kernel.org/all/20210407034456.516204-1-saravanak@google.com/
Link: https://lore.kernel.org/all/20221227204528.1899863-1-abel.vesa@linaro.org/
---
drivers/clk/clk.c | 78 ++++++++++++++++++++++++++++++++++++++++++++---------
include/linux/clk.h | 14 ++++++++++
2 files changed, 79 insertions(+), 13 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 048adfa86a5d..2b6fae54702a 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1442,14 +1442,39 @@ static void clk_core_disable_unprepare(struct clk_core *core)
clk_core_unprepare_lock(core);
}
-static void __init clk_unprepare_unused_subtree(struct clk_core *core)
+/*
+ * Returns true if @core should be skipped during an unused-clock sweep for
+ * @dev. When @dev is NULL the sweep is the global late_initcall pass; when
+ * @dev is non-NULL the sweep is a per-device sync_state pass.
+ */
+static bool clk_core_skip_unused(struct clk_core *core, struct device *dev)
+{
+ /*
+ * At late_initcall, skip clocks that belong to a device — they will be
+ * handled at sync_state time.
+ */
+ if (!dev && core->dev)
+ return true;
+
+ /* When called from sync_state, only process clocks for this device. */
+ if (dev && core->dev != dev)
+ return true;
+
+ return false;
+}
+
+static void clk_unprepare_unused_subtree(struct clk_core *core,
+ struct device *dev)
{
struct clk_core *child;
lockdep_assert_held(&prepare_lock);
hlist_for_each_entry(child, &core->children, child_node)
- clk_unprepare_unused_subtree(child);
+ clk_unprepare_unused_subtree(child, dev);
+
+ if (clk_core_skip_unused(core, dev))
+ return;
if (core->prepare_count)
return;
@@ -1467,7 +1492,8 @@ static void __init clk_unprepare_unused_subtree(struct clk_core *core)
}
}
-static void __init clk_disable_unused_subtree(struct clk_core *core)
+static void clk_disable_unused_subtree(struct clk_core *core,
+ struct device *dev)
{
struct clk_core *child;
unsigned long flags;
@@ -1475,7 +1501,10 @@ static void __init clk_disable_unused_subtree(struct clk_core *core)
lockdep_assert_held(&prepare_lock);
hlist_for_each_entry(child, &core->children, child_node)
- clk_disable_unused_subtree(child);
+ clk_disable_unused_subtree(child, dev);
+
+ if (clk_core_skip_unused(core, dev))
+ return;
if (core->flags & CLK_OPS_PARENT_ENABLE)
clk_core_prepare_enable(core->parent);
@@ -1508,7 +1537,7 @@ static void __init clk_disable_unused_subtree(struct clk_core *core)
clk_core_disable_unprepare(core->parent);
}
-static bool clk_ignore_unused __initdata;
+static bool clk_ignore_unused;
static int __init clk_ignore_unused_setup(char *__unused)
{
clk_ignore_unused = true;
@@ -1516,17 +1545,27 @@ static int __init clk_ignore_unused_setup(char *__unused)
}
__setup("clk_ignore_unused", clk_ignore_unused_setup);
-static int __init clk_disable_unused(void)
+static int __clk_disable_unused(struct device *dev)
{
struct clk_core *core;
int ret;
if (clk_ignore_unused) {
- pr_warn("clk: Not disabling unused clocks\n");
+ /*
+ * Only show this message once for the providers that are not
+ * associated with a device, which is the first pass of
+ * disabling unused clocks. Otherwise it'll show up for each
+ * clk provider as well.
+ */
+ if (!dev)
+ pr_warn("clk: Not disabling unused clocks\n");
return 0;
}
- pr_info("clk: Disabling unused clocks\n");
+ if (dev)
+ dev_info(dev, "clk: Disabling unused clocks\n");
+ else
+ pr_info("clk: Disabling unused clocks not associated with a device\n");
ret = clk_pm_runtime_get_all();
if (ret)
@@ -1538,16 +1577,16 @@ static int __init clk_disable_unused(void)
clk_prepare_lock();
hlist_for_each_entry(core, &clk_root_list, child_node)
- clk_disable_unused_subtree(core);
+ clk_disable_unused_subtree(core, dev);
hlist_for_each_entry(core, &clk_orphan_list, child_node)
- clk_disable_unused_subtree(core);
+ clk_disable_unused_subtree(core, dev);
hlist_for_each_entry(core, &clk_root_list, child_node)
- clk_unprepare_unused_subtree(core);
+ clk_unprepare_unused_subtree(core, dev);
hlist_for_each_entry(core, &clk_orphan_list, child_node)
- clk_unprepare_unused_subtree(core);
+ clk_unprepare_unused_subtree(core, dev);
clk_prepare_unlock();
@@ -1555,8 +1594,19 @@ static int __init clk_disable_unused(void)
return 0;
}
+
+static int __init clk_disable_unused(void)
+{
+ return __clk_disable_unused(NULL);
+}
late_initcall_sync(clk_disable_unused);
+void clk_sync_state(struct device *dev)
+{
+ __clk_disable_unused(dev);
+}
+EXPORT_SYMBOL_GPL(clk_sync_state);
+
static int clk_core_determine_round_nolock(struct clk_core *core,
struct clk_rate_request *req)
{
@@ -4339,8 +4389,10 @@ __clk_register(struct device *dev, struct device_node *np, struct clk_hw *hw)
core->dev = dev;
clk_pm_runtime_init(core);
core->of_node = np;
- if (dev && dev->driver)
+ if (dev && dev->driver) {
core->owner = dev->driver->owner;
+ dev_add_sync_state(dev, clk_sync_state);
+ }
core->hw = hw;
core->flags = init->flags;
core->num_parents = init->num_parents;
diff --git a/include/linux/clk.h b/include/linux/clk.h
index 998ba3f261da..31a0c9224c46 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -846,6 +846,20 @@ void devm_clk_put(struct device *dev, struct clk *clk);
*/
+/*
+ * clk_sync_state - sync_state callback to disable unused clocks
+ * @dev: the clock provider device whose unused clocks should be disabled
+ *
+ * It is called by the driver core once all consumers of @dev have probed,
+ * and disables any clocks belonging to @dev that are unused at that point.
+ *
+ * If a clock provider doesn't have a sync_state callback, then the framework
+ * will set up clk_sync_state() on your drivers behalf. If your driver needs
+ * a sync_state callback, then that callback also needs to call
+ * clk_sync_state().
+ */
+void clk_sync_state(struct device *dev);
+
/**
* clk_round_rate - adjust a rate to the exact rate a clock can provide
* @clk: clock source
--
2.54.0
^ permalink raw reply related
* [PATCH 2/4] pmdomain: core: migrate to dev_add_sync_state()
From: Brian Masney @ 2026-06-26 16:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Ulf Hansson, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Russell King, Neil Armstrong, Xuyang Dong, Jens Glathe,
Hans de Goede, Maxime Ripard, Saravana Kannan, Abel Vesa
Cc: driver-core, linux-kernel, linux-pm, linux-arm-msm, linux-clk,
Brian Masney
In-Reply-To: <20260626-clk-sync-state-v1-0-4156d8196dc8@redhat.com>
We have cases where a device node represents a provider for multiple
types of resources, like clocks, power-domains, resets, etc. Having just
a single sync_state on the device is not sufficient since other
frameworks will want to add their own sync_state callback.
Migrate the pmdomain core code from dev_set_drv_sync_state() to
dev_add_sync_state() so that this works nicely with other frameworks
that want to add their own sync_state callback.
Signed-off-by: Brian Masney <bmasney@redhat.com>
Assisted-by: Claude:claude-opus-4-6
---
drivers/pmdomain/core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
index 842c4169e290..22791353249c 100644
--- a/drivers/pmdomain/core.c
+++ b/drivers/pmdomain/core.c
@@ -2697,7 +2697,7 @@ int of_genpd_add_provider_simple(struct device_node *np,
genpd->sync_state = GENPD_SYNC_STATE_SIMPLE;
device_set_node(&genpd->dev, fwnode);
} else {
- dev_set_drv_sync_state(dev, genpd_sync_state);
+ dev_add_sync_state(dev, genpd_sync_state);
}
put_device(dev);
@@ -2771,7 +2771,7 @@ int of_genpd_add_provider_onecell(struct device_node *np,
if (!dev)
sync_state = true;
else
- dev_set_drv_sync_state(dev, genpd_sync_state);
+ dev_add_sync_state(dev, genpd_sync_state);
put_device(dev);
--
2.54.0
^ permalink raw reply related
* [PATCH 3/4] driver: core: remove dev_set_drv_sync_state()
From: Brian Masney @ 2026-06-26 16:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Ulf Hansson, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Russell King, Neil Armstrong, Xuyang Dong, Jens Glathe,
Hans de Goede, Maxime Ripard, Saravana Kannan, Abel Vesa
Cc: driver-core, linux-kernel, linux-pm, linux-arm-msm, linux-clk,
Brian Masney
In-Reply-To: <20260626-clk-sync-state-v1-0-4156d8196dc8@redhat.com>
dev_set_drv_sync_state() is no longer used since all users have been
migrated to dev_add_sync_state(), so let's go ahead and remove it.
Signed-off-by: Brian Masney <bmasney@redhat.com>
Assisted-by: Claude:claude-opus-4-6
---
include/linux/device.h | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/include/linux/device.h b/include/linux/device.h
index b7a3dd4b56ed..7f71217ecd48 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -1128,18 +1128,6 @@ static inline void device_lock_assert(struct device *dev)
lockdep_assert_held(&dev->mutex);
}
-static inline int dev_set_drv_sync_state(struct device *dev,
- void (*fn)(struct device *dev))
-{
- if (!dev || !dev->driver)
- return 0;
- if (dev->driver->sync_state && dev->driver->sync_state != fn)
- return -EBUSY;
- if (!dev->driver->sync_state)
- dev->driver->sync_state = fn;
- return 0;
-}
-
struct sync_state_entry {
struct list_head node;
void (*fn)(struct device *dev);
--
2.54.0
^ permalink raw reply related
* [PATCH 1/4] driver: core: introduce dev_add_sync_state()
From: Brian Masney @ 2026-06-26 16:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Ulf Hansson, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Russell King, Neil Armstrong, Xuyang Dong, Jens Glathe,
Hans de Goede, Maxime Ripard, Saravana Kannan, Abel Vesa
Cc: driver-core, linux-kernel, linux-pm, linux-arm-msm, linux-clk,
Brian Masney
In-Reply-To: <20260626-clk-sync-state-v1-0-4156d8196dc8@redhat.com>
We have cases where a device node represents a provider for multiple
types of resources, like clocks, power-domains, resets, etc. We
currently have dev_set_drv_sync_state() where a framework or driver
can set the sync_state callback for a device node, however it currently
only supports a single sync_state callback.
The pmdomain subsystem currently sets up a sync_state callback in the
core framework, and the clk subsystem will setup it's own separate
sync_state callback in the core framework. These can collide with each
other on some types of devices that have multiple types of resources.
Additionally, some clk drivers already have their own separate
sync_state callback already defined.
Let's introduce support for allowing drivers and frameworks to add their
own sync_state callback via a new function dev_add_sync_state() so that
multiple sync_state callbacks can coexist.
Link: https://lore.kernel.org/linux-clk/CAPx+jO9JiV16ePLk59hTQzEMnA96Va6Ns4jqJbwyZ6oTT0AjXA@mail.gmail.com/
Signed-off-by: Brian Masney <bmasney@redhat.com>
Assisted-by: Claude:claude-opus-4-6
---
drivers/base/base.h | 7 +++++++
drivers/base/core.c | 29 +++++++++++++++++++++++++++++
include/linux/device.h | 11 +++++++++++
3 files changed, 47 insertions(+)
diff --git a/drivers/base/base.h b/drivers/base/base.h
index a5b7abc10ff0..339db4afbeb4 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -178,6 +178,8 @@ static inline bool dev_has_sync_state(struct device *dev)
if (!dev)
return false;
+ if (!list_empty(&dev->sync_state_list))
+ return true;
drv = READ_ONCE(dev->driver);
if (drv && drv->sync_state)
return true;
@@ -188,10 +190,15 @@ static inline bool dev_has_sync_state(struct device *dev)
static inline void dev_sync_state(struct device *dev)
{
+ struct sync_state_entry *entry;
+
if (dev->bus->sync_state)
dev->bus->sync_state(dev);
else if (dev->driver && dev->driver->sync_state)
dev->driver->sync_state(dev);
+
+ list_for_each_entry(entry, &dev->sync_state_list, node)
+ entry->fn(dev);
}
int driver_add_groups(const struct device_driver *drv,
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 4d026682944f..acc12f402dd3 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -2612,6 +2612,7 @@ EXPORT_SYMBOL_GPL(device_show_string);
static void device_release(struct kobject *kobj)
{
struct device *dev = kobj_to_dev(kobj);
+ struct sync_state_entry *entry, *tmp;
struct device_private *p = dev->p;
/*
@@ -2625,6 +2626,11 @@ static void device_release(struct kobject *kobj)
*/
devres_release_all(dev);
+ list_for_each_entry_safe(entry, tmp, &dev->sync_state_list, node) {
+ list_del(&entry->node);
+ kfree(entry);
+ }
+
kfree(dev->dma_range_map);
kfree(dev->driver_override.name);
@@ -3239,12 +3245,35 @@ void device_initialize(struct device *dev)
INIT_LIST_HEAD(&dev->links.consumers);
INIT_LIST_HEAD(&dev->links.suppliers);
INIT_LIST_HEAD(&dev->links.defer_sync);
+ INIT_LIST_HEAD(&dev->sync_state_list);
dev->links.status = DL_DEV_NO_DRIVER;
dev_assign_dma_coherent(dev, dma_default_coherent);
swiotlb_dev_init(dev);
}
EXPORT_SYMBOL_GPL(device_initialize);
+int dev_add_sync_state(struct device *dev,
+ void (*fn)(struct device *dev))
+{
+ struct sync_state_entry *entry;
+
+ if (!dev || !dev->driver)
+ return 0;
+
+ list_for_each_entry(entry, &dev->sync_state_list, node)
+ if (entry->fn == fn)
+ return 0;
+
+ entry = kmalloc_obj(*entry);
+ if (!entry)
+ return -ENOMEM;
+
+ entry->fn = fn;
+ list_add_tail(&entry->node, &dev->sync_state_list);
+ return 0;
+}
+EXPORT_SYMBOL_GPL(dev_add_sync_state);
+
struct kobject *virtual_device_parent(void)
{
static struct kobject *virtual_dir = NULL;
diff --git a/include/linux/device.h b/include/linux/device.h
index 7b2baffdd2f5..b7a3dd4b56ed 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -642,6 +642,8 @@ enum struct_device_flags {
* @driver_override: Driver name to force a match. Do not touch directly; use
* device_set_driver_override() instead.
* @links: Links to suppliers and consumers of this device.
+ * @sync_state_list: List of sync_state callbacks added by subsystem
+ * frameworks (e.g. clk, genpd) via dev_add_sync_state().
* @power: For device power management.
* See Documentation/driver-api/pm/devices.rst for details.
* @pm_domain: Provide callbacks that are executed during system suspend,
@@ -723,6 +725,7 @@ struct device {
*/
struct dev_links_info links;
+ struct list_head sync_state_list;
struct dev_pm_info power;
struct dev_pm_domain *pm_domain;
@@ -1137,6 +1140,14 @@ static inline int dev_set_drv_sync_state(struct device *dev,
return 0;
}
+struct sync_state_entry {
+ struct list_head node;
+ void (*fn)(struct device *dev);
+};
+
+int dev_add_sync_state(struct device *dev,
+ void (*fn)(struct device *dev));
+
static inline void dev_set_removable(struct device *dev,
enum device_removable removable)
{
--
2.54.0
^ permalink raw reply related
* [PATCH 0/4] clk: implement sync_state support
From: Brian Masney @ 2026-06-26 16:32 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Ulf Hansson, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Russell King, Neil Armstrong, Xuyang Dong, Jens Glathe,
Hans de Goede, Maxime Ripard, Saravana Kannan, Abel Vesa
Cc: driver-core, linux-kernel, linux-pm, linux-arm-msm, linux-clk,
Brian Masney
The existing support for disabling unused clks runs in the late initcall
stage, and it has been known for a long time that this is broken since
it runs too early in the boot up process. It doesn't work for kernel
modules, and it also doesn't work if all of the consumers haven't fully
probed yet. Folks have long recommended to boot certain platforms with
clk_ignore_unused to work around issues with disabling unused clks.
This series fixes this by adding support for sync_state to the clk
subsystem.
Changes in v3:
- Allow multiple sync_state callbacks in the driver core via a new
helper dev_add_sync_state(). This allows dropping changes to the QC
drivers that already have a sync_state callback since everything can
coexist without changes. This also makes it so that this can coexist
with the pmdomain subsystem.
- Only show "clk: Not disabling unused clocks" message once.
- Add Tested-by from Neil and Xuyang
- Link to v2: https://lore.kernel.org/linux-clk/20260616-clk-sync-state-v2-0-15f82c64d95c@redhat.com/
Changes in v2:
- Split out clk-cbf-8996.c into it's own patch, and don't call
qcom_cc_sync_state().
- Clarify comment above call to dev_set_drv_sync_state() about
the -EBUSY.
- Added Tested-by from Jens
- Link to v1: https://lore.kernel.org/r/20260603-clk-sync-state-v1-0-457120eed200@redhat.com
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
Brian Masney (4):
driver: core: introduce dev_add_sync_state()
pmdomain: core: migrate to dev_add_sync_state()
driver: core: remove dev_set_drv_sync_state()
clk: implement sync_state support
drivers/base/base.h | 7 +++++
drivers/base/core.c | 29 ++++++++++++++++++
drivers/clk/clk.c | 78 ++++++++++++++++++++++++++++++++++++++++---------
drivers/pmdomain/core.c | 4 +--
include/linux/clk.h | 14 +++++++++
include/linux/device.h | 21 +++++++------
6 files changed, 127 insertions(+), 26 deletions(-)
---
base-commit: 6c94b38b83a04c43ea49004275f0391404051093
change-id: 20260626-clk-sync-state-ad008829a689
Best regards,
--
Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH] clk: qcom: enable ALWAYS_ON for titan_top_gdsc
From: Konrad Dybcio @ 2026-06-26 16:32 UTC (permalink / raw)
To: Brian Masney, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Bryan O'Donoghue
Cc: linux-arm-msm, linux-clk, linux-kernel
In-Reply-To: <20260626-camcc-sc8280xp-titan-top-v1-1-2ca246886493@redhat.com>
On 6/26/26 6:26 PM, Brian Masney wrote:
> With the introduction of sync_state support in the clk and pmdomain
> subsystems, the following warning happens when the unused clocks are
> shutdown in camcc-sc8280xp:
Stuck at _on_ sounds wrong.. does clk_ignore_unused / removing
the sync state from the clock part only resolve this? There may
be a clock dependency for the TITAN_TOP_GDSC that we're failing to
describe
Konrad
^ permalink raw reply
* [PATCH] clk: qcom: enable ALWAYS_ON for titan_top_gdsc
From: Brian Masney @ 2026-06-26 16:26 UTC (permalink / raw)
To: Bjorn Andersson, Michael Turquette, Stephen Boyd,
Bryan O'Donoghue
Cc: linux-arm-msm, linux-clk, linux-kernel, Brian Masney
With the introduction of sync_state support in the clk and pmdomain
subsystems, the following warning happens when the unused clocks are
shutdown in camcc-sc8280xp:
[ 15.408367] titan_top_gdsc status stuck at 'on'
[ 15.408429] WARNING: drivers/clk/qcom/gdsc.c:178 at gdsc_toggle_logic+0x14c/0x160, CPU#2: kworker/u32:1/14
[ 15.408462] Modules linked in: bnep vfat fat ath11k_pci(+) ath11k mac80211 cfg80211 mhi libarc4 snd_soc_wcd938x snd_soc_wcd938x_sdw snd_soc_wcd_classh hci_uart snd_soc_wcd_common
snd_soc_sc8280xp soundwire_qcom snd_soc_wcd_mbhc snd_soc_qcom_sdw slimbus snd_soc_qcom_common regmap_sdw btqca btrtl qcom_camss soundwire_bus btbcm btintel snd_soc_sdca snd_soc_lpass_wsa_macro
bluetooth snd_soc_lpass_tx_macro snd_soc_lpass_va_macro snd_soc_lpass_rx_macro snd_soc_hdmi_codec snd_soc_lpass_macro_common videobuf2_dma_sg ov5675 v4l2_fwnode videobuf2_memops
qcom_spmi_adc5 snd_soc_core qcom_spmi_adc_tm5 videobuf2_v4l2 snd_seq snd_seq_device videobuf2_common v4l2_async qcom_vadc_common qcom_spmi_temp_alarm pm8941_pwrkey industrialio videodev
snd_compress rfkill ac97_bus snd_pcm_dmaengine qcom_tsens mc qcom_edac snd_pcm pci_pwrctrl_pwrseq qcom_cpufreq_hw snd_timer snd qcomtee soundcore tee leds_gpio joydev binfmt_misc zram
lz4hc_compress governor_simpleondemand panel_edp msm xhci_plat_hcd nvme nvme_core dwc3 qcom_pm8008_regulator
[ 15.408688] ucsi_glink nvme_keyring nvme_auth pmic_glink_altmode udc_core typec_ucsi aux_hpd_bridge qcom_battmgr ulpi ubwc_config socinfo ocmem drm_gpuvm qcom_q6v5_pas drm_exec
qcom_pil_info leds_qcom_lpg gpu_sched led_class_multicolor rtc_pm8xxx qcom_pbs qcom_common drm_display_helper qcom_pon qcom_glink_smem qcom_glink ghash_ce pwrseq_qcom_wcn gpio_sbu_mux
qcom_stats phy_qcom_qmp_combo qcom_q6v5 gf128mul cec dispcc_sc8280xp phy_qcom_edp camcc_sc8280xp i2c_qcom_cci qcom_sysmon drm_dp_aux_bus mdt_loader aux_bridge qcom_pm8008 i2c_hid_of_elan
dwc3_qcom_legacy llcc_qcom icc_bwmon gpi typec qcom_refgen_regulator phy_qcom_qmp_usb nvmem_qfprom qcom_ipcc phy_qcom_snps_femto_v2 gpucc_sc8280xp pinctrl_sc8280xp_lpass_lpi qcom_hwspinlock
pinctrl_lpass_lpi lpasscc_sc8280xp qrtr qcom_aoss pmic_glink pdr_interface phy_qcom_qmp_pcie qcom_smd qcom_pdr_msg icc_osm_l3 qcom_wdt qmi_helpers qcom_rng smp2p rpmsg_core gpio_keys pwm_bl
smem hid_multitouch fuse i2c_dev
[ 15.408928] CPU: 2 UID: 0 PID: 14 Comm: kworker/u32:1 Not tainted 7.1.0+ #2 PREEMPT(lazy)
[ 15.408937] Hardware name: LENOVO 21BX0016US/21BX0016US, BIOS N3HET88W (1.60 ) 03/14/2024
[ 15.408942] Workqueue: pm pm_runtime_work
[ 15.408959] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 15.408967] pc : gdsc_toggle_logic+0x14c/0x160
[ 15.408978] lr : gdsc_toggle_logic+0x14c/0x160
[ 15.408987] sp : ffff8000800f3b40
[ 15.408991] x29: ffff8000800f3b40 x28: 0000000000000000 x27: 0000000000000000
[ 15.409003] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000
[ 15.409014] x23: 0000000000000000 x22: 0000000000000001 x21: ffffa33f298fca88
[ 15.409024] x20: 0000000000000000 x19: ffffa33f298fc5b0 x18: 00cd15db75dacefd
[ 15.409035] x17: 000000040044ffff x16: ffffa33f3b1a3d88 x15: 726f776b80000002
[ 15.409045] x14: ffffffffffffffff x13: 0000000000000028 x12: 0101010101010101
[ 15.409056] x11: 7f7f7f7f7f7f7f7f x10: fefeff3039313274 x9 : ffffa33f3a5edafc
[ 15.409067] x8 : ffff8000800f3780 x7 : 0000000000000001 x6 : 0000000000000001
[ 15.409078] x5 : ffff000bf3ca1288 x4 : 0000000000000000 x3 : ffff5cccb6a3f000
[ 15.409088] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000080ae0000
[ 15.409098] Call trace:
[ 15.409103] gdsc_toggle_logic+0x14c/0x160 (P)
[ 15.409115] gdsc_disable+0x4c/0x190
[ 15.409126] _genpd_power_off+0xa0/0x1a8
[ 15.409137] genpd_power_off.part.0+0x180/0x2a0
[ 15.409149] genpd_runtime_suspend+0x218/0x310
[ 15.409155] __rpm_callback+0x50/0x1f8
[ 15.409166] rpm_callback+0x7c/0x90
[ 15.409175] rpm_suspend+0xe8/0x690
[ 15.409185] pm_runtime_work+0xd0/0xe0
[ 15.409195] process_one_work+0x18c/0x518
[ 15.409208] worker_thread+0x190/0x320
[ 15.409218] kthread+0x110/0x130
[ 15.409227] ret_from_fork+0x10/0x20
Let's go ahead and add the flag ALWAYS_ON to titan_top_gdsc so that it
is not disabled in the unused clock sweep.
Fixes: ff93872a9c616 ("clk: qcom: camcc-sc8280xp: Add sc8280xp CAMCC")
Signed-off-by: Brian Masney <bmasney@redhat.com>
Assisted-by: Claude:claude-opus-4-6
---
drivers/clk/qcom/camcc-sc8280xp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/qcom/camcc-sc8280xp.c b/drivers/clk/qcom/camcc-sc8280xp.c
index 18f5a3eb313e..52e1a786083f 100644
--- a/drivers/clk/qcom/camcc-sc8280xp.c
+++ b/drivers/clk/qcom/camcc-sc8280xp.c
@@ -2803,7 +2803,7 @@ static struct gdsc titan_top_gdsc = {
.pd = {
.name = "titan_top_gdsc",
},
- .flags = RETAIN_FF_ENABLE,
+ .flags = ALWAYS_ON | RETAIN_FF_ENABLE,
.pwrsts = PWRSTS_OFF_ON,
};
---
base-commit: 6c94b38b83a04c43ea49004275f0391404051093
change-id: 20260626-camcc-sc8280xp-titan-top-196cf6757b49
Best regards,
--
Brian Masney <bmasney@redhat.com>
^ permalink raw reply related
* Re: [PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY
From: Konrad Dybcio @ 2026-06-26 16:02 UTC (permalink / raw)
To: Doug Anderson
Cc: Bjorn Andersson, Mahadevan P, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, cros-qcom-dts-watchers,
linux-arm-msm, devicetree, linux-kernel, Mahadevan P,
Stephen Boyd
In-Reply-To: <CAD=FV=XQH3kng7MV=Jr=HmZQc4TEUCq+V3TsLNChr5vUHUtXAg@mail.gmail.com>
On 6/22/26 12:11 AM, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 19, 2026 at 8:34 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
[...]
>>>
>>> Are you sure that herobrine has 4 lanes routed on the PCB?
>>
>> +Doug any chance you still have schematics for that old boy?
>>
>> Bjorn, perhaps we could switch to a model where we define the max
>> capabilities (i.e. 4-lane 8.1 GHz link) in the SoC DTs and only limit
>> them as necessary? Not meeting these is borderline a board defect anyway
>
> Bleh, I'd forgotten what a pain it was to look at herobrine schematics
> with the whole qcard "abstraction".
>
> My memory and a quick glance at schematics makes me say that herobrine
> only has 2 lanes of DP. The problem is that this SoC really wasn't
> designed with a laptop in mind. I seem to remember there only being
> one USB 3 port and it is muxed with two of the DP lanes (since the SoC
> is designed to drive a single Type-C port). In order to support all of
> the ports that a laptop should have, you pretty much need to feed that
> one USB 3 port into a USB hub and hardcode the DP to always use two
> lanes.
>
> The two DP lanes then go to a mux where they can be routed either
> towards the left Type C port or the right Type C port.
>
> In terms of whether we can support the 8.1 GHz link speed, I remember
> much debate during the project, but I don't recall all the details. I
> think the discussion was that we were supposed to support the higher
> speeds, but we had to disable them because they weren't working. From
> my fuzzy memory, it was unclear whether the problem was known to be
> hardware or software related. I can try to dig deeper if it's
> relevant.
If anyone still has herobrine easily accessible, I guess a smoke test
with a high res display and this:
diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
index 5c5e4f1dd221..a39e418fdabb 100644
--- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
@@ -464,7 +464,7 @@ &mdss_dp {
&mdss_dp_out {
data-lanes = <0 1>;
- link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000>;
+ link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
};
/* NVMe drive, enabled on a per-board basis */
would be the quickest way to confirm that. Although we can just leave
it as-is if it's problematic.. I think you said there's some folks that
still use it a couple years ago
Konrad
^ permalink raw reply related
* Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
From: Sudeep Holla @ 2026-06-26 15:52 UTC (permalink / raw)
To: Hans de Goede
Cc: Rafael J . Wysocki, Sudeep Holla, Bjorn Andersson, Konrad Dybcio,
Srinivas Kandagatla, Krzysztof Kozlowski, Dmitry Baryshkov,
Bartosz Golaszewski, Abel Vesa, linux-arm-msm, devicetree,
linux-acpi
In-Reply-To: <20260623145225.143218-1-johannes.goede@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 04:52:13PM +0200, Hans de Goede wrote:
> Hi All,
>
> Currently as soon as the kernel boots with a populated DT provided then
> the arch/arm64 code sets acpi_disabled=1 and the complete ACPI subsystem
> gets disabled. On WoA Snapdragon laptops where the factory Windows OS
> actually boots using these tables this is not necessarily desirable.
>
I am bit lost reading the very first statement here.
Who is populating DT and why ? It seems that is the source of the problem.
If windows can boot with ACPI tables, why is it causing issues for the
Linux kernel, any specifics?
IOW why is DT populated which creates the problem you are trying to address
here.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-26 15:49 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <c1ac3ab4-f214-4947-b42f-cbc635be6bbb@oss.qualcomm.com>
On Fri, Jun 26, 2026 at 08:09:58PM +0800, Jie Gan wrote:
[...]
> I have another proposal: what if we allocate the ATID in trace_noc_id() when
> the device does not already have a valid ATID?
>
> Possible scenarios:
>
> If the itnoc device is connected to a TPDM device (which has no ATID),
> trace_noc_id() will be invoked via coresight_path_assign_trace_id(), and a
> valid ATID can be allocated for the path.
>
> If the itnoc device is connected to sources other than TPDM, trace_noc_id()
> will never be invoked, and therefore no ATID will be allocated for the
> device, saving resources.
TBH, I'm not sure I can make a judgement here, as I don't have enough
knowledge of the topology. And I'm not sure whether the listed
connections cover all possible cases.
I also found commit 5799dee92dc2:
| This patch adds platform driver support for the CoreSight Interconnect
| TNOC, Interconnect TNOC is a CoreSight link that forwards trace data
| from a subsystem to the Aggregator TNOC. Compared to Aggregator TNOC,
| it does not have aggregation and ATID functionality.
With your proposal, wouldn't ATID be allocated for the interconnect
TNOC while being skipped for the Aggregator TNOC? That seems to
contradict the commit log.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: glymur: Add label properties to CoreSight devices
From: Konrad Dybcio @ 2026-06-26 15:40 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260624-add-label-node-for-glymur-v2-1-e8420fd7025f@oss.qualcomm.com>
On 6/24/26 2:38 PM, Jie Gan wrote:
> Add label properties to TPDM and CTI nodes in the glymur device tree to
> provide human-readable identifiers for each CoreSight device. These
> labels allow userspace tools and the CoreSight framework to identify
> devices by name rather than by base address.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode
From: Konrad Dybcio @ 2026-06-26 15:34 UTC (permalink / raw)
To: Mukesh Savaliya, Pengyu Luo, Dmitry Baryshkov
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, linux-arm-msm, linux-spi, devicetree,
linux-kernel
In-Reply-To: <14491fd8-f785-4404-878b-5764bb8fd593@oss.qualcomm.com>
On 6/25/26 11:06 AM, Mukesh Savaliya wrote:
> Hi Konrad, sorry for late response.
>
> On 6/15/2026 5:12 PM, Konrad Dybcio wrote:
>> On 6/15/26 6:25 AM, Pengyu Luo wrote:
>>> On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
>>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>>
>>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>>> also support GSI mode, which is highly preferred for certain
>>>>> peripherals like SPI touchscreens to improve performance.
>>>>>
>>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>>> the controller into GSI mode during initialization.
>>>>
>>>> Ideally, this should be decided by the SPI controller based on the
>>>> requirements. Another option would be to prefer GSI for all transfers if
>>>> it is available, ignoring the FIFO even if it is not disabled.
>>>>
>>>
>>> I have read reviews. Can we check if the compatible
>>> "qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
>>> presented, then we enable GSI mode.
>>
>>
>> This hunk is very odd:
>>
>> /*
>> * in case of failure to get gpi dma channel, we can still do the
>> * FIFO mode, so fallthrough
>> */
>> dev_warn(mas->dev, "FIFO mode disabled, but couldn't get DMA, fall back to FIFO mode\n");
>>
>> In my understanding, GSI DMA mode is always preferable. +Mukesh, do
>> you have any insights?
>>
> GSI mode is preferable but if for some reason it fails, we try to continue with the FIFO mode. Just fallback mechanism.
So, would making GSI the default and FIFO the fallback option
sound good?
Konrad
^ permalink raw reply
* Re: [PATCH v4 4/4] spi: qcom-geni: Enable SPI on SA8255p Qualcomm platforms
From: Konrad Dybcio @ 2026-06-26 15:29 UTC (permalink / raw)
To: Praveen Talari, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, bjorn.andersson
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
mukesh.savaliya, aniket.randive, chandana.chiluveru,
jyothi.seerapu, chiluka.harish
In-Reply-To: <20260618-enable-spi-on-sa8255p-v4-4-f5b5067e7e1e@oss.qualcomm.com>
On 6/18/26 11:06 AM, Praveen Talari wrote:
> The Qualcomm automotive SA8255p SoC relies on firmware to configure
> platform resources, including clocks, interconnects and TLMM.
> The driver requests resources operations over SCMI using power
> and performance protocols.
>
> The SCMI power protocol enables or disables resources like clocks,
> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
> such as resume/suspend, to control power states(on/off).
>
> The SCMI performance protocol manages SPI frequency, with each
> frequency rate represented by a performance level. The driver uses
> geni_se_set_perf_opp() API to request the desired frequency rate.
>
> As part of geni_se_set_perf_opp(), the OPP for the requested frequency
> is obtained using dev_pm_opp_find_freq_floor() and the performance
> level is set using dev_pm_opp_set_opp().
>
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
page: next (older)
- 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