* Re: [PATCH 2/6] remoteproc: qcom: Add M0 BTSS secure PIL driver
From: Konrad Dybcio @ 2026-06-26 11:20 UTC (permalink / raw)
To: george.moussalem, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Bjorn Andersson,
Konrad Dybcio, Mathieu Poirier, Philipp Zabel
Cc: linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260625-ipq5018-bluetooth-v1-2-d999be0e04f7@outlook.com>
On 6/25/26 4:10 PM, George Moussalem via B4 Relay wrote:
> From: George Moussalem <george.moussalem@outlook.com>
>
> Add support to bring up the M0 core of the bluetooth subsystem found in
> the IPQ5018 SoC.
>
> The signed firmware loaded is authenticated by TrustZone. If successful,
> the M0 core boots the firmware and the peripheral is taken out of reset
> using a Secure Channel Manager call to TrustZone.
>
> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
> ---
Can this not fit inside the existing PAS driver?
Konrad
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: George Moussalem @ 2026-06-26 11:20 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <20260626-discerning-light-swan-6b599c@quoll>
On 6/26/26 14:53, Krzysztof Kozlowski wrote:
> On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote:
>> Document the Qualcomm IPQ5018 Bluetooth controller.
>>
>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>> ---
>> .../bindings/net/bluetooth/qcom,ipq5018-bt.yaml | 63 ++++++++++++++++++++++
>> 1 file changed, 63 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
>> new file mode 100644
>> index 000000000000..afd33f851858
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,ipq5018-bt.yaml
>> @@ -0,0 +1,63 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/net/bluetooth/qcom,ipq5018-bt.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm IPQ5018 Bluetooth
>> +
>> +maintainers:
>> + - George Moussalem <george.moussalem@outlook.com>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - qcom,ipq5018-bt
>> +
>> + interrupts:
>> + items:
>> + - description:
>> + Interrupt line from the M0 Bluetooth Subsystem to the host processor
>
> What is M0?
it's a low power Cortex M0 core, for Bluetooth processing in this case.
>
> Anyway, this part feels completely redundant. Can "interrupts" property
> be anything else than an interrupt line from the device to the host
> processor?
>
>
>> + to notify it of events such as re
>
> This feels useful, but cut/incomplete.
yeah, c/p error. The interrupt is to notify the host of bluetooth events
running on the m0 core, such as TX/CMD completion and/or availability of
new data frames in the ring buffers.
>
>> +
>> + qcom,ipc:
>> + $ref: /schemas/types.yaml#/definitions/phandle-array
>> + items:
>> + - items:
>> + - description: phandle to a syscon node representing the APCS registers
>> + - description: u32 representing offset to the register within the syscon
>> + - description: u32 representing the ipc bit within the register
>> + description: |
>> + These entries specify the outgoing IPC bit used for signaling the remote
>> + M0 BTSS core of a host event or for sending an ACK if the remote processor
>> + expects it.
>> +
>> + qcom,rproc:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + Phandle to the remote processor node representing the M0 BTSS core.
>> +
>> +required:
>> + - compatible
>> + - interrupts
>> + - qcom,ipc
>> + - qcom,rproc
>> +
>> +allOf:
>> + - $ref: bluetooth-controller.yaml#
>> + - $ref: qcom,bluetooth-common.yaml
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> +
>> + bluetooth: bluetooth {
>
> Drop unused label
will drop
>
>> + compatible = "qcom,ipq5018-bt";
>> +
>> + qcom,ipc = <&apcs_glb 8 23>;
>> + interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
>
> No firmware to load?
firmware is loaded by the remoteproc in patch 1
>
> It feels like remoteproc node split is fake. The property qcom,rproc is
> even more supporting that case. Shouldn't this be simply one device -
> bluetooth? What sort of two devices do you have exactly? How can I
> identify them in the hardware?
I wasn't sure how to represent the HW. Should I make this bluetooth node
a childnode of the rproc? Essentially, this is the transport layer
(using shared memory space and IPC/interrupt).
Most QCA BT controllers are also childnodes of a serdev/uart node as
they use serdev for transport.
From what I understand, it's simply BT firmware running on this
dedicated M0 core in the SoC itself connected to an RF.
>
>> +
>> + qcom,rproc = <&m0_btss>;
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Bibek Kumar Patro @ 2026-06-26 11:25 UTC (permalink / raw)
To: Konrad Dybcio, 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: <4f0878a0-2ab1-490d-b251-c6d68c4ee241@oss.qualcomm.com>
On 6/25/2026 2:17 PM, Konrad Dybcio wrote:
> On 6/19/26 12:54 PM, Bibek Kumar Patro wrote:
>>
>>
>> On 6/18/2026 2:58 PM, Konrad Dybcio wrote:
>>> On 6/17/26 4:26 PM, Bibek Kumar Patro wrote:
>>>>
>>>>
>>>> On 6/16/2026 5:51 AM, Dmitry Baryshkov wrote:
>>>>> On Mon, Jun 15, 2026 at 06:36:51PM +0530, Bibek Kumar Patro wrote:
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> This is true for Qualcomm devices. However, you are adding this to a
>>>>> generic code.
>>>>>
>>>>>> 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.
>>>>>
>>>>> Shift it to the qcom instance or provide platform-specific values? (My
>>>>> preference would be towards the first solution).
>>>>>
>>>>
>>>>
>>>> To support platform-specific values, we may need to introduce a LUT-based approach in the driver. (Bandwidth voting values cannot be placed in device-tree property IIRC ?)
>>>>
>>>> Currently, all Qualcomm platforms use 0x1000 for SMMU ICC voting. I
>>>
>>> (you used decimal 1000)
>>>
>>
>> It's my bad, i meant 1000 only
>> (I'll check on the icc_bw calculation to get clarity on the values)
>>
>>>> can evaluate if this could be moved to a Qualcomm-specific
>>>> implementation.
>>>
>>> Add a vendor hook to arm_smmu_runtime_suspend/resume and handle it within
>>> the QC driver
>>>
>>
>> Just curious, wouldn't this apply for all the arm-smmu users in addition to Qualcomm devices as i mentioned here [1].
>> Vendor hook would make it Qualcomm specific.
>
> You're proposing to use a Qualcomm-specific bandwidth value so that
> fits
>
Got it, It seems valid. Will be sharing the new implementation post
testing in next revision.
Thanks & regards,
Bibek
> Konrad
>
>>
>> [1]: https://lore.kernel.org/all/984ff9c7-3eef-463c-a330-bf7acd063667@oss.qualcomm.com/
>>
>> Thanks & regards,
>> Bibek
>>
>>> Konrad
>>
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
From: Konrad Dybcio @ 2026-06-26 11:26 UTC (permalink / raw)
To: Jason Pettit, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Akhil P Oommen,
Mahadevan P, Sibi Sankar, Jingyi Wang, Ananthu C V
In-Reply-To: <20260625-glymur-send-v2-2-00905324ffbf@oss.qualcomm.com>
On 6/26/26 7:47 AM, Jason Pettit wrote:
> Add board support for the HP EliteBook X G2q 14" Next Gen AI PC
> (product SKU C4JG0AV, board 8E91), a Snapdragon X2 Elite (Glymur)
> laptop, using the "hp,elitebook-x-g2q" / "qcom,glymur" compatible.
[...]
> +/*
> + * usb_2 is a fixed DP-to-HDMI bridge; its SID-11 eUSB2 repeater is
> + * firmware-gated and never probes, so leave smb2370_l disabled.
> + */
> +&smb2370_l_e2 {
> + status = "disabled";
> +};
I would assume it's simply not present (as every SMB2370 is a separate
physical chip) - perhaps we should just add status = "disabled" in the
DTSI file and enable the nodes on an as-needed basis
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: Add HP EliteBook X G2q 14 AI
From: Konrad Dybcio @ 2026-06-26 11:27 UTC (permalink / raw)
To: Jason Pettit, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Akhil P Oommen,
Mahadevan P, Sibi Sankar, Jingyi Wang, Ananthu C V
In-Reply-To: <20260625-glymur-send-v2-2-00905324ffbf@oss.qualcomm.com>
On 6/26/26 7:47 AM, Jason Pettit wrote:
> Add board support for the HP EliteBook X G2q 14" Next Gen AI PC
> (product SKU C4JG0AV, board 8E91), a Snapdragon X2 Elite (Glymur)
> laptop, using the "hp,elitebook-x-g2q" / "qcom,glymur" compatible.
[...]
> +/*
> + * usb_2 is not exposed as a connector; its combo-PHY's DP lanes drive the
> + * chassis HDMI bridge (see hdmi-bridge).
> + */
> +&usb_2 {
> + maximum-speed = "high-speed";
> +
> + phys = <&usb_2_hsphy>;
> + phy-names = "usb2-phy";
> +
> + status = "okay";
> +};
> +
> +&usb_2_hsphy {
> + vdd-supply = <&vreg_l3f_e0_0p91>;
> + vdda12-supply = <&vreg_l4h_e0_1p2>;
> +
> + status = "okay";
> +};
If you remove these two nodes, the QMPPHY-as-DP-only should still
function (it's the USB3 block that depends on the QMPPHY, not the
other way around)
Konrad
^ permalink raw reply
* Re: [PATCH 4/6] dt-bindings: net: bluetooth: Document Qualcomm IPQ5018 Bluetooth controller
From: Konrad Dybcio @ 2026-06-26 11:30 UTC (permalink / raw)
To: George Moussalem, Krzysztof Kozlowski
Cc: Jens Axboe, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Johannes Berg, Jeff Johnson, Bartosz Golaszewski,
Marcel Holtmann, Luiz Augusto von Dentz, Balakrishna Godavarthi,
Rocky Liao, Saravana Kannan, Andrew Lunn, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Bjorn Andersson, Konrad Dybcio,
Mathieu Poirier, Philipp Zabel, linux-block, linux-kernel,
linux-mmc, devicetree, linux-wireless, ath10k, linux-arm-msm,
linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <SN7PR19MB673692EBED649CF6DC9833A89DEB2@SN7PR19MB6736.namprd19.prod.outlook.com>
On 6/26/26 1:20 PM, George Moussalem wrote:
> On 6/26/26 14:53, Krzysztof Kozlowski wrote:
>> On Thu, Jun 25, 2026 at 06:10:08PM +0400, George Moussalem wrote:
>>> Document the Qualcomm IPQ5018 Bluetooth controller.
>>>
>>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>>> ---
[...]
>>> + compatible = "qcom,ipq5018-bt";
>>> +
>>> + qcom,ipc = <&apcs_glb 8 23>;
>>> + interrupts = <GIC_SPI 162 IRQ_TYPE_EDGE_RISING>;
>>
>> No firmware to load?
>
> firmware is loaded by the remoteproc in patch 1
>
>>
>> It feels like remoteproc node split is fake. The property qcom,rproc is
>> even more supporting that case. Shouldn't this be simply one device -
>> bluetooth? What sort of two devices do you have exactly? How can I
>> identify them in the hardware?
>
> I wasn't sure how to represent the HW. Should I make this bluetooth node
> a childnode of the rproc? Essentially, this is the transport layer
> (using shared memory space and IPC/interrupt).
>
> Most QCA BT controllers are also childnodes of a serdev/uart node as
> they use serdev for transport.
>
> From what I understand, it's simply BT firmware running on this
> dedicated M0 core in the SoC itself connected to an RF.
Seems like this rhymes with the WPSS remoteproc +ATH1xK_AHB situation
- the Q6 core power sequences and manages the wireless controller,
while Linux gets to drive the device as it would if it were connected
over PCIe/ UART respectively, just with MMIO writes instead.
Konrad
^ permalink raw reply
* Re: [PATCH 2/6] remoteproc: qcom: Add M0 BTSS secure PIL driver
From: George Moussalem @ 2026-06-26 11:32 UTC (permalink / raw)
To: Konrad Dybcio, Jens Axboe, Ulf Hansson, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Johannes Berg, Jeff Johnson,
Bartosz Golaszewski, Marcel Holtmann, Luiz Augusto von Dentz,
Balakrishna Godavarthi, Rocky Liao, Saravana Kannan, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Bjorn Andersson,
Konrad Dybcio, Mathieu Poirier, Philipp Zabel
Cc: linux-block, linux-kernel, linux-mmc, devicetree, linux-wireless,
ath10k, linux-arm-msm, linux-bluetooth, netdev, linux-remoteproc
In-Reply-To: <38aceb33-b28e-4994-b277-de070b6dae2b@oss.qualcomm.com>
On 6/26/26 15:20, Konrad Dybcio wrote:
> On 6/25/26 4:10 PM, George Moussalem via B4 Relay wrote:
>> From: George Moussalem <george.moussalem@outlook.com>
>>
>> Add support to bring up the M0 core of the bluetooth subsystem found in
>> the IPQ5018 SoC.
>>
>> The signed firmware loaded is authenticated by TrustZone. If successful,
>> the M0 core boots the firmware and the peripheral is taken out of reset
>> using a Secure Channel Manager call to TrustZone.
>>
>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>> ---
>
> Can this not fit inside the existing PAS driver?
I've tried but there were two issues with that:
1. a custom way to load the firmware into memory is required because the
loadable segment needs to be offset by the virtual address in the mbn
file (see 0x20250 below). The standard mdt_loader uses the physical
addresses.
readelf -l bt_fw_patch.mbn
Elf file type is EXEC (Executable file)
Entry point 0x20255
There are 3 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NULL 0x000000 0x00000000 0x00000000 0x00094 0x00000 0
NULL 0x001000 0x0001a000 0x0001a000 0x00088 0x01000 0x1000
LOAD 0x002000 0x00020250 0x00000000 0x06154 0x190f8 RWE 0x4
2. memory needs to be ioremapped using ioremap, not ioremap_wc, else TZ
will complain and throw XPU violations due to strict memory alignment
and non-cache requirements.
>
> Konrad
Cheers,
George
^ permalink raw reply
* Re: [PATCH v5 2/3] arm64: dts: qcom: monaco: Add monaco-ac EVK board
From: sashiko-bot @ 2026-06-26 11:42 UTC (permalink / raw)
To: Umang Chheda; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260626111301.3479559-3-umang.chheda@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Massive contradiction in I2C GPIO expander configuration (1x TCA9534 vs 7x TCA9538)
- [Low] Missing pinctrl configuration for the Ethernet PHY reset GPIO
--
commit 060d5e44d123b8d9a920b4fe86d7d2ff2f7d1da6
Author: Umang Chheda <umang.chheda@oss.qualcomm.com>
arm64: dts: qcom: monaco: Add monaco-ac EVK board
Add initial device tree support for monaco-ac EVK board, based on Qualcomm's
monaco-ac (QCS8300-AC) variant SoC.
> diff --git a/arch/arm64/boot/dts/qcom/monaco-ac-evk.dts b/arch/arm64/boot/dts/qcom/monaco-ac-evk.dts
> new file mode 100644
> index 0000000000000..6f3c3ffefe340
> --- /dev/null
> +++ b/arch/arm64/boot/dts/qcom/monaco-ac-evk.dts
[ ... ]
> +&i2c15 {
> + pinctrl-0 = <&qup_i2c15_default>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> +
> + expander0: gpio@38 {
> + compatible = "ti,tca9538";
> + reg = <0x38>;
[ ... ]
> + expander6: gpio@3e {
> + compatible = "ti,tca9538";
> + reg = <0x3e>;
[Severity: Medium]
Is the commit message description accurate? The commit message mentions a
single TCA9534 expander providing 8 GPIO lines, but the device tree adds
seven TCA9538 expanders here.
If the hardware actually only has one expander, won't I2C transfers to the
others time out and fail, potentially breaking peripherals like USB and
DisplayPort which route their pins through these extra expanders?
[ ... ]
> +ðernet0 {
> + phy-mode = "2500base-x";
> + phy-handle = <&hsgmii_phy0>;
[ ... ]
> + mdio {
> + compatible = "snps,dwmac-mdio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + hsgmii_phy0: ethernet-phy@1c {
> + compatible = "ethernet-phy-id004d.d101";
> + reg = <0x1c>;
> + reset-gpios = <&tlmm 31 GPIO_ACTIVE_LOW>;
[Severity: Low]
Does this reset-gpios property need a corresponding pinctrl state to mux the
pin? If the bootloader leaves tlmm pin 31 in an undefined or alternate
state, could the Ethernet PHY fail to reset during network initialization?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626111301.3479559-1-umang.chheda@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [PATCH 0/6] arm64: ti: Use syscon for the Control Module
From: Tomi Valkeinen @ 2026-06-26 11:42 UTC (permalink / raw)
To: Andrew Davis, Krzysztof Kozlowski
Cc: linux-arm-kernel, devicetree, linux-kernel, Nishanth Menon,
Vignesh Raghavendra, Tero Kristo, Rob Herring, Conor Dooley,
Abraham I, Roger Quadros, Devarsh Thakkar, Swamil Jain
In-Reply-To: <29c9bd27-df32-4c56-8df2-987722d02b9a@ti.com>
Hi Andrew, Krzysztof,
On 29/05/2026 01:59, Andrew Davis wrote:
> On 5/28/26 7:53 AM, Tomi Valkeinen wrote:
>> I have been trying to get BeagleY-AI display support to upstream:
>>
>> 20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com
>>
>> One difficulty has been the handling of the Control Module region, as
>> we need access to a single in that region, surrounded by registers for
>> other subsystems. In my series I made the related node a syscon, thus
>> allowing versatile access to the registers:
>>
>> https://lore.kernel.org/all/20260513-beagley-ai-display-
>> v2-14-9e9bcefde6bc@ideasonboard.com/
>>
>> However, that's not a correct way to handle it. I realized we already
>> have ti,j721e-system-controller.yaml binding for older SoCs, which has
>> syscon but it's not used for the newer TI SoCs. This series takes the
>> same binding into use for the newer SoCs.
>>
>
> We moved away from this system-controller thing because it was always
> a hack to allow us to poke into random control registers from nodes
> throughout the DT. This was a mess and also caused issues with multiple
> mappings to the same registers (some sub nodes inside the control space
> also make their own mappings). If you need access to registers then make
> a node with those registers in the `reg` property.
>
> The only reason we didn't get rid of `ti,j721e-system-controller.yaml`
> completely from the older SoCs was we were told it would be an ABI
> break to correct those DT files. Let's not spread that problem to
> new SoCs.
I'm still stuck on this issue.
So, to summarize, we have the big control module memory region from
which various drivers need "random" registers. In my particular case,
the display subsystem (DSS) driver needs to access a single register
from the control module, but as the control module contains a lot of
registers, there are other similar cases too (I've seen at least one
other series, trying to add access to control module registers).
Taking AM62 SoC as an example, we have this in upstream:
https://github.com/torvalds/linux/blob/4edcdefd4083ae04b1a5656f4be6cd83ae919ef4/arch/arm64/boot/dts/ti/k3-am62-main.dtsi#L44
"main_conf" (simple-bus) node representing the control module, and nodes
under that representing either small things like clocks or, in
dss_oldi_io_ctrl case, a syscon.
I'm aware of three options on how to handle this.
1) Adding small syscon nodes under the main_conf, similar to the
existing dss_oldi_io_ctrl.
I did this in the earlier series:
https://lore.kernel.org/all/20260420-beagley-ai-display-v1-3-f628543dfd14%40ideasonboard.com/
2) Making the whole control module a syscon, as I do in this series.
3) Adding the required registers as a new 'reg' block under the dss' DT
node.
Both 1) and 2) have been nacked or at least very strongly questioned. 3)
doesn't feel right, the register is not a register for the IP but an
external SoC integration register.
Is there an option 4)? In your opinion, is one of the above the one
clear choice?
Tomi
^ permalink raw reply
* Re: [RFC PATCH 2/3] dt-bindings: riscv: Add Worlds per-hart properties
From: Yu-Chien Peter Lin @ 2026-06-26 11:47 UTC (permalink / raw)
To: Conor Dooley
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: <20260622-profanity-herbs-1cc1bcf6206f@spud>
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.
>
> > +
> > + riscv,pmlwidlist:
> > + $ref: /schemas/types.yaml#/definitions/uint64
> > + description:
> > + Platform-defined bitmap of World IDs (WIDs) that S-mode and U-mode may use
> > + on this hart.
> > +
> > # RISC-V has multiple properties for cache op block sizes as the sizes
> > # differ between individual CBO extensions
> > cache-op-block-size: false
> > # RISC-V requires 'timebase-frequency' in /cpus, so disallow it here
> > timebase-frequency: false
>
> > + # RISC-V requires 'riscv,nworlds' in /cpus, so disallow it here
> > + riscv,nworlds: false
>
> Isn't this pointless? Nothing ever defines riscv,nworlds as a cpu level
> property so there's no need to disallow it?
Okay, thanks for the catch, will drop this.
Best regards,
Peter Lin
>
> >
> > interrupt-controller:
> > type: object
> > diff --git a/Documentation/devicetree/bindings/riscv/worlds.yaml b/Documentation/devicetree/bindings/riscv/worlds.yaml
> > new file mode 100644
> > index 000000000000..cc8b3747591e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/riscv/worlds.yaml
> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR MIT)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/riscv/worlds.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: RISC-V Worlds Extension
> > +
> > +maintainers:
> > + - Yu-Chien Peter Lin <peter.lin@sifive.com>
> > +
> > +description: |
> > + The RISC-V Worlds ISA extension, as described in the RISC-V Privileged
> > + Specification, adds World ID tagging for context isolation.
> > +
> > + This binding describes the system-wide Worlds configuration for the /cpus node
> > + and is used alongside per-hart Worlds-related properties such as riscv,pmwid in
> > + the RISC-V CPU binding and Worlds-related ISA extensions enumerated via
> > + riscv,isa-extensions.
> > +
> > +select:
> > + properties:
> > + $nodename:
> > + pattern: "^cpus$"
> > +
> > +properties:
> > + riscv,nworlds:
> > + $ref: /schemas/types.yaml#/definitions/uint32
> > + description: |
> > + Number of World IDs (WIDs) supported by the platform. This is a system-wide
> > + property that describes the total number of isolation contexts available.
> > + Hardware components such as the WorldGuard Checker use this to determine
> > + the valid range of WID values.
> > + minimum: 2
> > + maximum: 64
> > +
> > +additionalProperties: true
> > +
> > +examples:
> > + - |
> > + // Example: System with 4 World IDs
> > + cpus {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > + timebase-frequency = <1000000>;
> > + riscv,nworlds = <4>;
> > +
> > + cpu@0 {
> > + device_type = "cpu";
> > + reg = <0>;
> > + compatible = "sifive,bullet0", "riscv";
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
> > + riscv,pmwid = <0>;
> > +
> > + interrupt-controller {
> > + #interrupt-cells = <1>;
> > + compatible = "riscv,cpu-intc";
> > + interrupt-controller;
> > + };
> > + };
> > +
> > + cpu@1 {
> > + device_type = "cpu";
> > + reg = <1>;
> > + compatible = "sifive,bullet0", "riscv";
> > + riscv,isa-base = "rv64i";
> > + riscv,isa-extensions = "i", "m", "a", "f", "d", "c";
> > + riscv,pmwid = <1>;
> > +
> > + interrupt-controller {
> > + #interrupt-cells = <1>;
> > + compatible = "riscv,cpu-intc";
> > + interrupt-controller;
> > + };
> > + };
> > + };
> > --
> > 2.43.7
> >
^ permalink raw reply
* [PATCH v2 0/8] dt-bindings: Orientation defines
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Conor Dooley, Kieran Bingham, Kieran Bingham
Add a new dt-bindings/media/video-interface-devices.h header that
initially supports the Orientation types and convert existing users
throughout the code base.
v2:
- Now expands from the original v1 "dt-bindings: media: Add macros for
video interface devices" to update
Documentation/devicetree/bindings/media/video-interface-devices.yaml
and extend to actually change all users to the new types.
---
Kieran Bingham (8):
dt-bindings: media: Add macros for video interface devices
media: dt-bindings: video-interface-devices: add video-interface-devices.h references
dt-bindings: media: i2c: Utilise video-interface-devices enums
ARM: tegra: Convert to new media orientation definitions
arm64: dts: freescale: Convert to new media orientation definitions
arm64: dts: qcom: Convert to new media orientation definitions
arm64: dts: renesas: Convert to new media orientation definitions
arm64: dts: rockchip: Convert to new media orientation definitions
.../devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov08d10.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov4689.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov5693.yaml | 3 ++-
.../devicetree/bindings/media/i2c/ovti,ov64a40.yaml | 3 ++-
.../devicetree/bindings/media/i2c/sony,imx111.yaml | 3 ++-
.../devicetree/bindings/media/i2c/sony,imx355.yaml | 3 ++-
.../devicetree/bindings/media/i2c/sony,imx415.yaml | 3 ++-
.../devicetree/bindings/media/i2c/st,vd55g1.yaml | 3 ++-
.../devicetree/bindings/media/i2c/st,vd56g3.yaml | 3 ++-
.../devicetree/bindings/media/i2c/thine,thp7312.yaml | 3 ++-
.../bindings/media/video-interface-devices.yaml | 17 +++++++++++------
.../dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi | 3 ++-
.../dts/nvidia/tegra30-asus-transformer-common.dtsi | 3 ++-
arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 4 +++-
arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 3 ++-
.../imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso | 3 ++-
arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 3 ++-
arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 3 ++-
.../boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 3 ++-
arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi | 3 ++-
.../renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso | 3 ++-
.../renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso | 3 ++-
.../renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso | 3 ++-
.../renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso | 3 ++-
arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi | 3 ++-
.../dts/rockchip/px30-ringneck-haikou-video-demo.dtso | 3 ++-
arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 5 +++--
.../rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso | 3 ++-
.../rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso | 3 ++-
include/dt-bindings/media/video-interface-devices.h | 13 +++++++++++++
32 files changed, 86 insertions(+), 37 deletions(-)
---
base-commit: 30ffa8de54e5cc80d93fd211ca134d1764a7011f
change-id: 20260608-kbingham-orientation-20afc0fb6957
Best regards,
--
--
Kieran
^ permalink raw reply
* [PATCH v2 1/8] dt-bindings: media: Add macros for video interface devices
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Conor Dooley, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com>
Add a new dt-bindings/media/video-interface-devices.h header that
defines macros corresponding to the orientation enumeration types from
media/video-interface-devices.yaml.
This allows avoiding hardcoded constants in device tree sources.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
include/dt-bindings/media/video-interface-devices.h | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/include/dt-bindings/media/video-interface-devices.h b/include/dt-bindings/media/video-interface-devices.h
new file mode 100644
index 000000000000..d2340b457292
--- /dev/null
+++ b/include/dt-bindings/media/video-interface-devices.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
+/*
+ * Copyright (C) 2026 Kieran Bingham <kieran.bingham@ideasonboard.com>
+ */
+
+#ifndef __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
+#define __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
+
+#define MEDIA_ORIENTATION_FRONT 0
+#define MEDIA_ORIENTATION_BACK 1
+#define MEDIA_ORIENTATION_EXTERNAL 2
+
+#endif /* __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__ */
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/8] media: dt-bindings: video-interface-devices: add video-interface-devices.h references
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: 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-0-47178be927b4@ideasonboard.com>
Expand the documentation of the video-interface-devices orientation to
reference the include/dt-bindings/media/video-interface-devices.h header
which provides human readable defines for the orientation enum, to help
avoid hardcoding values in dts.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
.../bindings/media/video-interface-devices.yaml | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
index a81d2a155fe6..c9c3f4f16719 100644
--- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
+++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
@@ -392,17 +392,22 @@ properties:
The orientation of a device (typically an image sensor or a flash LED)
describing its mounting position relative to the usage orientation of the
system where the device is installed on.
+ See include/dt-bindings/media/video-interface-devices.h.
+
$ref: /schemas/types.yaml#/definitions/uint32
enum:
- # Front. The device is mounted on the front facing side of the system. For
- # mobile devices such as smartphones, tablets and laptops the front side
- # is the user facing side.
+ # MEDIA_ORIENTATION_FRONT
+ # The device is mounted on the front facing side of the system. For
+ # mobile devices such as smartphones, tablets and laptops the front
+ # side is the user facing side.
- 0
- # Back. The device is mounted on the back side of the system, which is
+ # MEDIA_ORIENTATION_BACK
+ # The device is mounted on the back side of the system, which is
# defined as the opposite side of the front facing one.
- 1
- # External. The device is not attached directly to the system but is
- # attached in a way that allows it to move freely.
+ # MEDIA_ORIENTATION_EXTERNAL
+ # The device is not attached directly to the system but is attached in
+ # a way that allows it to move freely.
- 2
additionalProperties: true
--
2.52.0
^ permalink raw reply related
* [PATCH v2 3/8] dt-bindings: media: i2c: Utilise video-interface-devices enums
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: 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-0-47178be927b4@ideasonboard.com>
The orientation property for video interface devices now has definitions
to prevent hardcoded integer values for the enum options.
Update the existing examples throughout the bindings documentation for
camera sensors.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml | 3 ++-
Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml | 3 ++-
12 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
index 1a57f2aa1982..b7bc6ba26e6e 100644
--- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
@@ -86,6 +86,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -102,7 +103,7 @@ examples:
vddio-supply = <®_camera_vddio>;
reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
rotation = <0>;
port {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
index 6f2017c75125..b9c61395b24f 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
@@ -69,6 +69,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -84,7 +85,7 @@ examples:
avdd-supply = <&ov08d10_vdda_2v8>;
dvdd-supply = <&ov08d10_vddd_1v2>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
index d96199031b66..fcd617848ce3 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
@@ -96,6 +96,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -114,7 +115,7 @@ examples:
powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
reset-gpios = <&pio 109 GPIO_ACTIVE_LOW>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
index ad07204057f9..6df62fd0c0c0 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
@@ -85,6 +85,7 @@ examples:
- |
#include <dt-bindings/clock/px30-cru.h>
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/rockchip.h>
i2c {
@@ -108,7 +109,7 @@ examples:
dovdd-supply = <&vcc_2v8>;
rotation = <90>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
port {
ucam_out: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
index 3368b3bd8ef2..5732657e1484 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
@@ -103,6 +103,7 @@ examples:
- |
#include <dt-bindings/clock/px30-cru.h>
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/pinctrl/rockchip.h>
i2c {
@@ -126,7 +127,7 @@ examples:
dovdd-supply = <&vcc_2v8>;
rotation = <90>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
port {
ucam_out: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
index 2b6143aff391..24787c9aa155 100644
--- a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
@@ -72,6 +72,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -87,7 +88,7 @@ examples:
powerdown-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
rotation = <180>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
port {
endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
index 20f48d5e9b2d..56fb5f18f07b 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
@@ -69,6 +69,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -84,7 +85,7 @@ examples:
dvdd-supply = <&camera_vddd_1v2>;
avdd-supply = <&camera_vdda_2v7>;
- orientation = <1>;
+ orientation = <MEDIA_ORIENTATION_BACK>;
rotation = <90>;
nvmem = <&eeprom>;
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
index 6050d7e7dcfe..b4a88eaa7ef2 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
@@ -74,6 +74,7 @@ examples:
- |
#include <dt-bindings/clock/qcom,camcc-sdm845.h>
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -98,7 +99,7 @@ examples:
pinctrl-0 = <&cam_front_default>;
rotation = <270>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
port {
cam_front_endpoint: endpoint {
diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
index 7c11e871dca6..69a37ff68db3 100644
--- a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
@@ -86,6 +86,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -98,7 +99,7 @@ examples:
clocks = <&clock_cam>;
dvdd-supply = <&vcc1v1_cam>;
lens-focus = <&vcm>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
ovdd-supply = <&vcc1v8_cam>;
reset-gpios = <&gpio_expander 14 GPIO_ACTIVE_LOW>;
rotation = <180>;
diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
index 060ac6829b66..db9f0c15576c 100644
--- a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
@@ -105,6 +105,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -123,7 +124,7 @@ examples:
reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
st,leds = <2>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
index c6673b8539db..48db22ca4a7e 100644
--- a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
@@ -107,6 +107,7 @@ unevaluatedProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -125,7 +126,7 @@ examples:
reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
st,leds = <6>;
- orientation = <2>;
+ orientation = <MEDIA_ORIENTATION_EXTERNAL>;
rotation = <0>;
port {
diff --git a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
index bc339a7374b2..4a66cb711372 100644
--- a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
+++ b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
@@ -173,6 +173,7 @@ examples:
- |
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/media/video-interfaces.h>
+ #include <dt-bindings/media/video-interface-devices.h>
i2c {
#address-cells = <1>;
@@ -196,7 +197,7 @@ examples:
vddgpio-0-supply = <&vsys_v4p2>;
vddgpio-1-supply = <&vsys_v4p2>;
- orientation = <0>;
+ orientation = <MEDIA_ORIENTATION_FRONT>;
rotation = <0>;
sensors {
--
2.52.0
^ permalink raw reply related
* [PATCH v2 4/8] ARM: tegra: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: 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-0-47178be927b4@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 nvidia device trees to use the new
definitions.
Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
---
arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi | 3 ++-
arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi | 3 ++-
arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 4 +++-
arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 3 ++-
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
index 892d718294dd..a7fdd194300c 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
@@ -3,6 +3,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/power/summit,smb347-charger.h>
#include <dt-bindings/thermal/thermal.h>
@@ -991,7 +992,7 @@ front-camera@48 {
vdd-supply = <&vddio_cam>;
vaa-supply = <&avdd_cam1>;
- orientation = <0>; /* Front camera */
+ orientation = <MEDIA_ORIENTATION_FRONT>;
assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
<&tegra_car TEGRA30_CLK_CSUS>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
index bf1c3a31d406..76286e15684c 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
@@ -3,6 +3,7 @@
#include <dt-bindings/input/gpio-keys.h>
#include <dt-bindings/input/input.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/thermal/thermal.h>
#include "tegra30.dtsi"
@@ -1262,7 +1263,7 @@ front-camera@48 {
vdd-supply = <&vdd_1v8_cam>;
vaa-supply = <&avdd_2v85_fcam>;
- orientation = <0>; /* Front camera */
+ orientation = <MEDIA_ORIENTATION_FRONT>;
assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
<&tegra_car TEGRA30_CLK_CSUS>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
index 896639599c12..28680063bcc0 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
@@ -1,6 +1,8 @@
// SPDX-License-Identifier: GPL-2.0
/dts-v1/;
+#include <dt-bindings/media/video-interface-devices.h>
+
#include "tegra30-lg-x3.dtsi"
/ {
@@ -132,7 +134,7 @@ front-camera@48 {
vdd-supply = <&vt_1v8_front>;
vaa-supply = <&vt_2v8_front>;
- orientation = <0>; /* Front camera */
+ orientation = <MEDIA_ORIENTATION_FRONT>;
assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
<&tegra_car TEGRA30_CLK_CSUS>;
diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
index 60e8a19aa70e..c58e3026a115 100644
--- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
+++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
@@ -4,6 +4,7 @@
#include <dt-bindings/input/input.h>
#include <dt-bindings/leds/common.h>
#include <dt-bindings/media/video-interfaces.h>
+#include <dt-bindings/media/video-interface-devices.h>
#include <dt-bindings/mfd/max77620.h>
#include <dt-bindings/thermal/thermal.h>
@@ -1216,7 +1217,7 @@ rear-camera@10 {
dvdd-supply = <&vdd_1v2_rear>;
avdd-supply = <&vdd_2v7_rear>;
- orientation = <1>; /* Rear camera */
+ orientation = <MEDIA_ORIENTATION_REAR>;
rotation = <90>;
nvmem = <&m24c08>;
--
2.52.0
^ permalink raw reply related
* [PATCH v2 6/8] arm64: dts: qcom: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: 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-0-47178be927b4@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 qualcomm device trees to use the new
definitions.
Signed-off-by: Kieran Bingham <kieran.bingham@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 {
--
2.52.0
^ permalink raw reply related
* [PATCH v2 5/8] arm64: dts: freescale: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: 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-0-47178be927b4@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 freescale/NXP device trees to use the new
definitions.
Signed-off-by: Kieran Bingham <kieran.bingham@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 {
--
2.52.0
^ permalink raw reply related
* [PATCH v2 8/8] arm64: dts: rockchip: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: 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-0-47178be927b4@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 rockchip device trees to use the new
definitions.
Signed-off-by: Kieran Bingham <kieran.bingham@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>;
--
2.52.0
^ permalink raw reply related
* [PATCH v2 7/8] arm64: dts: renesas: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven, Magnus Damm,
Heiko Stuebner
Cc: 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-0-47178be927b4@ideasonboard.com>
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>
---
.../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 {
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-26 12:09 UTC (permalink / raw)
To: Leo Yan
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: <20260626103015.GE575984@e132581.arm.com>
Hi Leo,
On 6/26/2026 6:30 PM, Leo Yan wrote:
> Hi Jie,
>
> On Fri, Jun 26, 2026 at 10:03:41AM +0800, Jie Gan wrote:
>
> [...]
>
>> Hi Leo,
>>
>> To be honest, I would prefer not to modify the interconnect platform driver.
>> On some Qualcomm platforms, multiple itnoc devices reside within small
>> blocks(one or more than one for each block) and are connected to a dummy
>> source. In such cases, two ATIDs are allocated for a path (the dummy source
>> and the itnoc), which is inefficient. This is why the itnoc platform driver
>> created to avoid this waste.
>>
>> The TraceNoC (called as AG TraceNoC) is a generic TraceNoC device which
>> connected to multiple source and link devices, aggregating data from all
>> source devices into a single output path.
>
> As I said, it may be fragile to couple a specific device property (ATID)
> to the AMBA driver.
>
> You're now facing a case where a device cannot be registered as an AMBA
> device, so it cannot use ATID. Likewise, I can imagine in future where a
> device is registered as an AMBA device, but you don't want ATID.
>
Agree. That's possible.
>> This device is implemented as an AMBA device but lacks proper hardware
>> configuration. As a result, it must be handled in the driver as a
>> workaround, which unfortunately breaks the original design intent.
>
> Seems to me, it is not reasonable to pretend an AMBA device but AMBA
> ID registers are absent.
>
> How about add a new DT property ("qcom,tnoc-enable-atid") to force
> enabling ATID?
That's a good proposal.
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.
Thanks,
Jie
>
> Thanks,
> Leo
^ permalink raw reply
* Re: [PATCH v2 4/8] ARM: tegra: Convert to new media orientation definitions
From: sashiko-bot @ 2026-06-26 12:15 UTC (permalink / raw)
To: Kieran Bingham; +Cc: wsa+renesas, devicetree, robh, conor+dt, Frank.Li, imx
In-Reply-To: <20260626-kbingham-orientation-v2-4-47178be927b4@ideasonboard.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The commit introduces an undefined macro `MEDIA_ORIENTATION_REAR`, causing a Device Tree Compiler (dtc) build failure.
--
commit 26c9ba57e237b4ebfdbb6dbf2af353106c11c695
Author: Kieran Bingham <kieran.bingham@ideasonboard.com>
ARM: tegra: Convert to new media orientation definitions
The commit updates the NVIDIA device trees to use new media orientation
definitions instead of hardcoded integer values for video interface devices.
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> index 60e8a19aa70ec..c58e3026a115e 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
[ ... ]
> @@ -1216,7 +1217,7 @@ rear-camera@10 {
> dvdd-supply = <&vdd_1v2_rear>;
> avdd-supply = <&vdd_2v7_rear>;
>
> - orientation = <1>; /* Rear camera */
> + orientation = <MEDIA_ORIENTATION_REAR>;
[Severity: Low]
Will this cause a Device Tree Compiler build failure?
Looking at the dt-bindings/media/video-interface-devices.h header, it
defines MEDIA_ORIENTATION_FRONT, MEDIA_ORIENTATION_BACK, and
MEDIA_ORIENTATION_EXTERNAL.
Since MEDIA_ORIENTATION_REAR is undefined, the C preprocessor will leave it
as an unexpanded token, which will cause a syntax error when dtc parses it.
Could this be updated to use MEDIA_ORIENTATION_BACK instead?
> rotation = <90>;
>
> nvmem = <&m24c08>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com?part=4
^ permalink raw reply
* Re: [PATCH v2 6/8] arm64: dts: qcom: Convert to new media orientation definitions
From: Konrad Dybcio @ 2026-06-26 12:30 UTC (permalink / raw)
To: Kieran Bingham, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jacopo Mondi, Sakari Ailus,
Jimmy Su, Matthias Fend, Mikhail Rudenko, Daniel Scally,
Jacopo Mondi, Michael Riesch, Benjamin Mugnier, Sylvain Petinot,
Laurent Pinchart, Paul Elder, Martin Kepplinger, Quentin Schulz,
Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan, Thierry Reding,
Jonathan Hunter, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Bjorn Andersson, Konrad Dybcio, Geert Uytterhoeven,
Magnus Damm, Heiko Stuebner
Cc: 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 6/26/26 2:07 PM, 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>
> ---
Finally someone shaved this yak, thank you
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 4/8] ARM: tegra: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:33 UTC (permalink / raw)
To: sashiko-bot, sashiko-reviews
Cc: wsa+renesas, devicetree, robh, conor+dt, Frank.Li, imx
In-Reply-To: <20260626121557.92C6D1F000E9@smtp.kernel.org>
Hi Sashiko,
Quoting sashiko-bot@kernel.org (2026-06-26 13:15:57)
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] The commit introduces an undefined macro `MEDIA_ORIENTATION_REAR`, causing a Device Tree Compiler (dtc) build failure.
> --
>
> commit 26c9ba57e237b4ebfdbb6dbf2af353106c11c695
> Author: Kieran Bingham <kieran.bingham@ideasonboard.com>
>
> ARM: tegra: Convert to new media orientation definitions
>
> The commit updates the NVIDIA device trees to use new media orientation
> definitions instead of hardcoded integer values for video interface devices.
>
> > diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> > index 60e8a19aa70ec..c58e3026a115e 100644
> > --- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> > +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> [ ... ]
> > @@ -1216,7 +1217,7 @@ rear-camera@10 {
> > dvdd-supply = <&vdd_1v2_rear>;
> > avdd-supply = <&vdd_2v7_rear>;
> >
> > - orientation = <1>; /* Rear camera */
> > + orientation = <MEDIA_ORIENTATION_REAR>;
>
> [Severity: Low]
> Will this cause a Device Tree Compiler build failure?
>
> Looking at the dt-bindings/media/video-interface-devices.h header, it
> defines MEDIA_ORIENTATION_FRONT, MEDIA_ORIENTATION_BACK, and
> MEDIA_ORIENTATION_EXTERNAL.
>
> Since MEDIA_ORIENTATION_REAR is undefined, the C preprocessor will leave it
> as an unexpanded token, which will cause a syntax error when dtc parses it.
> Could this be updated to use MEDIA_ORIENTATION_BACK instead?
Ah man - the heat must have been getting to me. That's definitely
supposed to be MEDIA_ORIENTATION_BACK. I shouldn't have read the comment
I replaced.
--
Kieran
>
> > rotation = <90>;
> >
> > nvmem = <&m24c08>;
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260626-kbingham-orientation-v2-0-47178be927b4@ideasonboard.com?part=4
^ permalink raw reply
* Re: [PATCH v2 7/8] arm64: dts: renesas: Convert to new media orientation definitions
From: Geert Uytterhoeven @ 2026-06-26 12:30 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Laurent Pinchart, Paul Elder,
Martin Kepplinger, Quentin Schulz, Tommaso Merciai,
Svyatoslav Ryhel, Richard Acayan, Thierry Reding, Jonathan Hunter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Bjorn Andersson, Konrad Dybcio, 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, 26 Jun 2026 at 14:08, Kieran Bingham
<kieran.bingham@ideasonboard.com> 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: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 2/3] MAINTAINERS: Update imagination maintainers
From: Matt Coster @ 2026-06-26 12:43 UTC (permalink / raw)
To: imagination, linux-kernel
Cc: Conor Dooley, Alessio Belle, Luigi Santivetti, Frank Binns,
Brajesh Gupta, Alexandru Dadu, dri-devel, devicetree, Matt Coster
In-Reply-To: <20260626-maintainer-updates-v2-0-e1b3f246c44c@imgtec.com>
New people are taking up maintainership roles within the team.
Signed-off-by: Matt Coster <matt.coster@imgtec.com>
---
MAINTAINERS | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index b45e60524762..fe02d1087ab2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12567,8 +12567,9 @@ S: Orphan
F: drivers/media/rc/img-ir/
IMGTEC POWERVR DRM DRIVER
-M: Frank Binns <frank.binns@imgtec.com>
M: Matt Coster <matt.coster@imgtec.com>
+M: Alessio Belle <alessio.belle@imgtec.com>
+M: Luigi Santivetti <luigi.santivetti@imgtec.com>
L: imagination@lists.freedesktop.org
S: Supported
Q: https://patchwork.freedesktop.org/project/imagination/list/
--
2.48.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox