* [PATCH v2 2/3] arm64: dts: qcom: sm8250: Add JPEG encoder node
From: Atanas Filipov @ 2026-06-25 13:38 UTC (permalink / raw)
To: linux-media
Cc: bod, mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel, Atanas Filipov
In-Reply-To: <20260625133828.3221781-1-atanas.filipov@oss.qualcomm.com>
Add the JPEG encoder hardware node to the SM8250 device tree so the
qcom-jpeg V4L2 encoder driver can bind and operate on this platform.
The node wires the resources expected by the qcom,jpeg-encoder binding:
- reg: MMIO region at 0xac53000, size 0x1000
- interrupts: SPI 474, edge-triggered
- power-domains: TITAN_TOP_GDSC (camera top-level power domain)
- clocks: GCC HF/SF AXI clocks and CAM_CC core/AHB/CPAS/CAMNOC clocks
- iommus: two SMMU stream IDs for JPEG pixel and JPEG DMA processing
- interconnects: four ICC paths for AHB config and MNOC data traffic
- operating-points-v2: OPP table with performance levels mapped to JPEG
clock frequencies
Signed-off-by: Atanas Filipov <atanas.filipov@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/sm8250.dtsi | 65 ++++++++++++++++++++++++++++
1 file changed, 65 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250.dtsi b/arch/arm64/boot/dts/qcom/sm8250.dtsi
index 7076720413ab..3d741179c916 100644
--- a/arch/arm64/boot/dts/qcom/sm8250.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250.dtsi
@@ -4469,6 +4469,71 @@ cci1_i2c1: i2c-bus@1 {
};
};
+ qcom_jpeg_enc: jpeg-encoder@ac53000 {
+ compatible = "qcom,sm8250-jenc";
+
+ reg = <0 0xac53000 0 0x1000>;
+
+ interrupts = <GIC_SPI 474 IRQ_TYPE_EDGE_RISING>;
+ power-domains = <&camcc TITAN_TOP_GDSC>;
+
+ clocks = <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_JPEG_CLK>;
+
+ clock-names = "bus_hf",
+ "bus_sf",
+ "iface",
+ "cpas",
+ "axi",
+ "core";
+
+ iommus = <&apps_smmu 0x2040 0x400>,
+ <&apps_smmu 0x2440 0x400>;
+
+ interconnects = <&gem_noc MASTER_AMPSS_M0 0 &config_noc SLAVE_CAMERA_CFG 0>,
+ <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI_CH0 0>,
+ <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI_CH0 0>,
+ <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI_CH0 0>;
+ interconnect-names = "cam_ahb",
+ "cam_hf_0_mnoc",
+ "cam_sf_0_mnoc",
+ "cam_sf_icp_mnoc";
+
+ operating-points-v2 = <&jpeg_opp_table>;
+
+ jpeg_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-level = <0>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-400000000 {
+ opp-hz = /bits/ 64 <400000000>;
+ opp-level = <1>;
+ required-opps = <&rpmhpd_opp_svs>;
+ };
+
+ opp-480000000 {
+ opp-hz = /bits/ 64 <480000000>;
+ opp-level = <2>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ };
+
+ opp-600000000-nom {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-level = <3>;
+ required-opps = <&rpmhpd_opp_nom>;
+ };
+ };
+ };
+
camss: camss@ac6a000 {
compatible = "qcom,sm8250-camss";
status = "disabled";
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: media: qcom: Add JPEG encoder binding
From: Atanas Filipov @ 2026-06-25 13:38 UTC (permalink / raw)
To: linux-media
Cc: bod, mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel, Atanas Filipov
In-Reply-To: <20260625133828.3221781-1-atanas.filipov@oss.qualcomm.com>
Add device-tree binding for the Qualcomm JPEG encoder hardware block
present in SM8250 (Kona) SoCs.
The JPEG encoder is a standalone hardware IP within the camera subsystem
that performs JPEG compression in memory-to-memory fashion. It is
separate from the CAMSS ISP pipeline and has its own register space,
interrupt, clocks, power domain, IOMMU streams, and interconnect paths.
Properties documented:
- compatible: qcom,sm8250-jenc
- reg / reg-names: single MMIO region named "jpeg"
- interrupts: single edge-triggered interrupt
- clocks / clock-names: Common clocks and JPEG core clock
- power-domains: TITAN_TOP_GDSC common domain
- iommus: two SMMU stream IDs for JPEG pixel and JPEG DMA processing
- interconnects / interconnect-names
- OPP table mapping performance levels to clock frequencies
Signed-off-by: Atanas Filipov <atanas.filipov@oss.qualcomm.com>
---
.../bindings/media/qcom,jpeg-encoder.yaml | 135 ++++++++++++++++++
1 file changed, 135 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,jpeg-encoder.yaml
diff --git a/Documentation/devicetree/bindings/media/qcom,jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/qcom,jpeg-encoder.yaml
new file mode 100644
index 000000000000..ab8d8951d21f
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/qcom,jpeg-encoder.yaml
@@ -0,0 +1,135 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/qcom,jpeg-encoder.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm JPEG Encoder
+
+maintainers:
+ - Atanas Filipov <atanas.filipov@oss.qualcomm.com>
+
+description:
+ Qualcomm JPEG Encoder is the JPEG encode hardware present in Qualcomm SoCs.
+
+properties:
+ compatible:
+ enum:
+ - qcom,sm8250-jenc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ minItems: 6
+ maxItems: 6
+
+ clock-names:
+ items:
+ - const: bus_hf
+ - const: bus_sf
+ - const: iface
+ - const: cpas
+ - const: axi
+ - const: core
+
+ power-domains:
+ maxItems: 1
+
+ iommus:
+ description:
+ Two SMMU stream IDs for the JPEG hardware. The first entry is for
+ the JPEG core engine; the second is for the JPEG DMA/scale path.
+ The exact stream ID assignment is SoC-specific and not publicly
+ documented by Qualcomm.
+ minItems: 2
+ maxItems: 2
+
+ interconnects:
+ maxItems: 4
+
+ interconnect-names:
+ items:
+ - const: cam_ahb
+ - const: cam_hf_0_mnoc
+ - const: cam_sf_0_mnoc
+ - const: cam_sf_icp_mnoc
+
+ operating-points-v2: true
+
+ opp-table:
+ type: object
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - power-domains
+ - iommus
+ - interconnects
+ - interconnect-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/qcom,camcc-sm8250.h>
+ #include <dt-bindings/clock/qcom,gcc-sm8250.h>
+ #include <dt-bindings/interconnect/qcom,sm8250.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ jpeg-encoder@ac53000 {
+ compatible = "qcom,sm8250-jenc";
+ reg = <0xac53000 0x1000>;
+
+ interrupts = <GIC_SPI 474 IRQ_TYPE_EDGE_RISING>;
+ power-domains = <&camcc TITAN_TOP_GDSC>;
+
+ clocks = <&gcc GCC_CAMERA_HF_AXI_CLK>,
+ <&gcc GCC_CAMERA_SF_AXI_CLK>,
+ <&camcc CAM_CC_CORE_AHB_CLK>,
+ <&camcc CAM_CC_CPAS_AHB_CLK>,
+ <&camcc CAM_CC_CAMNOC_AXI_CLK>,
+ <&camcc CAM_CC_JPEG_CLK>;
+ clock-names =
+ "bus_hf",
+ "bus_sf",
+ "iface",
+ "cpas",
+ "axi",
+ "core";
+
+ iommus = <&apps_smmu 0x2040 0x400>,
+ <&apps_smmu 0x2440 0x400>;
+
+ interconnects =
+ <&gem_noc MASTER_AMPSS_M0 0 &config_noc SLAVE_CAMERA_CFG 0>,
+ <&mmss_noc MASTER_CAMNOC_HF 0 &mc_virt SLAVE_EBI_CH0 0>,
+ <&mmss_noc MASTER_CAMNOC_SF 0 &mc_virt SLAVE_EBI_CH0 0>,
+ <&mmss_noc MASTER_CAMNOC_ICP 0 &mc_virt SLAVE_EBI_CH0 0>;
+ interconnect-names =
+ "cam_ahb",
+ "cam_hf_0_mnoc",
+ "cam_sf_0_mnoc",
+ "cam_sf_icp_mnoc";
+
+ operating-points-v2 = <&jpeg_opp_table>;
+
+ jpeg_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-300000000 {
+ opp-hz = /bits/ 64 <300000000>;
+ opp-level = <0>;
+ };
+
+ opp-600000000 {
+ opp-hz = /bits/ 64 <600000000>;
+ opp-level = <3>;
+ };
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/3] Add Qualcomm JPEG V4L2 encoder for SM8250
From: Atanas Filipov @ 2026-06-25 13:38 UTC (permalink / raw)
To: linux-media
Cc: bod, mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel, Atanas Filipov
This series adds support for the Qualcomm JPEG V4L2 mem2mem encoder on SM8250.
The goal is to upstream a standards-based JPEG encode path using the V4L2 M2M
framework, with DT-described hardware resources and SoC DTS integration.
Patch layout:
- 1/3: dt-bindings: media: qcom,jpeg-encoder: add binding
- 2/3: arm64: dts: qcom: sm8250: add JPEG encoder node
- 3/3: media: qcom: jpeg: add Qualcomm JPEG V4L2 encoder
Supported compatibles:
- qcom,sm8250-jenc
Driver scope and design choices:
- uses the standard V4L2 mem2mem + vb2 workflow
- maps runtime resources from DT (clocks/interconnects/iommu/etc.)
- keeps userspace interface within existing V4L2 JPEG controls/framework
- uses runtime PM for balanced power transitions across stream/probe/remove
Functional validation (hardware):
- platform: Kona / SM8250 / qcom,sm8250-jenc / RB5
- tested with v4l2-ctl and GStreamer (v4l2jpegenc):
- single-frame encode: 8192x8192 NV12
- single-frame encode: 1920x1080 NV12
- single-frame encode: 1920x1080 GREY
- GStreamer NV12 pipeline to JPEG files
- GStreamer GRAY8 pipeline to MJPEG output
Changes since v1:
Binding (dt-bindings: media: qcom,jpeg-encoder):
- Removed qcm6490 and sm8550 compatible strings; this series is SM8250
only.
- Fixed clock-names block in the binding example.
- Added operating-points-v2 property documentation.
- Fixed reg in the example to use the correct 2-cell (64-bit) format
matching the sm8250 soc node address/size cells.
- Dropped reg-names: with a single reg entry it is unnecessary.
- Removed description literal block scalar (|).
- Dropped _clk suffix from clock-names.
- Added iommus description in the properties section with
minItems/maxItems constraints.
Driver (media: qcom: jpeg):
- Trimmed hardware register map and definitions.
- Migrated to devm_clk_bulk_get_all() replacing per-SoC named clock
arrays.
- Migrated to the OPP framework for core clock rate and performance
level management; the OPP table is embedded in the DTS node and maps
performance levels to frequencies.
- Switched to devm_platform_ioremap_resource(pdev, 0); reg-names no
longer needed.
- Switched to RUNTIME_PM_OPS() and SYSTEM_SLEEP_PM_OPS() macros.
- Switched to devm_mutex_init().
- platform_set_drvdata() moved to immediately after allocation.
- .pm uses pm_ptr().
Known limitations:
- scaling is not supported
- width and height must be aligned to 16 pixels
Atanas Filipov (3):
dt-bindings: media: qcom: Add JPEG encoder binding
arm64: dts: qcom: sm8250: Add JPEG encoder node
media: qcom: jpeg: Add Qualcomm JPEG V4L2 encoder
Atanas Filipov (3):
dt-bindings: media: qcom: Add JPEG encoder binding
arm64: dts: qcom: sm8250: Add JPEG encoder node
media: qcom: jpeg: Add Qualcomm JPEG V4L2 encoder
.../bindings/media/qcom,jpeg-encoder.yaml | 135 ++
arch/arm64/boot/dts/qcom/sm8250.dtsi | 65 +
drivers/media/platform/qcom/Kconfig | 1 +
drivers/media/platform/qcom/Makefile | 1 +
drivers/media/platform/qcom/jpeg/Kconfig | 17 +
drivers/media/platform/qcom/jpeg/Makefile | 9 +
.../media/platform/qcom/jpeg/qcom_jenc_defs.h | 259 +++
.../media/platform/qcom/jpeg/qcom_jenc_dev.c | 313 ++++
.../media/platform/qcom/jpeg/qcom_jenc_dev.h | 109 ++
.../media/platform/qcom/jpeg/qcom_jenc_hdr.c | 354 ++++
.../media/platform/qcom/jpeg/qcom_jenc_hdr.h | 119 ++
.../media/platform/qcom/jpeg/qcom_jenc_ops.c | 1510 +++++++++++++++++
.../media/platform/qcom/jpeg/qcom_jenc_ops.h | 52 +
.../media/platform/qcom/jpeg/qcom_jenc_res.c | 39 +
.../media/platform/qcom/jpeg/qcom_jenc_res.h | 30 +
.../qcom/jpeg/qcom_jenc_v420_hw_info.h | 527 ++++++
.../media/platform/qcom/jpeg/qcom_jenc_v4l2.c | 1136 +++++++++++++
.../media/platform/qcom/jpeg/qcom_jenc_v4l2.h | 25 +
18 files changed, 4701 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/qcom,jpeg-encoder.yaml
create mode 100644 drivers/media/platform/qcom/jpeg/Kconfig
create mode 100644 drivers/media/platform/qcom/jpeg/Makefile
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_defs.h
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_dev.c
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_dev.h
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_hdr.c
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_hdr.h
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_ops.c
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_ops.h
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_res.c
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_res.h
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_v420_hw_info.h
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_v4l2.c
create mode 100644 drivers/media/platform/qcom/jpeg/qcom_jenc_v4l2.h
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
prerequisite-patch-id: 8bfa054e24f9de8d7a09cfab8db0efff173d98fc
--
2.34.1
^ permalink raw reply
* Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Sunyun Yang @ 2026-06-25 13:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard,
Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <a0352a42-15db-4c7a-ae73-8a4e1543cd50@kernel.org>
Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 21:17写道：
>
> On 25/06/2026 15:14, Sunyun Yang wrote:
> > Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 20:54写道：
> >>
> >> On 08/05/2026 15:40, syyang@lontium.com wrote:
> >>> +
> >>> +static void lt9611c_reset(struct lt9611c *lt9611c)
> >>> +{
> >>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> >>> + msleep(20);
> >>> +
> >>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> >>> + msleep(20);
> >>> +
> >>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> >>
> >> This is just plain wrong. Why do you assert, then de-assert and then
> >> finally assert AGAIN the reset leaving the device in powerdown stage?
> >>
> > I am using software to emulate the hardware RESET button on our EVB.
> > When the hardware RESET button is pressed while our chip is running,
> > the signal level changes from HIGH to LOW and then back to HIGH.
> >
> > Of course, we can also use the following:
> > static void lt9611c_reset(struct lt9611c *lt9611c)
> > {
> > gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> > msleep(50);
> > gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> > msleep(20);
> > }
>
> Makes no sense either and you just did not get the point and did not
> answer my question. I asked WHY you leave asserted. Answer "we emulate"
> is just plain wrong.
>
> So again please answer:
>
> Why do you leave device with reset asserted?
>
devicetree: reset-gpios = <&tlmm 128 GPIO_ACTIVE_HIGH>;
GPIO_ACTIVE_HIGH:
gpiod_set_value_cansleep(lt9611c->reset_gpio, 0); ------ reset pin
is Low level : Clear the register configuration in the chip to stop
the chip from working.
gpiod_set_value_cansleep(lt9611c->reset_gpio, 1); ------ reset pin
is high level: The chip resumes operation.
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-25 13:24 UTC (permalink / raw)
To: syyang, robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard
Cc: Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, yangsunyun1993, xmzhu, xmzhu, rlyu,
xbpeng
In-Reply-To: <20260508134009.4582-3-syyang@lontium.com>
On 08/05/2026 15:40, syyang@lontium.com wrote:
> +
> +static int lt9611c_probe(struct i2c_client *client)
> +{
> + const struct i2c_device_id *id = i2c_client_get_device_id(client);
> + struct lt9611c *lt9611c;
> + struct device *dev = &client->dev;
> + bool fw_updated = false;
> + int ret;
> +
> + crc8_populate_msb(lt9611c_crc8_table, LT9611C_CRC_POLYNOMIAL);
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C))
> + return dev_err_probe(dev, -ENODEV, "device doesn't support I2C\n");
> +
> + lt9611c = devm_drm_bridge_alloc(dev, struct lt9611c, bridge, <9611c_bridge_funcs);
> + if (IS_ERR(lt9611c))
> + return dev_err_probe(dev, PTR_ERR(lt9611c), "drm bridge alloc failed.\n");
> +
> + lt9611c->dev = dev;
> + lt9611c->client = client;
> + lt9611c->chip_type = id->driver_data;
Also, NULL pointer exception here. With simple look I found at least two
easy to reproduce and trigger bugs which makes me questioning how did
you test it.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Sunyun Yang @ 2026-06-25 13:21 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard,
Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <206f2e80-132a-4586-bd27-5983783f97ce@kernel.org>
Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 20:59写道：
>
> On 25/06/2026 04:01, Sunyun Yang wrote:
> > Sunyun Yang <syyang@lontium.com> 于2026年6月25日周四 08:52写道：
> >>
> >> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月24日周三 22:05写道：
> >>>
> >>> On 11/05/2026 05:28, Sunyun Yang wrote:
> >>>> <syyang@lontium.com> 于2026年5月8日周五 22:25写道：
> >>>>>
> >>>>> From: Sunyun Yang <syyang@lontium.com>
> >>>>>
> >>>>> LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port
> >>>>> mipi dsi and output hdmi, differences in hardware features:
> >>>>> - LT9611C: supports 1-port mipi dsi to hdmi 1.4
> >>>>> - LT9611EX: supports 2-port mipi dsi to hdmi 1.4
> >>>>> - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0
> >>>>>
> >>>>> Signed-off-by: Sunyun Yang <syyang@lontium.com>
> >>>>> ---
> >>>>> .../bindings/display/bridge/lontium,lt9611.yaml | 8 ++++++--
> >>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
> >>>>>
> >>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> >>>>> index 429a06057ae8..e0821a63d9d7 100644
> >>>>> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> >>>>> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
> >>>>> @@ -4,19 +4,23 @@
> >>>>> $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
> >>>>> $schema: http://devicetree.org/meta-schemas/core.yaml#
> >>>>>
> >>>>> -title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge
> >>>>> +title: Lontium LT9611(UXC/C/EX/UXD) 2 Port MIPI DSI to HDMI Bridge
> >>>>>
> >>>>> maintainers:
> >>>>> - Vinod Koul <vkoul@kernel.org>
> >>>>>
> >>>>> description: |
> >>>>> - The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI
> >>>>> + The LT9611、LT9611UXC、LT9611C、LT9611EX and LT9611UXD
> >>>>> + are bridge devices which convert DSI to HDMI
> >>>>>
> >>>>> properties:
> >>>>> compatible:
> >>>>> enum:
> >>>>> - lontium,lt9611
> >>>>> + - lontium,lt9611c
> >>>>> + - lontium,lt9611ex
> >>>>> - lontium,lt9611uxc
> >>>>> + - lontium,lt9611uxd
> >>>>>
> >>>>> reg:
> >>>>> maxItems: 1
> >>>>> --
> >>>>
> >>>> Gentle ping.
> >>>> Thanks.
> >>>
> >>> Except mess with threading, your patchset does not build, when applied
> >>> on next-20260618.
> >>>
> >>> What is the base of this?
> >>>
> >>
> >> Thanks for testing my patchset on next-20260618.
> >>
> >> The base of this series is v7.0.
> >>
> > Krzysztof, Is Sashiko AI review required before merging a patch now?
>
> Fixing obvious bugs in your code is required before merging.
>
> But even without bugs, this cannot be merged - does not apply. And you
> sending the same three different times does not help, because now there
> is complete mess in reviews.
>
We will modify the driver and the device tree, and test it on next-20260623.
Additionally, we would like to ask you a question regarding Sashiko
AI: Is Sashiko AI review required before merging a patch now?
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v1 3/3] arm64: dts: qcom: x1e78100-t14s: Add thermal zones for keyboard skin and charging sensors
From: Daniel Lezcano @ 2026-06-25 13:20 UTC (permalink / raw)
To: Konrad Dybcio, sre, hansg, ilpo.jarvinen, linux, andersson,
konradybcio, robh, krzk+dt, conor+dt
Cc: bryan.odonoghue, platform-driver-x86, linux-kernel, linux-hwmon,
linux-arm-msm, devicetree
In-Reply-To: <ea233160-505d-496d-a321-dc23e7f69d80@oss.qualcomm.com>
On 6/25/26 13:36, Konrad Dybcio wrote:
> On 6/24/26 11:08 PM, Daniel Lezcano wrote:
>> Add thermal zone descriptions for the keyboard skin temperature and
>> battery charging circuitry sensors exposed by the embedded controller.
>>
>> Expose the EC as a thermal sensor provider and define two thermal zones
>> using the temperatures reported by the EC:
>>
>> - a keyboard skin temperature zone with passive and hot trip points,
>> - a charging circuitry temperature zone with multiple passive trip
>> points and CPU frequency mitigation levels.
>>
>> The charging thermal zone progressively throttles the different CPU
>> clusters as the charging circuitry temperature rises and triggers a hot
>> condition at the highest trip point.
>>
>> This provides thermal framework integration for the EC temperature
>> sensors and enables platform thermal management through standard thermal
>> zone definitions.
>>
>> Signed-off-by: Daniel Lezcano <daniel.lezcano@oss.qualcomm.com>
>> ---
>
> [...]
>
>> + ec-charging-thermal {
>> + polling-delay = <5000>;
>> + polling-delay-passive = <2000>;
>> +
>> + thermal-sensors = <&ec 3>;
>> +
>> + trips {
>> + psv0: trip-point0 {
>
> "ec_charging_tripN", please - these labels are file-wide, so it's
> better if they're not overly short
>
>> + temperature = <55000>;
>> + hysteresis = <0>;
>> + type = "passive";
>> + };
>> +
>> + alert0: trip-point1 {
>> + temperature = <63000>;
>> + hysteresis = <0>;
>> + type = "hot";
>> + };
>> + };
>> +
>> + cooling-maps {
>> + map0 {
>> + trip = <&psv0>;
>> + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu1 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu2 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu3 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu4 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu5 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu6 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu7 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu8 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu9 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu10 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>,
>> + <&cpu11 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
>> +
>> + };
>
> Stray \n above, might also possibly want to throttle the GPU.
At this point, I don't think GPU throttling is needed
^ permalink raw reply
* Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-25 13:17 UTC (permalink / raw)
To: Sunyun Yang
Cc: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard,
Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <CAFQXuNbKBfyeQL3N3P5QY=6BWoD3O6DSbXN-WMA1rRG9vCs3Kg@mail.gmail.com>
On 25/06/2026 15:14, Sunyun Yang wrote:
> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 20:54写道：
>>
>> On 08/05/2026 15:40, syyang@lontium.com wrote:
>>> +
>>> +static void lt9611c_reset(struct lt9611c *lt9611c)
>>> +{
>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
>>> + msleep(20);
>>> +
>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
>>> + msleep(20);
>>> +
>>> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
>>
>> This is just plain wrong. Why do you assert, then de-assert and then
>> finally assert AGAIN the reset leaving the device in powerdown stage?
>>
> I am using software to emulate the hardware RESET button on our EVB.
> When the hardware RESET button is pressed while our chip is running,
> the signal level changes from HIGH to LOW and then back to HIGH.
>
> Of course, we can also use the following:
> static void lt9611c_reset(struct lt9611c *lt9611c)
> {
> gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> msleep(50);
> gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> msleep(20);
> }
Makes no sense either and you just did not get the point and did not
answer my question. I asked WHY you leave asserted. Answer "we emulate"
is just plain wrong.
So again please answer:
Why do you leave device with reset asserted?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Sunyun Yang @ 2026-06-25 13:14 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard,
Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <3188f63f-5358-48d7-b934-af20a8f95c6f@kernel.org>
Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月25日周四 20:54写道：
>
> On 08/05/2026 15:40, syyang@lontium.com wrote:
> > +
> > +static void lt9611c_reset(struct lt9611c *lt9611c)
> > +{
> > + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> > + msleep(20);
> > +
> > + gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> > + msleep(20);
> > +
> > + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
>
> This is just plain wrong. Why do you assert, then de-assert and then
> finally assert AGAIN the reset leaving the device in powerdown stage?
>
I am using software to emulate the hardware RESET button on our EVB.
When the hardware RESET button is pressed while our chip is running,
the signal level changes from HIGH to LOW and then back to HIGH.
Of course, we can also use the following:
static void lt9611c_reset(struct lt9611c *lt9611c)
{
gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
msleep(50);
gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
msleep(20);
}
> > + msleep(400);
> > +
> > + dev_dbg(lt9611c->dev, "lt9611c reset");
>
> Drop such debug statements. This is some downstream, semi-useless code.
> You are not supposed to add debug to every call.
>
it will be fixed in next version.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v6 07/10] ACPI: APEI: introduce GHES helper
From: Ahmed Tiba @ 2026-06-25 13:12 UTC (permalink / raw)
To: Julian Braha, Rafael J. Wysocki, Tony Luck, Borislav Petkov,
Hanjun Guo, Mauro Carvalho Chehab, Shuai Xue, Len Brown,
Saket Dumbre, Davidlohr Bueso, Jonathan Cameron, Dave Jiang,
Alison Schofield, Vishal Verma, Ira Weiny, Dan Williams,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan
Cc: linux-kernel, linux-acpi, acpica-devel, linux-cxl, devicetree,
linux-edac, linux-doc, Dmitry.Lamerov
In-Reply-To: <84dabe49-8405-4213-8b73-433cf736ded9@gmail.com>
On 19/06/2026 18:46, Julian Braha wrote:
> On 6/19/26 16:45, Ahmed Tiba wrote:
>> GHES_CPER_HELPERS is intended for both the ACPI GHES path and the DT
>> firmware-first provider, so I do not want to tie it to ACPI.
>
> So what's the plan to fix the build error when ACPI is disabled:
> https://lore.kernel.org/all/0f131ee4-d335-45d2-b6ae-49c18df1353b@gmail.com/
>
> - Julian Braha
I can fix this by adding a !CONFIG_ACPI fallback for
arch_apei_report_x86_error() in drivers/firmware/efi/cper-x86.c.
Thanks,
Ahmed
^ permalink raw reply
* Re: [PATCH v6 1/2] dt-bindings: bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-25 12:59 UTC (permalink / raw)
To: Sunyun Yang
Cc: robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard,
Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, xmzhu, xmzhu, rlyu, xbpeng
In-Reply-To: <CAFQXuNbvSQSZayBGcS6L106ic6M9D+xi8CF9=k27fCAn5U8tdg@mail.gmail.com>
On 25/06/2026 04:01, Sunyun Yang wrote:
> Sunyun Yang <syyang@lontium.com> 于2026年6月25日周四 08:52写道：
>>
>> Krzysztof Kozlowski <krzk@kernel.org> 于2026年6月24日周三 22:05写道：
>>>
>>> On 11/05/2026 05:28, Sunyun Yang wrote:
>>>> <syyang@lontium.com> 于2026年5月8日周五 22:25写道：
>>>>>
>>>>> From: Sunyun Yang <syyang@lontium.com>
>>>>>
>>>>> LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port
>>>>> mipi dsi and output hdmi, differences in hardware features:
>>>>> - LT9611C: supports 1-port mipi dsi to hdmi 1.4
>>>>> - LT9611EX: supports 2-port mipi dsi to hdmi 1.4
>>>>> - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0
>>>>>
>>>>> Signed-off-by: Sunyun Yang <syyang@lontium.com>
>>>>> ---
>>>>> .../bindings/display/bridge/lontium,lt9611.yaml | 8 ++++++--
>>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>>>>> index 429a06057ae8..e0821a63d9d7 100644
>>>>> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>>>>> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9611.yaml
>>>>> @@ -4,19 +4,23 @@
>>>>> $id: http://devicetree.org/schemas/display/bridge/lontium,lt9611.yaml#
>>>>> $schema: http://devicetree.org/meta-schemas/core.yaml#
>>>>>
>>>>> -title: Lontium LT9611(UXC) 2 Port MIPI to HDMI Bridge
>>>>> +title: Lontium LT9611(UXC/C/EX/UXD) 2 Port MIPI DSI to HDMI Bridge
>>>>>
>>>>> maintainers:
>>>>> - Vinod Koul <vkoul@kernel.org>
>>>>>
>>>>> description: |
>>>>> - The LT9611 and LT9611UXC are bridge devices which convert DSI to HDMI
>>>>> + The LT9611、LT9611UXC、LT9611C、LT9611EX and LT9611UXD
>>>>> + are bridge devices which convert DSI to HDMI
>>>>>
>>>>> properties:
>>>>> compatible:
>>>>> enum:
>>>>> - lontium,lt9611
>>>>> + - lontium,lt9611c
>>>>> + - lontium,lt9611ex
>>>>> - lontium,lt9611uxc
>>>>> + - lontium,lt9611uxd
>>>>>
>>>>> reg:
>>>>> maxItems: 1
>>>>> --
>>>>
>>>> Gentle ping.
>>>> Thanks.
>>>
>>> Except mess with threading, your patchset does not build, when applied
>>> on next-20260618.
>>>
>>> What is the base of this?
>>>
>>
>> Thanks for testing my patchset on next-20260618.
>>
>> The base of this series is v7.0.
>>
> Krzysztof, Is Sashiko AI review required before merging a patch now?
Fixing obvious bugs in your code is required before merging.
But even without bugs, this cannot be merged - does not apply. And you
sending the same three different times does not help, because now there
is complete mess in reviews.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ARM: dts: am33xx: avoid invalid OCP device-link for timers
From: Wagner Popov dos Santos @ 2026-06-25 12:55 UTC (permalink / raw)
To: AaroKoskinenaaro.koskinen
Cc: AndreasKemnadeandreas, KevinHilmankhilman, RogerQuadrosrogerq,
TonyLindgrentony, RobHerringrobh, KrzysztofKozlowskikrzk+dt,
ConorDooleyconor+dt, linux-omap, devicetree, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-ARM-dts-am33xx-avoid-invalid-OCP-device-link-for-tim.patch --]
[-- Type: text/x-diff, Size: 1829 bytes --]
From 6d482ff72d1a11a5851602717a48eb3e059946d4 Mon Sep 17 00:00:00 2001
From: Wagner Popov dos Santos <wpopov@gmail.com>
Date: Wed, 24 Jun 2026 13:28:02 -0300
Subject: [PATCH] ARM: dts: am33xx: avoid invalid OCP device-link for timers
This patch fixes boot-time fw_devlink errors on AM335x/UCC3 caused
by invalid device-link creation attempts involving timer1/timer2
and supplier ocp.
Observed kernel log messages:
ti-sysc 44e31000.target-module: Failed to create device link (0x180)
with supplier ocp for
/ocp/interconnect@44c00000/segment@200000/target-module@31000/timer@0
ti-sysc 48040000.target-module: Failed to create device link (0x180)
with supplier ocp for
/ocp/interconnect@48000000/segment@0/target-module@40000/timer@0
The change updates dependency handling for timer1 and timer2 so the
kernel no longer attempts this invalid link-creation path during
initialization of supplier ocp.
Impact:
- Removes the two ti-sysc/fw_devlink error messages at boot
- Preserves current timer and clock assignment behavior
- No functional regression observed in boot and timer operation tests
Signed-off-by: Wagner Popov dos Santos <wpopov@gmail.com>
---
arch/arm/boot/dts/ti/omap/am33xx.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/ti/omap/am33xx.dtsi b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
index ca3e7f5d7d0d..760598d5ae1c 100644
--- a/arch/arm/boot/dts/ti/omap/am33xx.dtsi
+++ b/arch/arm/boot/dts/ti/omap/am33xx.dtsi
@@ -708,6 +708,7 @@ &timer1_target {
timer@0 {
assigned-clocks = <&timer1_fck>;
assigned-clock-parents = <&sys_clkin_ck>;
+ post-init-providers = <&ocp>;
};
};
@@ -721,5 +722,6 @@ &timer2_target {
timer@0 {
assigned-clocks = <&timer2_fck>;
assigned-clock-parents = <&sys_clkin_ck>;
+ post-init-providers = <&ocp>;
};
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v6 2/2] drm/bridge: Add Lontium LT9611C(EX/UXD) MIPI DSI to HDMI driver
From: Krzysztof Kozlowski @ 2026-06-25 12:54 UTC (permalink / raw)
To: syyang, robh, krzk+dt, conor+dt, andrzej.hajda, neil.armstrong,
dmitry.baryshkov, maarten.lankhorst, rfoss, mripard
Cc: Laurent.pinchart, tzimmermann, jonas, jernej.skrabec, devicetree,
dri-devel, linux-kernel, yangsunyun1993, xmzhu, xmzhu, rlyu,
xbpeng
In-Reply-To: <20260508134009.4582-3-syyang@lontium.com>
On 08/05/2026 15:40, syyang@lontium.com wrote:
> +
> +static void lt9611c_reset(struct lt9611c *lt9611c)
> +{
> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
> + msleep(20);
> +
> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 0);
> + msleep(20);
> +
> + gpiod_set_value_cansleep(lt9611c->reset_gpio, 1);
This is just plain wrong. Why do you assert, then de-assert and then
finally assert AGAIN the reset leaving the device in powerdown stage?
> + msleep(400);
> +
> + dev_dbg(lt9611c->dev, "lt9611c reset");
Drop such debug statements. This is some downstream, semi-useless code.
You are not supposed to add debug to every call.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 04/12] i3c: master: Add support for devices using SETAASA
From: Frank Li @ 2026-06-25 12:42 UTC (permalink / raw)
To: Akhil R
Cc: Frank.Li, conor+dt, devicetree, linux-hwmon, linux-i3c, robh,
sashiko-reviews
In-Reply-To: <20260625093815.1794492-1-akhilrajeev@nvidia.com>
On Thu, Jun 25, 2026 at 09:38:15AM +0000, Akhil R wrote:
> On Wed, 24 Jun 2026 13:57:46 -0400, Frank Li wrote:
> ...
> ...
> >> [Severity: High]
> >> Is it possible that sending the SETAASA broadcast before direct SETDASA
> >> assignments breaks initialization for devices that natively support SETAASA
> >> but are configured for SETDASA?
> >>
> >> According to the I3C specification, any device on the bus natively supporting
> >> SETAASA will respond to this broadcast by adopting its static address as its
> >> dynamic address.
> >>
> >> After this broadcast, the driver iterates through devices and attempts to
> >> assign custom dynamic addresses via direct SETDASA commands:
> >>
> >> drivers/i3c/master.c:i3c_master_early_i3c_dev_add() {
> >> ...
> >> ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
> >> i3cdev->boardinfo->init_dyn_addr);
> >> ...
> >> }
> >>
> >> Since the target device already adopted its dynamic address during the
> >> SETAASA broadcast, it is no longer in the unassigned state and will NACK
> >> the subsequent SETDASA command.
> >
> > Look like correct, but I am not sure if target will NACK SETDASA. Or should
> > use SETNEWDA for SETAASA method.
>
> Yes, this looks valid for mixed device buses. I can move
> i3c_master_setaasa_locked() after the SETDASA handling and before
> i3c_master_do_daa() in the same function, so SETDASA-assigned devices will
> ignore the later SETAASA broadcast. Does that sound good to you?
yes, try it to follow spec.
Frank
>
> Best Regards,
> Akhil
^ permalink raw reply
* Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level triggered.
From: Parthiban.Veerasooran @ 2026-06-25 12:36 UTC (permalink / raw)
To: Selvamani.Rajagopal, andrew+netdev, davem, edumazet, kuba, pabeni,
robh, krzk+dt, conor+dt, Pier.Beruto
Cc: andrew, netdev, linux-kernel, Conor.Dooley, devicetree
In-Reply-To: <CYYPR02MB9828E1167750AEA090EC60CD83EE2@CYYPR02MB9828.namprd02.prod.outlook.com>
Hi Selvamani,
On 23/06/26 11:18 am, Selvamani Rajagopal wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>> -----Original Message-----
>> From: Parthiban.Veerasooran@microchip.com <Parthiban.Veerasooran@microchip.com>
>> Subject: Re: [PATCH net v5 1/4] net: ethernet: oa_tc6: Interrupt is active low, level
>> triggered.
>>
>>
>> I will find some time this week to test and share my feedback. In the
>> meantime, would it be possible for you to test using two instances (Test
>> Case 2)? I did not encounter many issues when testing with a single
>> instance.
>>
>> I believe that testing with two instances increases the likelihood of
>> reproducing the issue in your setup as well.
>
> Parthiban,
>
> Thanks.
>
> Our EVB design allows only one board to be connected to one Raspberry Pi.
> So, I don't think I can have a setup like yours. We did test with three Raspberry Pi boards with
> multi-drop connection. Couldn't see your "NULL pointer" crash. Will keep trying though.
Thank you for the update. So it seems you can't connect two of your
MAC-PHYs in one RPI 4? RPI 4 can support two SPI devices (MAC-PHYs).
https://patchwork.kernel.org/project/netdevbpf/list/?series=1114495&state=%2A&archive=both
https://patchwork.kernel.org/project/netdevbpf/patch/20260621-fix-race-condition-and-crash-v1-1-87e290d9357f@onsemi.com/
https://patchwork.kernel.org/project/netdevbpf/patch/20260621-fix-race-condition-and-crash-v1-2-87e290d9357f@onsemi.com/
With your above patches, I did a quick test (Test case 2) with two
Microchip MAC-PHYs and faced a similar issue reported before. Sharing
the dmesg crash log for your reference.
[ 2863.182105] eth1: Receive buffer overflow error
[ 2863.199905] eth1: Receive buffer overflow error
[ 2867.669312] Unable to handle kernel NULL pointer dereference at
virtual address 00000000000000b8
[ 2867.677658] Mem abort info:
[ 2867.680474] ESR = 0x0000000096000005
[ 2867.684258] EC = 0x25: DABT (current EL), IL = 32 bits
[ 2867.689630] SET = 0, FnV = 0
[ 2867.692717] EA = 0, S1PTW = 0
[ 2867.695888] FSC = 0x05: level 1 translation fault
[ 2867.700825] Data abort info:
[ 2867.703726] ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[ 2867.709303] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 2867.714399] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 2867.719773] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000113c2e000
[ 2867.726296] [00000000000000b8] pgd=0000000000000000,
p4d=0000000000000000, pud=0000000000000000
[ 2867.735109] Internal error: Oops: 0000000096000005 [#1] SMP
[ 2867.740830] Modules linked in: lan865x_t1s(O) microchip_t1s(O) sch_fq
snd_seq_dummy snd_hrtimer snd_seq snd_seq_device rfcomm algif_hash
aes_neon_bs algif_skcipher af_alg bnep binfmt_misc brcmfmac_cyw brcmfmac
hci_uart brcmutil btbcm bluetooth vc4 cfg80211 snd_soc_hdmi_codec
drm_exec ecdh_generic ecc drm_display_helper cec rfkill bcm2835_codec(C)
drm_dma_helper v3d rpi_hevc_dec drm_client_lib bcm2835_v4l2(C) gpu_sched
drm_shmem_helper crc_ccitt bcm2835_isp snd_soc_core drm_kms_helper
bcm2835_mmal_vchiq v4l2_mem2mem vc_sm_cma videobuf2_vmalloc
videobuf2_dma_contig raspberrypi_hwmon videobuf2_memops snd_compress
snd_bcm2835(C) videobuf2_v4l2 snd_pcm_dmaengine i2c_brcmstb snd_pcm
snd_timer videodev videobuf2_common snd mc raspberrypi_gpiomem
spi_bcm2835 gpio_fan nvmem_rmem sch_fq_codel i2c_dev zram lz4_compress
drm fuse drm_panel_orientation_quirks backlight nfnetlink [last
unloaded: microchip_t1s(O)]
[ 2867.821558] CPU: 3 UID: 0 PID: 2808 Comm: irq/59-spi0.0 Tainted: G
C O 7.1.0-rc7-v8+ #2 PREEMPT
[ 2867.831779] Tainted: [C]=CRAP, [O]=OOT_MODULE
[ 2867.836183] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 2867.842088] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS
BTYPE=--)
[ 2867.849138] pc : oa_tc6_update_rx_skb+0x2c/0xa8 [lan865x_t1s]
[ 2867.854955] lr : oa_tc6_macphy_threaded_irq+0x430/0x870 [lan865x_t1s]
[ 2867.861476] sp : ffffffc083dbbd20
[ 2867.864825] x29: ffffffc083dbbd20 x28: 000000003e002020 x27:
ffffffed1cf609c8
[ 2867.872051] x26: 0000000000000000 x25: 0000000000000001 x24:
ffffff8040796480
[ 2867.879277] x23: 000000002020003e x22: 0000000000000000 x21:
0000000000000040
[ 2867.886504] x20: ffffff804a479080 x19: ffffff8040796480 x18:
00000000000982f8
[ 2867.893731] x17: ffffff80482d6500 x16: ffffffed1d87b6b0 x15:
ffffff8041a43c00
[ 2867.900957] x14: 0000000000000016 x13: 0000073d6a5d38dc x12:
00000000001d4ebe
[ 2867.908184] x11: 00000000000000c0 x10: 0000000000001ae0 x9 :
ffffffecc9c959e8
[ 2867.915410] x8 : ffffff804f1e5a40 x7 : 0000000000000002 x6 :
ffffffffffffffff
[ 2867.922636] x5 : ffffffed1e59d000 x4 : 0000000000000002 x3 :
0000000000000000
[ 2867.929863] x2 : 0000000000000040 x1 : ffffff804a479080 x0 :
0000000000000000
[ 2867.937090] Call trace:
[ 2867.939558] oa_tc6_update_rx_skb+0x2c/0xa8 [lan865x_t1s] (P)
[ 2867.945375] oa_tc6_macphy_threaded_irq+0x430/0x870 [lan865x_t1s]
[ 2867.951543] irq_thread_fn+0x34/0xc0
[ 2867.955156] irq_thread+0x1a8/0x308
[ 2867.958680] kthread+0x138/0x150
[ 2867.961942] ret_from_fork+0x10/0x20
[ 2867.965558] Code: aa0103f4 f90013f5 12001c55 f9403800 (29570403)
[ 2867.971727] ---[ end trace 0000000000000000 ]---
[ 2867.976443] genirq: exiting task "irq/59-spi0.0" (2808) is an active
IRQ thread (irq 59)
[ 2868.094789] irq 59: nobody cared (try booting with the "irqpoll" option)
[ 2868.101000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Tainted: G D C
O 7.1.0-rc7-v8+ #2 PREEMPT
[ 2868.101007] Tainted: [D]=DIE, [C]=CRAP, [O]=OOT_MODULE
[ 2868.101009] Hardware name: Raspberry Pi 4 Model B Rev 1.4 (DT)
[ 2868.101011] Call trace:
[ 2868.101013] show_stack+0x20/0x38 (C)
[ 2868.101027] dump_stack_lvl+0x60/0x80
[ 2868.101033] dump_stack+0x18/0x24
[ 2868.101038] __report_bad_irq+0x54/0xf0
[ 2868.101043] note_interrupt+0x344/0x398
[ 2868.101048] handle_irq_event+0xa4/0x110
[ 2868.101051] handle_level_irq+0xe0/0x178
[ 2868.101056] handle_irq_desc+0x3c/0x68
[ 2868.101061] generic_handle_domain_irq+0x20/0x40
[ 2868.101067] bcm2835_gpio_irq_handle_bank+0x180/0x1c8
[ 2868.101074] bcm2835_gpio_irq_handler+0x88/0x188
[ 2868.101080] handle_irq_desc+0x3c/0x68
[ 2868.101085] generic_handle_domain_irq+0x20/0x40
[ 2868.101091] gic_handle_irq+0x4c/0xe0
[ 2868.101094] call_on_irq_stack+0x30/0x88
[ 2868.101099] do_interrupt_handler+0x88/0x98
[ 2868.101102] el1_interrupt+0x3c/0x60
[ 2868.101108] el1h_64_irq_handler+0x18/0x30
[ 2868.101113] el1h_64_irq+0x6c/0x70
[ 2868.101116] default_idle_call+0x34/0x1a0 (P)
[ 2868.101123] do_idle+0x260/0x2a0
[ 2868.101128] cpu_startup_entry+0x3c/0x50
[ 2868.101132] rest_init+0xe8/0xf0
[ 2868.101137] start_kernel+0x7f4/0x800
[ 2868.101143] __primary_switched+0x88/0x98
[ 2868.101149] handlers:
[ 2868.207750] lan8650 spi0.1: SPI transfer timed out
[ 2868.208070] [<0000000019361c17>] oa_tc6_macphy_isr [lan865x_t1s]
[ 2868.212048] spi_master spi0: failed to transfer one message from queue
[ 2868.215296] threaded [<00000000a4e6f0fa>] oa_tc6_macphy_threaded_irq
[lan865x_t1s]
[ 2868.219005] spi_master spi0: noqueue transfer failed
[ 2868.223053] Disabling IRQ #59
[ 2868.260162] lan8650 spi0.1 eth2: SPI data transfer failed: -110
[ 2868.266211] lan8650 spi0.1: Device interrupt disabled to avoid
interrupt storm
Best regards,
Parthiban V
>
> But I could see assert in skb_put immediately quickly.
>
>>
>> Best regards,
>> Parthiban V
>>>
>>>>
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
From: Konrad Dybcio @ 2026-06-25 12:23 UTC (permalink / raw)
To: Aaron Kling
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <CALHNRZ-J6DH1ebhUcRqbVRmStO_MGBJr63TEQg5vxNO_UpF-vQ@mail.gmail.com>
On 18-Jun-26 06:37, Aaron Kling wrote:
> On Wed, Jun 17, 2026 at 5:41 AM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 6/6/26 12:36 AM, Aaron Kling via B4 Relay wrote:
>>> From: Aaron Kling <webgeek1234@gmail.com>
>>>
>>> Add the OPP tables for each CPU cluster (cpu0-1-2-3-4-5 & cpu6-7) to
>>> permit scaling the Last Level Cache Controller (LLCC) and DDR frequency
>>> by aggregating bandwidth requests of all CPU core with reference to the
>>> current OPP they are configured in by the hardware.
>>>
>>> The effect is proper caches & DDR frequency scaling when CPU cores
>>> change frequency.
>>>
>>> The OPP tables were built using the downstream memlat ddr & llcc tables
>>> for each cluster types with the actual cpufreq LUT tables from running a
>>> CQ8725S device.
>>>
>>> Also add the interconnect entry for each cpu, with 2 different paths:
>>> - CPU to Last Level Cache Controller (LLCC)
>>> - Last Level Cache Controller (LLCC) to DDR
>>>
>>> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
>>> ---
>>> arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
>>> ---
>>
>> [...]
>>
>>> + cpu6_opp_table: opp-table-cpu6 {
>>> + compatible = "operating-points-v2";
>>> + opp-shared;
>>> +
>>> + opp-1017600000 {
>>> + opp-hz = /bits/ 64 <1017600000>;
>>> + opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
>>
>> I think this should be * 4 in both cases since the interconnect driver
>> ignores the channel count for a node in peak voting. We may have a bug
>> in all other DTs here.
>
> If this is confirmed, I can update this patch. I based the
> calculations on my sm8550 copy of this change, which in turn was based
> on the sm8650 change. If this is wrong, that means one piece is
> scaling 4x too quickly? Making it a power consumption issue, not a
> performance issue.
>
>> BTW, are there no lower OPPs for the fast cores?
>
> Not on cq8725s at least. These lists came from an AYN Odin 3 with that
> soc. I don't have any sm8750 proper devices to see if that's any
> different.
Mobile SM8750:
root@qcom-armv8a:~# cat /sys/bus/cpu/devices/cpu6/cpufreq/scaling_available_frequencies
1017600 1209600 1401600 1689600 1958400 2246400 2438400 2649600 2841600 3072000 3283200 3513600 3840000 4089600
root@qcom-armv8a:~# cat /sys/bus/cpu/devices/cpu0/cpufreq/scaling_available_frequencies
384000 556800 748800 960000 1152000 1363200 1555200 1785600 1996800 2227200 2400000 2745600 2918400 3072000 3321600 3532800
root@qcom-armv8a:~# grep ^ /sys/bus/soc/devices/soc0/*
/sys/bus/soc/devices/soc0/family:Snapdragon
/sys/bus/soc/devices/soc0/machine:SM8750
/sys/bus/soc/devices/soc0/revision:2.0
/sys/bus/soc/devices/soc0/serial_number:<snip>
/sys/bus/soc/devices/soc0/soc_id:618
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: supply: Add TI BQ25630 charger
From: Waqar Hameed @ 2026-06-25 12:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
kernel, linux-pm, devicetree, linux-kernel
In-Reply-To: <18ae59ae-024f-4dfb-ad66-2db90e6f7ed4@kernel.org>
On Thu, Jun 25, 2026 at 14:10 +0200 Krzysztof Kozlowski <krzk@kernel.org> wrote:
> On 25/06/2026 13:27, Waqar Hameed wrote:
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - reg
>>>> + - interrupts
>>>> + - monitored-battery
>>>> +
>>>> +additionalProperties: false
>>>
>>> And here use 'unevaluatedProperties: false' instead.
>>
>> Hm, reading the documentation [1], `unevaluatedProperties` should be
>> used, because of the "include" of `power-supply.yaml`. I'll change to
>> that.
>>
>> However, there are tons of other places where `additionalProperties` is
>> used instead _with_ a reference to `power-supply.yaml` (which is what I
>> followed). Are all of them actually "wrong" then?
>
> No, they are not wrong, but usually preferred is to allow all properties
> from referenced power-supply schema.
Ah ok, I can see why it's more preferable to be more "permissive" with
`unevaluatedProperties`. Thanks!
^ permalink raw reply
* Re: [PATCH 1/3] arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
From: sashiko-bot @ 2026-06-25 12:20 UTC (permalink / raw)
To: Gokul Praveen; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260625120805.28948-2-g-praveen@ti.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Adding a third clock to the serdes2 node violates the Cadence Torrent PHY DT binding schema, which will cause `dtbs_check` validation to fail.
--
commit c7948a2c66b640fab1ce0e80a89c69a933059939
Author: Gokul Praveen <g-praveen@ti.com>
arm64: dts: ti: Add PLL1 refclk to J784S4 SoC SERDES node
This commit adds the PLL1 reference clock to the clocks and clock-names
properties of the SERDES2 node. This is done to satisfy the assigned-clocks
parameter and prevent multilink configuration failures.
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> index 78fcd0c40abcf..da8d582574d03 100644
> --- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
> @@ -122,8 +122,9 @@ serdes2: serdes@5020000 {
> resets = <&serdes_wiz2 0>;
> reset-names = "torrent_reset";
> clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
> + <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
> <&serdes_wiz2 TI_WIZ_PHY_EN_REFCLK>;
> - clock-names = "refclk", "phy_en_refclk";
> + clock-names = "refclk","pll1_refclk", "phy_en_refclk";
[Severity: Low]
Will adding a third clock to the serdes2 node cause dtbs_check validation
to fail?
The Cadence Torrent PHY device tree binding schema in
Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml restricts
the clocks and clock-names properties to a maximum of 2 items. By adding
pll1_refclk alongside refclk and phy_en_refclk, the array now contains 3
items, which violates the existing schema constraints.
Does the device tree binding schema need to be updated first to support
this third clock?
> assigned-clocks = <&serdes_wiz2 TI_WIZ_PLL0_REFCLK>,
> <&serdes_wiz2 TI_WIZ_PLL1_REFCLK>,
> <&serdes_wiz2 TI_WIZ_REFCLK_DIG>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625120805.28948-1-g-praveen@ti.com?part=1
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode
From: sashiko-bot @ 2026-06-25 12:20 UTC (permalink / raw)
To: Gokul Praveen; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260625120805.28948-4-g-praveen@ti.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Incomplete clock configuration in `&serdes_wiz2` leaves a dangling `assigned-clocks` element as dead code.
- [Low] The unit addresses in the PHY node names do not match their `reg` property values.
--
commit ec16658036ad6f4bdcb6018a15184b9bd2b3c4aa
Author: Gokul Praveen <g-praveen@ti.com>
arm64: dts: ti: k3-j784s4: Add overlay for dual port USXGMII+SGMII mode
The CPSW9G instance of the CPSW Ethernet Switch supports SGMII and
USXGMII mode with MAC Ports 1 and 2 of the instance, which are
connected to ENET Expansion 1 and ENET Expansion 2 slots on
the EVM respectively, through the Serdes2 instance of the SERDES.
Enable CPSW9G MAC Ports 1 and 2 in fixed-link configuration
SGMII and USXGMII mode at 1Gbps and 5 Gbps each.
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
> new file mode 100644
> index 0000000000000..553546b281a9e
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-sgmii-usxgmii-exp1-exp2_board1.dtso
[ ... ]
> +&serdes_wiz2 {
> + assigned-clocks = <&k3_clks 406 6>, <&k3_clks 406 5>;
> + //assigned-clock-parents = <&k3_clks 406 9>; /* Use 100 MHz clock for SGMII */
> + status = "okay";
> +};
[Severity: Medium]
The assigned-clock-parents override is commented out here, but the
assigned-clocks array was expanded to two elements.
Because the base device tree only defines a single parent, the clock framework
will only process the first clock and silently ignore the second element.
Does this leave the second clock unconfigured, and should
assigned-clock-parents be uncommented to resolve this?
> +
> +&serdes2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + assigned-clock-parents = <&k3_clks 406 5>,
> + <&k3_clks 406 6>,
> + <&k3_clks 406 5>;
> +
> + serdes2_sgmii2_link: phy@1 {
> + reg = <2>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = <PHY_TYPE_SGMII>;
> + resets = <&serdes_wiz2 3>;
> + };
> + serdes2_usxgmii_link: phy@0 {
> + reg = <3>;
[Severity: Low]
Do the unit addresses phy@1 and phy@0 need to match their reg property
values <2> and <3>?
The dtc compiler will generate unit_address_vs_reg warnings when the unit
address and reg property do not match.
[ ... ]
> diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
> new file mode 100644
> index 0000000000000..c98be3bbf2c8b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm-usxgmii-sgmii-exp1-exp2_board2.dtso
[ ... ]
> +&serdes_wiz2 {
> + assigned-clocks = <&k3_clks 406 6>, <&k3_clks 406 5>;
> + //assigned-clock-parents = <&k3_clks 406 9>; /* Use 156.25 MHz clock for USXGMII */
> + status = "okay";
> +};
[Severity: Medium]
Similar to the first overlay, the assigned-clock-parents override is commented
out while assigned-clocks contains two elements.
Is the second clock intended to be left unconfigured here?
> +
> +&serdes2 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + status = "okay";
> +
> + assigned-clock-parents = <&k3_clks 406 5>,
> + <&k3_clks 406 6>,
> + <&k3_clks 406 5>;
> +
> +
> +
> + serdes2_sgmii2_link: phy@1 {
> + reg = <3>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = <PHY_TYPE_SGMII>;
> + resets = <&serdes_wiz2 4>;
> + };
> + serdes2_usxgmii_link: phy@0 {
> + reg = <2>;
[Severity: Low]
Are the unit addresses for these nodes correct?
They are named phy@1 and phy@0, but their reg properties are set to <3>
and <2>. Should they be updated to match the reg properties to prevent dtc
warnings?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625120805.28948-1-g-praveen@ti.com?part=3
^ permalink raw reply
* Re: [PATCH 2/3] net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode
From: sashiko-bot @ 2026-06-25 12:18 UTC (permalink / raw)
To: Gokul Praveen; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260625120805.28948-3-g-praveen@ti.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Missing AM65_CPSW_SGMII_CONTROL_MASTER bit in SGMII control register write
- [Medium] Hardcoded SGMII link advertisement to 1000 Mbps Full Duplex
--
commit 2e14387f10f244dbb25f009bd28dfe67470e6821
Author: Gokul Praveen <g-praveen@ti.com>
net: ethernet: ti: am65-cpsw: Fix MAC configuration for SGMII mode
Fix MAC configuration of CPSW Ethernet Switch in SGMII mode by
modifying the CPSW_SGMII_MR_ADV_ABILITY_REG and configuring MAC
in master mode as per CPSGMII Module specification.
> diff --git a/drivers/net/ethernet/ti/am65-cpsw-nuss.c b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> index 7ac75fc8cdcf4..4740b35052464 100644
> --- a/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> +++ b/drivers/net/ethernet/ti/am65-cpsw-nuss.c
> @@ -84,6 +84,7 @@
> #define AM65_CPSW_SGMII_CONTROL_REG 0x010
> #define AM65_CPSW_SGMII_MR_ADV_ABILITY_REG 0x018
> #define AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE BIT(0)
> +#define AM65_CPSW_SGMII_CONTROL_MASTER BIT(5)
>
> #define AM65_CPSW_CTL_VLAN_AWARE BIT(1)
[ ... ]
> @@ -2063,8 +2064,10 @@ static void am65_cpsw_nuss_mac_config(struct phylink_config *config, unsigned in
>
> if (common->pdata.extra_modes & BIT(state->interface)) {
> if (state->interface == PHY_INTERFACE_MODE_SGMII) {
> - writel(ADVERTISE_SGMII,
> - port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
> + writel(ADVERTISE_SGMII | LPA_SGMII_1000FULL | LPA_SGMII_LINK,
> + port->sgmii_base + AM65_CPSW_SGMII_MR_ADV_ABILITY_REG);
[Severity: Medium]
Will this hardcoded advertisement break SGMII operation at 10 Mbps or 100
Mbps?
By unconditionally applying LPA_SGMII_1000FULL and LPA_SGMII_LINK, the MAC
seems to always claim 1000 Mbps capabilities regardless of the actual
requested or negotiated speed, which could restrict generic SGMII
functionality to gigabit-only.
> + writel(AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE,
> + port->sgmii_base + AM65_CPSW_SGMII_CONTROL_REG);
[Severity: High]
Does this write miss the AM65_CPSW_SGMII_CONTROL_MASTER bit introduced earlier
in the patch?
The commit message states the intent is to configure the MAC in master mode,
but only AM65_CPSW_SGMII_CONTROL_MR_AN_ENABLE is being set in
am65_cpsw_nuss_mac_config().
Could this cause the MAC to remain in slave mode, potentially preventing the
SGMII link from coming up on MAC-to-MAC connections that require the MAC to
act as the master?
> cpsw_sl_ctl_set(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
> } else {
> cpsw_sl_ctl_clr(port->slave.mac_sl, CPSW_SL_CTL_EXT_EN);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625120805.28948-1-g-praveen@ti.com?part=2
^ permalink raw reply
* Re: [PATCH v3 2/3] arm64: dts: qcom: sm8250: Add cam_mclk3_default pinctrl
From: Konrad Dybcio @ 2026-06-25 12:15 UTC (permalink / raw)
To: Xin Xu, andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <tencent_47473BB31C9142449F8C7C1BE69D9071510A@qq.com>
On 6/25/26 2:05 PM, Xin Xu wrote:
> Add a default pin configuration for CAM_MCLK3 (GPIO97), which is used
> as a master clock for camera sensors on SM8250 boards.
>
> Signed-off-by: Xin Xu <xxsemail@qq.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/13] dt-bindings: sound: Add Qualcomm QAIF binding
From: Konrad Dybcio @ 2026-06-25 12:11 UTC (permalink / raw)
To: Harendra Gautam
Cc: Srinivas Kandagatla, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-sound, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <CAC-tS8Af8GNQ1rq2PN6Yr-wG8_D55ddU9t77H4CUEvWfaP=Gkw@mail.gmail.com>
On 6/24/26 8:59 AM, Harendra Gautam wrote:
> On Tue, Jun 23, 2026 at 9:18 PM Konrad Dybcio
> <konrad.dybcio@oss.qualcomm.com> wrote:
>>
>> On 6/23/26 2:26 PM, Harendra Gautam wrote:
>>> On Tue, Jun 9, 2026 at 3:27 PM Konrad Dybcio
>>> <konrad.dybcio@oss.qualcomm.com> wrote:
[...]
>>>>> + qcom,qaif-aif-sync-mode:
>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>> + description:
>>>>> + Sync mode. Use QAIF_AIF_SYNC_MODE_SHORT (0) for short (pulse)
>>>>> + sync or QAIF_AIF_SYNC_MODE_LONG (1) for long (level) sync.
>>>>> + qcom,qaif-aif-sync-src:
>>>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>>>> + description:
>>>>> + Sync source. Use QAIF_AIF_SYNC_SRC_SLAVE (0) for slave mode
>>>>> + or QAIF_AIF_SYNC_SRC_MASTER (1) for master mode.
>>>>
>>>> Should these be boolean flags then?
>>> It should not be, the intention is to define explicitly, for better
>>> readability I can rename these flags as EXTERNAL/INTERNAL, Please
>>> suggest.
>>
>> Are all 4 combinations of them being present/absent valid on shikra?
>>
>> Konrad
> Sorry if I did not put details properly, I will be correcting in the
> next patch. sync-src can be external clock or internal clock, where 0
> means external and 1 means internal.
What I meant to ask is whether all combinations of qcom,qaif-aif-sync-mode
and qcom,qaif-aif-sync-src being present/absent (set to 0/1) are actually
valid and should be supported
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: supply: Add TI BQ25630 charger
From: Krzysztof Kozlowski @ 2026-06-25 12:10 UTC (permalink / raw)
To: Waqar Hameed
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
kernel, linux-pm, devicetree, linux-kernel
In-Reply-To: <pndwlvm6ese.a.out@axis.com>
On 25/06/2026 13:27, Waqar Hameed wrote:
>>> +
>>> +required:
>>> + - compatible
>>> + - reg
>>> + - interrupts
>>> + - monitored-battery
>>> +
>>> +additionalProperties: false
>>
>> And here use 'unevaluatedProperties: false' instead.
>
> Hm, reading the documentation [1], `unevaluatedProperties` should be
> used, because of the "include" of `power-supply.yaml`. I'll change to
> that.
>
> However, there are tons of other places where `additionalProperties` is
> used instead _with_ a reference to `power-supply.yaml` (which is what I
> followed). Are all of them actually "wrong" then?
No, they are not wrong, but usually preferred is to allow all properties
from referenced power-supply schema.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/6] clk: qcom: gpucc: Add Nord graphics clock controller support
From: Konrad Dybcio @ 2026-06-25 12:09 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Shawn Guo, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Konrad Dybcio
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-6-860c84539804@oss.qualcomm.com>
On 6/23/26 12:54 PM, Taniya Das wrote:
> Add support for the GPU clock controllers (GPUCC) on the Qualcomm
> Nord platform.
>
> The platform includes two GPU clock controller instances,GPUCC
> and GPU2CC. Register support for both controllers, which provide
> clocks required for the graphics subsystem.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 11 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/gpu2cc-nord.c | 546 +++++++++++++++++++++++++++++++++++++
> drivers/clk/qcom/gpucc-nord.c | 593 +++++++++++++++++++++++++++++++++++++++++
GPU_2_CC and GPU_CC seem to have a different set of clocks and
resets. If that's not physically the case, please align the
lists. Otherwise, please use a separate bindings header for each
one
Konrad
^ permalink raw reply
* [PATCH v3 3/3] arm64: dts: qcom: sm8250-xiaomi-elish: Add ov8856 front camera
From: Xin Xu @ 2026-06-25 12:08 UTC (permalink / raw)
To: konrad.dybcio, andersson, konradybcio
Cc: linux-arm-msm, devicetree, linux-kernel, Xin Xu
In-Reply-To: <tencent_47473BB31C9142449F8C7C1BE69D9071510A@qq.com>
Add the ov8856 front camera, connected on CCI1 to CSIPHY4 and
powered by pm8008 LDOs and other supplies.
Signed-off-by: Xin Xu <xxsemail@qq.com>
---
Changes in v3:
- Reorder pinctrl properties in camera_front_active.
- Use the new cam_mclk3_default from sm8250.dtsi and remove board-local
mclk3 node.
Changes in v2:
- Fix coding style (property order)
.../dts/qcom/sm8250-xiaomi-elish-common.dtsi | 63 +++++++++++++++++++
1 file changed, 63 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
index 05c366eaeff1..19aff83ecf7b 100644
--- a/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-common.dtsi
@@ -4,6 +4,7 @@
*/
#include <dt-bindings/arm/qcom,ids.h>
+#include <dt-bindings/media/video-interfaces.h>
#include <dt-bindings/phy/phy.h>
#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
#include <dt-bindings/usb/pd.h>
@@ -531,6 +532,61 @@ vreg_l7f_1p8: ldo7 {
};
};
+&camss {
+ status = "okay";
+
+ vdda-phy-supply = <&vreg_l5a_0p88>;
+ vdda-pll-supply = <&vreg_l9a_1p2>;
+
+ ports {
+ port@4 {
+ csiphy4_ep: endpoint {
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ bus-type = <MEDIA_BUS_TYPE_CSI2_DPHY>;
+ remote-endpoint = <&ov8856_front_ep>;
+ };
+ };
+ };
+};
+
+&cci1 {
+ status = "okay";
+};
+
+&cci1_i2c1 {
+ camera_front: camera@10 {
+ compatible = "ovti,ov8856";
+ reg = <0x10>;
+
+ avdd-supply = <&vreg_l5p>;
+ dovdd-supply = <&vreg_l1c_1p8>;
+ dvdd-supply = <&vreg_l1p>;
+
+ clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ clock-names = "xvclk";
+ assigned-clocks = <&camcc CAM_CC_MCLK3_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ reset-gpios = <&tlmm 109 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&cam_mclk3_default &camera_front_active>;
+ pinctrl-names = "default";
+
+ orientation = <0>; /* Front facing */
+ rotation = <270>;
+
+ port {
+ ov8856_front_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64
+ <720000000 360000000>;
+ remote-endpoint = <&csiphy4_ep>;
+ };
+ };
+ };
+};
+
&cdsp {
firmware-name = "qcom/sm8250/xiaomi/elish/cdsp.mbn";
status = "okay";
@@ -891,6 +947,13 @@ pm8008_reset_default: pm8008-reset-default-state {
bias-pull-up;
};
+ camera_front_active: camera-front-active-state {
+ pins = "gpio109";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
wlan_en_state: wlan-default-state {
pins = "gpio20";
function = "gpio";
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox