* Re: [PATCH v5 5/9] block: implement NVMEM provider
From: Bartosz Golaszewski @ 2026-06-15 13:06 UTC (permalink / raw)
To: Loic Poulain
Cc: Bartosz Golaszewski, linux-mmc, devicetree, linux-kernel,
linux-arm-msm, linux-block, linux-wireless, ath10k,
linux-bluetooth, netdev, daniel, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Jens Axboe, Johannes Berg, Jeff Johnson, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Srinivas Kandagatla, Andrew Lunn, Heiner Kallweit,
Russell King, Saravana Kannan
In-Reply-To: <CAFEp6-0oxBEdfH-fqhdM18pt4JewLwrMOON9qpQgLFh8KS0hDg@mail.gmail.com>
On Mon, 15 Jun 2026 11:33:22 +0200, Loic Poulain
<loic.poulain@oss.qualcomm.com> said:
> On Mon, Jun 15, 2026 at 11:28 AM Loic Poulain
> <loic.poulain@oss.qualcomm.com> wrote:
>>
>
> Also we cannot safely return -EPROBE_DEFER from add_disk_final()
> either. The NVMEM registration point is late in the sequence, too much
> has already happened to easily unwind. The easiest is that the NVMEM
> simply won't be available if registration fails, which looks
> acceptable?
>
I'd argue that it's a problem with subsystem code then as unwinding should
work fine no matter the point in the sequence when it's initiated but I guess
this isn't really an issue in your patches.
I suppose we shouldn't typically run into probe deferral here so I'm fine just
ignoring the return value.
Bart
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro @ 2026-06-15 13:06 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <7xfxlxfqjcqdzl6gckaoyy2ioefglc7bgi66yv5khrbl6fi2zc@ivtiukdaj4jv>
On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
> On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
>> On some SoCs the SMMU registers require an active interconnect
>> bandwidth vote to be accessible. While other clients typically
>> satisfy this requirement implicitly, certain corner cases (e.g.
>> during sleep/wakeup transitions) can leave the SMMU without a
>> vote, causing intermittent register access failures.
>>
>> Add support for an optional interconnect path to the arm-smmu
>> driver and vote for bandwidth while the SMMU is active. The path
>> is acquired from DT if present and ignored otherwise.
>>
>> The bandwidth vote is enabled before accessing SMMU registers
>> during probe and runtime resume, and released during runtime
>> suspend and on error paths.
>>
>> Generally, from an architectural perspective, GEM_NOC and DDR are
>> expected to have an active vote whenever the adreno_smmu block is
>> powered on. In most common use cases, this requirement is implicitly
>> satisfied because other GPU-related clients (for example, the GMU
>> device) already hold a GEM_NOC vote when adreno_smmu is enabled.
>>
>> However, there are certain corner cases, such as during sleep/wakeup
>> transitions, where the GEM_NOC vote can be removed before adreno_smmu
>> is powered down. If adreno_smmu is then accessed while the interconnect
>> vote is missing, it can lead to the observed failures. Because of the
>> precise ordering involved, this scenario is difficult to reproduce
>> consistently.
>> (also GDSC is involved in adreno usecases can have an independent vote)
>>
>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>> ---
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> @@ -53,6 +53,11 @@
>> #define MSI_IOVA_BASE 0x8000000
>> #define MSI_IOVA_LENGTH 0x100000
>>
>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>> +#define ARM_SMMU_ICC_AVG_BW 0
>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>
> totally random numbers, which might be different for non-Qualcomm platform.
>
Ideally, any non-zero value would be enough to keep the path active.
Here 1 Would be enough to keep the path active, but might be too small
to reliably keep the bus active.
Other is UINT_MAX, which will reliably keep the bus active but might
cause a power penalty.
#define ARM_SMMU_ICC_PEAK_BW_HIGH UINT_MAX
seems to be suitable here to reliably keep the bus active by BCM
for both Qualcomm and non-Qualcomm platforms (with some power penalty).
LMK, if you feel otherwise.
>> +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
>> +
>> static int force_stage;
>> module_param(force_stage, int, S_IRUGO);
>> MODULE_PARM_DESC(force_stage,
>> @@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
>> }
>> }
>>
>> +static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
>> +{
>> + smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
>
> Is there always only one bus / path in question?
>
>> + if (IS_ERR(smmu->icc_path)) {
>
> if (!IS_ERR(smmu->icc_path))
> return 0;
>
> int err = PTR_ERR();
> if (err == -ENODEV) {
> icc_path = NULL;
> return 0;
> }
>
> return dev_err_probe();
>
>
>> + int err = PTR_ERR(smmu->icc_path);
>> +
>> + if (err == -ENODEV) {
>> + smmu->icc_path = NULL;
>> + return 0;
>> + }
>> + return dev_err_probe(smmu->dev, err,
>> + "failed to get interconnect path\n");
>> + }
>> + return 0;
>> +}
>> +
>> +static void arm_smmu_icc_enable(struct arm_smmu_device *smmu)
>> +{
>> + if (smmu->icc_path)
>
> Drop the if.
>
Ack, will address it in next revision
>> + WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
>> + ARM_SMMU_ICC_PEAK_BW_HIGH));
>
> WARN_ON_ONCE()?
>
> Pass the error to the caller.
>
>
Ack, would be better to pass. Thanks for pointing this.
>> +}
>> +
>> +static void arm_smmu_icc_disable(struct arm_smmu_device *smmu)
>> +{
>> + if (smmu->icc_path)
>
> Drop the if.
>
Ack.
>> + WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
>> + ARM_SMMU_ICC_PEAK_BW_LOW));
>
> Pass the error to the caller.
>
Ack.
>> +}
>> +
>> static void arm_smmu_rpm_use_autosuspend(struct arm_smmu_device *smmu)
>> {
>> /*
>> @@ -2189,6 +2224,17 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>> if (err)
>> return err;
>>
>> + /*
>> + * Acquire and vote the interconnect path before accessing any SMMU
>> + * registers (including ARM_SMMU_GR0_ID0 in arm_smmu_device_cfg_probe).
>> + */
>> + err = arm_smmu_icc_get(smmu);
>> + if (err) {
>> + clk_bulk_disable_unprepare(smmu->num_clks, smmu->clks);
>> + return err;
>> + }
>> + arm_smmu_icc_enable(smmu);
>
> Handle the error.
>
Ack, will address this in next revision. to disable the clocks here as well.
+ err = arm_smmu_icc_enable(smmu);
+ if (err) {
+ clk_bulk_disable_unprepare(smmu->num_clks, smmu->clks);
+ return err;
+ }
>> +
>> err = arm_smmu_device_cfg_probe(smmu);
>> if (err)
>> return err;
>> @@ -2273,8 +2319,10 @@ static void arm_smmu_device_shutdown(struct platform_device *pdev)
>>
>> if (pm_runtime_enabled(smmu->dev))
>> pm_runtime_force_suspend(smmu->dev);
>> - else
>> + else {
>> clk_bulk_disable(smmu->num_clks, smmu->clks);
>> + arm_smmu_icc_disable(smmu);
>
> Handle the error.
>
> etc.
>
Ack, will address the if(), and error handling suggestion in next iteration.
Thanks & regards,
Bibek
>> + }
>>
>> clk_bulk_unprepare(smmu->num_clks, smmu->clks);
>> }
>
^ permalink raw reply
* Re: [PATCH v2 0/2] Add psci_sys_reset2 reboot modes for Qualcomm boards
From: Shivendra Pratap @ 2026-06-15 13:08 UTC (permalink / raw)
To: Lorenzo Pieralisi, Loic Poulain
Cc: Anurag Pateriya, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel, Xin Liu
In-Reply-To: <aivBcGQgeKGW45Is@lpieralisi>
On 12-06-2026 13:51, Lorenzo Pieralisi wrote:
> On Wed, Jun 10, 2026 at 02:57:19PM +0200, Loic Poulain wrote:
>> Hi Anurag,
>>
>> On Fri, May 29, 2026 at 4:29 PM Anurag Pateriya
>> <anurag.pateriya@oss.qualcomm.com> wrote:
>>>
>>> Adding PSCI SYSTEM_RESET2 reboot-modes for sm8750 and
>>> kaanapali based boards.
>>
>> I would like to highlight that when Linux/EFI is enabled, which is a
>> common config, efi_reboot is used as the primary reboot path (see
>> machine_restart).
Yes but, only if EFI RESET RUNTIME service is enabled by UEFI.
efi_reboot(...) {
..
if (!efi_rt_services_supported(EFI_RT_SUPPORTED_RESET_SYSTEM))
return;
..
>> As a result, the PSCI reboot hook is not invoked in
>> this scenario, assuming Qualcomm firmware provides EFI runtime
>> services.
Currently EFI RUNTIME RESET service is not enabled on these firmware.
>> As a follow-up, it would therefore be beneficial to also
>> improve the EFI path to support such custom mode(s)...
Yes, and potentially linux should also have some control, if it wants to
go via efi reset path or the PSCI reset path.
thanks,
Shivendra
>
> I have not checked but we should probably put in a place a way for user
> space to check that PSCI is _not_ the reboot method that will be
> used, lest it would be allowed to send commands to the kernel that
> would be duly ignored.
>
> Need to go through the whole thing again before commenting any further.
>
> Thanks,
> Lorenzo
>
>> Regards,
>> Loic
>>
>>
>>
>>>
>>> These DT patches depend on PSCI SYSTEM_RESET2 support introduced in:
>>> https://lore.kernel.org/all/20260514-arm-psci-system_reset2-vendor-reboots-v22-0-28a5bde07483@oss.qualcomm.com/
>>>
>>> To: Bjorn Andersson <andersson@kernel.org>
>>> To: Konrad Dybcio <konradybcio@kernel.org>
>>> To: Rob Herring <robh@kernel.org>
>>> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
>>> To: Conor Dooley <conor+dt@kernel.org>
>>> Cc: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
>>> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
>>> Cc: linux-arm-msm@vger.kernel.org
>>> Cc: devicetree@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>>
>>> Signed-off-by: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>
>>> ---
>>> Changes in v2:
>>> - Fixed subject lines.
>>> - Link to v1: https://lore.kernel.org/r/20260529-psci_sys_reset-dt-changes-for-pakala-v1-0-7c32161cf50b@oss.qualcomm.com
>>>
>>> ---
>>> Anurag Pateriya (1):
>>> arm64: dts: qcom: sm8750: add reboot-mode support
>>>
>>> Xin Liu (1):
>>> arm64: dts: qcom: kaanapali: add reboot-mode support
>>>
>>> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 +++++++
>>> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 7 +++++++
>>> arch/arm64/boot/dts/qcom/kaanapali.dtsi | 2 +-
>>> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 7 +++++++
>>> arch/arm64/boot/dts/qcom/sm8750-qrd.dts | 7 +++++++
>>> arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 +-
>>> 6 files changed, 30 insertions(+), 2 deletions(-)
>>> ---
>>> base-commit: 6ee02bbf328be8a8586487e3af73b65a906cce58
>>> change-id: 20260529-psci_sys_reset-dt-changes-for-pakala-a09fc0e2a8a8
>>>
>>> Best regards,
>>> --
>>> Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>
>>>
>>>
^ permalink raw reply
* Re: [PATCH] dt-bindings: vendor-prefixes: add Gira
From: Conor Dooley @ 2026-06-15 13:09 UTC (permalink / raw)
To: Lucas Stach
Cc: Conor Dooley, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
devicetree, kernel
In-Reply-To: <624ac28d675035f26f3ea2dd8afb288d59af34f9.camel@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1076 bytes --]
On Mon, Jun 15, 2026 at 02:53:11PM +0200, Lucas Stach wrote:
> Hi Conor,
>
> Am Donnerstag, dem 11.06.2026 um 18:40 +0100 schrieb Conor Dooley:
> > On Wed, Jun 10, 2026 at 11:30:47PM +0200, Lucas Stach wrote:
> > > Add vendor prefix for Gira Giersiepen GmbH & Co. KG
> > > Link: https://www.gira.de/
> > >
> > > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> >
> > Where is the user?
> >
> The user is a currently under development board support for the Barebox
> bootloader. It is expected that the DT for this board will also land in
> Linux at a later time.
>
> Since the kernel source is basically the registry for vendor prefixes,
> I didn't expect that a in-tree user would be required for this
> submission.
Not an in-tree user, but a user at all. It was not obvious that there
actually was one here. If there's other instances of this in the future,
please put some info about the device under the --- line, so that we
know there's a barebox user for it.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v2] dt-bindings: arm: xen: Convert to DT schema
From: Tejas @ 2026-06-15 13:09 UTC (permalink / raw)
To: devicetree; +Cc: robh, krzk+dt, conor+dt, sstabellini, Tejas
In-Reply-To: <20260615112625.7892-1-tejasmutalikdesai@gmail.com>
Convert the Xen ARM device tree binding documentation from the legacy
plain-text format (Documentation/devicetree/bindings/arm/xen.txt) to
the YAML schema format, as required by the modern DT binding process.
The old xen.txt is removed as the YAML schema is now the authoritative
source.
The YAML schema:
- Uses the preferred dual license (GPL-2.0-only OR BSD-2-Clause)
- Validates compatible string format as "xen,xen-<major>.<minor>"
followed by the generic "xen,xen" string
- Documents reg as accepting 1..N regions (region 0 mandatory for
grant table mapping; regions 1..N optional extended regions)
- Documents the uefi subnode with correct types:
* xen,uefi-system-table: uint64 (guest PA of UEFI System Table)
* xen,uefi-mmap-start: uint64 (guest PA of UEFI memory map)
* xen,uefi-mmap-size: uint32 (size of UEFI memory map)
* xen,uefi-mmap-desc-size: uint32 (size of each mmap entry)
* xen,uefi-mmap-desc-ver: uint32 (mmap descriptor format version)
- Marks all five xen,uefi-* properties as required within the uefi
subnode; the source table lists all of them as unconditionally
populated by Xen when UEFI is supported
- 64-bit properties use /bits/ 64 <value> in the example, consistent
with other bindings carrying uint64 properties (e.g. opp-v2.yaml,
arm/mali-bifrost.yaml)
The uefi subnode was originally introduced through a multi-version review
series (v2..v7); the mistakes caught during those reviews (typos,
duplicated UEFI spec content, insufficient description of Xen-specific
hypercall semantics) are avoided with deliberate caution here.
Note: the example emits a dtc warning (unit_address_vs_reg) for the
/hypervisor node. Both the normative text in xen.txt ("Xen ARM virtual
platforms shall have a top-level 'hypervisor' node") and the example
in xen.txt mandate this exact node name — the $nodename: const:
hypervisor in the schema is a direct encoding of that pre-existing
requirement. A unit address is therefore impossible despite the presence
of reg. This warning is pre-existing and not introduced by this
conversion.
Signed-off-by: Tejas Mutalikdesai <tejasmutalikdesai@gmail.com>
---
Changes since v1:
- Switch to dual license (GPL-2.0-only OR BSD-2-Clause) as required by
submitting-patches.rst §3
- Add required: for all five xen,uefi-* properties within the uefi subnode;
the source table lists them as unconditionally populated by Xen
- Fix grammar: "an HYPERVISOR_memory_op" -> "a HYPERVISOR_memory_op"
- Fix subject: s/YAML schema/DT schema/ per submitting-patches.rst
Documentation/devicetree/bindings/arm/xen.txt | 62 ---------
.../devicetree/bindings/arm/xen.yaml | 120 ++++++++++++++++++
2 files changed, 120 insertions(+), 62 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/xen.txt
create mode 100644 Documentation/devicetree/bindings/arm/xen.yaml
diff --git a/Documentation/devicetree/bindings/arm/xen.txt b/Documentation/devicetree/bindings/arm/xen.txt
deleted file mode 100644
index f925290d4641..000000000000
--- a/Documentation/devicetree/bindings/arm/xen.txt
+++ /dev/null
@@ -1,62 +0,0 @@
-* Xen hypervisor device tree bindings
-
-Xen ARM virtual platforms shall have a top-level "hypervisor" node with
-the following properties:
-
-- compatible:
- compatible = "xen,xen-<version>", "xen,xen";
- where <version> is the version of the Xen ABI of the platform.
-
-- reg: specifies the base physical address and size of the regions in memory
- where the special resources should be mapped to, using an HYPERVISOR_memory_op
- hypercall.
- Region 0 is reserved for mapping grant table, it must be always present.
- The memory region is large enough to map the whole grant table (it is larger
- or equal to gnttab_max_grant_frames()).
- Regions 1...N are extended regions (unused address space) for mapping foreign
- GFNs and grants, they might be absent if there is nothing to expose.
-
-- interrupts: the interrupt used by Xen to inject event notifications.
- A GIC node is also required.
-
-To support UEFI on Xen ARM virtual platforms, Xen populates the FDT "uefi" node
-under /hypervisor with following parameters:
-
-________________________________________________________________________________
-Name | Size | Description
-================================================================================
-xen,uefi-system-table | 64-bit | Guest physical address of the UEFI System
- | | Table.
---------------------------------------------------------------------------------
-xen,uefi-mmap-start | 64-bit | Guest physical address of the UEFI memory
- | | map.
---------------------------------------------------------------------------------
-xen,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map
- | | pointed to in previous entry.
---------------------------------------------------------------------------------
-xen,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI
- | | memory map.
---------------------------------------------------------------------------------
-xen,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format.
---------------------------------------------------------------------------------
-
-Example (assuming #address-cells = <2> and #size-cells = <2>):
-
-hypervisor {
- compatible = "xen,xen-4.3", "xen,xen";
- reg = <0 0xb0000000 0 0x20000>;
- interrupts = <1 15 0xf08>;
- uefi {
- xen,uefi-system-table = <0xXXXXXXXX>;
- xen,uefi-mmap-start = <0xXXXXXXXX>;
- xen,uefi-mmap-size = <0xXXXXXXXX>;
- xen,uefi-mmap-desc-size = <0xXXXXXXXX>;
- xen,uefi-mmap-desc-ver = <0xXXXXXXXX>;
- };
-};
-
-The format and meaning of the "xen,uefi-*" parameters are similar to those in
-Documentation/arch/arm/uefi.rst, which are provided by the regular UEFI stub. However
-they differ because they are provided by the Xen hypervisor, together with a set
-of UEFI runtime services implemented via hypercalls, see
-http://xenbits.xen.org/docs/unstable/hypercall/x86_64/include,public,platform.h.html.
diff --git a/Documentation/devicetree/bindings/arm/xen.yaml b/Documentation/devicetree/bindings/arm/xen.yaml
new file mode 100644
index 000000000000..f4ba3aea2483
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/xen.yaml
@@ -0,0 +1,120 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/xen.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Xen hypervisor
+
+maintainers:
+ - Stefano Stabellini <sstabellini@kernel.org>
+
+description: |
+ Xen ARM virtual platforms shall have a top-level "hypervisor" node with
+ the properties defined below.
+
+properties:
+ $nodename:
+ const: hypervisor
+
+ compatible:
+ description: |
+ Specifies the Xen hypervisor. The version of the Xen ABI is encoded
+ in the first item as "xen,xen-<version>", followed by the generic
+ "xen,xen" string.
+ items:
+ - pattern: "^xen,xen-[0-9]+\\.[0-9]+$"
+ - const: xen,xen
+
+ reg:
+ description: |
+ Base physical address and size of the regions in memory where special
+ resources should be mapped to, using a HYPERVISOR_memory_op hypercall.
+
+ Region 0 is reserved for mapping the grant table and must always be
+ present. The memory region must be large enough to map the whole grant
+ table (it is larger or equal to gnttab_max_grant_frames()).
+
+ Regions 1...N are extended regions (unused address space) for mapping
+ foreign GFNs and grants. They might be absent if there is nothing to
+ expose.
+ minItems: 1
+
+ interrupts:
+ description: |
+ The interrupt used by Xen to inject event notifications.
+ A GIC node is also required.
+ maxItems: 1
+
+ uefi:
+ type: object
+ description: |
+ Node populated by Xen to support UEFI on Xen ARM virtual platforms.
+ The format and meaning of the "xen,uefi-*" parameters are similar to
+ those in Documentation/arch/arm/uefi.rst, but are provided by the Xen
+ hypervisor together with a set of UEFI runtime services implemented via
+ hypercalls.
+ properties:
+ xen,uefi-system-table:
+ description: Guest physical address of the UEFI System Table.
+ $ref: /schemas/types.yaml#/definitions/uint64
+
+ xen,uefi-mmap-start:
+ description: Guest physical address of the UEFI memory map.
+ $ref: /schemas/types.yaml#/definitions/uint64
+
+ xen,uefi-mmap-size:
+ description: Size in bytes of the UEFI memory map pointed to by xen,uefi-mmap-start.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ xen,uefi-mmap-desc-size:
+ description: Size in bytes of each entry in the UEFI memory map.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ xen,uefi-mmap-desc-ver:
+ description: Version of the mmap descriptor format.
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+ required:
+ - xen,uefi-system-table
+ - xen,uefi-mmap-start
+ - xen,uefi-mmap-size
+ - xen,uefi-mmap-desc-size
+ - xen,uefi-mmap-desc-ver
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+additionalProperties: false
+
+examples:
+ - |
+ / {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ gic: interrupt-controller {
+ #interrupt-cells = <3>;
+ interrupt-controller;
+ };
+
+ hypervisor {
+ compatible = "xen,xen-4.3", "xen,xen";
+ reg = <0 0xb0000000 0 0x20000>;
+ interrupt-parent = <&gic>;
+ interrupts = <1 15 0xf08>;
+
+ uefi {
+ xen,uefi-system-table = /bits/ 64 <0x1301415>;
+ xen,uefi-mmap-start = /bits/ 64 <0x7591400>;
+ xen,uefi-mmap-size = <0x1800>;
+ xen,uefi-mmap-desc-size = <0x30>;
+ xen,uefi-mmap-desc-ver = <1>;
+ };
+ };
+ };
+...
--
2.54.0
^ permalink raw reply related
* [PATCH v5 0/7] drm/rcar-du: Add support for DSI pipelines with DSC
From: Tomi Valkeinen @ 2026-06-15 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen, Conor Dooley
Some DSI pipelines have DSC (Display Stream Compression) IP block
between the DU and the DSI. Even if DSC is not needed, the IP must be
enabled for the DSI output to work.
This series adds a basic DSC driver, so that the DSC IP gets enabled in
bypass mode. This enables DisplayPort output on Sparrow Hawk board, as
the DP output comes from DSI and sn65dsi86 bridge, and also White Hawk
board's second mini-DP output.
Original series from Marek.
Note: I see that not every run of kms++'s kmstest gives me a picture on
my monitor. Sometimes the monitor seems to be trying to repeatedly sync,
but fails, and the screen stays black. However, I see this same issue on
WhiteHawk, which uses DSI0 pipeline, without DSC, so I think that is a
separate issue.
Tomi
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
Changes in v5:
- Drop the "renesas,rcar-dsc" compatible, and rename the binding file to renesas,r8a779g0-dsc.yaml
- Check pm_runtime_get_sync() < 0 for error, instead of
pm_runtime_get_sync() != 0
- Move pm_runtime_enable() before drm_bridge_add(), so that runtime PM
is ready when we publish the bridge
- Fix "DCS" typo in commit desc
- Rewrite "drm/rcar-du: dsi: Support DSC in the pipeline" again, this
time solving the DSI/DSC question in rcar_du_encoder_init()
- Link to v4: https://patch.msgid.link/20260615-rcar-du-dsc-v4-0-93096a1b56a3@ideasonboard.com
Changes in v4:
- Add 'renesas,rcar-dsc' compatible, in addition to the SoC specific
compatible
- Use 'bridge' as the name of the DT node
- Arrange Kconfig and Makefile entries alphabetically
- Rebase on drm-misc-next, and fix the drm_atomic_state rename issue
- Use pm_runtime_get_sync() in .atomic_enable() instead of
pm_runtime_resume_and_get() to fix the possible runtime PM get/put
discrepancy
- Drop ioremap and mmio field, as the driver does not touch the
registers
- Use of_drm_get_bridge_by_endpoint() to get the next bridge
- Rewrite "drm/rcar-du: dsi: Support DSC in the pipeline" to use
bridge->type to detect the DSI and the DSC
- And some cosmetic fixes pointed out in the review comments
- Link to v3: https://patch.msgid.link/20260515-rcar-du-dsc-v3-0-164157820498@ideasonboard.com
Changes in v3:
- Simplify DSC driver: drop reset control, drop clk handling, use runtime PM
- Split dts changes for r8a779g0 and sparrow-hawk to separate patches
- Add "arm64: dts: renesas: white-hawk: Add second mini-DP output
support"
- Link to v2: https://patch.msgid.link/20260515-rcar-du-dsc-v2-0-f6b9240a1240@ideasonboard.com
Changes in v2:
- Fixed the dts example in "dt-bindings: display: bridge: Document
Renesas R-Car V4H DSC bindings"
- Link to v1: https://lore.kernel.org/r/20260514-rcar-du-dsc-v1-0-d65f7a9e9841@ideasonboard.com
---
Geert Uytterhoeven (1):
arm64: dts: renesas: white-hawk: Add second mini-DP output support
Marek Vasut (5):
clk: renesas: r8a779g0: Add DSC clock
dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
drm/rcar-du: dsc: Add rudimentary Renesas R-Car V4H DSC driver
arm64: dts: renesas: r8a779g0: Add DSC
arm64: dts: renesas: sparrow-hawk: Enable DisplayPort by adding DSC
Tomi Valkeinen (1):
drm/rcar-du: dsi: Support DSC in the pipeline
.../display/bridge/renesas,r8a779g0-dsc.yaml | 96 +++++++++++++
.../arm64/boot/dts/renesas/r8a779g0-white-hawk.dts | 94 +++++++++++++
arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 31 ++++-
.../boot/dts/renesas/r8a779g3-sparrow-hawk.dts | 5 +
drivers/clk/renesas/r8a779g0-cpg-mssr.c | 1 +
drivers/gpu/drm/renesas/rcar-du/Kconfig | 12 ++
drivers/gpu/drm/renesas/rcar-du/Makefile | 1 +
drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c | 154 +++++++++++++++++++++
drivers/gpu/drm/renesas/rcar-du/rcar_du_encoder.c | 18 ++-
drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 1 +
10 files changed, 410 insertions(+), 3 deletions(-)
---
base-commit: a56a73ec85c81c7e533bc249ff0fd996256053fd
change-id: 20260514-rcar-du-dsc-45bcf0c2fe86
Best regards,
--
Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
^ permalink raw reply
* [PATCH v5 1/7] clk: renesas: r8a779g0: Add DSC clock
From: Tomi Valkeinen @ 2026-06-15 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v5-0-aed1a28610e4@ideasonboard.com>
From: Marek Vasut <marek.vasut+renesas@mailbox.org>
Add the DSC module clock for Renesas R-Car V4H (R8A779G0) SoC.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
drivers/clk/renesas/r8a779g0-cpg-mssr.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/renesas/r8a779g0-cpg-mssr.c b/drivers/clk/renesas/r8a779g0-cpg-mssr.c
index 015b9773cc55..54ba76ff5ab0 100644
--- a/drivers/clk/renesas/r8a779g0-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a779g0-cpg-mssr.c
@@ -245,6 +245,7 @@ static const struct mssr_mod_clk r8a779g0_mod_clks[] __initconst = {
DEF_MOD("fcpvx0", 1100, R8A779G0_CLK_S0D1_VIO),
DEF_MOD("fcpvx1", 1101, R8A779G0_CLK_S0D1_VIO),
DEF_MOD("tsn", 2723, R8A779G0_CLK_S0D4_HSC),
+ DEF_MOD("dsc", 2819, R8A779G0_CLK_VIOBUSD2),
DEF_MOD("ssiu", 2926, R8A779G0_CLK_S0D6_PER),
DEF_MOD("ssi", 2927, R8A779G0_CLK_S0D6_PER),
};
--
2.43.0
^ permalink raw reply related
* [PATCH v5 2/7] dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
From: Tomi Valkeinen @ 2026-06-15 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen, Conor Dooley
In-Reply-To: <20260615-rcar-du-dsc-v5-0-aed1a28610e4@ideasonboard.com>
From: Marek Vasut <marek.vasut+renesas@mailbox.org>
The Renesas DSC Display Stream Compression is a bridge embedded in the
Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
8k or 400 Mpixel/s .
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[tomi.valkeinen: fix the example]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
.../display/bridge/renesas,r8a779g0-dsc.yaml | 96 ++++++++++++++++++++++
1 file changed, 96 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,r8a779g0-dsc.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,r8a779g0-dsc.yaml
new file mode 100644
index 000000000000..6ce2444409a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/renesas,r8a779g0-dsc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/bridge/renesas,r8a779g0-dsc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R-Car DSC Display Stream Compression
+
+maintainers:
+ - Marek Vasut <marek.vasut+renesas@mailbox.org>
+
+description: |
+ This binding describes the VESA DSC Display Stream Compression encoder
+ embedded in the Renesas R-Car V4H SoC. The encoder supports all DSC1.1
+ encoding mechanisms, configurable bits-per-pixel, resolution up to 8k.
+
+properties:
+ compatible:
+ const: renesas,r8a779g0-dsc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ power-domains:
+ maxItems: 1
+
+ resets:
+ maxItems: 1
+
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: R-Car DU input port
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: R-Car DSI output port
+
+ required:
+ - port@0
+ - port@1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - interrupts
+ - power-domains
+ - resets
+ - ports
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/r8a779g0-cpg-mssr.h>
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/power/r8a779g0-sysc.h>
+
+ bridge@feb8d000 {
+ compatible = "renesas,r8a779g0-dsc";
+ reg = <0xfeb8d000 0x400>;
+ interrupts = <GIC_SPI 559 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 2819>;
+ power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
+ resets = <&cpg 2819>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsc_in_dsi1: endpoint {
+ remote-endpoint = <&du_out_dsi1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsc_out_dsi1: endpoint {
+ remote-endpoint = <&dsi1_in>;
+ };
+ };
+ };
+ };
+...
--
2.43.0
^ permalink raw reply related
* [PATCH v5 3/7] drm/rcar-du: dsc: Add rudimentary Renesas R-Car V4H DSC driver
From: Tomi Valkeinen @ 2026-06-15 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v5-0-aed1a28610e4@ideasonboard.com>
From: Marek Vasut <marek.vasut+renesas@mailbox.org>
The Renesas DSC Display Stream Compression is a bridge embedded in the
Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
8k or 400 Mpixel/s. Add rudimentary driver, which currently acts as a
pass-through bridge and allows DSI1 to be operational on R-Car V4H.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[tomi.valkeinen: use bridge->next_bridge, minor changes]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/gpu/drm/renesas/rcar-du/Kconfig | 12 +++
drivers/gpu/drm/renesas/rcar-du/Makefile | 1 +
drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c | 154 +++++++++++++++++++++++++++++
3 files changed, 167 insertions(+)
diff --git a/drivers/gpu/drm/renesas/rcar-du/Kconfig b/drivers/gpu/drm/renesas/rcar-du/Kconfig
index 840305fdeb49..80bd770ae0f6 100644
--- a/drivers/gpu/drm/renesas/rcar-du/Kconfig
+++ b/drivers/gpu/drm/renesas/rcar-du/Kconfig
@@ -25,6 +25,18 @@ config DRM_RCAR_CMM
def_tristate DRM_RCAR_DU
depends on DRM_RCAR_USE_CMM
+config DRM_RCAR_USE_DSC
+ bool "R-Car DU DSC Encoder Support"
+ depends on DRM_BRIDGE && OF
+ depends on DRM_RCAR_DU || COMPILE_TEST
+ default DRM_RCAR_DU
+ help
+ Enable support for the R-Car Display Unit embedded DSC encoder.
+
+config DRM_RCAR_DSC
+ def_tristate DRM_RCAR_DU
+ depends on DRM_RCAR_USE_DSC
+
config DRM_RCAR_DW_HDMI
tristate "R-Car Gen3 and RZ/G2 DU HDMI Encoder Support"
depends on DRM && OF
diff --git a/drivers/gpu/drm/renesas/rcar-du/Makefile b/drivers/gpu/drm/renesas/rcar-du/Makefile
index 6f132325c8b7..9ab7a0ac45d8 100644
--- a/drivers/gpu/drm/renesas/rcar-du/Makefile
+++ b/drivers/gpu/drm/renesas/rcar-du/Makefile
@@ -10,6 +10,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
obj-$(CONFIG_DRM_RCAR_CMM) += rcar_cmm.o
+obj-$(CONFIG_DRM_RCAR_DSC) += rcar_dsc.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
obj-$(CONFIG_DRM_RCAR_LVDS) += rcar_lvds.o
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c b/drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c
new file mode 100644
index 000000000000..362e683289d6
--- /dev/null
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_dsc.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * R-Car DSC Encoder
+ *
+ * Copyright (C) 2025 Marek Vasut <marek.vasut+renesas@mailbox.org>
+ * Copyright (C) 2025 Renesas Electronics Corporation
+ */
+
+#include <linux/container_of.h>
+#include <linux/io.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#include <drm/drm_atomic_helper.h>
+#include <drm/drm_bridge.h>
+
+struct rcar_dsc {
+ struct drm_bridge bridge;
+
+ struct device *dev;
+};
+
+static inline struct rcar_dsc *bridge_to_rcar_dsc(struct drm_bridge *bridge)
+{
+ return container_of(bridge, struct rcar_dsc, bridge);
+}
+
+/* -----------------------------------------------------------------------------
+ * Bridge
+ */
+
+static int rcar_dsc_attach(struct drm_bridge *bridge,
+ struct drm_encoder *encoder,
+ enum drm_bridge_attach_flags flags)
+{
+ struct rcar_dsc *dsc = bridge_to_rcar_dsc(bridge);
+
+ if (!(flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR))
+ return -EINVAL;
+
+ return drm_bridge_attach(encoder, dsc->bridge.next_bridge, bridge,
+ DRM_BRIDGE_ATTACH_NO_CONNECTOR);
+}
+
+static void rcar_dsc_atomic_enable(struct drm_bridge *bridge,
+ struct drm_atomic_commit *commit)
+{
+ struct rcar_dsc *dsc = bridge_to_rcar_dsc(bridge);
+
+ WARN_ON(pm_runtime_get_sync(dsc->dev) < 0);
+}
+
+static void rcar_dsc_atomic_disable(struct drm_bridge *bridge,
+ struct drm_atomic_commit *commit)
+{
+ struct rcar_dsc *dsc = bridge_to_rcar_dsc(bridge);
+
+ pm_runtime_put(dsc->dev);
+}
+
+static enum drm_mode_status
+rcar_dsc_bridge_mode_valid(struct drm_bridge *bridge,
+ const struct drm_display_info *info,
+ const struct drm_display_mode *mode)
+{
+ if (mode->hdisplay < 320 || mode->hdisplay > 8190)
+ return MODE_BAD_HVALUE;
+
+ if (mode->vdisplay < 160 || mode->vdisplay > 8190)
+ return MODE_BAD_VVALUE;
+
+ if (mode->clock > 400000) /* Really 400 Mpixel/s */
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static const struct drm_bridge_funcs rcar_dsc_bridge_ops = {
+ .attach = rcar_dsc_attach,
+ .atomic_duplicate_state = drm_atomic_helper_bridge_duplicate_state,
+ .atomic_destroy_state = drm_atomic_helper_bridge_destroy_state,
+ .atomic_reset = drm_atomic_helper_bridge_reset,
+ .atomic_enable = rcar_dsc_atomic_enable,
+ .atomic_disable = rcar_dsc_atomic_disable,
+ .mode_valid = rcar_dsc_bridge_mode_valid,
+};
+
+/* -----------------------------------------------------------------------------
+ * Probe & Remove
+ */
+
+static int rcar_dsc_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct rcar_dsc *dsc;
+ int ret;
+
+ dsc = devm_drm_bridge_alloc(dev, struct rcar_dsc, bridge,
+ &rcar_dsc_bridge_ops);
+ if (IS_ERR(dsc))
+ return PTR_ERR(dsc);
+
+ platform_set_drvdata(pdev, dsc);
+
+ dsc->dev = &pdev->dev;
+
+ dsc->bridge.next_bridge = of_drm_get_bridge_by_endpoint(dev->of_node,
+ 1, 0);
+ if (IS_ERR(dsc->bridge.next_bridge))
+ return PTR_ERR(dsc->bridge.next_bridge);
+
+ dsc->bridge.of_node = dev->of_node;
+
+ pm_runtime_enable(&pdev->dev);
+
+ ret = devm_drm_bridge_add(dev, &dsc->bridge);
+ if (ret)
+ goto err_runtime_disable;
+
+ return 0;
+
+err_runtime_disable:
+ pm_runtime_disable(&pdev->dev);
+
+ return ret;
+}
+
+static void rcar_dsc_remove(struct platform_device *pdev)
+{
+ pm_runtime_disable(&pdev->dev);
+}
+
+static const struct of_device_id rcar_dsc_of_table[] = {
+ { .compatible = "renesas,r8a779g0-dsc" },
+ {}
+};
+
+MODULE_DEVICE_TABLE(of, rcar_dsc_of_table);
+
+static struct platform_driver rcar_dsc_platform_driver = {
+ .probe = rcar_dsc_probe,
+ .remove = rcar_dsc_remove,
+ .driver = {
+ .name = "rcar-dsc",
+ .of_match_table = rcar_dsc_of_table,
+ },
+};
+
+module_platform_driver(rcar_dsc_platform_driver);
+
+MODULE_DESCRIPTION("Renesas R-Car DSC Encoder Driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v5 4/7] drm/rcar-du: dsi: Support DSC in the pipeline
From: Tomi Valkeinen @ 2026-06-15 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v5-0-aed1a28610e4@ideasonboard.com>
Enabling DSI clocks on rcar-du needs some tricks as the DU dot clock is
provided by the DSI. Thus, we call rcar_mipi_dsi_pclk_enable() from the
crtc, when enabling the crtc.
With DSC (added in upcoming patch) in the pipeline, between the DU and
the DSI, the above call path is broken as the crtc tries to call
rcar_mipi_dsi_pclk_enable() on the DSC.
To solve this problem, make sure we store the DSI bridge to the
rcdu->dsi[] array, instead of the first bridge in the DSI pipeline
(which can be DCS), by checking the bridge's bridge->type.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
drivers/gpu/drm/renesas/rcar-du/rcar_du_encoder.c | 18 ++++++++++++++++--
drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 1 +
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_du_encoder.c b/drivers/gpu/drm/renesas/rcar-du/rcar_du_encoder.c
index db2088529b48..ac85838ab3b8 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_du_encoder.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_du_encoder.c
@@ -89,9 +89,23 @@ int rcar_du_encoder_init(struct rcar_du_device *rcdu,
drm_bridge_get(bridge);
if (output == RCAR_DU_OUTPUT_DSI0 ||
- output == RCAR_DU_OUTPUT_DSI1)
+ output == RCAR_DU_OUTPUT_DSI1) {
+ struct drm_bridge *dsi_bridge;
+
+ /*
+ * When we have a DSC block between the DU and the DSI,
+ * the "bridge" points to the DSC. Detect the DSC by looking
+ * at the bridge type, and skip the DSC if the bridge is not
+ * the DSI bridge.
+ */
+
+ dsi_bridge = bridge->type == DRM_MODE_CONNECTOR_DSI ?
+ bridge :
+ bridge->next_bridge;
+
rcdu->dsi[output - RCAR_DU_OUTPUT_DSI0] =
- drm_bridge_get(bridge);
+ drm_bridge_get(dsi_bridge);
+ }
}
/*
diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
index aaafee1c060b..f429f03a380c 100644
--- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
+++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
@@ -957,6 +957,7 @@ static int rcar_mipi_dsi_host_attach(struct mipi_dsi_host *host,
/* Initialize the DRM bridge. */
dsi->bridge.of_node = dsi->dev->of_node;
+ dsi->bridge.type = DRM_MODE_CONNECTOR_DSI;
drm_bridge_add(&dsi->bridge);
return 0;
--
2.43.0
^ permalink raw reply related
* [PATCH v5 5/7] arm64: dts: renesas: r8a779g0: Add DSC
From: Tomi Valkeinen @ 2026-06-15 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v5-0-aed1a28610e4@ideasonboard.com>
From: Marek Vasut <marek.vasut+renesas@mailbox.org>
The Renesas DSC Display Stream Compression is a bridge embedded in the
Renesas R-Car V4H SoC. The bridge is placed between DU and DSI1 units.
The current dtsi file does not represent the DSC at all, and thus the
pipeline for DSI1 has not been functional.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[tomi.valkeinen: separated the sparrowhawk changes]
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 31 ++++++++++++++++++++++++++++++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
index 82a7278836e5..717bd41807ec 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
@@ -2298,6 +2298,35 @@ du_out_dsi0: endpoint {
port@1 {
reg = <1>;
du_out_dsi1: endpoint {
+ remote-endpoint = <&dsc_in_dsi1>;
+ };
+ };
+ };
+ };
+
+ dsc: bridge@feb8d000 {
+ compatible = "renesas,r8a779g0-dsc";
+ reg = <0 0xfeb8d000 0 0x400>;
+ interrupts = <GIC_SPI 559 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_MOD 2819>;
+ power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
+ resets = <&cpg 2819>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dsc_in_dsi1: endpoint {
+ remote-endpoint = <&du_out_dsi1>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dsc_out_dsi1: endpoint {
remote-endpoint = <&dsi1_in>;
};
};
@@ -2534,7 +2563,7 @@ ports {
port@0 {
reg = <0>;
dsi1_in: endpoint {
- remote-endpoint = <&du_out_dsi1>;
+ remote-endpoint = <&dsc_out_dsi1>;
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v5 6/7] arm64: dts: renesas: sparrow-hawk: Enable DisplayPort by adding DSC
From: Tomi Valkeinen @ 2026-06-15 13:11 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v5-0-aed1a28610e4@ideasonboard.com>
From: Marek Vasut <marek.vasut+renesas@mailbox.org>
DisplayPort on the Sparrow Hawk board uses sn65dsi86 bridge, which in
turn gets the video stream from the SoC's DSI1 port. DSI1 pipeline has a
DSC block in between the DU and the DSI1. However, there was no DSC
driver in Linux and also the DSC was not defined in the dts files, and
thus the DisplayPort output did not work.
Now that we have DSC defined in the SoC dts file (r8a779g0.dtsi), we can
enable DSC for sparrowhawk.
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
[tomi.valkeinen: separated the sparrow hawk changes from the soc changes]
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
index af680290ce81..0a5ebe0460ca 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk.dts
@@ -288,6 +288,11 @@ channel4 {
};
};
+/* Page 27 / DSI to Display */
+&dsc {
+ status = "okay";
+};
+
/* Page 27 / DSI to Display */
&dsi1 {
status = "okay";
--
2.43.0
^ permalink raw reply related
* [PATCH v5 7/7] arm64: dts: renesas: white-hawk: Add second mini-DP output support
From: Tomi Valkeinen @ 2026-06-15 13:12 UTC (permalink / raw)
To: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel
Cc: linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree,
Tomi Valkeinen
In-Reply-To: <20260615-rcar-du-dsc-v5-0-aed1a28610e4@ideasonboard.com>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Add support for the mini-DisplayPort connector on the White Hawk
BreakOut board. This connector is driven by a TI SN65DSI86 DSI to eDP
bridge, which in turn gets the pixel data from the second DSI channel on
the R-Car V4H SoC. Note that this port is not present on the White Hawk
Single development board.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
[tomi.valkeinen: added status=okay for dsc]
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
---
.../arm64/boot/dts/renesas/r8a779g0-white-hawk.dts | 94 ++++++++++++++++++++++
1 file changed, 94 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts
index 784d4e8b204c..89d60b83ac4f 100644
--- a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts
+++ b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk.dts
@@ -12,4 +12,98 @@
/ {
model = "Renesas White Hawk CPU and Breakout boards based on r8a779g0";
compatible = "renesas,white-hawk-breakout", "renesas,white-hawk-cpu", "renesas,r8a779g0";
+
+ sn65dsi86_refclk2: clk-x16 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <38400000>;
+ };
+
+ mini-dp-con2 {
+ compatible = "dp-connector";
+ label = "CN15";
+ type = "mini";
+
+ port {
+ mini_dp_con_in2: endpoint {
+ remote-endpoint = <&sn65dsi86_out2>;
+ };
+ };
+ };
+};
+
+&dsc {
+ status = "okay";
+};
+
+&dsi1 {
+ status = "okay";
+
+ ports {
+ port@1 {
+ dsi1_out: endpoint {
+ remote-endpoint = <&sn65dsi86_in2>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+ };
+};
+
+&i2c4 {
+ pinctrl-0 = <&i2c4_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+ clock-frequency = <400000>;
+
+ bridge@2c {
+ pinctrl-0 = <&irq1_pins>;
+ pinctrl-names = "default";
+
+ compatible = "ti,sn65dsi86";
+ reg = <0x2c>;
+
+ clocks = <&sn65dsi86_refclk2>;
+ clock-names = "refclk";
+
+ interrupts-extended = <&intc_ex 1 IRQ_TYPE_LEVEL_HIGH>;
+
+ enable-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
+
+ vccio-supply = <®_1p8v>;
+ vpll-supply = <®_1p8v>;
+ vcca-supply = <®_1p2v>;
+ vcc-supply = <®_1p2v>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ sn65dsi86_in2: endpoint {
+ remote-endpoint = <&dsi1_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ sn65dsi86_out2: endpoint {
+ remote-endpoint = <&mini_dp_con_in2>;
+ };
+ };
+ };
+ };
+};
+
+&pfc {
+ i2c4_pins: i2c4 {
+ groups = "i2c4";
+ function = "i2c4";
+ };
+
+ irq1_pins: irq1 {
+ groups = "intc_ex_irq1_a";
+ function = "intc_ex";
+ };
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro @ 2026-06-15 13:25 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
linux-arm-kernel, iommu, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <7xfxlxfqjcqdzl6gckaoyy2ioefglc7bgi66yv5khrbl6fi2zc@ivtiukdaj4jv>
On 6/8/2026 7:25 PM, Dmitry Baryshkov wrote:
> On Tue, May 26, 2026 at 08:12:03PM +0530, Bibek Kumar Patro wrote:
>> On some SoCs the SMMU registers require an active interconnect
>> bandwidth vote to be accessible. While other clients typically
>> satisfy this requirement implicitly, certain corner cases (e.g.
>> during sleep/wakeup transitions) can leave the SMMU without a
>> vote, causing intermittent register access failures.
>>
>> Add support for an optional interconnect path to the arm-smmu
>> driver and vote for bandwidth while the SMMU is active. The path
>> is acquired from DT if present and ignored otherwise.
>>
>> The bandwidth vote is enabled before accessing SMMU registers
>> during probe and runtime resume, and released during runtime
>> suspend and on error paths.
>>
>> Generally, from an architectural perspective, GEM_NOC and DDR are
>> expected to have an active vote whenever the adreno_smmu block is
>> powered on. In most common use cases, this requirement is implicitly
>> satisfied because other GPU-related clients (for example, the GMU
>> device) already hold a GEM_NOC vote when adreno_smmu is enabled.
>>
>> However, there are certain corner cases, such as during sleep/wakeup
>> transitions, where the GEM_NOC vote can be removed before adreno_smmu
>> is powered down. If adreno_smmu is then accessed while the interconnect
>> vote is missing, it can lead to the observed failures. Because of the
>> precise ordering involved, this scenario is difficult to reproduce
>> consistently.
>> (also GDSC is involved in adreno usecases can have an independent vote)
>>
>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>> ---
>> drivers/iommu/arm/arm-smmu/arm-smmu.c | 57 +++++++++++++++++++++++++++++++++--
>> drivers/iommu/arm/arm-smmu/arm-smmu.h | 2 ++
>> 2 files changed, 57 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.c b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> index 0bd21d206eb3e75c3b9fb1364cdc92e82c5aa499..07c7e44ec6a5bd1488f00f87d859a20495e46601 100644
>> --- a/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> +++ b/drivers/iommu/arm/arm-smmu/arm-smmu.c
>> @@ -53,6 +53,11 @@
>> #define MSI_IOVA_BASE 0x8000000
>> #define MSI_IOVA_LENGTH 0x100000
>>
>> +/* Interconnect bandwidth vote values for the SMMU register access path */
>> +#define ARM_SMMU_ICC_AVG_BW 0
>> +#define ARM_SMMU_ICC_PEAK_BW_HIGH 1000
>
> totally random numbers, which might be different for non-Qualcomm platform.
>
>> +#define ARM_SMMU_ICC_PEAK_BW_LOW 0
>> +
>> static int force_stage;
>> module_param(force_stage, int, S_IRUGO);
>> MODULE_PARM_DESC(force_stage,
>> @@ -86,6 +91,36 @@ static inline void arm_smmu_rpm_put(struct arm_smmu_device *smmu)
>> }
>> }
>>
>> +static int arm_smmu_icc_get(struct arm_smmu_device *smmu)
>> +{
>> + smmu->icc_path = devm_of_icc_get(smmu->dev, NULL);
>
> Is there always only one bus / path in question?
>
<Apologies, missed to respond to this query>
Yes for TCU, it needs to only have a vote on GEM_NOC interconnect
while accessing the DDR in downstream path (client->TCU->DDR), which we
are addressing here.
Hence it's only one icc path in question here.
Thanks & regards,
Bibek
>> + if (IS_ERR(smmu->icc_path)) {
>
> if (!IS_ERR(smmu->icc_path))
> return 0;
>
> int err = PTR_ERR();
> if (err == -ENODEV) {
> icc_path = NULL;
> return 0;
> }
>
> return dev_err_probe();
>
>
>> + int err = PTR_ERR(smmu->icc_path);
>> +
>> + if (err == -ENODEV) {
>> + smmu->icc_path = NULL;
>> + return 0;
>> + }
>> + return dev_err_probe(smmu->dev, err,
>> + "failed to get interconnect path\n");
>> + }
>> + return 0;
>> +}
>> +
>> +static void arm_smmu_icc_enable(struct arm_smmu_device *smmu)
>> +{
>> + if (smmu->icc_path)
>
> Drop the if.
>
>> + WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
>> + ARM_SMMU_ICC_PEAK_BW_HIGH));
>
> WARN_ON_ONCE()?
>
> Pass the error to the caller.
>
>
>> +}
>> +
>> +static void arm_smmu_icc_disable(struct arm_smmu_device *smmu)
>> +{
>> + if (smmu->icc_path)
>
> Drop the if.
>
>> + WARN_ON(icc_set_bw(smmu->icc_path, ARM_SMMU_ICC_AVG_BW,
>> + ARM_SMMU_ICC_PEAK_BW_LOW));
>
> Pass the error to the caller.
>
>> +}
>> +
>> static void arm_smmu_rpm_use_autosuspend(struct arm_smmu_device *smmu)
>> {
>> /*
>> @@ -2189,6 +2224,17 @@ static int arm_smmu_device_probe(struct platform_device *pdev)
>> if (err)
>> return err;
>>
>> + /*
>> + * Acquire and vote the interconnect path before accessing any SMMU
>> + * registers (including ARM_SMMU_GR0_ID0 in arm_smmu_device_cfg_probe).
>> + */
>> + err = arm_smmu_icc_get(smmu);
>> + if (err) {
>> + clk_bulk_disable_unprepare(smmu->num_clks, smmu->clks);
>> + return err;
>> + }
>> + arm_smmu_icc_enable(smmu);
>
> Handle the error.
>
>> +
>> err = arm_smmu_device_cfg_probe(smmu);
>> if (err)
>> return err;
>> @@ -2273,8 +2319,10 @@ static void arm_smmu_device_shutdown(struct platform_device *pdev)
>>
>> if (pm_runtime_enabled(smmu->dev))
>> pm_runtime_force_suspend(smmu->dev);
>> - else
>> + else {
>> clk_bulk_disable(smmu->num_clks, smmu->clks);
>> + arm_smmu_icc_disable(smmu);
>
> Handle the error.
>
> etc.
>
>> + }
>>
>> clk_bulk_unprepare(smmu->num_clks, smmu->clks);
>> }
>
^ permalink raw reply
* [PATCH v9 1/2] dt-bindings: ufs: Document static TX Equalization settings properties
From: Can Guo @ 2026-06-15 13:28 UTC (permalink / raw)
To: krzk, bvanassche, beanhuo, peter.wang, martin.petersen, mani
Cc: linux-scsi, Can Guo, Alim Akhtar, Avri Altman, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ram Kumar Dwivedi,
Zhaoming Luo,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list
In-Reply-To: <20260615132834.2985346-1-can.guo@oss.qualcomm.com>
UFS v5.0/UFSHCI v5.0 adds HS-G6 support (46.6 Gbps/lane) via UniPro
v3.0 and M-PHY v6.0. These specs define TX Equalization for all
High-Speed Gears (not only HS-G6) to compensate channel loss and
improve signal integrity at high speed.
For HS-G6, M-PHY uses PAM4 1b1b line coding. Pre-Coding may also be
required depending on channel characteristics.
Document vendor-neutral properties in ufs-common.yaml:
- txeq-preshoot-g[1-6]
- txeq-deemphasis-g[1-6]
- tx-precode-enable-g6
Values are per-lane Host/Device tuples (2 values for x1, 4 values for
x2). PreShoot/DeEmphasis range from 0..7, and Precode is 0/1.
These are board-specific signal-integrity tuning values. They depend on
channel SI/PHY characterization and validation (host PHY, device PHY,
package, and board routing), and are determined by HW/PHY designers.
Although UFSHCI v5.0 supports TX Equalization Training via UniPro v3.0,
which allows host software to determine optimal TX Equalization at
runtime, static board-specific TX Equalization settings in the Device
Tree are still necessary because:
- TX Equalization Training is not supported for HS-G3 and below
- TX Equalization Training is disabled on some platforms
Signed-off-by: Can Guo <can.guo@oss.qualcomm.com>
---
.../devicetree/bindings/ufs/ufs-common.yaml | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
index ed97f5682509..cc32e1189d50 100644
--- a/Documentation/devicetree/bindings/ufs/ufs-common.yaml
+++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml
@@ -105,6 +105,64 @@ properties:
Restricts the UFS controller to rate-a or rate-b for both TX and
RX directions.
+ tx-precode-enable-g6:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ items:
+ - items:
+ - description: Host_Lane0 precode
+ enum: [0, 1]
+ - description: Device_Lane0 precode
+ enum: [0, 1]
+ - items:
+ - description: Host_Lane1 precode
+ enum: [0, 1]
+ - description: Device_Lane1 precode
+ enum: [0, 1]
+ description:
+ Static TX Precode enable values for HS-G6 only.
+
+patternProperties:
+ "^txeq-preshoot-g[1-6]$":
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ items:
+ - items:
+ - description: Host_Lane0 Preshoot value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - description: Device_Lane0 Preshoot value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - items:
+ - description: Host_Lane1 Preshoot value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - description: Device_Lane1 Preshoot value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ description: |
+ Static TX Equalization PreShoot settings for High Speed Gears. These
+ values are programmed to the corresponding UniPro PA layer attribute
+ PA_TxEQG[1-6]Setting. Each value selects a Pre-Shoot level as defined
+ by the MIPI M-PHY specification (TX_HS_PreShoot_Setting).
+
+ "^txeq-deemphasis-g[1-6]$":
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ minItems: 1
+ items:
+ - items:
+ - description: Host_Lane0 DeEmphasis value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - description: Device_Lane0 DeEmphasis value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - items:
+ - description: Host_Lane1 DeEmphasis value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ - description: Device_Lane1 DeEmphasis value
+ enum: [0, 1, 2, 3, 4, 5, 6, 7]
+ description: |
+ Static TX Equalization DeEmphasis settings for High Speed Gears. These
+ values are programmed to the corresponding UniPro PA layer attribute
+ PA_TxEQG[1-6]Setting. Each value selects a De-Emphasis level as defined
+ by the MIPI M-PHY specification (TX_HS_DeEmphasis_Setting).
+
dependencies:
freq-table-hz: [ clocks ]
operating-points-v2: [ clocks, clock-names ]
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net-next v7 02/12] net: phylink: introduce internal phylink PCS handling
From: Maxime Chevallier @ 2026-06-15 13:31 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-3-ansuelsmth@gmail.com>
Hi Christian,
On 6/15/26 14:29, Christian Marangi wrote:
> Introduce internal handling of PCS for phylink. This is an alternative
> way to .mac_select_pcs that moves the selection logic of the PCS entirely
> to phylink with the usage of the supported_interface value in the PCS
> struct.
>
> MAC should now provide a callback to fill the available PCS in
> phylink_config in .fill_available_pcs and fill the .num_possible_pcs with
> the number of elements in the array. MAC should also define a new bitmap,
> pcs_interfaces, in phylink_config to define for what interface mode a
> dedicated PCS is required.
>
> On phylink_create(), an array of PCS pointer is allocated of size
> .num_possible_pcs from phylink_config and .fill_available_pcs from
> phylink_config is called passing as args the just allocated array and
> the number of possible element in it.
>
> MAC will fill this passed array with all the available PCS.
>
> This array is then parsed and a linked list of PCS is created based on
> the allocated PCS array filled by MAC via .fill_available_pcs().
>
> Every PCS in phylink PCS list gets then linked to the phylink instance
> by setting the phylink value in phylink_pcs struct to the phylink instance.
> Also the supported_interface value in phylink struct is updated with
> the new supported_interface from the provided PCS.
>
> On phylink_destroy(), every PCS in phylink PCS list is unlinked from the
> phylink instance by setting the phylink value in phylink_pcs struct to NULL
> and removed from the PCS list.
>
> phylink_validate_mac_and_pcs(), phylink_major_config() and
> phylink_inband_caps() are updated to support this new implementation
> with the PCS list stored in phylink.
>
> They will make use of phylink_validate_pcs_interface() that will loop
> for every PCS in the phylink PCS available list and find one that supports
> the passed interface.
>
> phylink_validate_pcs_interface() applies the same logic of .mac_select_pcs
> where if a supported_interface value is not set for the PCS struct, then
> it's assumed every interface is supported.
>
> A MAC is required to implement either a .mac_select_pcs or make use of
> the PCS list implementation. Implementing both will result in a fail
> on phylink_create().
>
> A MAC defining .num_possible_pcs in phylink_config MUST also define a
> .fill_available_pcs or phylink_create() will fail with an negative error.
>
> phylink value in phylink_pcs struct with this implementation is used to
> track from PCS side when it's attached to a phylink instance. PCS driver
> will make use of this information to correctly detach from a phylink
> instance if needed.
>
> phylink_pcs_change() is also changed to verify that the PCS that triggered
> a link change is the one that is currently used by the phylink instance.
>
> The .mac_select_pcs implementation is not changed but it's expected that
> every MAC driver migrates to the new implementation to later deprecate
> and remove .mac_select_pcs.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
[...]
> @@ -1872,10 +1993,28 @@ struct phylink *phylink_create(struct phylink_config *config,
> mutex_init(&pl->phydev_mutex);
> mutex_init(&pl->state_mutex);
> INIT_WORK(&pl->resolve, phylink_resolve);
> + INIT_LIST_HEAD(&pl->pcs_list);
> +
> + /* Fill the PCS list with available PCS from phylink config */
> + ret = phylink_fill_available_pcs(pl, config);
> + if (ret < 0) {
> + kfree(pl);
> + return ERR_PTR(ret);
> + }
> +
> + /* Link available PCS to phylink */
> + list_for_each_entry(pcs, &pl->pcs_list, list)
> + pcs->phylink = pl;
>
> phy_interface_copy(pl->supported_interfaces,
> config->supported_interfaces);
>
> + /* Update supported interfaces */
> + list_for_each_entry(pcs, &pl->pcs_list, list)
> + phy_interface_or(pl->supported_interfaces,
> + pl->supported_interfaces,
> + pcs->supported_interfaces);
> +
I'm not entirely sure about that, we may need to restrict the supported_interfaces
from the MAC.
As an example, take mvpp2. We have 2 PCSs, one for BaseX/SGMII, one for BaseR. But
if we don't have a comphy (generic PHY) device, then we can't use all the
combination of modes our PCSs can provide :
https://elixir.bootlin.com/linux/v7.1-rc7/source/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c#L7074
These aren't external PCS IPs, but from what I understand you'd like to
handle these the same way as purely external PCSs, right ?
I'd say the MAC driver utltimately has the knowledge of all possible interfaces.
The way I see it, it's probably safer to let the MAC give a wide range of interfaces,
and filter that down with what the PCSs can provide (i.e. turn that or into an and,
while handling the case where the pcs supported interfaces is empty).
What do you think ?
Maxime
^ permalink raw reply
* Re: [PATCH net-next v7 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct
From: Maxime Chevallier @ 2026-06-15 13:33 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-2-ansuelsmth@gmail.com>
Hello Christian,
On 6/15/26 14:29, Christian Marangi wrote:
> Add in phylink struct a copy of supported_interfaces from phylink_config
> and make use of that instead of relying on phylink_config value.
>
> This in preparation for support of PCS handling internally to phylink
> where a PCS can be removed or added after the phylink is created and we
> need both a reference of the supported_interfaces value from
> phylink_config and an internal value that can be updated with the new
> PCS info.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> drivers/net/phy/phylink.c | 22 +++++++++++++++-------
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 087ac63f9193..4d59c0dd78db 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
> @@ -60,6 +60,11 @@ struct phylink {
> /* The link configuration settings */
> struct phylink_link_state link_config;
>
> + /* What interface are supported by the current link.
> + * Can change on removal or addition of new PCS.
> + */
> + DECLARE_PHY_INTERFACE_MASK(supported_interfaces);
Can you clarify a bit what you mean here ? Is that the combination of the
interfaces the MAC supports AND the currently in-use PCS ?
Maxime
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: Rob Herring (Arm) @ 2026-06-15 13:40 UTC (permalink / raw)
To: Joey Lu
Cc: Hui-Ping Chen, Neil Armstrong, Conor Dooley, Vinod Koul,
devicetree, Catalin Marinas, linux-arm-kernel,
Krzysztof Kozlowski, linux-kernel, Joey Lu, Jacky Huang,
Arnd Bergmann, linux-phy, Shan-Chun Hung
In-Reply-To: <20260615054911.48821-2-a0987203069@gmail.com>
On Mon, 15 Jun 2026 13:49:09 +0800, Joey Lu wrote:
> The MA35D1 has two USB PHY ports managed by the same hardware block:
>
> - PHY0 (index 0): OTG port shared between the DWC2 gadget controller
> and EHCI0/OHCI0 host controllers. A hardware mux follows the USB
> ID pin automatically.
>
> - PHY1 (index 1): dedicated host-only port for EHCI1/OHCI1.
>
> Extend the existing binding to cover both ports:
>
> - The PHY node is now a child of the system-management syscon node
> with a reg property. The nuvoton,sys phandle and clocks
> properties are removed; the driver derives the regmap from its
> parent, and clock gating is owned by each individual USB controller.
>
> - #phy-cells changes from 0 to 1: the cell selects the PHY port.
>
> - Two optional board-tuning properties are added: nuvoton,rcalcode
> for per-port resistor trim and nuvoton,oc-active-high for
> over-current polarity.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> .../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml | 62 ++++++++++++++-----
> 1 file changed, 48 insertions(+), 14 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): '#address-cells', '#size-cells', 'usb-phy@60' do not match any of the regexes: '^pinctrl-[0-9]+$'
from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): compatible: ['nuvoton,ma35d1-reset', 'syscon', 'simple-mfd'] is too long
from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.example.dtb: system-management@40460000 (nuvoton,ma35d1-reset): reg: [[0, 1078329344], [0, 512]] is too long
from schema $id: http://devicetree.org/schemas/reset/nuvoton,ma35d1-reset.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260615054911.48821-2-a0987203069@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v3 8/8] arm64: dts: freescale: imx95: Add NXP neoisp device tree node
From: Frank Li @ 2026-06-15 13:46 UTC (permalink / raw)
To: Francesco Dolcini
Cc: Antoine Bouyer, julien.vuillaumier, alexi.birlinger,
daniel.baluta, peng.fan, frank.li, jacopo.mondi, laurent.pinchart,
mchehab, robh, krzk+dt, conor+dt, michael.riesch,
anthony.mcgivern, linux-media, linux-kernel, devicetree, imx,
ai.luthra, paul.elder, geert, sakari.ailus, hverkuil+cisco
In-Reply-To: <20260615112549.GA137559@francesco-nb>
On Mon, Jun 15, 2026 at 01:25:49PM +0200, Francesco Dolcini wrote:
> On Mon, Jun 15, 2026 at 11:56:15AM +0200, Antoine Bouyer wrote:
> > On 6/14/26 11:05 AM, Francesco Dolcini wrote:
> > > On Fri, Jun 12, 2026 at 03:20:39PM +0200, Antoine Bouyer wrote:
> > > > Add neoisp device tree node to imx95.dtsi and enable it by default in
> > > > 19x19 evk board.
> > > >
> > > > Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
> > >
> > > ...
> > >
> > > > diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
> > > > index d6c549c16047..5543a6cb1250 100644
> > > > --- a/arch/arm64/boot/dts/freescale/imx95.dtsi
> > > > +++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
> > > > @@ -1867,6 +1867,17 @@ pmu@49252000 {
> > > > };
> > > > };
> > > >
> > > > + neoisp0: isp@4ae00000 {
> > > > + compatible = "nxp,imx95-neoisp";
> > > > + reg = <0x0 0x4ae00000 0x0 0x8000>,
> > > > + <0x0 0x4afe0000 0x0 0x10000>;
> > > > + interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>;
> > > > + clocks = <&scmi_clk IMX95_CLK_CAMCM0>;
> > > > + clock-names = "camcm0";
> > > > + power-domains = <&scmi_devpd IMX95_PD_CAMERA>;
> > > > + status = "disabled";
> > > > + };
> > >
> > > Why the node is disabled? If the node is wholly described in
> > > imx95.dtsi, it should be enabled.
> >
> > Actually, all nodes are disabled in the SoC dtsi, and enabled on the board
> > dts file, even if fully described on the dtsi. So I used same approach for
> > neoisp.
>
> This is not correct. Please check what we do for the GPU/VPU[1] and NPU [2],
> for example. Is there a reason to do it differently for the ISP?
I agree on Francesco. It is supposed be enabled by default if you can use
run time pm to manage clock and power.
Frank
>
> Francesco
>
> [1] arch/arm64/boot/dts/freescale/imx8mm.dtsi
> [2] arch/arm64/boot/dts/freescale/imx93.dtsi
>
^ permalink raw reply
* Re: [PATCH v11 0/3] Add eDP support for RK3576
From: Damon Ding @ 2026-06-15 13:32 UTC (permalink / raw)
To: Heiko Stübner, robh, krzk+dt, conor+dt
Cc: sebastian.reichel, nicolas.frattaroli, alchark, detlev.casanova,
cristian.ciocaltea, michael.riesch, andy.yan, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <3213683.CbtlEUcBR6@diego>
On 6/15/2026 9:01 PM, Heiko Stübner wrote:
> Hi Damon,
>
> Am Montag, 15. Juni 2026, 14:33:03 Mitteleuropäische Sommerzeit schrieb Damon Ding:
>> Gentle ping on this patch series.
>
> Linux 7.1 was released yesterday, so we're in the merge-window now.
> (And the 5th of june was shortly before -rc7, so too late for 7.2)
>
> So I'll pick those up after the merge window end in 2 weeks.
>
>
Thanks for the heads-up. Got it. ;-)
Best regards,
Damon
>>
>> On 6/5/2026 10:23 AM, Damon Ding wrote:
>>> Picked from:
>>> https://lore.kernel.org/all/20260601065100.1103873-1-damon.ding@rock-chips.com/
>>>
>>> Patch 1-2 are to add missing clock "hclk" for RK3588 eDP nodes.
>>> Patch 3 is to add the RK3576 eDP node.
>>>
>>> Damon Ding (3):
>>> arm64: dts: rockchip: Add missing hclk for RK3588 eDP0
>>> arm64: dts: rockchip: Add missing hclk for RK3588 eDP1
>>> arm64: dts: rockchip: Add eDP node for RK3576
>>>
>>> arch/arm64/boot/dts/rockchip/rk3576.dtsi | 28 +++++++++++++++++++
>>> arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 4 +--
>>> .../arm64/boot/dts/rockchip/rk3588-extra.dtsi | 4 +--
>>> 3 files changed, 32 insertions(+), 4 deletions(-)
>>>
>>> ---
>>>
>>> Changes in v2:
>>> - Split out separate patches to add the "hclk" clock reference.
>>> - Split out separate patches to enable the "hclk" clock.
>>> - Add Reviewed-by tag.
>>>
>>> Changes in v3:
>>> - Add a patch to expand descriptions for clocks of the eDP node.
>>> - Add Reviewed-by tag.
>>>
>>> Changes in v4:
>>> - Modify commit msg.
>>>
>>> Changes in v5:
>>> - Enforce the correct third clock name on a per-compatible basis.
>>> - Modify the commit msg simultaneously.
>>> - Add Acked-by tag.
>>>
>>> Changes in v6:
>>> - Expand more detail commit msg about using hclk instead of grf clock.
>>>
>>> Changes in v7:
>>> - List all valid clock names at the top level, and constrain the clock
>>> count for each platform with minItems/maxItems in allOf.
>>>
>>> Changes in v8:
>>> - Fix indentation to 10 for enum in clock-names property.
>>>
>>> Changes in v9:
>>> - Restore the explicit clock-names for RK3399 and RK3588 eDP dt-bindings.
>>>
>>> Changes in v10:
>>> - Use automatic cleanup to fix OF node reference leak reported by
>>> Sashiko.
>>>
>>> Changes in v11:
>>> - Pick and rebase DT related patches.
>>>
>>
>>
>
>
>
>
>
>
^ permalink raw reply
* Re: [PATCH 1/4] ASoC: qcom: audioreach: compute active channel maps from channel_map
From: Neil Armstrong @ 2026-06-15 13:54 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: kancy2333, linux-sound, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <05e15363-d49e-4a7b-82b3-0f07537b5366@kernel.org>
On 6/15/26 11:36, Srinivas Kandagatla wrote:
> On 6/15/26 10:31 AM, Neil Armstrong wrote:
>> On 6/15/26 10:38, Srinivas Kandagatla wrote:
>>>
>>>
>>> On 6/10/26 8:41 AM, Neil Armstrong wrote:
>>>> The Qualcom SM8650 based Ayaneo Pocket S2 gaming device has a set
>>>> of 2 WSA speakers connected on the WSA2 lines.
>>>>
>>>> But the Audioreach DSP only handles WSA2 in pair with the WSA
>>>> interface by using the upper bits of the active_channels_mask
>>>> for WSA2 and the lower bits for WSA:
>>>>
>>>> /-------------------------------------------------\
>>>> | Bits | 3 | 2 | 1 | 0 |
>>>> |-------------------------------------------------|
>>>> | Line | WSA2 Ch2 | WSA2 Ch1 | WSA Ch2 | WSA Ch1 |
>>>> \-------------------------------------------------/
>>>>
>>> No, this is not totally correct, if the setup only has WSA2, then
>>> channel 0 and 1 should be WSA2 channels.
>>>
>>> What is the backend dai id that is in DT, it should be
>>>
>>> sound-dai = <&q6apmbedai WSA2_CODEC_DMA_RX_0>;
>>>
>>> I also noticed that you are using
>>> https://github.com/linux-msm/audioreach-topology/blob/main/SM8550-HDK.m4
>>> which has WSA as backend dai, that is not correct, you should have WSA2.
>>
>> So I did try that, and DSP would error out when using the
>> LPAIF_INTF_TYPE_WSA2,
>> but I'm retrying from scratch right now.
>
> Please share the failure logs, we need to change
> 1. dt : bedai id, codec dais with correct soundwire wsa2 instance, the
> routes.
> 2. tplg
>
So I did all the changes as you suggested:
Resurected Krzk's serie: https://patch.msgid.link/20231019153541.49753-1-krzysztof.kozlowski@linaro.org
Adapted/Fixes it to apply on v7.1:
https://gitlab.com/superna9999/linux/-/commit/fd8cf1922d10175c5bcd8cf2a444c5825392d994
https://gitlab.com/superna9999/linux/-/commit/0c4e89e167b9ca9c7b500577c030e550ec2a6e73
https://gitlab.com/superna9999/linux/-/commit/6364a0a45a3f0985b872d9f504e9ea1d1f3f2a35
```
+#define WSA2_CODEC_DMA_RX_0 147
+#define WSA2_CODEC_DMA_TX_0 148
+#define WSA2_CODEC_DMA_RX_1 149
+#define WSA2_CODEC_DMA_TX_1 150
+#define WSA2_CODEC_DMA_TX_2 151
```
https://gitlab.com/superna9999/linux/-/commit/9bd0ce21f73df92fb35e3db7ef570f561a106478
DT:
https://gitlab.com/superna9999/linux/-/commit/2fc270860e3b77ccae28e0c38228cba3e39ea78a
```
- sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
+ sound-dai = <&q6apmbedai WSA2_CODEC_DMA_RX_0>;
};
```
Topology, copied the SM8550-HDK into a new one, dropped I2S and changed all WSA to WSA
and added the WSA defines:
https://github.com/superna9999/audioreach-topology/commit/12adc76859cde606c67e5a95df204b8d407038df
```
+define(`WSA2_CODEC_DMA_RX_0', `147') dnl
+define(`WSA2_CODEC_DMA_TX_0', `148') dnl
+define(`WSA2_CODEC_DMA_RX_1', `149') dnl
+define(`WSA2_CODEC_DMA_TX_1', `150') dnl
+define(`WSA2_CODEC_DMA_TX_2', `151') dnl
```
Extract of the SM8650-APS2.m4 concerning WSA2:
```
...
+dnl WSA Playback
+DEVICE_SG_ADD(audioreach/subgraph-device-codec-dma-playback.m4, `WSA2_CODEC_DMA_RX_0', WSA2_CODEC_DMA_RX_0,
+ `S16_LE', 48000, 48000, 2, 2,
+ LPAIF_INTF_TYPE_WSA2, CODEC_INTF_IDX_RX0, 0, DATA_FORMAT_FIXED_POINT,
+ 0x00004006, 0x00004006, 0x00006050)
+dnl
...
+STREAM_DEVICE_PLAYBACK_MIXER(WSA2_CODEC_DMA_RX_0, ``WSA2_CODEC_DMA_RX_0'', ``MultiMedia1'', ``MultiMedia2'', ``MultiMedia5'')
...
+STREAM_DEVICE_PLAYBACK_ROUTE(WSA2_CODEC_DMA_RX_0, ``WSA2_CODEC_DMA_RX_0 Audio Mixer'', ``MultiMedia1, stream0.logger1'', ``MultiMedia2, stream1.logger1'', ``MultiMedia5, stream4.logger1'')
...
```
On device, all sets up without errors:
```
[ 20.710228] qcom-apm gprsvc:service:2:1: CMD timeout for [1001021] opcode
[ 20.720234] platform 6800000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 30
[ 20.763797] va_macro 6d44000.codec: qcom,dmic-sample-rate dt entry missing
[ 20.791279] wsa_macro 6aa0000.codec: using zero-initialized flat cache, this may cause unexpected behavior
[ 20.912445] wcd939x_codec audio-codec: bound sdw:2:0:0217:010e:00:4 (ops wcd_sdw_component_ops [snd_soc_wcd_common])
[ 20.923343] wcd939x_codec audio-codec: bound sdw:3:0:0217:010e:00:3 (ops wcd_sdw_component_ops [snd_soc_wcd_common])
[ 20.960741] snd-sc8280xp sound: ASoC: Parent card not yet available, widget card binding deferred
[ 20.972182] va_macro 6d44000.codec: supply vdd-micb not found, using dummy regulator
[ 20.985751] ALSA: Control name 'stream0.vol_ctrl0 MultiMedia1 Playback Volume' truncated to 'stream0.vol_ctrl0 MultiMedia1 Playback Volu'
[ 20.998589] ALSA: Control name 'stream1.vol_ctrl1 MultiMedia2 Playback Volume' truncated to 'stream1.vol_ctrl1 MultiMedia2 Playback Volu'
[ 21.011536] ALSA: Control name 'stream4.vol_ctrl4 MultiMedia5 Playback Volume' truncated to 'stream4.vol_ctrl4 MultiMedia5 Playback Volu'
[ 21.026510] input: SM8650-APS2 Headset Jack as /devices/platform/sound/sound/card0/input7
[ 21.035151] input: SM8650-APS2 DP0 Jack as /devices/platform/sound/sound/card0/input8
```
Available mixer elements:
```
# amixer | grep WSA
Simple mixer control 'SpkrLeft WSA MODE',0
Simple mixer control 'SpkrRight WSA MODE',0
Simple mixer control 'WSA RX0 MUX',0
Simple mixer control 'WSA RX1 MUX',0
Simple mixer control 'WSA RX_MIX EC0_MUX',0
Simple mixer control 'WSA RX_MIX EC1_MUX',0
Simple mixer control 'WSA RX_MIX0 MUX',0
Simple mixer control 'WSA RX_MIX1 MUX',0
Simple mixer control 'WSA2_CODEC_DMA_RX_0 Audio Mixer MultiMedia1',0
Simple mixer control 'WSA2_CODEC_DMA_RX_0 Audio Mixer MultiMedia2',0
Simple mixer control 'WSA2_CODEC_DMA_RX_0 Audio Mixer MultiMedia5',0
Simple mixer control 'WSA_AIF_VI Mixer WSA_SPKR_VI_1',0
Simple mixer control 'WSA_AIF_VI Mixer WSA_SPKR_VI_2',0
Simple mixer control 'WSA_COMP1',0
Simple mixer control 'WSA_COMP2',0
Simple mixer control 'WSA_RX0 Digital',0
Simple mixer control 'WSA_RX0 Digital Mute',0
Simple mixer control 'WSA_RX0 EC_HQ',0
Simple mixer control 'WSA_RX0 INP0',0
Simple mixer control 'WSA_RX0 INP1',0
Simple mixer control 'WSA_RX0 INP2',0
Simple mixer control 'WSA_RX0 INT0 SIDETONE MIX',0
Simple mixer control 'WSA_RX0 MIX INP',0
Simple mixer control 'WSA_RX0_MIX Digital',0
Simple mixer control 'WSA_RX0_MIX Digital Mute',0
Simple mixer control 'WSA_RX1 Digital',0
Simple mixer control 'WSA_RX1 Digital Mute',0
Simple mixer control 'WSA_RX1 EC_HQ',0
Simple mixer control 'WSA_RX1 INP0',0
Simple mixer control 'WSA_RX1 INP1',0
Simple mixer control 'WSA_RX1 INP2',0
Simple mixer control 'WSA_RX1 MIX INP',0
Simple mixer control 'WSA_RX1_MIX Digital',0
Simple mixer control 'WSA_RX1_MIX Digital Mute',0
Simple mixer control 'WSA_Softclip0 Enable',0
Simple mixer control 'WSA_Softclip1 Enable',0
```
I setup the speaker with (no errors):
```
amixer -c 0 cset name='SpkrLeft PA Volume' 20
amixer -c 0 cset name='SpkrRight PA Volume' 20
amixer -c 0 cset name='WSA RX0 MUX' AIF1_PB
amixer -c 0 cset name='WSA RX1 MUX' AIF1_PB
amixer -c 0 cset name='WSA_RX0 INP0' RX0
amixer -c 0 cset name='WSA_RX1 INP0' RX1
amixer -c 0 cset name='SpkrLeft DAC Switch' 1
amixer -c 0 cset name='SpkrRight DAC Switch' 1
amixer -c 0 cset name='WSA_RX0 Digital Volume' 85
amixer -c 0 cset name='WSA_RX1 Digital Volume' 85
```
and finally:
```
amixer -c 0 cset name='WSA2_CODEC_DMA_RX_0 Audio Mixer MultiMedia1' 1
numid=216,iface=MIXER,name='WSA2_CODEC_DMA_RX_0 Audio Mixer MultiMedia1'
; type=BOOLEAN,access=rw------,values=2
: values=on,off
```
When playing sound, it just timeouts, no printed errors:
```
# speaker-test -D plughw:0,0 -c 2
speaker-test 1.2.14
Playback device is plughw:0,0
Stream parameters are 48000Hz, S16_LE, 2 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 960 to 130560
Period size range from 480 to 16320
Periods = 4
was set period_size = 12000
was set buffer_size = 48000
0 - Front Left
Write error: -5,Input/output error
xrun_recovery failed: -5,Input/output error
Transfer failed: Input/output error
```
Neil
>
> --srini
>>
>> Thanks,
>> Neil
>>
>>>
>>>
>>>> Setting only the WSA2 upper bits is perfectly valid and
>>>> functional but the current Audioreach code builds the bitmask
>>>> from the channels count with:
>>>> active_channels_mask = (1 << num_channels) - 1;
>>>>
>>>> In order to enable the WSA2 bits the channel count should be 4,
>>>> but the lower WSA bits are then also enabled and the DSP errors
>>>> out when trying to play on the disabled WSA interface.
>>>>
>>>> A solution would've been to add a fake WSA2 topology element which
>>>> would be translated into the top bits only, but it's not clean and
>>>> add some special exceptions in the generic Audioreach code.
>>>>
>>>> The solution suggested by Srinivas is to use the channel mapping to
>>>> set this bitmask.
>>>>
>>>> This works but makes all the other calls using the channel mapping fail
>>>> because the DSP requires the channel_mapping table to start from index 0
>>>> and using num_channel length in order to apply the mapping on the
>>>> active_channels_mask bits in order.
>>>>
>>>> So we need to skip the empty channel mapping entries in all other
>>>> users of the channel_map to build valid channel_mapping tables.
>>>>
>>>> This should not break any other usecases since the default channel
>>>> mapping always start from index 0, and will add flexibilty to allow
>>>> some special non linear mapping for other interfaces as well.
>>>>
>>>> Suggested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>>>> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
>>>> ---
>>>> sound/soc/qcom/qdsp6/audioreach.c | 47 ++++++++++++++++++++++++++++
>>>> ++---------
>>>> 1 file changed, 37 insertions(+), 10 deletions(-)
>>>>
>>>> diff --git a/sound/soc/qcom/qdsp6/audioreach.c b/sound/soc/qcom/
>>>> qdsp6/audioreach.c
>>>> index a13f753eff98..9b80cfa56e8a 100644
>>>> --- a/sound/soc/qcom/qdsp6/audioreach.c
>>>> +++ b/sound/soc/qcom/qdsp6/audioreach.c
>>>> @@ -703,6 +703,7 @@ static int
>>>> audioreach_codec_dma_set_media_format(struct q6apm_graph *graph,
>>>> int pm_sz = APM_HW_EP_PMODE_CFG_PSIZE;
>>>> int size = ic_sz + ep_sz + fs_sz + pm_sz;
>>>> void *p;
>>>> + int i;
>>>> struct gpr_pkt *pkt __free(kfree) =
>>>> audioreach_alloc_apm_cmd_pkt(size, APM_CMD_SET_CFG, 0);
>>>> if (IS_ERR(pkt))
>>>> @@ -741,7 +742,12 @@ static int
>>>> audioreach_codec_dma_set_media_format(struct q6apm_graph *graph,
>>>> intf_cfg->cfg.lpaif_type = module->hw_interface_type;
>>>> intf_cfg->cfg.intf_index = module->hw_interface_idx;
>>>> - intf_cfg->cfg.active_channels_mask = (1 << cfg->num_channels) - 1;
>>>> + intf_cfg->cfg.active_channels_mask = 0;
>>>> + /* Convert the physical channel mapping into a bit field */
>>>> + for (i = 0; i < AR_PCM_MAX_NUM_CHANNEL; i++)
>>>> + if (cfg->channel_map[i])
>>>> + intf_cfg->cfg.active_channels_mask |= BIT(i);
>>>> +
>>>
>>> This one looks good, this should be a bug fix patch.
>>>
>>>> p += ic_sz;
>>>> pm_cfg = p;
>>>> @@ -840,7 +846,7 @@ static int audioreach_mfc_set_media_format(struct
>>>> q6apm_graph *graph,
>>>> uint32_t num_channels = cfg->num_channels;
>>>> int payload_size = APM_MFC_CFG_PSIZE(media_format, num_channels) +
>>>> APM_MODULE_PARAM_DATA_SIZE;
>>>> - int i;
>>>> + int i, j;
>>>> void *p;
>>>> struct gpr_pkt *pkt __free(kfree) =
>>>> audioreach_alloc_apm_cmd_pkt(payload_size, APM_CMD_SET_CFG, 0);
>>>> @@ -860,8 +866,12 @@ static int
>>>> audioreach_mfc_set_media_format(struct q6apm_graph *graph,
>>>> media_format->sample_rate = cfg->sample_rate;
>>>> media_format->bit_width = cfg->bit_width;
>>>> media_format->num_channels = cfg->num_channels;
>>>> - for (i = 0; i < num_channels; i++)
>>>> - media_format->channel_mapping[i] = cfg->channel_map[i];
>>>> + /* Convert the physical mapping to a logical mapping of the
>>>> channels */
>>>> + for (i = 0, j = 0; i < AR_PCM_MAX_NUM_CHANNEL && j < cfg-
>>>>> num_channels; i++) {
>>>> + if (!cfg->channel_map[i])
>>>> + continue;
>>>> + media_format->channel_mapping[j++] = cfg->channel_map[i];
>>> Each element i of the channel_mapping[i] array, describes the channel i
>>> inside the buffer where i is less than num_channels. An unused channel
>>> is set to 0.
>>>
>>> For some reason I get impression that user is trying to set a 4 channels
>>> instead of 2 channel.
>>>
>>> Can you fix the backend-dai id and play it directly on WSA2 instead of
>>> WSA.
>>> Or was there a reason for not doing it otherwise?
>>>
>>> --srini
>>>
>>>> + }
>>>> return q6apm_send_cmd_sync(graph->apm, pkt, 0);
>>>> }
>>>> @@ -1080,6 +1090,7 @@ static int
>>>> audioreach_pcm_set_media_format(struct q6apm_graph *graph,
>>>> struct apm_pcm_module_media_fmt_cmd *cfg;
>>>> struct apm_module_param_data *param_data;
>>>> int payload_size;
>>>> + int i, j;
>>>> if (num_channels > 4) {
>>>> dev_err(graph->dev, "Error: Invalid channels (%d)!\n",
>>>> num_channels);
>>>> @@ -1113,7 +1124,12 @@ static int
>>>> audioreach_pcm_set_media_format(struct q6apm_graph *graph,
>>>> media_cfg->num_channels = mcfg->num_channels;
>>>> media_cfg->q_factor = mcfg->bit_width - 1;
>>>> media_cfg->bits_per_sample = mcfg->bit_width;
>>>> - memcpy(media_cfg->channel_mapping, mcfg->channel_map, mcfg-
>>>>> num_channels);
>>>> + /* Convert the physical mapping to a logical mapping of the
>>>> channels */
>>>> + for (i = 0, j = 0; i < AR_PCM_MAX_NUM_CHANNEL && j < mcfg-
>>>>> num_channels; i++) {
>>>> + if (!mcfg->channel_map[i])
>>>> + continue;
>>>> + media_cfg->channel_mapping[j++] = mcfg->channel_map[i];
>>>> + }
>>>> return q6apm_send_cmd_sync(graph->apm, pkt, 0);
>>>> }
>>>> @@ -1127,6 +1143,7 @@ static int
>>>> audioreach_shmem_set_media_format(struct q6apm_graph *graph,
>>>> struct payload_media_fmt_pcm *cfg;
>>>> struct media_format *header;
>>>> int rc, payload_size;
>>>> + int i, j;
>>>> void *p;
>>>> if (num_channels > 4) {
>>>> @@ -1166,7 +1183,12 @@ static int
>>>> audioreach_shmem_set_media_format(struct q6apm_graph *graph,
>>>> cfg->q_factor = mcfg->bit_width - 1;
>>>> cfg->endianness = PCM_LITTLE_ENDIAN;
>>>> cfg->num_channels = mcfg->num_channels;
>>>> - memcpy(cfg->channel_mapping, mcfg->channel_map, mcfg-
>>>>> num_channels);
>>>> + /* Convert the physical mapping to a logical mapping of the
>>>> channels */
>>>> + for (i = 0, j = 0; i < AR_PCM_MAX_NUM_CHANNEL && j < cfg-
>>>>> num_channels; i++) {
>>>> + if (!mcfg->channel_map[i])
>>>> + continue;
>>>> + cfg->channel_mapping[j++] = mcfg->channel_map[i];
>>>> + }
>>>> } else {
>>>> rc = audioreach_set_compr_media_format(header, p, mcfg);
>>>> if (rc)
>>>> @@ -1243,7 +1265,7 @@ static int
>>>> audioreach_speaker_protection_vi(struct q6apm_graph *graph,
>>>> struct apm_module_sp_vi_ex_mode_cfg *ex_cfg;
>>>> int op_sz, cm_sz, ex_sz;
>>>> struct apm_module_param_data *param_data;
>>>> - int rc, i, payload_size;
>>>> + int rc, i, payload_size, j;
>>>> struct gpr_pkt *pkt;
>>>> void *p;
>>>> @@ -1284,14 +1306,19 @@ static int
>>>> audioreach_speaker_protection_vi(struct q6apm_graph *graph,
>>>> param_data->param_size = cm_sz - APM_MODULE_PARAM_DATA_SIZE;
>>>> cm_cfg->cfg.num_channels = num_channels * 2;
>>>> - for (i = 0; i < num_channels; i++) {
>>>> + /* Convert the physical mapping to a logical mapping of the
>>>> channels */
>>>> + for (i = 0, j = 0; i < AR_PCM_MAX_NUM_CHANNEL && j <
>>>> num_channels; i++) {
>>>> + if (!mcfg->channel_map[i])
>>>> + continue;
>>>> /*
>>>> * Map speakers into Vsense and then Isense of each channel.
>>>> * E.g. for PCM_CHANNEL_FL and PCM_CHANNEL_FR to:
>>>> * [1, 2, 3, 4]
>>>> */
>>>> - cm_cfg->cfg.channel_mapping[2 * i] = (mcfg->channel_map[i] -
>>>> 1) * 2 + 1;
>>>> - cm_cfg->cfg.channel_mapping[2 * i + 1] = (mcfg-
>>>>> channel_map[i] - 1) * 2 + 2;
>>>> + cm_cfg->cfg.channel_mapping[2 * j] = (mcfg->channel_map[i] -
>>>> 1) * 2 + 1;
>>>> + cm_cfg->cfg.channel_mapping[2 * j + 1] = (mcfg-
>>>>> channel_map[i] - 1) * 2 + 2;
>>>> +
>>>> + ++j;
>>>> }
>>>> p += cm_sz;
>>>>
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v2 0/2] Add psci_sys_reset2 reboot modes for Qualcomm boards
From: Loic Poulain @ 2026-06-15 14:06 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Lorenzo Pieralisi, Anurag Pateriya, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Xin Liu
In-Reply-To: <9a2f95e1-f01e-4956-9e84-23f0a5f26298@oss.qualcomm.com>
On Mon, Jun 15, 2026 at 3:09 PM Shivendra Pratap
<shivendra.pratap@oss.qualcomm.com> wrote:
>
>
>
> On 12-06-2026 13:51, Lorenzo Pieralisi wrote:
> > On Wed, Jun 10, 2026 at 02:57:19PM +0200, Loic Poulain wrote:
> >> Hi Anurag,
> >>
> >> On Fri, May 29, 2026 at 4:29 PM Anurag Pateriya
> >> <anurag.pateriya@oss.qualcomm.com> wrote:
> >>>
> >>> Adding PSCI SYSTEM_RESET2 reboot-modes for sm8750 and
> >>> kaanapali based boards.
> >>
> >> I would like to highlight that when Linux/EFI is enabled, which is a
> >> common config, efi_reboot is used as the primary reboot path (see
> >> machine_restart).
>
> Yes but, only if EFI RESET RUNTIME service is enabled by UEFI.
>
> efi_reboot(...) {
> ..
> if (!efi_rt_services_supported(EFI_RT_SUPPORTED_RESET_SYSTEM))
> return;
> ..
>
> >> As a result, the PSCI reboot hook is not invoked in
> >> this scenario, assuming Qualcomm firmware provides EFI runtime
> >> services.
>
> Currently EFI RUNTIME RESET service is not enabled on these firmware.
Okay, if the EFI/firmware does not expose it or ignores the reset
call, the PSCI hook will still be reached successfully. Thanks for the
clarification.
>
> >> As a follow-up, it would therefore be beneficial to also
> >> improve the EFI path to support such custom mode(s)...
>
> Yes, and potentially linux should also have some control, if it wants to
> go via efi reset path or the PSCI reset path.
>
> thanks,
> Shivendra
>
> >
> > I have not checked but we should probably put in a place a way for user
> > space to check that PSCI is _not_ the reboot method that will be
> > used, lest it would be allowed to send commands to the kernel that
> > would be duly ignored.
> >
> > Need to go through the whole thing again before commenting any further.
> >
> > Thanks,
> > Lorenzo
> >
> >> Regards,
> >> Loic
> >>
> >>
> >>
> >>>
> >>> These DT patches depend on PSCI SYSTEM_RESET2 support introduced in:
> >>> https://lore.kernel.org/all/20260514-arm-psci-system_reset2-vendor-reboots-v22-0-28a5bde07483@oss.qualcomm.com/
> >>>
> >>> To: Bjorn Andersson <andersson@kernel.org>
> >>> To: Konrad Dybcio <konradybcio@kernel.org>
> >>> To: Rob Herring <robh@kernel.org>
> >>> To: Krzysztof Kozlowski <krzk+dt@kernel.org>
> >>> To: Conor Dooley <conor+dt@kernel.org>
> >>> Cc: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> >>> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> >>> Cc: linux-arm-msm@vger.kernel.org
> >>> Cc: devicetree@vger.kernel.org
> >>> Cc: linux-kernel@vger.kernel.org
> >>>
> >>> Signed-off-by: Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>
> >>> ---
> >>> Changes in v2:
> >>> - Fixed subject lines.
> >>> - Link to v1: https://lore.kernel.org/r/20260529-psci_sys_reset-dt-changes-for-pakala-v1-0-7c32161cf50b@oss.qualcomm.com
> >>>
> >>> ---
> >>> Anurag Pateriya (1):
> >>> arm64: dts: qcom: sm8750: add reboot-mode support
> >>>
> >>> Xin Liu (1):
> >>> arm64: dts: qcom: kaanapali: add reboot-mode support
> >>>
> >>> arch/arm64/boot/dts/qcom/kaanapali-mtp.dts | 7 +++++++
> >>> arch/arm64/boot/dts/qcom/kaanapali-qrd.dts | 7 +++++++
> >>> arch/arm64/boot/dts/qcom/kaanapali.dtsi | 2 +-
> >>> arch/arm64/boot/dts/qcom/sm8750-mtp.dts | 7 +++++++
> >>> arch/arm64/boot/dts/qcom/sm8750-qrd.dts | 7 +++++++
> >>> arch/arm64/boot/dts/qcom/sm8750.dtsi | 2 +-
> >>> 6 files changed, 30 insertions(+), 2 deletions(-)
> >>> ---
> >>> base-commit: 6ee02bbf328be8a8586487e3af73b65a906cce58
> >>> change-id: 20260529-psci_sys_reset-dt-changes-for-pakala-a09fc0e2a8a8
> >>>
> >>> Best regards,
> >>> --
> >>> Anurag Pateriya <anurag.pateriya@oss.qualcomm.com>
> >>>
> >>>
>
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Maxime Chevallier @ 2026-06-15 14:07 UTC (permalink / raw)
To: Christian Marangi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan,
Lorenzo Bianconi, Heiner Kallweit, Russell King, Saravana Kannan,
Philipp Zabel, Nathan Chancellor, Nick Desaulniers, Bill Wendling,
Justin Stitt, netdev, devicetree, linux-kernel, linux-doc,
linux-arm-kernel, linux-mediatek, llvm
In-Reply-To: <20260615122950.22281-6-ansuelsmth@gmail.com>
Hi Christian,
On 6/15/26 14:29, Christian Marangi wrote:
> Add support for late PCS provider attachment to a phylink instance.
> This works by creating a global notifier for the PCS provider and
> making each phylink instance that makes use of fwnode subscribe to
> this notifier.
>
> The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
> a new PCS provider is added.
>
> phylink will then react to this event and will call the new function
> fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
> provided by the event is present in the pcs-handle property of the
> phylink instance.
>
> If a related PCS is found, then such PCS is added to the phylink
> instance PCS list.
>
> Then we link the PCS to the phylink instance and we refresh the supported
> interfaces of the phylink instance.
>
> Finally we check if we are in a major_config_failed scenario and trigger
> an interface reconfiguration in the next phylink resolve.
>
> In the example scenario where the link was previously torn down due to
> removal of PCS, the link will be established again as the PCS came back
> and is now available to phylink.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
[...]
> @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
> if (pl->link_gpio)
> gpiod_put(pl->link_gpio);
>
> + /* Unregister notifier for late PCS attach */
> + if (pl->fwnode_pcs_nb.notifier_call)
> + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
I wanted to try this out, but I get :
drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| register_fwnode_pcs_notifier
I guess you either need to stub this, or there's a missing Kconfig
dependency somewhere
Maxime
^ permalink raw reply
* Re: [PATCH v2 3/5] arm64: dts: renesas: r9a09g087: Add VSPD and FCPVD nodes
From: sashiko-bot @ 2026-06-15 14:09 UTC (permalink / raw)
To: Prabhakar; +Cc: wsa+renesas, conor+dt, robh, devicetree
In-Reply-To: <20260615115455.1412098-4-prabhakar.mahadev-lad.rj@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Missing strictly required 'resets' property in vspd and fcpvd nodes prevents driver probing.
- [Low] Undeclared clock macro `R9A09G087_LCDC_CLKD` causes dtc compilation failure.
- [Low] Undocumented compatibles 'renesas,r9a09g087-fcpvd' and 'renesas,r9a09g087-vsp2' trigger cascading schema validation failures.
--
commit bbd19abf3f870d8f56a21516f41a6bb33f488901
Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
arm64: dts: renesas: r9a09g087: Add VSPD and FCPVD nodes
Add VSPD and FCPVD nodes to RZ/N2H SoC DTSI.
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> index f697e9698ed39..cb2eabe3242e0 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r9a09g087.dtsi
> @@ -1271,6 +1271,28 @@ sdhi1_vqmmc: vqmmc-regulator {
> status = "disabled";
> };
> };
> +
> + fcpvd: fcp@920d0000 {
> + compatible = "renesas,r9a09g087-fcpvd", "renesas,fcpv";
[Severity: Low]
Are these new compatible strings documented in the bindings?
If renesas,r9a09g087-fcpvd is missing from the renesas,fcp.yaml schema,
dtbs_check might fall back to default rules (such as enforcing a single item
for clocks) and trigger cascading validation failures for the rest of this
node.
> + reg = <0 0x920d0000 0 0x10000>;
[Severity: High]
Does this hardware block require a resets property to function?
The device tree binding schemas strictly require a resets property for fcpv.
Without it, driver initialization might fail or be unable to reset the hardware.
> + clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> + <&cpg CPG_MOD 1204>,
> + <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;
[Severity: Low]
Could this cause a compilation failure when building the device tree?
The R9A09G087_LCDC_CLKD macro does not appear to be defined in the clock
bindings header or elsewhere in the kernel tree. This usually results in a dtc
undeclared identifier error during compilation.
> + clock-names = "aclk", "pclk", "vclk";
> + power-domains = <&cpg>;
> + };
> +
> + vspd: vsp@920e0000 {
> + compatible = "renesas,r9a09g087-vsp2", "renesas,r9a07g044-vsp2";
[Severity: Low]
Is renesas,r9a09g087-vsp2 documented in the renesas,vsp1.yaml schema?
Like the fcpvd node, an undocumented compatible string here might cause
dtbs_check validation failures.
> + reg = <0 0x920e0000 0 0x8000>;
> + interrupts = <GIC_SPI 780 IRQ_TYPE_LEVEL_HIGH>;
[Severity: High]
Will the vsp1 driver fail to probe here?
Looking at drivers/media/platform/renesas/vsp1/vsp1_drv.c, vsp1_probe() calls
devm_reset_control_get_shared() unconditionally. This will return -ENOENT if
the resets property is omitted from the device tree node.
Does this node need a resets property to prevent the probe from aborting?
> + clocks = <&cpg CPG_CORE R9A09G087_CLK_PCLKAH>,
> + <&cpg CPG_MOD 1204>,
> + <&cpg CPG_CORE R9A09G087_LCDC_CLKD>;
[Severity: Low]
Will this also fail to compile due to the undeclared R9A09G087_LCDC_CLKD
identifier?
> + clock-names = "aclk", "pclk", "vclk";
> + power-domains = <&cpg>;
> + renesas,fcp = <&fcpvd>;
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615115455.1412098-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=3
^ permalink raw reply
* Re: [PATCH net-next v7 05/12] net: phylink: support late PCS provider attach
From: Christian Marangi @ 2026-06-15 14:10 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Simon Horman, Jonathan Corbet, Shuah Khan, Lorenzo Bianconi,
Heiner Kallweit, Russell King, Saravana Kannan, Philipp Zabel,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
netdev, devicetree, linux-kernel, linux-doc, linux-arm-kernel,
linux-mediatek, llvm
In-Reply-To: <867a39de-ccc2-4dcf-be24-ab2542d20ab6@bootlin.com>
On Mon, Jun 15, 2026 at 04:07:03PM +0200, Maxime Chevallier wrote:
> Hi Christian,
>
> On 6/15/26 14:29, Christian Marangi wrote:
> > Add support for late PCS provider attachment to a phylink instance.
> > This works by creating a global notifier for the PCS provider and
> > making each phylink instance that makes use of fwnode subscribe to
> > this notifier.
> >
> > The PCS notifier will emit the event FWNODE_PCS_PROVIDER_ADD every time
> > a new PCS provider is added.
> >
> > phylink will then react to this event and will call the new function
> > fwnode_phylink_pcs_get_from_fwnode() that will check if the PCS fwnode
> > provided by the event is present in the pcs-handle property of the
> > phylink instance.
> >
> > If a related PCS is found, then such PCS is added to the phylink
> > instance PCS list.
> >
> > Then we link the PCS to the phylink instance and we refresh the supported
> > interfaces of the phylink instance.
> >
> > Finally we check if we are in a major_config_failed scenario and trigger
> > an interface reconfiguration in the next phylink resolve.
> >
> > In the example scenario where the link was previously torn down due to
> > removal of PCS, the link will be established again as the PCS came back
> > and is now available to phylink.
> >
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
>
> [...]
>
> > @@ -2151,6 +2204,10 @@ void phylink_destroy(struct phylink *pl)
> > if (pl->link_gpio)
> > gpiod_put(pl->link_gpio);
> >
> > + /* Unregister notifier for late PCS attach */
> > + if (pl->fwnode_pcs_nb.notifier_call)
> > + unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
>
> I wanted to try this out, but I get :
>
> drivers/net/phy/phylink.c:2218:17: error: implicit declaration of function ‘unregister_fwnode_pcs_notifier’; did you mean ‘register_fwnode_pcs_notifier’? [-Werror=implicit-function-declaration]
> 2218 | unregister_fwnode_pcs_notifier(&pl->fwnode_pcs_nb);
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> | register_fwnode_pcs_notifier
>
> I guess you either need to stub this, or there's a missing Kconfig
> dependency somewhere
>
Hi yes if you want toi test just enable CONFIG_FWNODE_PCS. I forgot to add
the static declaration for unregister_fwnode_pcs_notifier.
--
Ansuel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox