* Re: [PATCH 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: Conor Dooley @ 2026-06-26 15:57 UTC (permalink / raw)
To: Gregor Herburger
Cc: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20260626-rpi-tryboot-v1-2-490b1c4c4970@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
On Fri, Jun 26, 2026 at 09:35:05AM +0200, Gregor Herburger wrote:
> The Raspberry Pi firmware allows to set a reboot mode called tryboot
> that allows to try booting from a different partition to allow updating
> of the boot partition. Allow reboot mode properties by referencing the
> reboot-mode schema.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> .../devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index 983ea80eaec97..30b490e0d9fb3 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -133,11 +133,14 @@ properties:
> required:
> - compatible
>
> +allOf:
> + - $ref: /schemas/power/reset/reboot-mode.yaml#
> +
> required:
> - compatible
> - mboxes
>
> -additionalProperties: false
> +unevaluatedProperties: false
I think you should keep additionalProperties: false and add
mode-normal: true
mode-tryboot: true
(I don't know if the latter works though, you may need to have a $ref to
uint32-array).
What you've done permits freeform reboot modes, but I think only normal
and tryboot are valid?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
From: Sudeep Holla @ 2026-06-26 15:52 UTC (permalink / raw)
To: Hans de Goede
Cc: Rafael J . Wysocki, Sudeep Holla, Bjorn Andersson, Konrad Dybcio,
Srinivas Kandagatla, Krzysztof Kozlowski, Dmitry Baryshkov,
Bartosz Golaszewski, Abel Vesa, linux-arm-msm, devicetree,
linux-acpi
In-Reply-To: <20260623145225.143218-1-johannes.goede@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 04:52:13PM +0200, Hans de Goede wrote:
> Hi All,
>
> Currently as soon as the kernel boots with a populated DT provided then
> the arch/arm64 code sets acpi_disabled=1 and the complete ACPI subsystem
> gets disabled. On WoA Snapdragon laptops where the factory Windows OS
> actually boots using these tables this is not necessarily desirable.
>
I am bit lost reading the very first statement here.
Who is populating DT and why ? It seems that is the source of the problem.
If windows can boot with ACPI tables, why is it causing issues for the
Linux kernel, any specifics?
IOW why is DT populated which creates the problem you are trying to address
here.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-26 15:49 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <c1ac3ab4-f214-4947-b42f-cbc635be6bbb@oss.qualcomm.com>
On Fri, Jun 26, 2026 at 08:09:58PM +0800, Jie Gan wrote:
[...]
> I have another proposal: what if we allocate the ATID in trace_noc_id() when
> the device does not already have a valid ATID?
>
> Possible scenarios:
>
> If the itnoc device is connected to a TPDM device (which has no ATID),
> trace_noc_id() will be invoked via coresight_path_assign_trace_id(), and a
> valid ATID can be allocated for the path.
>
> If the itnoc device is connected to sources other than TPDM, trace_noc_id()
> will never be invoked, and therefore no ATID will be allocated for the
> device, saving resources.
TBH, I'm not sure I can make a judgement here, as I don't have enough
knowledge of the topology. And I'm not sure whether the listed
connections cover all possible cases.
I also found commit 5799dee92dc2:
| This patch adds platform driver support for the CoreSight Interconnect
| TNOC, Interconnect TNOC is a CoreSight link that forwards trace data
| from a subsystem to the Aggregator TNOC. Compared to Aggregator TNOC,
| it does not have aggregation and ATID functionality.
With your proposal, wouldn't ATID be allocated for the interconnect
TNOC while being skipped for the Aggregator TNOC? That seems to
contradict the commit log.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v2 7/8] dt-bindings: riscv: Add generic CBQRI controller binding
From: Conor Dooley @ 2026-06-26 15:44 UTC (permalink / raw)
To: Drew Fustini
Cc: Adrien Ricciardi, Alexandre Ghiti, Atish Kumar Patra, Atish Patra,
Babu Moger, Ben Horgan, Borislav Petkov, Chen Pei, Conor Dooley,
Conor Dooley, Dave Hansen, Dave Martin, Fenghua Yu, Gong Shuai,
Gong Shuai, guo.wenjia23, James Morse, Kornel Dulęba,
Krzysztof Kozlowski, liu.qingtao2, Liu Zhiwei, Palmer Dabbelt,
Paul Walmsley, Peter Newman, Radim Krčmář,
Reinette Chatre, Rob Herring, Samuel Holland,
Sebastian Andrzej Siewior, Tony Luck, Vasudevan Srinivasan,
Ved Shanbhogue, Weiwei Li, yunhui cui, linux-kernel, linux-riscv,
x86, devicetree, linux-rt-devel, linux-doc
In-Reply-To: <aj1_0AnIBk8_xoDd@gen8>
[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]
On Thu, Jun 25, 2026 at 12:21:52PM -0700, Drew Fustini wrote:
> On Thu, Jun 25, 2026 at 05:19:28PM +0100, Conor Dooley wrote:
> > On Wed, Jun 24, 2026 at 06:38:35PM -0700, Drew Fustini wrote:
> > > Document the generic compatibles for capacity and bandwidth controllers
> > > that implement the RISC-V CBQRI specification. The binding also
> > > describes the common riscv,cbqri-rcid and riscv,cbqri-mcid properties,
> > > and the optional riscv,cbqri-cache phandle that links a capacity
> > > controller to the cache whose capacity it allocates.
> > >
> > > Assisted-by: Claude:claude-opus-4-8
> > > Co-developed-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > > Signed-off-by: Adrien Ricciardi <aricciardi@baylibre.com>
> > > Signed-off-by: Drew Fustini <fustini@kernel.org>
> > > ---
> > > .../devicetree/bindings/riscv/riscv,cbqri.yaml | 97 ++++++++++++++++++++++
> > > MAINTAINERS | 1 +
> > > 2 files changed, 98 insertions(+)
>
> Thanks for the review.
>
> [..]
> > > +properties:
> > > + compatible:
> > > + oneOf:
> > > + - items:
> > > + - description: Tenstorrent Ascalon Shared Cache
> > > + const: tenstorrent,ascalon-sc-cbqri
> > > + - const: riscv,cbqri-capacity-controller
> > > + - enum:
> > > + - riscv,cbqri-capacity-controller
> > > + - riscv,cbqri-bandwidth-controller
> >
> > Please modify this, as has been done for other riscv spec related
> > bindings, to let people get away without using device-specific
> > compatibles.
> >
> > In this case, you can just delete the first entry from this enum, since
> > it already has a user and only have to implement this feedback for the
> > second entry.
>
> Would this work?
>
> properties:
> compatible:
> oneOf:
> - items:
> - enum:
> - tenstorrent,ascalon-sc-cbqri # Tenstorrent Ascalon Shared Cache
> - const: riscv,cbqri-capacity-controller
> - items:
> - {}
> - const: riscv,cbqri-bandwidth-controller
Should do, yes. I question the need for a comment though, seems pretty
evident from the compatible what it is.
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > +
> > > +allOf:
> > > + - if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + const: tenstorrent,ascalon-sc-cbqri
> > > + then:
> > > + required:
> > > + - riscv,cbqri-rcid
> > > + - riscv,cbqri-cache
> > > +
> > > +additionalProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + l2_cache: l2-cache {
> > > + compatible = "cache";
> > > + cache-level = <2>;
> > > + cache-unified;
> > > + cache-size = <0xc00000>;
> > > + cache-sets = <512>;
> > > + cache-block-size = <64>;
> > > + };
> > > +
> > > + cache-controller@a21a00c0 {
> > > + compatible = "tenstorrent,ascalon-sc-cbqri",
> > > + "riscv,cbqri-capacity-controller";
> >
> > Is this or is this not a cache controller?
> > The compatible and fact that the property points to an actual cache
> > controller suggests that this is not.
>
> Good point. This nodes represents just the QoS interface (CBQRI) and
> should not use that node name. 'qos-controller' seems like it would be
> more appropriate but that has no precedent. What do you think?
Sure.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: glymur: Add label properties to CoreSight devices
From: Konrad Dybcio @ 2026-06-26 15:40 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260624-add-label-node-for-glymur-v2-1-e8420fd7025f@oss.qualcomm.com>
On 6/24/26 2:38 PM, Jie Gan wrote:
> Add label properties to TPDM and CTI nodes in the glymur device tree to
> provide human-readable identifiers for each CoreSight device. These
> labels allow userspace tools and the CoreSight framework to identify
> devices by name rather than by base address.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: tegra: Add lenovo,thinkedge-se70 compatible string
From: Conor Dooley @ 2026-06-26 15:36 UTC (permalink / raw)
To: Jiqi Li
Cc: linux-tegra, devicetree, robh+dt, krzk+dt, conor+dt, jonathanh,
thierry.reding, mpearson-lenovo
In-Reply-To: <20260626105625.600156-2-lijq9@lenovo.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: gpu: img,powervr-*: Add maintainer entries
From: Conor Dooley @ 2026-06-26 15:34 UTC (permalink / raw)
To: Matt Coster
Cc: imagination, linux-kernel, Alessio Belle, Luigi Santivetti,
Frank Binns, Brajesh Gupta, Alexandru Dadu, dri-devel, devicetree
In-Reply-To: <20260626-maintainer-updates-v2-3-e1b3f246c44c@imgtec.com>
[-- Attachment #1: Type: text/plain, Size: 82 bytes --]
\x02
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode
From: Konrad Dybcio @ 2026-06-26 15:34 UTC (permalink / raw)
To: Mukesh Savaliya, Pengyu Luo, Dmitry Baryshkov
Cc: Mark Brown, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andy Gross, Bjorn Andersson, linux-arm-msm, linux-spi, devicetree,
linux-kernel
In-Reply-To: <14491fd8-f785-4404-878b-5764bb8fd593@oss.qualcomm.com>
On 6/25/26 11:06 AM, Mukesh Savaliya wrote:
> Hi Konrad, sorry for late response.
>
> On 6/15/2026 5:12 PM, Konrad Dybcio wrote:
>> On 6/15/26 6:25 AM, Pengyu Luo wrote:
>>> On Mon, Jun 15, 2026 at 5:18 AM Dmitry Baryshkov
>>> <dmitry.baryshkov@oss.qualcomm.com> wrote:
>>>>
>>>> On Sun, Jun 14, 2026 at 04:34:24PM +0800, Pengyu Luo wrote:
>>>>> Some devices (such as gaokun3) do not disable FIFO mode, causing the
>>>>> driver to fallback to FIFO mode by default. However, these platforms
>>>>> also support GSI mode, which is highly preferred for certain
>>>>> peripherals like SPI touchscreens to improve performance.
>>>>>
>>>>> Introduce the "qcom,force-gsi-mode" device property to hint and force
>>>>> the controller into GSI mode during initialization.
>>>>
>>>> Ideally, this should be decided by the SPI controller based on the
>>>> requirements. Another option would be to prefer GSI for all transfers if
>>>> it is available, ignoring the FIFO even if it is not disabled.
>>>>
>>>
>>> I have read reviews. Can we check if the compatible
>>> "qcom,sm6350-gpi-dma" is in DT? If the gpi dma controller is
>>> presented, then we enable GSI mode.
>>
>>
>> This hunk is very odd:
>>
>> /*
>> * in case of failure to get gpi dma channel, we can still do the
>> * FIFO mode, so fallthrough
>> */
>> dev_warn(mas->dev, "FIFO mode disabled, but couldn't get DMA, fall back to FIFO mode\n");
>>
>> In my understanding, GSI DMA mode is always preferable. +Mukesh, do
>> you have any insights?
>>
> GSI mode is preferable but if for some reason it fails, we try to continue with the FIFO mode. Just fallback mechanism.
So, would making GSI the default and FIFO the fallback option
sound good?
Konrad
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-26 15:32 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Conor Dooley, Joey Lu, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <9456bde5059bea3aac1ed64355e3f017dd9bd3e5.camel@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
On Fri, Jun 26, 2026 at 05:33:26PM +0800, Icenowy Zheng wrote:
> > > >
> > > > > > > +
> > > > > > > + resets:
> > > > > > > + minItems: 1
> > > > > > > + maxItems: 1
> > > > > > > +
> > > > > > > + reset-names:
> > > > > > > + items:
> > > > > > > + - const: core
> > > > > >
> > > > > > This is just maxItems: 1.
> > > > >
> > > > > Well the implicit rules of DT binding schemas are quite
> > > > > weird...
> > > >
> > > > I don't think it is that strange, as the binding has
> > > > reset-names:
> > > > items:
> > > > - const: core
> > > > - const: axi
> > > > - const: ahb
> > >
> > > Ah does the list constraint the order of items? If it constrains
> > > the
> >
> > It does, yes.
> > Alternatively, using an enum permits free ordering.
>
> Ah in this case this should be converted to an enum, I think.
>
> Should I send a patch for converting it?
Why do you think it should be an enum? We don't currently have any users
of this that only provide no core or no axi reset.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: ti: Add support for the phyCORE-AM67x
From: Nathan Morrisson @ 2026-06-26 15:29 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20260625161706.1436B1F000E9@smtp.kernel.org>
On Thu, 2026-06-25 at 16:17 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 5 potential
> issue(s) to consider:
> - [High] The PCF8574 GPIO expanders specify `IRQ_TYPE_LEVEL_LOW`,
> which is unsupported by the K3 GPIO controller and will cause probe
> failure.
> - [Medium] The `reset-gpios` for `pcie0_rc` is specified as
> `GPIO_ACTIVE_HIGH`, which inverses the standard PCIe PERST# active-
> low logic.
> - [Medium] Mismatch between `mcasp1` serializer configuration and its
> pin multiplexing: AXR2 is configured for RX but is not pinned out.
> - [Medium] Button 'key-menu' connected to PCF8574 uses
> GPIO_ACTIVE_HIGH, causing inverted logic.
> - [Low] Typo in the micbias voltage property for the `tlv320aic3110`
> audio codec.
> --
>
> commit 736b51d7a471b4b2aa4f1281a1e87be6e988051c
> Author: Nathan Morrisson <nmorrisson@phytec.com>
>
> arm64: dts: ti: Add support for the phyCORE-AM67x
>
> Add support for the PHYTEC phyCORE-AM67x SoM and the corresponding
> phyBOARD-Rigel carrier board. The phyCORE-AM67x SoM uses the TI AM67x
> SoC
> and can come with different sizes and models of DDR, eMMC, and SPI
> NOR
> Flash.
>
> Link:
> https://www.phytec.com/product/phycore-am67x/
> Link:
> https://www.phytec.com/product/phyboard-am67x-development-kit/
>
> > diff --git a/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
> > b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
> > new file mode 100644
> > index 0000000000000..7853d4f5d3b95
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
> [ ... ]
> > + keys {
> > + compatible = "gpio-keys";
> > + autorepeat;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&gpio_keys_pins_default>;
> [ ... ]
> > + key-menu {
> > + label = "menu";
> > + linux,code = <KEY_MENU>;
> > + gpios = <&gpio_exp1 4 GPIO_ACTIVE_HIGH>;
>
> [Severity: Medium]
> Does this configuration cause the button to register as permanently
> pressed?
We have an inverter on this line, so the button works correctly as
active high.
>
> The key-menu button is connected to gpio_exp1, which is a PCF8574
> expander.
> These pins have internal weak pull-ups, meaning their default resting
> state
> is HIGH, and buttons typically pull them to GND (LOW). Specifying
> GPIO_ACTIVE_HIGH inverses the logical state unless a strong external
> pull-down resistor is present.
>
> > + };
> > + };
> [ ... ]
> > +&main_pmx0 {
> [ ... ]
> > + main_mcasp1_pins_default: main-mcasp1-default-pins {
> > + pinctrl-single,pins = <
> > + J722S_IOPAD(0x0090, PIN_INPUT, 2) /*
> > (P27) GPMC0_BE0n_CLE.MCASP1_ACLKX */
> > + J722S_IOPAD(0x0098, PIN_INPUT, 2) /*
> > (V21) GPMC0_WAIT0.MCASP1_AFSX */
> > + J722S_IOPAD(0x008c, PIN_OUTPUT, 2) /*
> > (N23) GPMC0_WEn.MCASP1_AXR0 */
> > + >;
> > + };
>
> [Severity: Medium]
> Will audio capture on the mcasp1 interface fail here because the data
> pin
> is not connected?
mcasp1 is not connected to this audio codec. mcasp1 is used for HDMI on
this board, but HDMI is not yet supported in this version of the
kernel. I will remove mcasp1 in the next version of my patch as there
is no reason for it to be included yet.
>
> The mcasp1 node below configures serial-dir index 2 to RX, enabling
> MCASP1_AXR2. However, the corresponding pin configuration for
> MCASP1_AXR2
> is missing from main_mcasp1_pins_default. The pin remains in its
> default
> state, meaning the controller receives no data.
>
> [ ... ]
> > +&main_i2c1 {
> [ ... ]
> > + audio_codec: audio-codec@18 {
> > + compatible = "ti,tlv320aic3110";
> > + reg = <0x18>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&audio_ext_refclk1_pins_default>;
> > + #sound-dai-cells = <0>;
> > + ai3xx-micbias-vg = <2>;
>
> [Severity: Low]
> Is there a typo in the micbias voltage property name?
Will fix in v2.
>
> The ti,tlv320aic3110 codec driver expects the property ai31xx-
> micbias-vg.
> Using ai3xx-micbias-vg causes the driver to ignore this configuration
> and
> fall back to the default 2.0V bias, which could cause incorrect
> microphone
> gain or distortion.
>
> > + reset-gpios = <&gpio_exp1 7 GPIO_ACTIVE_LOW>;
> [ ... ]
> > + gpio_exp0: gpio@20 {
> > + compatible = "nxp,pcf8574";
> > + reg = <0x20>;
> > + gpio-controller;
> > + #gpio-cells = <2>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&gpio_exp0_int_pins_default>;
> > + interrupt-parent = <&main_gpio0>;
> > + interrupts = <21 IRQ_TYPE_LEVEL_LOW>;
>
> [Severity: High]
> Will this expander fail to probe due to an unsupported interrupt
> type?
Will change to IRQ_TYPE_EDGE_FALLING in v2.
>
> The K3 GPIO controller driver (gpio-davinci.c) strictly supports only
> edge-triggered interrupts and returns -EINVAL for level types in its
> irq_set_type callback. This would prevent the expanders and all
> attached
> devices from probing.
>
> > + gpio-line-names = "CSI3_STROBE", "CSI3_TRIGGER",
> [ ... ]
> > +&pcie0_rc {
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&main_pcie_pins_default>;
> > + num-lanes = <1>;
> > + phys = <&serdes1_pcie_link>;
> > + phy-names = "pcie-phy";
> > + reset-gpios = <&main_gpio0 31 GPIO_ACTIVE_HIGH>;
>
> [Severity: Medium]
> Could this cause the PCIe endpoint to fail enumeration by keeping the
> reset line asserted?
This signal is inverted so it functions normally with the active high
reset.
Regards,
Nathan
>
> The standard PCIe PERST# signal is active-low. Specifying
> GPIO_ACTIVE_HIGH
> causes the host controller to invert this logic, driving the line
> high when
> it intends to assert reset, and low when it releases it. Unless the
> board
> has a physical inverter on this line, the endpoint will remain in
> reset.
>
> > + status = "okay";
> > +};
>
^ permalink raw reply
* Re: [PATCH v4 4/4] spi: qcom-geni: Enable SPI on SA8255p Qualcomm platforms
From: Konrad Dybcio @ 2026-06-26 15:29 UTC (permalink / raw)
To: Praveen Talari, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, bjorn.andersson
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
mukesh.savaliya, aniket.randive, chandana.chiluveru,
jyothi.seerapu, chiluka.harish
In-Reply-To: <20260618-enable-spi-on-sa8255p-v4-4-f5b5067e7e1e@oss.qualcomm.com>
On 6/18/26 11:06 AM, Praveen Talari wrote:
> The Qualcomm automotive SA8255p SoC relies on firmware to configure
> platform resources, including clocks, interconnects and TLMM.
> The driver requests resources operations over SCMI using power
> and performance protocols.
>
> The SCMI power protocol enables or disables resources like clocks,
> interconnect paths, and TLMM (GPIOs) using runtime PM framework APIs,
> such as resume/suspend, to control power states(on/off).
>
> The SCMI performance protocol manages SPI frequency, with each
> frequency rate represented by a performance level. The driver uses
> geni_se_set_perf_opp() API to request the desired frequency rate.
>
> As part of geni_se_set_perf_opp(), the OPP for the requested frequency
> is obtained using dev_pm_opp_find_freq_floor() and the performance
> level is set using dev_pm_opp_set_opp().
>
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sc8280xp: Fix DWC3 core register size
From: Konrad Dybcio @ 2026-06-26 15:21 UTC (permalink / raw)
To: Xilin Wu, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johan Hovold, Krishna Kurapati
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel,
stable
In-Reply-To: <20260626-sc8280xp-fix-dwc3-reg-size-v1-1-ddcba897b19d@radxa.com>
On 6/26/26 5:07 PM, Xilin Wu wrote:
> The SC8280XP DWC3 core register regions are currently described as 0xcd00
> bytes, but the hardware register block extends further. In particular, the
> DWC_usb31 LLUCTL registers start at 0xd024 and are accessed by the DWC3
> driver when a controller is limited to SuperSpeed using
> maximum-speed = "super-speed".
>
> With the shorter resource, probing such a controller can fault when the
> driver programs LLUCTL.FORCE_GEN1. Use the correct 0xd950-byte register
> size for all SC8280XP DWC3 core instances.
>
> Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
> Fixes: 3170a2c906c6 ("arm64: dts: qcom: sc8280xp: Add USB DWC3 Multiport controller")
> Cc: stable@vger.kernel.org
> Signed-off-by: Xilin Wu <sophon@radxa.com>
> ---
> arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> index a2bd6b10e475..d06f79b7680c 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
> @@ -4034,7 +4034,7 @@ usb_2: usb@a4f8800 {
>
> usb_2_dwc3: usb@a400000 {
> compatible = "snps,dwc3";
> - reg = <0 0x0a400000 0 0xcd00>;
> + reg = <0 0x0a400000 0 0xd950>;
Let's do 0xfc100, the QC glue driver already does out-of-bounds
accesses into the base+0xfxxx space..
Konrad
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
From: Konrad Dybcio @ 2026-06-26 15:18 UTC (permalink / raw)
To: William Bright, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-4-358e71d606bc@imd-tec.com>
On 6/10/26 10:57 AM, William Bright wrote:
> The IMDT QCS8550 SBC is a two-board design from IMD Technologies Ltd
> built around the Qualcomm QCS8550 SoC. An IMDT QCS8550 SoM is soldered
> onto the IMDT QCS8550 carrier board that supplies VPH_PWR and exposes
> the off-module peripherals.
[...]
> + /* Enables 5V_PER, 3V3_PER and 1V8_PER rails. These rails
> + * aren't used by anything within the device-tree but are used
> + * for on board logic level conversion and as rails for
> + * pull-ups.
> + */
> + per_pwr: regulator-per-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "per_pwr";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwr_per_en_default>;
style nit:
property-n
property-names
file-wide
[...]
> +&apps_rsc {
> + regulators-0 {
This way of overriding that is super shaky - instead, use a label,
like:
--- som.dtsi
pm8550_rpmh_regulators: regulators-0 {
...
--- sbc.dts
&pm8550_rpmh_regulators {
foo = bar;
};
[...]
> +&gpu_zap_shader {
> + firmware-name = "qcom/sm8550/a740_zap.mbn";
> + /* Zap shader doesn't load so is disabled */
If your SoC is production fused, you must provide your own ZAP firmware
that's signed by you. Conversely, if you have a software stack that
does not include the Gunyah hypervisor, this is likely not necessary
> + status = "disabled";
> +};
> +
> +&i2c_master_hub_0 {
> + status = "okay";
> +};
> +
> +&i2c_hub_2 {
> + clock-frequency = <400000>;
> + status = "okay";
nit: let's keep a \n before status, everywhere
[...]
> +&pcie0 {
> + wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
> + perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
> +
> + /*
> + * pcie0 hosts the M.2 Key-E slot. Apply the SDIO
> + * reset de-assert here so any module's chip enable is settled
> + * before pcie0 trains its link.
> + */
We now have:
Documentation/devicetree/bindings/connector/pcie-m2-e-connector.yaml
which may come in useful here
[...]
> +&pcie1 {
> + wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
> + perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
> +
> + /*
> + * pcie_switch_sel_default and gbe_reset_default are board-init
> + * lines that must be stable before pcie1 trains its link: the
> + * PCIe switch needs its mode-select strap settled, and the
> + * downstream LAN743x must be out of reset to enumerate.
> + * Applying them via pcie1's pinctrl-0 fires them during
> + * qcom-pcie probe, before bus enumeration.
> + */
> + pinctrl-0 = <&pcie1_default_state>,
> + <&pcie_switch_sel_default>,
> + <&gbe_reset_default>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +};
[...]
> + pwr_per_en_default: pwr-per-en-default-state {
> + pwr-per-en-pins {
> + pins = "gpio142";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + };
> + };
For single-group pin state definitions, you can skip the inner
level and define the properties directly under the -state {} node
> +
> + sd_vset_default: sd-vset-default-state {
> + sd-vset-pins {
> + pins = "gpio4";
> + function = "gpio";
> + drive-strength = <16>;
> + bias-disable;
> + };
> + };
> +
> + /*
> + * Drive LAN743x reset high (de-asserted) when pcie1 probes,
> + * so the PHY enumerates on the bus.
> + */
> + gbe_reset_default: gbe-reset-default-state {
> + pins = "gpio138";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + output-high;
> + };
> +
> + /*
> + * We drive this GPIO physically high on the M2 Key-E connector
> + * to make sure the module is enabled. An M2 Key-E module could
> + * be using this pin as a chip enable.
> + */
> + m2e_sdio_resetn_default: m2e-sdio-resetn-default-state {
> + pins = "gpio41";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + output-high;
> + };
> +
> + /* Force the on-board PCIe switch to select the GbE upstream
> + * port.
> + */
> + pcie_switch_sel_default: pcie-switch-sel-default-state {
> + pins = "gpio16";
> + function = "gpio";
> + drive-strength = <2>;
> + bias-disable;
> + output-low;
> + };
Normally this would be handled via an actual driver - see e.g.
Documentation/devicetree/bindings/pci/toshiba,tc9563.yaml
https://lore.kernel.org/linux-arm-msm/20260605010022.968612-1-elder@riscstar.com/
Konrad
> +};
> +
> +&uart7 {
> + status = "okay";
> +};
> +
> +&ufs_mem_hc {
> + reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
> +
> + vcc-supply = <&vreg_l17b_2p5>;
> + vcc-max-microamp = <1300000>;
> + vccq-supply = <&vreg_l1g_1p2>;
> + vccq-max-microamp = <1200000>;
> + vdd-hba-supply = <&vreg_l3g_1p2>;
> +
> + status = "okay";
> +};
> +
> +&ufs_mem_phy {
> + vdda-phy-supply = <&vreg_l1d_0p88>;
> + vdda-pll-supply = <&vreg_l3e_1p2>;
> +
> + status = "okay";
> +};
> +
> +&usb_1 {
> + /delete-property/ usb-role-switch;
> + dr_mode = "peripheral";
Is it really peripheral-only?
Konrad
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-26 15:16 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Conor Dooley, Joey Lu, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <996c3d442e92e7f908fb3a32973805dd2d2680d7.camel@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 4813 bytes --]
On Fri, Jun 26, 2026 at 05:09:12PM +0800, Icenowy Zheng wrote:
> 在 2026-06-26五的 09:57 +0100，Conor Dooley写道：
> > On Fri, Jun 26, 2026 at 03:58:14PM +0800, Icenowy Zheng wrote:
> > > 在 2026-06-26五的 08:22 +0100，Conor Dooley写道：
> > > > On Thu, Jun 25, 2026 at 05:33:37PM +0100, Conor Dooley wrote:
> > > > > On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> > > > > > +
> > > > > > + - if:
> > > > > > + properties:
> > > > > > + compatible:
> > > > > > + contains:
> > > > > > + const: nuvoton,ma35d1-dcu
> > > > > > + then:
> > > > > > + properties:
> > > > > > + clocks:
> > > > > > + minItems: 2
> > > > >
> > > > > Anything that updates the minimum constraint should be done at
> > > > > the
> > > > > top
> > > > > level of this schema. The conditional section should then
> > > > > tighten
> > > > > the
> > > > > constraint, in this case that means only having maxItems.
> > > > >
> > > > > > + maxItems: 2
> > > > > > +
> > > > > > + clock-names:
> > > > > > + items:
> > > > > > + - const: core
> > > > > > + - const: pix0
> > > > >
> > > > > Does this even work when the top level schema thinks clock 2
> > > > > should
> > > > > be
> > > > > called axi?
> > > >
> > > > Additionally here, only have core and pix0 seems like it might be
> > > > an
> > > > oversimplification. I doubt removing the second output port means
> > > > that
> > > > the axi and ahb clocks are no longer needed.
> > > > Is it the case that your device supplies the same clock to core,
> > > > ahb
> > > > and
> > > > axi? If so, then you should fill those clocks in in your
> > > > devicetree
> > > > and
> > > > this can just constrain the number of clocks/clock-names to 4.
> > >
> > > The clock controller of that SoC is quite weird -- it has only a
> > > single
> > > gate bit, but controlling 3 clock gates. All core, ahb and axi
> > > clocks
> > > have gates controlled by this single bit, so it's why currently
> > > it's
> > > modelled as only core clock supplied.
> >
> > Yeah, then what's in the binding is definitely wrong.
> > Even if the same clock was provided to all clock inputs in the IP,
> > all
> > individual clock should be listed in the devicetree - although it
> > will
> > look a little silly to see clocks = <&foo 2>, <&foo 2>, <&foo 2>,
> > <&foo 2>;
> > In this case, 3 clocks controlled by 1 gate bit is an implementation
> > detail
> > of the SoC's clocking hardware, and not relevant to how the dc
> > instance
> > should be described.
> >
> > > Well it might be worthful to supply the bus clock before the gate
> > > as
> > > ahb/axi, especially axi, because both the AXI clock and the core
> > > clock
> > > constraints the maximum pixel clock.
> >
> > Right. And looking at patch 4/7, and the wording:
> > > The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller
> > > whose
> > > AXI and AHB bus clocks share a single gate enable bit with the
> > > display
> > > core clock, so the clock driver does not expose them separately.
> > > This
> > > patch makes the axi and ahb clocks optional in the probe.
> >
> > It sounds like there's probably some issues with how things are
> > modelled
> > clock wise in this device, unless this is not an accurate statement
> > and
> > there's actually one clock provided to all three inputs. If they're
> > distinct clocks, with different rates, only having one exposed has a
> > lot
> > of potential to be problematic!
>
> Yes, I agree with this, they're different clocks according to the
> manual.
>
> I added the clk people to the CC list in a reply of the previous
> revision, but they didn't react yet. I don't know how to represent
> multiple clock gates sharing a single control bit in the clock
> framework...
Yeah, I have absolutely no idea. Maybe it requires custom refcounting?
Surely this cannot be the only device that does something like this
though.
> Maybe just supplying the ungated AXI/AHB clocks here, and let the core
> clock manage the gate?
I guess, but that seems incorrect and would require commentary about why
it's being done. Feel like they (the missing axi/ahb clocks) should be
added to the clock driver and binding, and any special workarounds done
there.
Of course letting the core clock manage the gate and making the enable
method for the gated AXI/AHB clocks be a NOP is one way of handling it
in the clock driver. Still a bit of a hack compared to refcounting it,
but it makes me happier to have the correct clock tree modelled in DT.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Add PCIe PHY and controller nodes
From: Abel Vesa @ 2026-06-26 15:15 UTC (permalink / raw)
To: Krishna Chaitanya Chundru
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <a8a2c394-666c-4294-9eb1-911564a32fc7@oss.qualcomm.com>
On 26-06-26 09:46:03, Krishna Chaitanya Chundru wrote:
>
>
> On 6/25/2026 3:42 PM, Abel Vesa wrote:
> > On 26-06-10 17:40:09, Krishna Chaitanya Chundru wrote:
> >> Eliza supports two PCIe instances: one 8GT/s x1 (PCIe0) and one 8GT/s x2
> >> (PCIe1). Add PCIe controller and PHY nodes for both instances, and update
> >> the GCC clock references to use the newly added PHY nodes instead of
> >> placeholder zeros.
> >>
> >> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> >> ---
> >> This patch depends on https://lore.kernel.org/all/20260608-eliza-v3-0-9bdeb7434b28@oss.qualcomm.com/
> >> ---
> >> arch/arm64/boot/dts/qcom/eliza.dtsi | 359 +++++++++++++++++++++++++++++++++++-
> >> 1 file changed, 357 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
> >> index 7e97361a5dc5..2a51da62270d 100644
> >> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
> >> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
> >> @@ -610,8 +610,8 @@ gcc: clock-controller@100000 {
> >>
> >> clocks = <&bi_tcxo_div2>,
> >> <&sleep_clk>,
> >> - <0>,
> >> - <0>,
> >> + <&pcie0_phy>,
> >> + <&pcie1_phy>,
> >> <&ufs_mem_phy 0>,
> >> <&ufs_mem_phy 1>,
> >> <&ufs_mem_phy 2>,
> >> @@ -716,6 +716,361 @@ mmss_noc: interconnect@1780000 {
> >> #interconnect-cells = <2>;
> >> };
> >>
> >> + pcie0: pcie@1c00000 {
> >> + device_type = "pci";
> >> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
> >> + reg = <0 0x01c00000 0 0x3000>,
> >> + <0 0x40000000 0 0xf1d>,
> >> + <0 0x40000f20 0 0xa8>,
> >> + <0 0x40001000 0 0x1000>,
> >> + <0 0x40100000 0 0x100000>,
> >> + <0 0x01c03000 0 0x1000>;
> >> + reg-names = "parf",
> >> + "dbi",
> >> + "elbi",
> >> + "atu",
> >> + "config",
> >> + "mhi";
> >> + #address-cells = <3>;
> >> + #size-cells = <2>;
> >> + ranges = <0x01000000 0 0x00000000 0 0x40200000 0 0x100000>,
> >> + <0x02000000 0 0x40300000 0 0x40300000 0 0x3d00000>;
> >> +
> >> + interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 653 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
> >> + interrupt-names = "msi0",
> >> + "msi1",
> >> + "msi2",
> >> + "msi3",
> >> + "msi4",
> >> + "msi5",
> >> + "msi6",
> >> + "msi7",
> >> + "global";
> >> +
> >> + clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
> >> + <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
> >> + <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
> >> + <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
> >> + <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
> >> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> >> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
> >> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> >> + clock-names = "aux",
> >> + "cfg",
> >> + "bus_master",
> >> + "bus_slave",
> >> + "slave_q2a",
> >> + "ddrss_sf_tbu",
> >> + "noc_aggr",
> >> + "cnoc_sf_axi";
> >> +
> >> + resets = <&gcc GCC_PCIE_0_BCR>,
> >> + <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
> >> + reset-names = "pci",
> >> + "link_down";
> >> +
> >> + interconnects = <&pcie_noc MASTER_PCIE_0 QCOM_ICC_TAG_ALWAYS
> >> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> >> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> >> + &cnoc_main SLAVE_PCIE_0 QCOM_ICC_TAG_ACTIVE_ONLY>;
> >> + interconnect-names = "pcie-mem",
> >> + "cpu-pcie";
> >> +
> >> + power-domains = <&gcc GCC_PCIE_0_GDSC>;
> >> +
> >> + operating-points-v2 = <&pcie0_opp_table>;
> >> +
> >> + iommu-map = <0 &apps_smmu 0x1480 0x1>,
> >> + <0x100 &apps_smmu 0x1481 0x1>;
> >> +
> >> + interrupt-map = <0 0 0 1 &intc 0 0 0 564 IRQ_TYPE_LEVEL_HIGH>,
> >> + <0 0 0 2 &intc 0 0 0 565 IRQ_TYPE_LEVEL_HIGH>,
> >> + <0 0 0 3 &intc 0 0 0 566 IRQ_TYPE_LEVEL_HIGH>,
> >> + <0 0 0 4 &intc 0 0 0 567 IRQ_TYPE_LEVEL_HIGH>;
> >> + interrupt-map-mask = <0 0 0 0x7>;
> >> + #interrupt-cells = <1>;
> >> +
> >> + linux,pci-domain = <0>;
> >> + num-lanes = <1>;
> >> + bus-range = <0 0xff>;
> >> +
> >> + dma-coherent;
> >> +
> > No pinctrl states?
> >
> >> +
> >> + pcie1: pcie@1c08000 {
> >> + device_type = "pci";
> >> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
> >> + reg = <0 0x01c08000 0 0x3000>,
> >> + <0 0x44000000 0 0xf1d>,
> >> + <0 0x44000f20 0 0xa8>,
> >> + <0 0x44001000 0 0x1000>,
> >> + <0 0x44100000 0 0x100000>,
> >> + <0 0x01c0b000 0 0x1000>;
> >> + reg-names = "parf",
> >> + "dbi",
> >> + "elbi",
> >> + "atu",
> >> + "config",
> >> + "mhi";
> >> + #address-cells = <3>;
> >> + #size-cells = <2>;
> >> + ranges = <0x01000000 0 0x00000000 0 0x44200000 0 0x100000>,
> >> + <0x02000000 0 0x44300000 0 0x44300000 0 0x3d00000>;
> >> +
> >> + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
> >> + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
> >> + interrupt-names = "msi0",
> >> + "msi1",
> >> + "msi2",
> >> + "msi3",
> >> + "msi4",
> >> + "msi5",
> >> + "msi6",
> >> + "msi7",
> >> + "global";
> >> +
> >> + clocks = <&gcc GCC_PCIE_1_AUX_CLK>,
> >> + <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
> >> + <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
> >> + <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
> >> + <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>,
> >> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
> >> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
> >> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
> >> + clock-names = "aux",
> >> + "cfg",
> >> + "bus_master",
> >> + "bus_slave",
> >> + "slave_q2a",
> >> + "ddrss_sf_tbu",
> >> + "noc_aggr",
> >> + "cnoc_sf_axi";
> >> +
> >> + resets = <&gcc GCC_PCIE_1_BCR>,
> >> + <&gcc GCC_PCIE_1_LINK_DOWN_BCR>;
> >> + reset-names = "pci",
> >> + "link_down";
> >> +
> >> + interconnects = <&pcie_noc MASTER_PCIE_1 QCOM_ICC_TAG_ALWAYS
> >> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> >> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> >> + &cnoc_main SLAVE_PCIE_1 QCOM_ICC_TAG_ACTIVE_ONLY>;
> >> + interconnect-names = "pcie-mem",
> >> + "cpu-pcie";
> >> +
> >> + power-domains = <&gcc GCC_PCIE_1_GDSC>;
> >> +
> >> + operating-points-v2 = <&pcie1_opp_table>;
> >> +
> >> + iommu-map = <0 &apps_smmu 0x1400 0x1>,
> >> + <0x100 &apps_smmu 0x1401 0x1>;
> >> +
> >> + interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>,
> >> + <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>,
> >> + <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>,
> >> + <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>;
> >> + interrupt-map-mask = <0 0 0 0x7>;
> >> + #interrupt-cells = <1>;
> >> +
> >> + linux,pci-domain = <1>;
> >> + num-lanes = <2>;
> >> + bus-range = <0 0xff>;
> >> +
> >> + dma-coherent;
> > No pinctrl states?
> As we are adding perst & wake gpio's in board specific file, it is better to
> add the pincntrl also
> there only.
I'll let Bjorn and Konrad reply, but most of the sm8*50.dtsi have
them. Though some of the newer platforms moved them in the board dts.
^ permalink raw reply
* Re: [PATCH v4 3/4] arm64: dts: qcom: Add IMDT QCS8550 SoM
From: Konrad Dybcio @ 2026-06-26 15:08 UTC (permalink / raw)
To: William Bright, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-3-358e71d606bc@imd-tec.com>
On 6/10/26 10:57 AM, William Bright wrote:
> The IMDT QCS8550 SoM is a System-on-Module from IMD Technologies Ltd
> built around the Qualcomm QCS8550 SoC. It is intended to be soldered
> onto a carrier board that supplies VPH_PWR and exposes the off-module
> peripherals.
>
> Add qcs8550-imdt-som.dtsi describing the SoM's PMICs (PM8550, PM8550VE,
> PM8550VS, PMK8550) and the apps_rsc PMIC outputs. Compared to other
> SM8550/QCS8550 boards, this SoM excludes the PM8550B charger PMIC.
>
> Assisted-by: Claude:claude-opus-4.7
> Signed-off-by: William Bright <william.bright@imd-tec.com>
> ---
[...]
> +&pm8550vs_d_gpios {
> + status = "okay";
> +};
This is already enabled by default
Konrad
^ permalink raw reply
* [PATCH] arm64: dts: qcom: sc8280xp: Fix DWC3 core register size
From: Xilin Wu @ 2026-06-26 15:07 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johan Hovold, Krishna Kurapati
Cc: Krzysztof Kozlowski, linux-arm-msm, devicetree, linux-kernel,
stable, Xilin Wu
The SC8280XP DWC3 core register regions are currently described as 0xcd00
bytes, but the hardware register block extends further. In particular, the
DWC_usb31 LLUCTL registers start at 0xd024 and are accessed by the DWC3
driver when a controller is limited to SuperSpeed using
maximum-speed = "super-speed".
With the shorter resource, probing such a controller can fault when the
driver programs LLUCTL.FORCE_GEN1. Use the correct 0xd950-byte register
size for all SC8280XP DWC3 core instances.
Fixes: 152d1faf1e2f ("arm64: dts: qcom: add SC8280XP platform")
Fixes: 3170a2c906c6 ("arm64: dts: qcom: sc8280xp: Add USB DWC3 Multiport controller")
Cc: stable@vger.kernel.org
Signed-off-by: Xilin Wu <sophon@radxa.com>
---
arch/arm64/boot/dts/qcom/sc8280xp.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
index a2bd6b10e475..d06f79b7680c 100644
--- a/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc8280xp.dtsi
@@ -4034,7 +4034,7 @@ usb_2: usb@a4f8800 {
usb_2_dwc3: usb@a400000 {
compatible = "snps,dwc3";
- reg = <0 0x0a400000 0 0xcd00>;
+ reg = <0 0x0a400000 0 0xd950>;
interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH>;
iommus = <&apps_smmu 0x800 0x0>;
phys = <&usb_2_hsphy0>, <&usb_2_qmpphy0>,
@@ -4100,7 +4100,7 @@ usb_0: usb@a6f8800 {
usb_0_dwc3: usb@a600000 {
compatible = "snps,dwc3";
- reg = <0 0x0a600000 0 0xcd00>;
+ reg = <0 0x0a600000 0 0xd950>;
interrupts = <GIC_SPI 803 IRQ_TYPE_LEVEL_HIGH>;
iommus = <&apps_smmu 0x820 0x0>;
phys = <&usb_0_hsphy>, <&usb_0_qmpphy QMP_USB43DP_USB3_PHY>;
@@ -4179,7 +4179,7 @@ usb_1: usb@a8f8800 {
usb_1_dwc3: usb@a800000 {
compatible = "snps,dwc3";
- reg = <0 0x0a800000 0 0xcd00>;
+ reg = <0 0x0a800000 0 0xd950>;
interrupts = <GIC_SPI 810 IRQ_TYPE_LEVEL_HIGH>;
iommus = <&apps_smmu 0x860 0x0>;
phys = <&usb_1_hsphy>, <&usb_1_qmpphy QMP_USB43DP_USB3_PHY>;
---
base-commit: 30ffa8de54e5cc80d93fd211ca134d1764a7011f
change-id: 20260626-sc8280xp-fix-dwc3-reg-size-89aed9666d96
Best regards,
--
Xilin Wu <sophon@radxa.com>
^ permalink raw reply related
* Re: [PATCH 2/2] pinctrl: qcom: spmi-gpio: Add PMG1110 GPIO support
From: Bartosz Golaszewski @ 2026-06-26 14:44 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-arm-msm, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-gpio, devicetree, linux-kernel,
Konrad Dybcio, Fenglin Wu, Bartosz Golaszewski
In-Reply-To: <CAD++jL=_27BOr28Pi_UqjDpJSuRztYGKO2CXynOvwSVpe1-uBA@mail.gmail.com>
On Fri, 26 Jun 2026 15:00:36 +0200, Linus Walleij <linusw@kernel.org> said:
> On Wed, Jun 10, 2026 at 9:05 AM Fenglin Wu <fenglin.wu@oss.qualcomm.com> wrote:
>
>
>> Add PMG1110 GPIO support with its compatible string and match data.
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>
> Acked-by: Linus Walleij <linusw@kernel.org>
>
> Bartosz will queue the patch, I think.
>
> Yours,
> Linus Walleij
>
I will go through the pending patches next week. Thanks.
Bart
^ permalink raw reply
* Re: [RFC 00/12] RFC: Devicetree-ACPI hybrid mode
From: Bryan O'Donoghue @ 2026-06-26 14:43 UTC (permalink / raw)
To: Hans de Goede, Rafael J . Wysocki, Bjorn Andersson, Konrad Dybcio
Cc: Srinivas Kandagatla, Krzysztof Kozlowski, Dmitry Baryshkov,
Bartosz Golaszewski, Abel Vesa, linux-arm-msm, devicetree,
linux-acpi
In-Reply-To: <04b4f1b0-4d8f-41eb-9b6f-d90b88aec2ff@kernel.org>
On 26/06/2026 15:33, Bryan O'Donoghue wrote:
> On 23/06/2026 15:52, Hans de Goede wrote:
>> Comments, thoughts ?
>
> Throw out DT and just do this...
>
> One thing I like about this approach TBH is that you don't do the easy
> thing of presuming to push the hard work into the bootloader - thus
> creating a dependency on bootloader.
>
> We've had _alot_ of problems doing DT selectivity to get OSes installed
> on arm64 laptops. You mentioned I2C-HID devices and EC controllers which
> I agree are a good and obvious targets.
>
> I don't think this can replace a full and complete DT but, then I don't
> think that should be the objective.
>
> Much like installing cursed OSes like Windows on "normal" laptops or x86
> machines, you'd expect to boot in ACPI mode have enough of the OS
> running to install more of the OS - which I think _can_ be a viable
> objective with an ACPI-DT translator.
>
> Sadly OpenBSD could boot all the way to console on the Qcom laptops
> where Linux could not - because ACPI support was better there.
>
> And, we have Nvidia laptops coming too, Windows laptops which will parse
> ACPI tables to boot.
>
> There's almost no upside in having ACPI data and not trying to make
> maximal use of it, especially if you don't have a DT supplied by
> antecedent boot stages.
>
> ---
> bod
>
I'm going to agree with myself some more on the boot story.
If you can boot Linux _at_all_ and dump out ACPI tables from the booted
system you are way further along than not being able to boot without a
"real" DT.
Again, bootloaders have had to be educated on how to make that DT
selection - a problem that isn't well solved or converged on - and even
if such an agreed method were present, exactly 100% useless to you
without the DT to go with it.
As a Linux user I don't expect everything to work, especially so on
aarch64 but, if I can get to a boot console with a screen and keyboard -
I have scope to play in a way I otherwise don't - parsing DSDT from
Windows and walking backwards to DT.
DT _should_ be the landing zone of course but, ACPI-DT hybrid to "just
boot" seems like an obvious yes to me.
---
bod
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: fix eMMC reset polarity on PX30 Ringneck
From: Quentin Schulz @ 2026-06-26 14:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Quentin Schulz
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Quentin Schulz, stable
From: Quentin Schulz <quentin.schulz@cherry.de>
According to the Jedec 5.1 specification, the device is held in reset
when RST_n is low, therefore the polarity of the line must be that, as
specified in the Device Tree binding (mmc/mmc-pwrseq-emmc.yaml).
Due to the wrong polarity, eMMC devices with RST_n_FUNCTION[162]
bitfield [1:0] set to 0x1 (the default is 0x0) will be held in reset
forever.
Cc: stable@vger.kernel.org
Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
PX30 Ringneck is affected by the same issue that Cobra and PP-1516 have
and for which patches[1][2] have already been sent.
Out of the other boards I own, RK3588 Tiger and Jaguar also have an
inverted polarity but I tried making the eMMC chip care about the reset
line polarity to no avail, therefore I'm not changing them until we
figure out a setup in which we can reproduce the issue.
There are a handful of other Rockchip boards with an inverted polarity
but I don't own any of them so I will not change them either.
[1] https://lore.kernel.org/linux-rockchip/20260609081728.30616-2-jakobunt@gmail.com/
[2] https://lore.kernel.org/linux-rockchip/20260612-pp1516-emmc-polarity-v1-1-4816c1c909f7@cherry.de/
---
arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi
index 973b4c5880e24..29794216592d8 100644
--- a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi
@@ -26,7 +26,7 @@ emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
pinctrl-0 = <&emmc_reset>;
pinctrl-names = "default";
- reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_LOW>;
};
leds {
---
base-commit: 4edcdefd4083ae04b1a5656f4be6cd83ae919ef4
change-id: 20260626-ringneck-emmc-polarity-717003c6b802
Best regards,
--
Quentin Schulz <quentin.schulz@cherry.de>
^ permalink raw reply related
* Re: [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties
From: Conor Dooley @ 2026-06-26 14:36 UTC (permalink / raw)
To: Yu-Chien Peter Lin
Cc: devicetree, linux-riscv, linux-kernel, robh, krzk+dt, conor+dt,
pjw, palmer, aou, alex, samuel.holland, dlan, guodong, dfustini,
michal.simek, junhui.liu, darshan.prajapati, akpm, zhangchunyan,
luxu.kernel, pincheng.plct, nick.hu, jim.shu, zong.li,
greentime.hu, robin.randhawa, scott, dave.patel, raymond.mao
In-Reply-To: <aj5m00m4KxRAPAnB@plin-1878>
[-- Attachment #1: Type: text/plain, Size: 2729 bytes --]
On Fri, Jun 26, 2026 at 07:47:31PM +0800, Yu-Chien Peter Lin wrote:
> Hi Conor,
>
> On Mon, Jun 22, 2026 at 06:12:47PM +0100, Conor Dooley wrote:
> > On Fri, Jun 19, 2026 at 06:58:33PM +0800, Yu-Chien Peter Lin wrote:
> > > Add per-hart DT properties for RISC-V Worlds architecture:
> > > riscv,pmwid, riscv,pmwidlist, and riscv,pmlwidlist. These
> > > platform-defined values are primarily used by M-mode firmware
> > > to configure World ID CSRs and restrict WID usage across
> > > privilege levels.
> > >
> > > Signed-off-by: Yu-Chien Peter Lin <peter.lin@sifive.com>
> > > ---
> > > .../devicetree/bindings/riscv/cpus.yaml | 21 +++++
> > > .../devicetree/bindings/riscv/worlds.yaml | 77 +++++++++++++++++++
> > > 2 files changed, 98 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/riscv/worlds.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > index 5feeb2203050..4b5778b6d3e7 100644
> > > --- a/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml
> > > @@ -26,6 +26,7 @@ description: |
> > > allOf:
> > > - $ref: /schemas/cpu.yaml#
> > > - $ref: extensions.yaml
> > > + - $ref: worlds.yaml
> > > - if:
> > > not:
> > > properties:
> > > @@ -120,11 +121,31 @@ properties:
> > > thead systems where the vector register length is not identical on all harts, or
> > > the vlenb CSR is not available.
> > >
> > > + riscv,pmwid:
> > > + $ref: /schemas/types.yaml#/definitions/uint32
> > > + description:
> > > + Platform-defined M-mode World ID (WID) assigned to this hart.
> > > + minimum: 0
> > > + maximum: 63
> > > +
> > > + riscv,pmwidlist:
> > > + $ref: /schemas/types.yaml#/definitions/uint64
> > > + description:
> > > + Platform-defined bitmap of M-mode World IDs (WIDs) that this hart may use.
> >
> > I don't understand what the difference is between this property and the
> > one before it are.
> > Is this one meant to be used by m-mode software to then select one which
> > will appear in riscv,pmwid?
>
> pmwid (single value) is the reset default, while pmwidlist (bitmap)
> defines the allowed set. The root-of-trust M-mode software may select
> an allowed value from the pmwidlist and write it to the mwid CSR.
I don't understand the point of the property then. If it is the reset
default, just read it out of the register?
Unless I am missing something, it's useless to s-mode because it may
not be what m-mode chose and useless to m-mode that has access to
the csr.
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: rockchip: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:36 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-8-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:08:00PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the rockchip device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi | 3 ++-
> arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso | 3 ++-
> arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 5 +++--
> .../boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso | 3 ++-
> .../boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso | 3 ++-
> 5 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi b/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
> index 192791993f05..d58d6ee6241e 100644
> --- a/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
> @@ -6,6 +6,7 @@
> /dts-v1/;
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include "px30.dtsi"
>
> @@ -413,7 +414,7 @@ camera@36 {
> dvdd-supply = <&vcc_cam_dvdd>;
> dovdd-supply = <&vcc_cam_dovdd>;
> lens-focus = <&focus>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> pinctrl-names = "default";
> pinctrl-0 = <&cif_clkout_m0 &cam_pwdn>;
> reset-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
> index 760d5139f95d..2168db9168a5 100644
> --- a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
> +++ b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
> @@ -16,6 +16,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> &{/} {
> @@ -185,7 +186,7 @@ camera@36 {
> dvdd-supply = <&cam_dvdd_1v2>;
> dovdd-supply = <&cam_dovdd_1v8>;
> lens-focus = <&focus>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> pinctrl-names = "default";
> pinctrl-0 = <&cif_clkout_m0>;
> reset-gpios = <&pca9670 6 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> index 8d26bd9b7500..6608c777f185 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> @@ -13,6 +13,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/linux-event-codes.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include "rk3399-s.dtsi"
>
> / {
> @@ -455,7 +456,7 @@ wcam: camera@1a {
> reg = <0x1a>;
> clocks = <&cru SCLK_CIF_OUT>; /* MIPI_MCLK0, derived from CIF_CLKO */
> lens-focus = <&wcam_lens>;
> - orientation = <1>; /* V4L2_CAMERA_ORIENTATION_BACK */
> + orientation = <MEDIA_ORIENTATION_BACK>;
> pinctrl-names = "default";
> pinctrl-0 = <&camera_rst_l>;
> reset-gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_LOW>;
> @@ -487,7 +488,7 @@ ucam: camera@36 {
> clocks = <&cru SCLK_CIF_OUT>; /* MIPI_MCLK1, derived from CIF_CLK0 */
> clock-names = "xvclk";
> dovdd-supply = <&vcc1v8_dvp>;
> - orientation = <0>; /* V4L2_CAMERA_ORIENTATION_FRONT */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> pinctrl-names = "default";
> pinctrl-0 = <&camera2_rst_l &dvp_pdn0_h>;
> powerdown-gpios = <&gpio2 RK_PB4 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
> index ee9ecf68a886..8c9a4a1181e4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
> @@ -9,6 +9,7 @@
>
> #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> &{/} {
> @@ -50,7 +51,7 @@ imx415: camera-sensor@1a {
> avdd-supply = <&savdd_cam0>;
> clocks = <&cru CLK_MIPI_CAMARAOUT_M3>;
> dvdd-supply = <&sdvdd_cam0>;
> - orientation = <2>; /* External */
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&siovdd_cam0>;
> pinctrl-names = "default";
> pinctrl-0 = <&cam0_rstn &mipim0_camera3_clk>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
> index 8a4cf3fdbf8e..0cc3d6a34cef 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
> @@ -9,6 +9,7 @@
>
> #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> &{/} {
> @@ -50,7 +51,7 @@ cam1_imx415: camera-sensor@1a {
> avdd-supply = <&savdd_cam1>;
> clocks = <&cru CLK_MIPI_CAMARAOUT_M4>;
> dvdd-supply = <&sdvdd_cam1>;
> - orientation = <2>; /* External */
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&siovdd_cam1>;
> pinctrl-names = "default";
> pinctrl-0 = <&cam1_rstn &mipim0_camera4_clk>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 7/8] arm64: dts: renesas: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:34 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-7-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:59PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the renesas device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso | 3 ++-
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso | 3 ++-
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso | 3 ++-
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso | 3 ++-
> 4 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
> index 3acaf714cf24..b816382bba0a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j1: clk-cam-j1 {
> @@ -44,7 +45,7 @@ cam@10 {
> VDIG-supply = <®_cam_j1>;
> VDDL-supply = <®_cam_j1>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
> index a19bc0840392..4019b80a88b7 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j1: clk-cam-j1 {
> @@ -46,7 +47,7 @@ cam@1a {
> vdda-supply = <®_cam_j1>;
> vddd-supply = <®_cam_j1>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
> index 512810b861aa..fea1ef4a1178 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j2: clk-cam-j2 {
> @@ -44,7 +45,7 @@ cam@10 {
> VDIG-supply = <®_cam_j2>;
> VDDL-supply = <®_cam_j2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
> index a31524b59834..177201a8a6d2 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j2: clk-cam-j2 {
> @@ -46,7 +47,7 @@ cam@1a {
> vdda-supply = <®_cam_j2>;
> vddd-supply = <®_cam_j2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 6/8] arm64: dts: qcom: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:34 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-6-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:58PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the qualcomm device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 3 ++-
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 3 ++-
> arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi | 3 ++-
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index 04cb9230d29f..d79be22108c8 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -13,6 +13,7 @@
> #include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
> #include <dt-bindings/leds/common.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> #include <dt-bindings/sound/qcom,q6asm.h>
> @@ -701,7 +702,7 @@ camera@10 {
> pinctrl-0 = <&cam_mclk3_default>;
> pinctrl-names = "default";
>
> - orientation = <0>; /* Front facing */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <270>;
>
> port {
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index abd9c5a67b9f..543fc691fd3c 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -11,6 +11,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>
> #include "sc8280xp.dtsi"
> @@ -682,7 +683,7 @@ camera@10 {
>
> clocks = <&camcc CAMCC_MCLK3_CLK>;
>
> - orientation = <0>; /* Front facing */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> avdd-supply = <&vreg_l6q>;
> dvdd-supply = <&vreg_l2q>;
> diff --git a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> index 0f57b915186b..375b3c0edea7 100644
> --- a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> @@ -9,6 +9,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> #include <dt-bindings/power/qcom-rpmpd.h>
> #include "sdm670.dtsi"
> @@ -460,7 +461,7 @@ camera@1a {
> pinctrl-names = "default";
>
> rotation = <270>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> cam_front_endpoint: endpoint {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 5/8] arm64: dts: freescale: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:33 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-5-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:57PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the freescale/NXP device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> .../boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso | 3 ++-
> arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
> index e5a2b3780215..7b44ae0f19b2 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
> @@ -9,6 +9,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> #include "imx8mp-pinfunc.h"
>
> @@ -47,7 +48,7 @@ camera@10 {
> VANA-supply = <®_cam>;
> VDIG-supply = <®_cam>;
> VDDL-supply = <®_cam>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> index f5d529c5baf3..178cfad93483 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> @@ -8,6 +8,7 @@
> #include "dt-bindings/input/input.h"
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include "dt-bindings/pwm/pwm.h"
> #include "dt-bindings/usb/pd.h"
> #include "imx8mq.dtsi"
> @@ -1116,7 +1117,7 @@ camera_front: camera@20 {
> vddd-supply = <®_vcam_1v2>;
> vddio-supply = <®_csi_1v8>;
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> camera1_ep: endpoint {
--
Regards,
Laurent Pinchart
^ 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