* Re: [PATCH v2 2/6] iommu/arm-smmu: Add interconnect bandwidth voting support
From: Konrad Dybcio @ 2026-06-25 8:47 UTC (permalink / raw)
To: Bibek Kumar Patro, 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: <aaf4daee-4886-4214-a761-80545d2565ee@oss.qualcomm.com>
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
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/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-25 8:56 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: <a13fb65c-726b-4c99-b741-29040c4564d0@oss.qualcomm.com>
On Thu, Jun 25, 2026 at 09:01:18AM +0800, Jie Gan wrote:
[...]
> > > However, I believe it is acceptable to allocate an ATID for the itNoC device
> > > and the issue can be fixed with this way.
> >
> > I think so.
>
> Hi Suzuki/Leo
>
> Which solution do you prefer to address the issue?
I will leave this to Suzuki.
> The interconnect traceNoC platform driver is intended for the itnoc device,
> implying that no TPDM devices are connected to it. So, if I modify it to
> allocate an ATID, I think it would be better to rename the “itnoc” node
> accordingly? Or it's ok to leave it as-is?
>
> BTW, the traceNoC device definitely is an AMBA device with CID/PID
> registers.
Just to share a bit thoughts on the driver's design.
I think it would be better to keep the probe function generic. The AMBA
probe should not be specific to TraceNoC, and the platform probe should
not be only dedicated to the interconnect TraceNoC. The probe function
should simply handle a device that appears on either the AMBA bus or the
platform bus.
So the question is: if allocat an ATID for all traceNoC devices, do you
still need to distinguish TraceNoC types? If no, then the code can be
unified.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH 2/2] spi: qcom-geni: Add property to force GSI mode
From: Mukesh Savaliya @ 2026-06-25 9:06 UTC (permalink / raw)
To: Konrad Dybcio, 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: <3451facc-4a2e-43bf-ba13-944488bce437@oss.qualcomm.com>
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.
> Konrad
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Grégoire Layet @ 2026-06-25 9:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <b9ca9e36-a851-4a98-a739-ca99dd534d6d@kernel.org>
Hi Krzysztof,
> > It's a Virtual UART. Internally, it's two FIFOs accessible via
> > 8250-compatible register sets on both ends.
>
> I do not know what is Virtual UART...
Yes the name of ASPEED is a bit weird, it means that it is not a real
UART. It is two 8250-compatible register sets, and the data path is
handled by two hardware FIFOs (one per direction).
> > There is 4 Virtuals UARTs on the LPC bus of the AST2600 and 2 of them
> > are bridged over the PCI bus.
> > So, from the host, you can access the 8250 register set on the PCI bus.
>
> You mean these appear (or are) as PCI devices?
Yes but not as a UART devices.
The two VUART are accessible under the same PCIe BMC device, at the
VUART addresses configured on the BMC. They are accessible on the BAR1
of the PCIe BMC device.
There is a 2 bit left shift between the addresses of the registers on
the BMC LPC bus and the addresses accessible over the PCI device.
0x3F8 on the BMC is accessible at BAR1 0xFE0 over the PCI device.
The PCIe BMC Device is one PCI device where you can access several
peripherals. It's not one PCI device per VUART.
For example, you can also enable the KCS channel 4 and it will be also
accessible via the BAR1 of the PCI BMC device. KCS is a protocol used
for IPMI.
Only these two peripherals can be accessed over the PCI BMC device and
they need to be enabled.
The host cannot access everything on the LPC bus of the BMC.
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH 0/3] arm64: dts: tegra: CPU and cache node updates
From: Thierry Reding @ 2026-06-25 9:10 UTC (permalink / raw)
To: jonathanh, robh, krzk+dt, conor+dt, devicetree, linux-tegra,
linux-kernel, Sumit Gupta
Cc: bbasu
In-Reply-To: <20260121104536.3214101-1-sumitg@nvidia.com>
From: Thierry Reding <treding@nvidia.com>
On Wed, 21 Jan 2026 16:15:33 +0530, Sumit Gupta wrote:
> - Fixes for Tegra234/264 device tree CPU compatible string.
> - Populate CPU and L2 cache nodes for Tegra264.
>
> Sumit Gupta (3):
> arm64: dts: tegra234: Fix CPU compatible string to cortex-a78ae
> arm64: dts: tegra264: Fix CPU1 node unit-address
> arm64: dts: tegra264: Populate CPU and L2 cache nodes
>
> [...]
Applied, thanks!
[1/3] arm64: dts: tegra234: Fix CPU compatible string to cortex-a78ae
commit: 2e1f4664c1be73065070d8b380a3c7440f98f6a4
[2/3] arm64: dts: tegra264: Fix CPU1 node unit-address
commit: c003ea35f934a9e6672ea02778f07f08cb6f13ad
[3/3] arm64: dts: tegra264: Populate CPU and L2 cache nodes
commit: 1199de78b2ca6439e83a565fe39eb4fed67d70b8
Best regards,
--
Thierry Reding <treding@nvidia.com>
^ permalink raw reply
* [PATCH] arm64: dts: hisilicon: hi3798cv200: Drop unused clock-names and reset-names
From: Krzysztof Kozlowski @ 2026-06-25 9:13 UTC (permalink / raw)
To: Wei Xu, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Neither Linux drivers nor DT bindings ever described or used clock-names
and reset-names for this SoC. The binding allows clock-names only for
atmel,at91sam9g45-ehci and atmel,at91rm9200-ohci, but not for HiSilicon.
reset-names were never allowed.
Drop them from DTS to fix dtbs_check warnings:
hi3798cv200-poplar.dtb: usb@9880000 (generic-ohci): False schema does not allow ['bus', 'clk12', 'clk48']
hi3798cv200-poplar.dtb: usb@9880000 (generic-ohci): Unevaluated properties are not allowed ('reset-names' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
index 2f4ad5da5e33..e5010c9d4c39 100644
--- a/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hi3798cv200.dtsi
@@ -633,9 +633,7 @@ ohci: usb@9880000 {
clocks = <&crg HISTB_USB2_BUS_CLK>,
<&crg HISTB_USB2_12M_CLK>,
<&crg HISTB_USB2_48M_CLK>;
- clock-names = "bus", "clk12", "clk48";
resets = <&crg 0xb8 12>;
- reset-names = "bus";
phys = <&usb2_phy1_port0>;
phy-names = "usb";
status = "disabled";
@@ -648,11 +646,9 @@ ehci: usb@9890000 {
clocks = <&crg HISTB_USB2_BUS_CLK>,
<&crg HISTB_USB2_PHY_CLK>,
<&crg HISTB_USB2_UTMI_CLK>;
- clock-names = "bus", "phy", "utmi";
resets = <&crg 0xb8 12>,
<&crg 0xb8 16>,
<&crg 0xb8 13>;
- reset-names = "bus", "phy", "utmi";
phys = <&usb2_phy1_port0>;
phy-names = "usb";
status = "disabled";
--
2.53.0
^ permalink raw reply related
* [PATCH] ARM: dts: st: spear13xx: Drop unused/incorrect usbh0_id and usbh1_id
From: Krzysztof Kozlowski @ 2026-06-25 9:13 UTC (permalink / raw)
To: Viresh Kumar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, soc, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
"usbh0_id" and "usbh1_id" properties were never documented and never
used by Linux drivers, thus should be safe to drop to fix dtbs_check
warnings like:
st/spear1310-evb.dtb: usb@e4800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh0_id' was unexpected)
st/spear1310-evb.dtb: usb@e5800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh1_id' was unexpected)
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm/boot/dts/st/spear13xx.dtsi | 4 ----
1 file changed, 4 deletions(-)
diff --git a/arch/arm/boot/dts/st/spear13xx.dtsi b/arch/arm/boot/dts/st/spear13xx.dtsi
index 0bb88f2d4ef5..cf98160ba268 100644
--- a/arch/arm/boot/dts/st/spear13xx.dtsi
+++ b/arch/arm/boot/dts/st/spear13xx.dtsi
@@ -178,7 +178,6 @@ usb@e4800000 {
compatible = "st,spear600-ehci", "usb-ehci";
reg = <0xe4800000 0x1000>;
interrupts = <0 64 0x4>;
- usbh0_id = <0>;
status = "disabled";
};
@@ -186,7 +185,6 @@ usb@e5800000 {
compatible = "st,spear600-ehci", "usb-ehci";
reg = <0xe5800000 0x1000>;
interrupts = <0 66 0x4>;
- usbh1_id = <1>;
status = "disabled";
};
@@ -194,7 +192,6 @@ usb@e4000000 {
compatible = "st,spear600-ohci", "usb-ohci";
reg = <0xe4000000 0x1000>;
interrupts = <0 65 0x4>;
- usbh0_id = <0>;
status = "disabled";
};
@@ -202,7 +199,6 @@ usb@e5000000 {
compatible = "st,spear600-ohci", "usb-ohci";
reg = <0xe5000000 0x1000>;
interrupts = <0 67 0x4>;
- usbh1_id = <1>;
status = "disabled";
};
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: usb: generic-ehci: Document clock-names in top-level
From: Krzysztof Kozlowski @ 2026-06-25 9:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-usb, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Convention is to always have properties defined in top-level part of the
binding and then customized (narrowed per variant) in "if:then:" blocks.
The clock-names were mentioned only in such "if:then:" block for
atmel,at91sam9g45-ehci, thus add the top-level part and disallow usage
of clock-names for other devices. This has no practical impact as
clock-names are not used by other variants, except in
hisilicon/hi3798cv200.dtsi, but that SoC has it undocumented.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/usb/generic-ehci.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index 55a5aa7d7a54..ae9fb70d0212 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -98,6 +98,10 @@ properties:
- if a USB DRD channel: first clock should be host and second
one should be peripheral
+ clock-names:
+ minItems: 1
+ maxItems: 4
+
power-domains:
maxItems: 1
@@ -186,6 +190,9 @@ allOf:
required:
- clocks
- clock-names
+ else:
+ properties:
+ clock-names: false
unevaluatedProperties: false
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: usb: generic-ohci: Document clock-names in top-level
From: Krzysztof Kozlowski @ 2026-06-25 9:17 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-usb, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260625091744.109467-3-krzysztof.kozlowski@oss.qualcomm.com>
Convention is to always have properties defined in top-level part of the
binding and then customized (narrowed per variant) in "if:then:" blocks.
The clock-names were mentioned only in such "if:then:" block for
atmel,at91rm9200-ohci, thus add the top-level part and disallow usage of
clock-names for other devices. This has no practical impact as
clock-names are not used by other variants, except in
hisilicon/hi3798cv200.dtsi, but that SoC has it undocumented.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/devicetree/bindings/usb/generic-ohci.yaml | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index d42f448fa204..322808aaa283 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -83,6 +83,10 @@ properties:
- if a USB DRD channel: first clock should be host and second
one should be peripheral
+ clock-names:
+ minItems: 1
+ maxItems: 4
+
power-domains:
maxItems: 1
@@ -182,6 +186,7 @@ allOf:
else:
properties:
+ clock-names: false
atmel,vbus-gpio: false
atmel,oc-gpio: false
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/8] irqchip/qcom-pdc: restructure version support
From: Maulik Shah (mkshah) @ 2026-06-25 9:19 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <0fcfe7c3-ff54-4a72-9529-8f55d77814ef@oss.qualcomm.com>
On 6/17/2026 6:42 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
>> PDC irqchip updates IRQ_ENABLE and IRQ_CFG and for three different
>> versions v2.7, v3.0 and v3.2. These registers are organized in H/W
>> as below on various SoCs.
>
> [...]
>
>> - ret = pdc_setup_pin_mapping(node);
>> + ret = pdc_setup_pin_mapping(dev, node);
>
> dev is enough, we can get the np in that function from dev->of_node
>
> otherwise:
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
Sure, Will update in v4 for getting np from dev->of_node.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH v3 2/8] irqchip/qcom-pdc: Move all statics to struct pdc_desc
From: Maulik Shah (mkshah) @ 2026-06-25 9:19 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <8754de51-bfbe-42f2-84bf-36cc000afa3f@oss.qualcomm.com>
On 6/17/2026 6:56 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
>> There are multiple statics used. Move all to struct pdc_desc to better
>> align with versioning support. Document them.
>>
>> No functional impact.
>>
>> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
>> ---
>
> [...]
>
>> static void pdc_enable_intr(struct irq_data *d, bool on)
>> {
>> - unsigned long flags;
>> + guard(raw_spinlock)(&pdc->lock);
>
> tglx suggested to use guard(irq) around "the other callsite"..
> which I'm not sure where it'd be - maybe around __pdc_enable_intr()
> in pdc_setup_pin_mapping()?
>
> Otherwise this patch looks good to me
>
> Konrad
All callers will be from irqchip except pdc_setup_pin_mapping() which was
invoking lock-less because at that time irqchip is not setup and as such
can stay lock less.
Once the patch-3 of this series is applied pdc_setup_pin_mapping() too
will use the lock as it makes direct use of pdc->enable_intr() where the new lock
is kept (only for v2.7 version specific enable function).
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH v3 4/8] irqchip/qcom-pdc: Differentiate between direct SPI and GPIO as SPI
From: Maulik Shah (mkshah) @ 2026-06-25 9:20 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <2978f55b-0b5c-4720-98ba-e14ef46b1169@oss.qualcomm.com>
On 6/18/2026 1:32 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
>> Before commit 4dc70713dc24 ("irqchip/qcom-pdc: Kill non-wakeup irqdomain")
>> there are separate domains for direct SPIs and GPIO used as SPIs. Separate
>> domains can be useful in case irqchip want to differentiate both of them.
>> Since commit unified both the domains there is no way to differentiate.
>>
>> In preparation to add the second level interrupt controller support where
>> GPIO interrupts get latched at PDC (but not direct SPIs) there is a need to
>> differentiate between SPIs and GPIOs as SPIs. Reverting above commit do not
>> seem a good option either which leads to waste of resources.
>>
>> PDC HW have the IRQ_PARAM register telling number of direct SPIs and number
>> of GPIOs as SPIs. Further PDC allocates direct SPIs at the beginning and
>> all GPIOs as SPIs are allocated at the end. This information can be used in
>> driver to differentiate them.
>>
>> Add the support to read this register and keep this information in
>> struct pdc_desc. Later change utilizes same.
>>
>> Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com>
>> ---
>
> [...]
>
>> + irq_param = pdc_reg_read(pdc->regs->irq_param_reg, 0);
>> + pdc->num_spis = FIELD_GET(GENMASK(7, 0), irq_param);
>> + pdc->num_gpios = FIELD_GET(GENMASK(15, 8), irq_param);
>
> num_gpios is not used in this series, please either drop it or
> use it to limit the index in the following patches
>
> Konrad
I will remove unused num_gpios from v4.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH v3 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Maulik Shah (mkshah) @ 2026-06-25 9:24 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <e513bc4c-ddeb-43b3-aa05-59051136ba4e@oss.qualcomm.com>
On 6/18/2026 1:48 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
[...]
>> + type = IRQ_TYPE_LEVEL_HIGH;
>
>
> Please carry your comment from the previous revision:
>
> /*
> * PDC forwards GPIOs as level high to GIC in secondary
> * mode. Update the type and clear any previously latched
> * phantom interrupt at PDC.
> */
>
I will add back this comment in v4.
[...]
>> + if (pdc->mode == PDC_PASS_THROUGH_MODE || !pdc_pin_is_gpio(hwirq)) {
>> + ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
>> + &qcom_pdc_gic_chip,
>> + NULL);
>> + if (ret)
>> + return ret;
>>
>> - region = get_pin_region(hwirq);
>> - if (!region)
>> - return irq_domain_disconnect_hierarchy(domain->parent, virq);
>> + if (type & IRQ_TYPE_EDGE_BOTH)
>> + type = IRQ_TYPE_EDGE_RISING;
>>
>> - if (type & IRQ_TYPE_EDGE_BOTH)
>> - type = IRQ_TYPE_EDGE_RISING;
>> + if (type & IRQ_TYPE_LEVEL_MASK)
>> + type = IRQ_TYPE_LEVEL_HIGH;
>> + } else {
>> + ret = irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
>> + &qcom_pdc_gic_secondary_chip,
>> + NULL);
>> + if (ret)
>> + return ret;
>>
>> - if (type & IRQ_TYPE_LEVEL_MASK)
>> + /* Secondary mode converts all interrupts to LEVEL HIGH type */
>> type = IRQ_TYPE_LEVEL_HIGH;
>> + }
>
> nit: (pdc->mode == PDC_SECONDARY_MODE && pdc_pin_is_gpio(hwirq))
> could be the primary case to better communicate intent
>
> Konrad
Made primary case as (pdc->mode == PDC_SECONDARY_MODE && pdc_pin_is_gpio(hwirq) in v4.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH v3 5/8] irqchip/qcom-pdc: Configure PDC to pass through mode
From: Maulik Shah (mkshah) @ 2026-06-25 9:25 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thomas Gleixner, Linus Walleij
Cc: linux-arm-msm, linux-kernel, devicetree, linux-gpio, Sneh Mankad
In-Reply-To: <c90884fd-a354-45f3-bbfa-77c58d8d3b1b@oss.qualcomm.com>
On 6/18/2026 1:49 PM, Konrad Dybcio wrote:
> On 6/16/26 11:25 AM, Maulik Shah wrote:
[...]
>> +
>> + if (pdc->version < PDC_VERSION_3_0)
>> + return;
>
> These version checks should be unnecessary now, given the function pointer
> is only assigned for hamoa
>
> Konrad
Yes, they are now unnecessary. I will remove in v4.
Thanks,
Maulik
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display: tegra: Make non-vm registers optional
From: Mikko Perttunen @ 2026-06-25 9:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260625-hospitable-antelope-of-diversity-f3456d@quoll>
On Thursday, June 25, 2026 5:34 PM Krzysztof Kozlowski wrote:
> On Mon, Jun 22, 2026 at 05:22:50PM +0900, Mikko Perttunen wrote:
> > Host1x can be used without accessing the hypervisor or common
> > registers. Adjust the bindings to make them optional.
>
> You still have these registers in the hardware, so it is not optional,
> not flexible. IOW, DTS represents the view of real hardware for the
> software, and that hardware still has this address space regardless if
> OS should use it or not.
>
> Otherwise you need to provide better background here.
>
> Best regards,
> Krzysztof
>
>
The intent is that the vm-only version is used in situations where the
other register regions are not available to software. Typically that
means running as a virtual machine, and the hypervisor owns the non-vm
register regions and doesn't pass them to the guest.
Since the guest runs under the hypervisor, its view of 'real hardware'
is what the hypervisor is exposing to it -- in this case with just the
"vm" register region.
I'll add further explanation along above lines to the commit message
if you're OK with it.
Thank you
Mikko
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: display: tegra: Add channel/syncpoint range properties
From: Mikko Perttunen @ 2026-06-25 9:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260625-poetic-heavy-vulture-7baabb@quoll>
On Thursday, June 25, 2026 5:36 PM Krzysztof Kozlowski wrote:
> On Mon, Jun 22, 2026 at 05:22:51PM +0900, Mikko Perttunen wrote:
> > Channels and syncpoints available may be limited when other system
>
> What are channels and syncpoints?
Very host1x-specific hardware resources. Somewhat close to GPU channels
and semaphores / fences if you're familiar with those.
>
> > components are using them. Add properties nvidia,channels and
> > nvidia,syncpoints to limit the range of usable channels and/or
> > syncpoints.
>
> Why isn't this deducible from the compatible?
When Host1x is partitioned, the hypervisor (or other software entity
with access to the non-vm host1x register regions) can configure which
channels and syncpoints are available to each partition arbitrarily.
How that partitioning was done is not discoverable through hardware
directly, so we need to pass that information through device tree.
>
> Also, nvidia,channels is too broad/generic. This is not ADC, right? And
> channels is a common term in IIO. And in few other cases.
It's not ADC. Yes, it's a common term in a lot of contexts. I can call
it nvidia,host1x-channels if you prefer but that seems a bit redundant
given the context.
>
> Best regards,
> Krzysztof
>
>
Thank you
Mikko
^ permalink raw reply
* [PATCH v8 0/2] drm: panel: support the R63419 based dual-DSI video mode Display Panels
From: Neil Armstrong @ 2026-06-25 9:29 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: dri-devel, devicetree, linux-kernel, linux-renesas-soc,
Dmitry Baryshkov, Doug Anderson, Neil Armstrong, Conor Dooley,
KancyJoe
Add support for the Renesas 63419 based dual-DSI video mode
Display Panels found in the Ayaneo gaming handled devices.
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
Changes in v8:
- Use mipi_dsi_dual instead of helper
- Revert to recommended prepare sequence from DDIC spec
- Disable VCC after gpio up
- Remove drm_connector_set_panel_orientation
- Use 2 params strscpy and make sure mipi_dsi_device_info is cleared
- Link to v7: https://patch.msgid.link/20260605-topic-sm8650-ayaneo-pocket-s2-r63419-v7-0-b84b6da84293@linaro.org
Changes in v7:
- Reverse "on" command order
- Rebase on drm-misc-next
- Link to v6: https://patch.msgid.link/20260522-topic-sm8650-ayaneo-pocket-s2-r63419-v6-0-16edddda9951@linaro.org
Changes in v6:
- Get new dt bindings review from Conor
- Properly init dsi_ctx
- Link to v5: https://patch.msgid.link/20260521-topic-sm8650-ayaneo-pocket-s2-r63419-v5-0-dd5700299390@linaro.org
Changes in v5:
- Import panel-common-dual.yaml in bindings
- Set reg as required
- fix bindings example typo
- Add helper to switch link in order to use single dsi_ctx to properly handle errors
- Disable vdd supplies if vcc supplied fail to enable
- Precise the power off sequence is recommended by the vendor spec
- Drop passing of node to second dsi to avoid re-probing the driver twice
- Link to v4: https://patch.msgid.link/20260519-topic-sm8650-ayaneo-pocket-s2-r63419-v4-0-b8929af5e951@linaro.org
Changes in v4:
- Moved height/width in the drm_mode, duplicated modes to use drm_connector_helper_get_modes_fixed
- Create dsi_info on the stack with proper OF node and name passed
- Switched to devm_drm_panel_add/devm_mipi_dsi_attach & dropped remove
- Link to v3: https://patch.msgid.link/20260504-topic-sm8650-ayaneo-pocket-s2-r63419-v3-0-9f61cf24aebf@linaro.org
Changes in v3:
- Added DDIC compatible as fallback
- Added rotation in bindings example
- Fixed bindings subject
- Added second MODULE_AUTHOR entry and re-ordered signed-off-by order
- Link to v2: https://patch.msgid.link/20260430-topic-sm8650-ayaneo-pocket-s2-r63419-v2-0-91ac10453d0c@linaro.org
Changes in v2:
- Add missing rotation property into bindings
- Fix commit message & subject typos
- Link to v1: https://patch.msgid.link/20260428-topic-sm8650-ayaneo-pocket-s2-r63419-v1-0-981eb5ab5a51@linaro.org
---
KancyJoe (1):
drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
Neil Armstrong (1):
dt-bindings: display: panel: document the Renesas R63419 based dual-DSI video mode Display Panels
.../bindings/display/panel/renesas,r63419.yaml | 98 ++++++
drivers/gpu/drm/panel/Kconfig | 12 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-renesas-r63419.c | 350 +++++++++++++++++++++
4 files changed, 461 insertions(+)
---
base-commit: cdeb2ccd993ed8647adbbda2c3b103aa717fd6f7
change-id: 20260428-topic-sm8650-ayaneo-pocket-s2-r63419-e72467e2db0f
Best regards,
--
Neil Armstrong <neil.armstrong@linaro.org>
^ permalink raw reply
* [PATCH v8 1/2] dt-bindings: display: panel: document the Renesas R63419 based dual-DSI video mode Display Panels
From: Neil Armstrong @ 2026-06-25 9:29 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: dri-devel, devicetree, linux-kernel, linux-renesas-soc,
Dmitry Baryshkov, Doug Anderson, Neil Armstrong, Conor Dooley
In-Reply-To: <20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-0-8570e692143e@linaro.org>
Document the Renesas R63419 based dual-DSI video mode Display Panels found
in the Ayaneo gaming handled devices.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
.../bindings/display/panel/renesas,r63419.yaml | 98 ++++++++++++++++++++++
1 file changed, 98 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/panel/renesas,r63419.yaml b/Documentation/devicetree/bindings/display/panel/renesas,r63419.yaml
new file mode 100644
index 000000000000..adfdd2c300a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/renesas,r63419.yaml
@@ -0,0 +1,98 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/display/panel/renesas,r63419.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Renesas R63419 based dual-DSI video mode Display Panel
+
+maintainers:
+ - Neil Armstrong <neil.armstrong@linaro.org>
+
+description:
+ The Renesas R63419 is a generic DDIC used to control dual-DSI LCD panels.
+
+allOf:
+ - $ref: panel-common-dual.yaml#
+
+properties:
+ compatible:
+ items:
+ - enum:
+ - ayaneo,wt0600-2k
+ - ayaneo,wt0630-2k
+ - const: renesas,r63419
+
+ reg:
+ maxItems: 1
+
+ vdd-supply: true
+ vddio-supply: true
+ vsp-supply: true
+ vsn-supply: true
+ vci-supply: true
+
+ backlight: true
+ reset-gpios: true
+ rotation: true
+ ports: true
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - vddio-supply
+ - vsp-supply
+ - vsn-supply
+ - vci-supply
+ - backlight
+ - reset-gpios
+ - ports
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ dsi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel@0 {
+ compatible = "ayaneo,wt0600-2k", "renesas,r63419";
+ reg = <0>;
+
+ reset-gpios = <&gpio 176 GPIO_ACTIVE_LOW>;
+
+ vdd-supply = <&vdd_3v0_lcd>;
+ vddio-supply = <&vdd_1v8_io>;
+ vsn-supply = <&vdd_5v0_neg>;
+ vsp-supply = <&vdd_5v0_pos>;
+ vci-supply = <&vdd_3v0_vci>;
+
+ backlight = <&backlight>;
+
+ rotation = <90>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ panel_in0: endpoint {
+ remote-endpoint = <&dsi0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ panel_in1: endpoint {
+ remote-endpoint = <&dsi1_out>;
+ };
+ };
+ };
+ };
+ };
+...
--
2.34.1
^ permalink raw reply related
* [PATCH v8 2/2] drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
From: Neil Armstrong @ 2026-06-25 9:29 UTC (permalink / raw)
To: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm
Cc: dri-devel, devicetree, linux-kernel, linux-renesas-soc,
Dmitry Baryshkov, Doug Anderson, Neil Armstrong, KancyJoe
In-Reply-To: <20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-0-8570e692143e@linaro.org>
From: KancyJoe <kancy2333@outlook.com>
Implement support for the Renesas 63419 based dual-DSI video mode
Display Panels found in the Ayaneo gaming handled devices.
Signed-off-by: KancyJoe <kancy2333@outlook.com>
Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
---
drivers/gpu/drm/panel/Kconfig | 12 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/panel/panel-renesas-r63419.c | 350 +++++++++++++++++++++++++++
3 files changed, 363 insertions(+)
diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index c0cc2bb4a3eb..2e84f6ce8190 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -826,6 +826,18 @@ config DRM_PANEL_RENESAS_R61307
This panel controller can be found in LG Optimus Vu P895 smartphone
in combination with LCD panel.
+config DRM_PANEL_RENESAS_R63419
+ tristate "Renesas R63419 dual-DSI video mode panels"
+ depends on OF && GPIOLIB
+ depends on DRM_MIPI_DSI
+ depends on BACKLIGHT_CLASS_DEVICE
+ help
+ Say Y here if you want to enable support for Ayaneo WT0600 and WT0630
+ 1440x2560 60Hz dual-DSI video mode display panels with Renesas
+ R63419 IC.
+
+ These panels are used in Ayaneo handheld gaming devices.
+
config DRM_PANEL_RENESAS_R69328
tristate "Renesas R69328 720x1280 DSI video mode panel"
depends on OF
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index 6926ef28ab8d..17bd4f51098f 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -81,6 +81,7 @@ obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM68200) += panel-raydium-rm68200.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM692E5) += panel-raydium-rm692e5.o
obj-$(CONFIG_DRM_PANEL_RAYDIUM_RM69380) += panel-raydium-rm69380.o
obj-$(CONFIG_DRM_PANEL_RENESAS_R61307) += panel-renesas-r61307.o
+obj-$(CONFIG_DRM_PANEL_RENESAS_R63419) += panel-renesas-r63419.o
obj-$(CONFIG_DRM_PANEL_RENESAS_R69328) += panel-renesas-r69328.o
obj-$(CONFIG_DRM_PANEL_RONBO_RB070D30) += panel-ronbo-rb070d30.o
obj-$(CONFIG_DRM_PANEL_SAMSUNG_AMS581VF01) += panel-samsung-ams581vf01.o
diff --git a/drivers/gpu/drm/panel/panel-renesas-r63419.c b/drivers/gpu/drm/panel/panel-renesas-r63419.c
new file mode 100644
index 000000000000..59ac323f5276
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-renesas-r63419.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * DRM driver for Renesas R63419 based dual-DSI video mode panels
+ *
+ * Copyright (c) 2025, Kancy Joe <kancy2333@outlook.com>
+ * Copyright (C) 2026 Linaro Limited
+ * Author: Neil Armstrong <neil.armstrong@linaro.org>
+ */
+
+#include <linux/backlight.h>
+#include <linux/delay.h>
+#include <linux/gpio/consumer.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/regulator/consumer.h>
+
+#include <video/mipi_display.h>
+
+#include <drm/drm_connector.h>
+#include <drm/drm_mipi_dsi.h>
+#include <drm/drm_modes.h>
+#include <drm/drm_panel.h>
+#include <drm/drm_probe_helper.h>
+
+struct renesas_r63419_panel {
+ struct drm_panel panel;
+ struct mipi_dsi_device *dsi[2];
+ const struct panel_desc *desc;
+
+ struct gpio_desc *reset_gpio;
+ struct regulator_bulk_data *vdd_supplies;
+ struct regulator_bulk_data *vcc_supplies;
+ enum drm_panel_orientation orientation;
+};
+
+/* VDDIO/VDD Supplies */
+static const struct regulator_bulk_data renesas_r63419_vdd_supplies[] = {
+ { .supply = "vddio" },
+ { .supply = "vdd" },
+};
+
+/* VSP/VSN/VCI Supplies */
+static const struct regulator_bulk_data renesas_r63419_vcc_supplies[] = {
+ { .supply = "vsp" },
+ { .supply = "vsn" },
+ { .supply = "vci" },
+};
+
+struct panel_desc {
+ const struct drm_display_mode *mode;
+ unsigned int lanes;
+ unsigned long mode_flags;
+ enum mipi_dsi_pixel_format format;
+ const struct mipi_dsi_device_info dsi_info;
+};
+
+static const struct drm_display_mode wt0600_mode = {
+ /* Dual dsi */
+ .clock = 2 * (720 + 100 + 8 + 40) * (2560 + 15 + 2 + 8) * 60 / 1000,
+ .hdisplay = 2 * 720,
+ .hsync_start = 2 * (720 + 100),
+ .hsync_end = 2 * (720 + 100 + 8),
+ .htotal = 2 * (720 + 100 + 8 + 40),
+ .vdisplay = 2560,
+ .vsync_start = 2560 + 15,
+ .vsync_end = 2560 + 15 + 2,
+ .vtotal = 2560 + 15 + 2 + 8,
+ .type = DRM_MODE_TYPE_DRIVER,
+ .width_mm = 74,
+ .height_mm = 131,
+};
+
+static const struct drm_display_mode wt0630_mode = {
+ /* Dual dsi */
+ .clock = 2 * (720 + 100 + 8 + 40) * (2560 + 15 + 2 + 8) * 60 / 1000,
+ .hdisplay = 2 * 720,
+ .hsync_start = 2 * (720 + 100),
+ .hsync_end = 2 * (720 + 100 + 8),
+ .htotal = 2 * (720 + 100 + 8 + 40),
+ .vdisplay = 2560,
+ .vsync_start = 2560 + 15,
+ .vsync_end = 2560 + 15 + 2,
+ .vtotal = 2560 + 15 + 2 + 8,
+ .type = DRM_MODE_TYPE_DRIVER,
+ .width_mm = 78,
+ .height_mm = 140,
+};
+
+static struct panel_desc wt0600_desc = {
+ .lanes = 4,
+ .mode = &wt0600_mode,
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS | MIPI_DSI_MODE_LPM,
+ .format = MIPI_DSI_FMT_RGB888,
+};
+
+static struct panel_desc wt0630_desc = {
+ .lanes = 4,
+ .mode = &wt0630_mode, /* wt0600 only has different screen size */
+ .mode_flags = MIPI_DSI_MODE_VIDEO | MIPI_DSI_MODE_VIDEO_BURST |
+ MIPI_DSI_CLOCK_NON_CONTINUOUS | MIPI_DSI_MODE_LPM,
+ .format = MIPI_DSI_FMT_RGB888,
+};
+
+static inline struct renesas_r63419_panel *
+to_renesas_r63419_panel(struct drm_panel *panel)
+{
+ return container_of(panel, struct renesas_r63419_panel, panel);
+}
+
+static int renesas_r63419_on(struct renesas_r63419_panel *ctx)
+{
+ struct mipi_dsi_multi_context dsi_ctx = { 0 };
+
+ /*
+ * Panel registers are loaded from DDIC Non Volatile Memory
+ *
+ * The DDIC expects this sequence to get out of sleep and enable display
+ */
+
+ mipi_dsi_dual(mipi_dsi_dcs_set_display_on_multi,
+ &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
+ mipi_dsi_msleep(&dsi_ctx, 50);
+
+ mipi_dsi_dual(mipi_dsi_dcs_exit_sleep_mode_multi,
+ &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
+ mipi_dsi_msleep(&dsi_ctx, 150);
+
+ return dsi_ctx.accum_err;
+}
+
+static int renesas_r63419_disable(struct drm_panel *panel)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+ struct mipi_dsi_multi_context dsi_ctx = { 0 };
+
+ mipi_dsi_dual(mipi_dsi_dcs_set_display_off_multi,
+ &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
+ mipi_dsi_msleep(&dsi_ctx, 50);
+
+ mipi_dsi_dual(mipi_dsi_dcs_enter_sleep_mode_multi,
+ &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
+ mipi_dsi_msleep(&dsi_ctx, 120);
+
+ return 0;
+}
+
+static int renesas_r63419_prepare(struct drm_panel *panel)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+ int ret;
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(renesas_r63419_vdd_supplies),
+ ctx->vdd_supplies);
+ if (ret < 0)
+ return ret;
+
+ usleep_range(1000, 2000);
+
+ ret = regulator_bulk_enable(ARRAY_SIZE(renesas_r63419_vcc_supplies),
+ ctx->vcc_supplies);
+ if (ret < 0) {
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vdd_supplies),
+ ctx->vdd_supplies);
+ return ret;
+ }
+
+ usleep_range(1000, 2000);
+
+ gpiod_set_value_cansleep(ctx->reset_gpio, 0);
+
+ usleep_range(3000, 4000);
+
+ ret = renesas_r63419_on(ctx);
+ if (ret < 0) {
+ dev_err(panel->dev, "Failed to initialize panel: %d\n", ret);
+
+ /* Power off sequence from the r63419 datasheet */
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vdd_supplies),
+ ctx->vdd_supplies);
+
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vcc_supplies),
+ ctx->vcc_supplies);
+
+ return ret;
+ }
+
+ return 0;
+}
+
+static int renesas_r63419_unprepare(struct drm_panel *panel)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+
+ /* Power off sequence from the r63419 datasheet */
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vdd_supplies), ctx->vdd_supplies);
+
+ gpiod_set_value_cansleep(ctx->reset_gpio, 1);
+
+ regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vcc_supplies), ctx->vcc_supplies);
+
+ return 0;
+}
+
+static int renesas_r63419_get_modes(struct drm_panel *panel,
+ struct drm_connector *connector)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+ const struct drm_display_mode *mode = ctx->desc->mode;
+
+ return drm_connector_helper_get_modes_fixed(connector, mode);
+}
+
+static enum drm_panel_orientation
+renesas_r63419_get_orientation(struct drm_panel *panel)
+{
+ struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
+
+ return ctx->orientation;
+}
+
+static const struct drm_panel_funcs renesas_r63419_panel_funcs = {
+ .disable = renesas_r63419_disable,
+ .prepare = renesas_r63419_prepare,
+ .unprepare = renesas_r63419_unprepare,
+ .get_modes = renesas_r63419_get_modes,
+ .get_orientation = renesas_r63419_get_orientation,
+};
+
+static int renesas_r63419_probe(struct mipi_dsi_device *dsi)
+{
+ struct mipi_dsi_device_info info = { 0 };
+ struct device *dev = &dsi->dev;
+ struct renesas_r63419_panel *ctx;
+ struct device_node *dsi1_node;
+ struct mipi_dsi_host *dsi1_host;
+ int ret, i;
+
+ ctx = devm_drm_panel_alloc(dev, struct renesas_r63419_panel, panel,
+ &renesas_r63419_panel_funcs, DRM_MODE_CONNECTOR_DSI);
+ if (IS_ERR(ctx))
+ return PTR_ERR(ctx);
+
+ ctx->desc = of_device_get_match_data(dev);
+ if (!ctx->desc)
+ return dev_err_probe(dev, -ENODEV,
+ "Failed to get panel description\n");
+
+ ret = devm_regulator_bulk_get_const(&dsi->dev,
+ ARRAY_SIZE(renesas_r63419_vdd_supplies),
+ renesas_r63419_vdd_supplies, &ctx->vdd_supplies);
+ if (ret < 0)
+ return ret;
+
+ ret = devm_regulator_bulk_get_const(&dsi->dev,
+ ARRAY_SIZE(renesas_r63419_vcc_supplies),
+ renesas_r63419_vcc_supplies, &ctx->vcc_supplies);
+ if (ret < 0)
+ return ret;
+
+ ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
+ if (IS_ERR(ctx->reset_gpio))
+ return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio),
+ "Failed to get reset gpio\n");
+
+ /* Get second DSI host */
+ dsi1_node = of_graph_get_remote_node(dsi->dev.of_node, 1, -1);
+ if (!dsi1_node)
+ return dev_err_probe(dev, -ENODEV,
+ "Failed to get remote node for second DSI\n");
+
+ dsi1_host = of_find_mipi_dsi_host_by_node(dsi1_node);
+ of_node_put(dsi1_node);
+ if (!dsi1_host)
+ return dev_err_probe(dev, -EPROBE_DEFER,
+ "Failed to find second DSI host\n");
+
+ /* Copy current DSI info, do not provide OF node since no driver needs to be attached */
+ strscpy(info.type, dsi->name);
+ info.channel = dsi->channel;
+
+ /* Register the second DSI device */
+ ctx->dsi[1] = devm_mipi_dsi_device_register_full(dev, dsi1_host, &info);
+ if (IS_ERR(ctx->dsi[1]))
+ return dev_err_probe(dev, PTR_ERR(ctx->dsi[1]),
+ "Failed to register second DSI device\n");
+
+ ctx->dsi[0] = dsi;
+ mipi_dsi_set_drvdata(dsi, ctx);
+
+ /* Get panel orientation */
+ ret = of_drm_get_panel_orientation(dev->of_node, &ctx->orientation);
+ if (ret < 0 && ret != -ENODEV)
+ return dev_err_probe(dev, ret,
+ "Failed to get panel orientation\n");
+
+ ctx->panel.prepare_prev_first = true;
+
+ ret = drm_panel_of_backlight(&ctx->panel);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to get backlight\n");
+
+ ret = devm_drm_panel_add(dev, &ctx->panel);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to add panel\n");
+
+ /* Configure and attach both DSI devices */
+ for (i = 0; i < ARRAY_SIZE(ctx->dsi); i++) {
+ ctx->dsi[i]->lanes = ctx->desc->lanes;
+ ctx->dsi[i]->format = ctx->desc->format;
+ ctx->dsi[i]->mode_flags = ctx->desc->mode_flags;
+
+ ret = devm_mipi_dsi_attach(dev, ctx->dsi[i]);
+ if (ret < 0)
+ return dev_err_probe(dev, ret,
+ "Failed to attach DSI device %d\n", i);
+ }
+
+ return 0;
+}
+
+static const struct of_device_id renesas_r63419_of_match[] = {
+ {
+ .compatible = "ayaneo,wt0600-2k",
+ .data = &wt0600_desc,
+ },
+ {
+ .compatible = "ayaneo,wt0630-2k",
+ .data = &wt0630_desc,
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(of, renesas_r63419_of_match);
+
+static struct mipi_dsi_driver renesas_r63419_driver = {
+ .probe = renesas_r63419_probe,
+ .driver = {
+ .name = "panel-renesas-r63419",
+ .of_match_table = renesas_r63419_of_match,
+ },
+};
+module_mipi_dsi_driver(renesas_r63419_driver);
+
+MODULE_AUTHOR("Kancy Joe <kancy2333@outlook.com>");
+MODULE_AUTHOR("Neil Armstrong <neil.armstrong@linaro.org>");
+MODULE_DESCRIPTION("DRM driver for Renesas R63419 based dual-DSI video mode panels");
+MODULE_LICENSE("GPL");
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] arm64: dts: qcom: qcs6490-rubikpi3: Enable cameras
From: Konrad Dybcio @ 2026-06-25 9:30 UTC (permalink / raw)
To: Hongyang Zhao, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, rosh
In-Reply-To: <20260616-rubikpi-next-20260615-v1-1-3d96b89397ff@thundersoft.com>
On 6/16/26 9:29 AM, Hongyang Zhao wrote:
> Enable the two Raspberry Pi camera connectors on RubikPi 3 with
> IMX219 sensors. CAM1 is connected to CCI1 and CSIPHY1, while CAM2
> is connected to CCI0 and CSIPHY4.
>
> Add the shared 24 MHz camera oscillator, camera power enable
> regulators, CAMSS endpoints, CCI sensor nodes and privacy LED GPIOs.
>
> Signed-off-by: Hongyang Zhao <hongyang.zhao@thundersoft.com>
> ---
[...]
> + vreg_cam1_pwr: regulator-camera1-pwr {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "vreg_camera1_pwr";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&tlmm 57 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +
> + pinctrl-0 = <&cam1_pwr_en>;
> + pinctrl-names = "default";
> +
> + vin-supply = <&vreg_vcc3v3_output>;
> + };
> +
> + vreg_cam2_pwr: regulator-camera2-pwr {
> + compatible = "regulator-fixed";
> +
> + regulator-name = "vreg_camera2_pwr";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&tlmm 58 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> +
> + pinctrl-0 = <&cam2_pwr_en>;
> + pinctrl-names = "default";
> +
> + vin-supply = <&vreg_vcc3v3_output>;
> + };
Are these supplies part of the baseboard?
[...]
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* CAM1 is routed to CSI1 / CSIPHY1. */
I believe these comments are self-explanatory given the names of the labels
[...]
> + cam1_privacy_led_state: cam1-privacy-led-state {
> + pins = "gpio18";
> + function = "gpio";
> + drive-strength = <8>;
> + output-low;
Please drop the output-foo properties from TLMM pins, the GPIO
state will be controlled by the driver
Konrad
^ permalink raw reply
* Re: [PATCH v5 04/12] i3c: master: Add support for devices using SETAASA
From: Akhil R @ 2026-06-25 9:38 UTC (permalink / raw)
To: frank.li
Cc: Frank.Li, akhilrajeev, conor+dt, devicetree, linux-hwmon,
linux-i3c, robh, sashiko-reviews
In-Reply-To: <ajwamrU8ehBINzxq@lizhi-Precision-Tower-5810>
On Wed, 24 Jun 2026 13:57:46 -0400, Frank Li wrote:
...
...
>> [Severity: High]
>> Is it possible that sending the SETAASA broadcast before direct SETDASA
>> assignments breaks initialization for devices that natively support SETAASA
>> but are configured for SETDASA?
>>
>> According to the I3C specification, any device on the bus natively supporting
>> SETAASA will respond to this broadcast by adopting its static address as its
>> dynamic address.
>>
>> After this broadcast, the driver iterates through devices and attempts to
>> assign custom dynamic addresses via direct SETDASA commands:
>>
>> drivers/i3c/master.c:i3c_master_early_i3c_dev_add() {
>> ...
>> ret = i3c_master_setdasa_locked(master, i3cdev->info.static_addr,
>> i3cdev->boardinfo->init_dyn_addr);
>> ...
>> }
>>
>> Since the target device already adopted its dynamic address during the
>> SETAASA broadcast, it is no longer in the unassigned state and will NACK
>> the subsequent SETDASA command.
>
> Look like correct, but I am not sure if target will NACK SETDASA. Or should
> use SETNEWDA for SETAASA method.
Yes, this looks valid for mixed device buses. I can move
i3c_master_setaasa_locked() after the SETDASA handling and before
i3c_master_do_daa() in the same function, so SETDASA-assigned devices will
ignore the later SETAASA broadcast. Does that sound good to you?
Best Regards,
Akhil
^ permalink raw reply
* Re: [PATCH] ARM: dts: st: spear13xx: Drop unused/incorrect usbh0_id and usbh1_id
From: Viresh Kumar @ 2026-06-25 9:41 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Viresh Kumar, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-kernel, soc, devicetree, linux-kernel
In-Reply-To: <20260625091355.107054-2-krzysztof.kozlowski@oss.qualcomm.com>
On 25-06-26, 11:13, Krzysztof Kozlowski wrote:
> "usbh0_id" and "usbh1_id" properties were never documented and never
> used by Linux drivers, thus should be safe to drop to fix dtbs_check
> warnings like:
>
> st/spear1310-evb.dtb: usb@e4800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh0_id' was unexpected)
> st/spear1310-evb.dtb: usb@e5800000 (st,spear600-ehci): Unevaluated properties are not allowed ('usbh1_id' was unexpected)
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm/boot/dts/st/spear13xx.dtsi | 4 ----
> 1 file changed, 4 deletions(-)
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
viresh
^ permalink raw reply
* Re: [PATCH v8 2/2] drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
From: sashiko-bot @ 2026-06-25 9:42 UTC (permalink / raw)
To: Neil Armstrong; +Cc: wsa+renesas, conor+dt, dri-devel, robh, devicetree
In-Reply-To: <20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-2-8570e692143e@linaro.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Asymmetric panel callbacks for DCS commands (display on/off) causes state mismatch and permanent blanking.
- [High] The panel initialization sequence sends the `set_display_on` command before the `exit_sleep_mode` command.
- [High] Missing device link between the panel and the secondary DSI host leads to Use-After-Free and Double-Free.
--
commit bd7c7e227b10119b2ca8cfde561c22808d05f4f2
Author: KancyJoe <kancy2333@outlook.com>
drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
This commit implements support for the Renesas 63419 based dual-DSI video
mode Display Panels used in the Ayaneo handheld gaming devices.
> diff --git a/drivers/gpu/drm/panel/panel-renesas-r63419.c b/drivers/gpu/drm/panel/panel-renesas-r63419.c
> new file mode 100644
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-renesas-r63419.c
[ ... ]
> +static int renesas_r63419_on(struct renesas_r63419_panel *ctx)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
> +
> + /*
> + * Panel registers are loaded from DDIC Non Volatile Memory
> + *
> + * The DDIC expects this sequence to get out of sleep and enable display
> + */
> +
> + mipi_dsi_dual(mipi_dsi_dcs_set_display_on_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
> + mipi_dsi_msleep(&dsi_ctx, 50);
> +
> + mipi_dsi_dual(mipi_dsi_dcs_exit_sleep_mode_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
[Severity: High]
Are these MIPI DCS commands sent in the correct order?
According to the standard, a display must exit sleep mode and wait for
internal initialization before processing the set_display_on command.
Sending set_display_on first might cause the sleeping DDIC to ignore it.
> + mipi_dsi_msleep(&dsi_ctx, 150);
> +
> + return dsi_ctx.accum_err;
> +}
[ ... ]
> +static int renesas_r63419_disable(struct drm_panel *panel)
> +{
> + struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
> +
> + mipi_dsi_dual(mipi_dsi_dcs_set_display_off_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
> + mipi_dsi_msleep(&dsi_ctx, 50);
> +
> + mipi_dsi_dual(mipi_dsi_dcs_enter_sleep_mode_multi,
> + &dsi_ctx, ctx->dsi[0], ctx->dsi[1]);
> + mipi_dsi_msleep(&dsi_ctx, 120);
> +
> + return 0;
> +}
[ ... ]
> +static const struct drm_panel_funcs renesas_r63419_panel_funcs = {
> + .disable = renesas_r63419_disable,
> + .prepare = renesas_r63419_prepare,
> + .unprepare = renesas_r63419_unprepare,
[Severity: High]
Should there be an enable callback to match the disable callback?
If the display pipeline is disabled and re-enabled during DPMS transitions,
the bridge framework cycles disable and enable. Since the panel receives
set_display_off and enter_sleep_mode during disable, but the enable
callback is missing, won't the panel remain permanently asleep when waking
up?
> + .get_modes = renesas_r63419_get_modes,
> + .get_orientation = renesas_r63419_get_orientation,
> +};
[ ... ]
> +static int renesas_r63419_probe(struct mipi_dsi_device *dsi)
> +{
[ ... ]
> + /* Register the second DSI device */
> + ctx->dsi[1] = devm_mipi_dsi_device_register_full(dev, dsi1_host, &info);
> + if (IS_ERR(ctx->dsi[1]))
> + return dev_err_probe(dev, PTR_ERR(ctx->dsi[1]),
> + "Failed to register second DSI device\n");
[Severity: High]
Does the secondary DSI device registration require a device link to protect
its lifetime?
If the secondary host is unbound via sysfs, the DSI core unregisters all
child devices, freeing this pointer. Without a device link to force the
panel to unbind first, could devm teardown or subsequent panel accesses
lead to a use-after-free or double-free?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625-topic-sm8650-ayaneo-pocket-s2-r63419-v8-0-8570e692143e@linaro.org?part=2
^ permalink raw reply
* [PATCH v5 0/7] drm/verisilicon: add Nuvoton MA35D1 DCU Lite support
From: Joey Lu @ 2026-06-25 9:44 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
This series adds support for the Verisilicon DCUltraLite display
controller as integrated in the Nuvoton MA35D1 SoC.
The Verisilicon DC driver and its DT binding were originally written by
Icenowy Zheng <zhengxingda@iscas.ac.cn> for the T-Head TH1520 SoC, which
carries a DC8200 IP block. The present series builds on that foundation
with gratitude to Icenowy for the original work.
The DCUltraLite is a different variant in the DC IP family. While the two
IPs share a broadly similar register layout, a number of differences
prevent the existing driver from working on the MA35D1 without
modification:
- No CONFIG_EX commit path: the DC8200 staging registers
(FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT, FB_BLEND_CONFIG,
PANEL_CONFIG_EX) are absent. The DCUltraLite uses enable (bit 0) and
reset (bit 4) bits in FB_CONFIG for direct framebuffer updates, and
requires a per-frame VALID bit toggle (FB_CONFIG bit 3) to latch
configuration changes.
- No PANEL_START register: panel output begins when
PANEL_CONFIG.RUNNING is set; the DC8200 multi-display sync start
register at 0x1CCC does not exist.
- Different IRQ registers: DISP_IRQ_STA at 0x147C / DISP_IRQ_EN at
0x1480, versus the DC8200's TOP_IRQ_ACK at 0x0010 / TOP_IRQ_EN at
0x0014.
- Simpler clock topology: two clocks ("core" bus gate and "pix0" pixel
divider); no axi or ahb clocks required.
- Single display output: no per-output indexing beyond index 0 is
needed.
- Hardware-discoverable identity: the DCUltraLite exposes chip identity
registers whose model field reads 0x0 (revision 0x5560,
customer_id 0x305), allowing the existing vs_fill_chip_identity()
path to identify the variant purely through register reads.
Patch 1 generalises the verisilicon,dc DT binding to accommodate the
Nuvoton MA35D1 SoC-specific compatible and the variant's two-clock,
one-reset, single-port topology.
Patch 2 adds the register-level macros needed by the DC8000 ops.
Patches 3-5 introduce the driver changes in three logical steps: the
vs_dc_funcs hardware ops vtable with DC8200 ops extracted into
vs_dc8200.c; making axi/ahb clocks optional as a separate atomic change;
and the DC8000 ops in vs_dc8000.c. Patch 6 adds the DCUltraLite HWDB
entry that gates hardware recognition once all support is in place.
Patch 7 adds the Kconfig dependency on ARCH_MA35, placed last because it
is only meaningful after the HWDB entry is added.
All patches have been tested on Nuvoton MA35D1 hardware.
Changes from v4:
- [dt-bindings] Kept clock and reset item descriptions in the global
clocks:/resets: properties; per-compatible sections only constrain
minItems/maxItems and override clock-names items for nuvoton,ma35d1-dcu.
- [dt-bindings] Dropped redundant global minItems/maxItems on clocks:
and clock-names:.
- [dt-bindings] Dropped the extra-space typo fix in port@0 description
to keep the patch atomic; left for a separate patch later.
- [ops] Renamed crtc_enable/crtc_disable hooks to crtc_enable_ex/
crtc_disable_ex.
- [ops] Added unified IRQ bit definitions; each irq_ack() implementation
now translates hardware-specific bits before returning.
- [clocks] Split the axi/ahb optional-clock change into its own patch
for atomicity.
- [hwdb] Simplified the commit message for patch 6.
- [kconfig] Simplified the commit message for patch 7.
Joey Lu (7):
dt-bindings: display: verisilicon,dc: generalize for single-output
variants
drm/verisilicon: add register-level macros for DC8000
drm/verisilicon: introduce per-variant hardware ops table
drm/verisilicon: make axi and ahb clocks optional
drm/verisilicon: add DC8000 (DCUltraLite) display controller support
drm/verisilicon: add DCUltraLite chip identity to HWDB
drm/verisilicon: extend Kconfig to support ARCH_MA35 platforms
.../bindings/display/verisilicon,dc.yaml | 57 +++++++++
drivers/gpu/drm/verisilicon/Kconfig | 2 +-
drivers/gpu/drm/verisilicon/Makefile | 2 +-
drivers/gpu/drm/verisilicon/vs_bridge.c | 20 +--
drivers/gpu/drm/verisilicon/vs_crtc.c | 38 +++++-
drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
drivers/gpu/drm/verisilicon/vs_dc.c | 13 +-
drivers/gpu/drm/verisilicon/vs_dc.h | 33 +++++
drivers/gpu/drm/verisilicon/vs_dc8000.c | 86 +++++++++++++
drivers/gpu/drm/verisilicon/vs_dc8200.c | 115 ++++++++++++++++++
drivers/gpu/drm/verisilicon/vs_drm.c | 5 +-
drivers/gpu/drm/verisilicon/vs_drm.h | 8 ++
drivers/gpu/drm/verisilicon/vs_hwdb.c | 14 +++
drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
.../gpu/drm/verisilicon/vs_primary_plane.c | 32 +----
.../drm/verisilicon/vs_primary_plane_regs.h | 3 +
16 files changed, 378 insertions(+), 57 deletions(-)
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
--
2.43.0
^ permalink raw reply
* [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Joey Lu @ 2026-06-25 9:44 UTC (permalink / raw)
To: zhengxingda, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel, Joey Lu
In-Reply-To: <20260625094449.708386-1-a0987203069@gmail.com>
The verisilicon,dc binding was originally written for the T-Head TH1520
SoC carrying a DC8200, and hard-codes five clocks, three resets and two
output ports.
Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to the binding.
The DCUltraLite uses only two clocks (core, pix0) and one reset (core),
with a single output port.
Use allOf/if blocks to express per-variant constraints rather than
hard-coding the DC8200 topology at the top level. Each compatible's
block constrains the clock and reset item counts; the nuvoton block
additionally overrides clock-names to the two names it actually uses.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
.../bindings/display/verisilicon,dc.yaml | 57 +++++++++++++++++++
1 file changed, 57 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
index 9dc35ab973f2..1e751f3c7ce8 100644
--- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
+++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
@@ -17,6 +17,7 @@ properties:
items:
- enum:
- thead,th1520-dc8200
+ - nuvoton,ma35d1-dcu
- const: verisilicon,dc # DC IPs have discoverable ID/revision registers
reg:
@@ -77,6 +78,62 @@ required:
- clock-names
- ports
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: thead,th1520-dc8200
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ maxItems: 5
+
+ clock-names:
+ minItems: 5
+ maxItems: 5
+
+ resets:
+ minItems: 3
+ maxItems: 3
+
+ reset-names:
+ minItems: 3
+ maxItems: 3
+
+ required:
+ - resets
+ - reset-names
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: nuvoton,ma35d1-dcu
+ then:
+ properties:
+ clocks:
+ minItems: 2
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: core
+ - const: pix0
+
+ resets:
+ minItems: 1
+ maxItems: 1
+
+ reset-names:
+ items:
+ - const: core
+
+ required:
+ - resets
+ - reset-names
+
additionalProperties: false
examples:
--
2.43.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox