* Re: [PATCH 08/12] rtc: rzn1: Dynamically calculate synchronization delay based on clock rate
From: Wolfram Sang @ 2026-06-17 10:58 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-9-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 737 bytes --]
As mentioned in another thread:
> drivers/rtc/rtc-rzn1.c | 19 ++++++++++++++-----
> 1 file changed, 14 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> index 06339adae71f..bc6af59744e4 100644
> --- a/drivers/rtc/rtc-rzn1.c
> +++ b/drivers/rtc/rtc-rzn1.c
> @@ -71,6 +71,7 @@ struct rzn1_rtc {
> */
> spinlock_t ctl1_access_lock;
> struct rtc_time tm_alarm;
> + unsigned long sync_time;
> int alarm_irq;
> int sec_irq;
> bool alarm_enabled;
rate = 32768 here...
> + rtc->sync_time = DIV_ROUND_UP(2 * NSEC_PER_MSEC, rate);
> +
> }
... and move this to the main body of the function.
Then, we should have all values always initialized.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Wolfram Sang @ 2026-06-17 10:57 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-8-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 4683 bytes --]
Hi,
Sashiko found issues, not introduced by your patch, but still.. I
curated the list and left only those which I think are valid. Do you
have time to look at these issues?
Thank you and happy hacking,
Wolfram
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Incorrect hardware alarm weekday assignment due to unsigned underflow when the alarm crosses a month boundary.
> - [High] Unconfigured alarms in `rzn1_rtc_read_alarm` can return an invalid `tm_wday` value of `-1`, risking out-of-bounds array access in userspace.
> - [High] Potential spurious interrupt when sequentially updating active hardware alarm registers.
> --
>
> commit d278abd6309a65fff235820bea9a8e8631da47be
> Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> Subject: rtc: rzn1: fix alarm range check truncation on 32-bit systems
>
> This commit fixes a silent truncation issue on 32-bit systems by changing
> the alarm and farest variables from unsigned long to time64_t. It also
> replaces the time_after() macro with a direct signed comparison.
>
> > diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> > index fe21fa6242881..06339adae71f6 100644
> > --- a/drivers/rtc/rtc-rzn1.c
> > +++ b/drivers/rtc/rtc-rzn1.c
> [ ... ]
> > @@ -265,8 +266,8 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> > {
> > struct rzn1_rtc *rtc = dev_get_drvdata(dev);
> > struct rtc_time *tm = &alrm->time, tm_now;
> > - unsigned long alarm, farest;
> > unsigned int days_ahead, wday;
> > + time64_t alarm, farest;
> > int ret;
> >
> > ret = rzn1_rtc_read_time(dev, &tm_now);
> > @@ -276,7 +277,7 @@ static int rzn1_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
> > /* We cannot set alarms more than one week ahead */
> > farest = rtc_tm_to_time64(&tm_now) + rtc->rtcdev->alarm_offset_max;
> > alarm = rtc_tm_to_time64(tm);
> > - if (time_after(alarm, farest))
> > + if (alarm > farest)
> > return -ERANGE;
> >
> > /* Convert alarm day into week day */
>
> [Severity: High]
> This isn't a bug introduced by this patch, but does the calculation for
> days_ahead underflow if the alarm crosses a month boundary?
>
> In rzn1_rtc_set_alarm(), days_ahead is typed as an unsigned int and is
> calculated like this:
>
> days_ahead = tm->tm_mday - tm_now.tm_mday;
> wday = (tm_now.tm_wday + days_ahead) % 7;
>
> If the alarm is set for the 1st of the next month, and today is the 31st,
> the subtraction results in -30. When assigned to an unsigned int, this
> underflows. Because 2^32 % 7 evaluates to 4, the resulting wday calculation
> shifts the weekday by exactly 4 days, causing the hardware alarm register
> to be programmed for the wrong day.
>
> [Severity: High]
> This is a pre-existing issue, but is there a risk of a spurious interrupt
> when updating the active hardware alarm registers?
>
> Just below this hunk in rzn1_rtc_set_alarm(), the match registers are
> updated sequentially:
>
> writel(bin2bcd(tm->tm_min), rtc->base + RZN1_RTC_ALM);
> writel(bin2bcd(tm->tm_hour), rtc->base + RZN1_RTC_ALH);
> writel(BIT(wday), rtc->base + RZN1_RTC_ALW);
>
> The RTC core can invoke this function without first disabling the hardware
> alarm if replacing an existing timer. If the hardware alarm interrupt is
> active, modifying these registers sequentially could cause the intermediate
> hardware state to momentarily match the current time, triggering a spurious
> interrupt and prematurely expiring the next timer in the queue.
>
> [Severity: High]
> This is a pre-existing issue, but what happens in rzn1_rtc_read_alarm() if
> the hardware alarm is unconfigured?
>
> If the hardware alarm register reads 0, fls(0) - 1 evaluates to -1:
>
> drivers/rtc/rtc-rzn1.c:rzn1_rtc_read_alarm() {
> ...
> wday = readl(rtc->base + RZN1_RTC_ALW);
> ...
> delta_days = ((fls(wday) - 1) - tm->tm_wday + 7) % 7;
> tm->tm_wday = fls(wday) - 1;
> ...
> }
>
> If the current weekday is Saturday (6), delta_days evaluates to 0:
> ((-1 - 6 + 7) % 7) == 0.
>
> Because delta_days is 0, the rtc_time64_to_tm() block is skipped, and the
> function returns with tm->tm_wday = -1. Since rtc_valid_tm() does not
> bound-check tm_wday, this -1 is passed to userspace where tools commonly
> use it as an array index, which could cause an out-of-bounds memory read.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=7
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v3 2/4] spi: qcom-geni: Use geni_se_resources_init() for resource initialization
From: Konrad Dybcio @ 2026-06-17 10:57 UTC (permalink / raw)
To: Praveen Talari, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, bjorn.andersson
Cc: linux-arm-msm, linux-spi, devicetree, linux-kernel,
mukesh.savaliya, aniket.randive, chandana.chiluveru,
jyothi.seerapu, chiluka.harish
In-Reply-To: <20260604-enable-spi-on-sa8255p-v3-2-43984eac4c67@oss.qualcomm.com>
On 6/4/26 8:50 AM, Praveen Talari wrote:
> Replace resources initialization such as clocks, ICC path and OPP with the
> common geni_se_resources_init() function to avoid code duplication across
> all drivers.
>
> The geni_se_resources_init() function handles all these resources
> internally, reducing code duplication and ensuring consistent resource
> management across GENI SE drivers.
>
> Signed-off-by: Praveen Talari <praveen.talari@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 5/5] dt-bindings: watchdog: mediatek: Add MT8127
From: Krzysztof Kozlowski @ 2026-06-17 10:56 UTC (permalink / raw)
To: Zakariya Hadrami
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, linux-watchdog
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-5-d02ad15ac359@proton.me>
On Wed, Jun 17, 2026 at 11:20:14AM +0900, Zakariya Hadrami wrote:
> Add entry for MT8127 SoC's watchdog which is compatible with MT6589's
> one.
>
> Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
> ---
> Documentation/devicetree/bindings/watchdog/mediatek,mtk-wdt.yaml | 1 +
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
<form letter>
This is an automated instruction, just in case, because many review
tags are being ignored. If you know the process, just skip it entirely
(please do not feel offended by me posting it here - no bad intentions
intended, no patronizing, I just want to avoid wasted efforts). If you
do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here ('b4 trailers -u ...').
However, there's no need to repost patches *only* to add the tags. The
upstream maintainer will do that for tags received on the version they
apply.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/process/submitting-patches.rst#L591
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/5] ARM: dts: mediatek: Add basic support for Amazon ford board
From: Krzysztof Kozlowski @ 2026-06-17 10:55 UTC (permalink / raw)
To: Zakariya Hadrami
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, linux-watchdog
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-3-d02ad15ac359@proton.me>
On Wed, Jun 17, 2026 at 11:20:12AM +0900, Zakariya Hadrami wrote:
> This tablet uses a MediaTek MT8127 system-on-chip with 1GB of RAM.
> It can currently boot into initramfs with a working UART and
> Simple Framebuffer using already initialized panel by the bootloader.
>
> Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
> ---
> arch/arm/boot/dts/mediatek/Makefile | 1 +
> arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts | 46 +++++++++++++++++++++++
> 2 files changed, 47 insertions(+)
>
> diff --git a/arch/arm/boot/dts/mediatek/Makefile b/arch/arm/boot/dts/mediatek/Makefile
> index 37c4cded0eae..a610bc75c7d9 100644
> --- a/arch/arm/boot/dts/mediatek/Makefile
> +++ b/arch/arm/boot/dts/mediatek/Makefile
> @@ -14,5 +14,6 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt7623n-rfb-emmc.dtb \
> mt7623n-bananapi-bpi-r2.dtb \
> mt7629-rfb.dtb \
> + mt8127-amazon-ford.dtb \
> mt8127-moose.dtb \
> mt8135-evbp1.dtb
> diff --git a/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
> new file mode 100644
> index 000000000000..21bdab0e43f8
> --- /dev/null
> +++ b/arch/arm/boot/dts/mediatek/mt8127-amazon-ford.dts
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/dts-v1/;
> +#include "mt8127.dtsi"
> +
> +/ {
> + model = "MediaTek MT8127 Amazon Ford";
> + compatible = "amazon,ford", "mediatek,mt8127";
Please organize the patch documenting the compatible (DT bindings)
before the patch using that compatible.
See also: https://elixir.bootlin.com/linux/v6.14-rc6/source/Documentation/devicetree/bindings/submitting-patches.rst#L46
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 4/5] dt-bindings: arm: mediatek: Add MT8127 Amazon ford
From: Krzysztof Kozlowski @ 2026-06-17 10:55 UTC (permalink / raw)
To: Zakariya Hadrami
Cc: Matthias Brugger, AngeloGioacchino Del Regno, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Wang, Wim Van Sebroeck,
Guenter Roeck, linux-kernel, linux-arm-kernel, linux-mediatek,
devicetree, linux-watchdog
In-Reply-To: <20260617-mt8127-amazon-ford-basic-v1-4-d02ad15ac359@proton.me>
On Wed, Jun 17, 2026 at 11:20:13AM +0900, Zakariya Hadrami wrote:
> Add entry for the MT8127 based Amazon ford tablet.
>
> Signed-off-by: Zakariya Hadrami <zkh1@proton.me>
> ---
> Documentation/devicetree/bindings/arm/mediatek.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml
> index 382d0eb4d0af..5ddc79689df9 100644
> --- a/Documentation/devicetree/bindings/arm/mediatek.yaml
> +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml
> @@ -124,6 +124,10 @@ properties:
> - enum:
> - mediatek,mt8127-moose
> - const: mediatek,mt8127
> + - items:
> + - enum:
> + - amazon,ford
And it is not part of existing enum because?
> + - const: mediatek,mt8127
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 6/6] arm64: dts: qcom: Add AYN Thor
From: Konrad Dybcio @ 2026-06-17 10:55 UTC (permalink / raw)
To: webgeek1234, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Teguh Sobirin
In-Reply-To: <20260503-ayn-qcs8550-v8-6-d733f5e57446@gmail.com>
On 5/3/26 11:48 PM, Aaron Kling via B4 Relay wrote:
> From: Teguh Sobirin <teguh@sobir.in>
>
> The AYN Thor is a high-performance Android-based handheld gaming console
> powered by the Qualcomm Snapdragon 8 Gen 2 processor featuring dual
> AMOLED touchscreens.
>
> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
[...]
> +&i2c4 {
> + clock-frequency = <400000>;
> +
> + status = "okay";
'status' is generally meant to be the last property
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
especially since these ones are already defined in the included SoC DTSI
(and would only be necessary when building a DTBO, which I know is your
ultimate usecase, but which you aren't doing in this patch)
Perhaps Bjorn can fix that up while applying..
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v8 3/6] arm64: dts: qcom: Add AYN QCS8550 Common
From: Konrad Dybcio @ 2026-06-17 10:52 UTC (permalink / raw)
To: webgeek1234, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Teguh Sobirin
In-Reply-To: <20260503-ayn-qcs8550-v8-3-d733f5e57446@gmail.com>
On 5/3/26 11:48 PM, Aaron Kling via B4 Relay wrote:
> From: Teguh Sobirin <teguh@sobir.in>
>
> This contains everything common between the AYN QCS8550 devices. It will
> be included by device specific dts'.
>
> Signed-off-by: Teguh Sobirin <teguh@sobir.in>
> Co-developed-by: Aaron Kling <webgeek1234@gmail.com>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: sound: add toshiba,apb-dummy-codec binding
From: Krzysztof Kozlowski @ 2026-06-17 10:50 UTC (permalink / raw)
To: Pablo D. Bergamasco
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vaibhav Agarwal,
Mark Greer, Liam Girdwood, Mark Brown, linux-sound, devicetree,
linux-kernel
In-Reply-To: <20260616185619.1581174-1-danpablo@gmail.com>
On Tue, Jun 16, 2026 at 03:56:19PM -0300, Pablo D. Bergamasco wrote:
> Add device tree binding documentation for the Toshiba APBridge
> dummy ALSA SoC codec used in the Greybus audio framework.
>
> Fixes the following checkpatch warning:
> WARNING: DT compatible string appears un-documented
Nope. We don't take bindings for staging. Isn't this documented in
staging docs already?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Wolfram Sang @ 2026-06-17 10:49 UTC (permalink / raw)
To: Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260615154805.1619693-8-prabhakar.mahadev-lad.rj@bp.renesas.com>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On Mon, Jun 15, 2026 at 04:48:00PM +0100, Prabhakar wrote:
> From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> alarm and farest were declared as unsigned long, but
> rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where
> unsigned long is 32 bits, the assignment silently truncates the upper
> 32 bits of the timestamp.
>
> Fix by declaring alarm and farest as time64_t and replacing
> time_after() with a direct signed comparison, which is correct for
> time64_t values that will never realistically overflow.
>
> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
I need to postpone testing this to the evening. Setting alarm behaves
strange here for alarms beyond the one-week-ahead-limit. No error, but
bogus values. Seems to be irrelevant to your patch, though. Does it work
for you?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Krzysztof Kozlowski @ 2026-06-17 10:49 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel, Frieder Schrempf
In-Reply-To: <20260616-upstreaming-next-20260609-imx-ocotp-ele-v1-1-cb7f3698c3e6@kontron.de>
On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> Some SoCs like the i.MX9 family allow full access to the fuses only
> through the secure enclave firmware API. Add a property to reference
> the secure enclave node and let the driver use the API.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> ---
> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> index a8076d0e2737..14a6429f4a4c 100644
> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
> @@ -53,6 +53,10 @@ properties:
> reg:
> maxItems: 1
>
> + secure-enclave:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description: A phandle to the secure enclave node
Two things here:
1. Here you describe what for is that phandle, how it is used by the
hardware. Currently the description repeats the property name and type,
so not much useful.
2. If you access OTP via firmware, then this is completely different
interface than MMIO, thus:
A. reg is not appropriate
B. Device is very different thus it has different compatible and I even
claim should be in different binding. Devices having completely
different SW interface should not be in the same binding, at least
usually.
If any of above is not accurate, then your commit msg should answer why
and give some background.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: qcom: ipq5210: Enable PCIe support
From: Konrad Dybcio @ 2026-06-17 10:47 UTC (permalink / raw)
To: Varadarajan Narayanan
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, linux-arm-msm,
linux-pci, devicetree, linux-kernel
In-Reply-To: <aifGReQQ12BdgCMb@hu-varada-blr.qualcomm.com>
On 6/9/26 9:52 AM, Varadarajan Narayanan wrote:
> On Mon, Jun 08, 2026 at 11:44:56AM +0200, Konrad Dybcio wrote:
>> On 6/4/26 1:28 PM, Varadarajan Narayanan wrote:
>>> On Fri, May 22, 2026 at 02:24:45PM +0200, Konrad Dybcio wrote:
>>>> On 5/14/26 6:13 AM, Varadarajan Narayanan wrote:
>>>>> Add DT entries to enable the PCIe controllers found in ipq5210.
>>>>>
>>>>> Signed-off-by: Varadarajan Narayanan <varadarajan.narayanan@oss.qualcomm.com>
>>>>> ---
>>
>> [...]
>>
>>>>> +
>>>>> + resets = <&gcc GCC_PCIE0_PHY_BCR>,
>>>>> + <&gcc GCC_PCIE0PHY_PHY_BCR>;
>>>>> + reset-names = "phy", "common";
>>>>> +
>>>>> + #clock-cells = <0>;
>>>>> + clock-output-names = "gcc_pcie0_pipe_clk_src";
>>>>
>>>> Having a gcc_ prefix here smells fishy..
>>>
>>> Followed what was used in ipq9574, ipq5424 etc. Will remove gcc_ & _src.
>>
>> What is the name of the PHY's output in the clock plan? I would assume
>> it doesn't have gcc_, but it may end in _src..
>
> In the clock plan it is called as gcc_pcie0_pipe_clk_src and
> gcc_pcie1_pipe_clk_src.
Let's follow prior art (glymur.dtsi) and call it pcie<N>_pipe_clk
Konrad
^ permalink raw reply
* Re: [PATCH 7/7] arm64: dts: qcom: sm8350-hdk: describe WiFi/BT chip
From: Konrad Dybcio @ 2026-06-17 10:46 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Manivannan Sadhasivam, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Qiang Yu,
Jeff Johnson, Liam Girdwood, Mark Brown, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
Bjorn Andersson, Konrad Dybcio, linux-arm-msm, linux-pci,
linux-kernel, linux-wireless, ath11k, devicetree,
Bartosz Golaszewski, linux-bluetooth
In-Reply-To: <dz4qovpquxgynnzviqg6g23oa2o3trlkznremnmlqfnlj3b62x@oqgcuvalfcph>
On 6/11/26 9:44 PM, Dmitry Baryshkov wrote:
> On Thu, Jun 11, 2026 at 02:09:27PM +0200, Konrad Dybcio wrote:
>> On 6/1/26 11:46 AM, Dmitry Baryshkov wrote:
>>> The SM8350 HDK has onboard WiFi/BT chip, WCN6851. It is an earlier
>>> version of well-known WCN6855 WiFI/BT SoC. Describe the PMU, BT and WiFI
>>> parts of the device.
>>
>> [...]
>>
>>> + wcn6855-pmu {
>>> + compatible = "qcom,wcn6851-pmu", "qcom,wcn6855-pmu";
>>> +
>>> + pinctrl-0 = <&bt_en>, <&wlan_en>, <&swctrl>;
>>> + pinctrl-names = "default";
>>> +
>>> + wlan-enable-gpios = <&tlmm 64 GPIO_ACTIVE_HIGH>;
>>> + bt-enable-gpios = <&tlmm 65 GPIO_ACTIVE_HIGH>;
>>> + swctrl-gpios = <&tlmm 153 GPIO_ACTIVE_HIGH>;
>>> +
>>> + vddio-supply = <&vreg_s10b_1p8>;
>>> + vddaon-supply = <&vreg_s11b_0p95>;
>>> + vddpmu-supply = <&vreg_s11b_0p95>;
>>> + vddpmumx-supply = <&vreg_s2e_0p85>;
>>> + vddpmucx-supply = <&vreg_s11b_0p95>;
>>> + vddrfa0p95-supply = <&vreg_s11b_0p95>;
>>> + vddrfa1p3-supply = <&vreg_s12b_1p25>;
>>> + vddrfa1p9-supply = <&vreg_s1c_1p86>;
>>> + vddpcie1p3-supply = <&vreg_s12b_1p25>;
>>> + vddpcie1p9-supply = <&vreg_s1c_1p86>;
>>
>> [...]
>>
>>> @@ -373,6 +437,13 @@ vreg_l7e_2p8: ldo7 {
>>> regulator-name = "vreg_l7e_2p8";
>>> regulator-min-microvolt = <2800000>;
>>> regulator-max-microvolt = <2800000>;
>>> +
>>> + /*
>>> + * This is used by the RF front-end for which there is
>>> + * no way to represent it in DT (yet?).
>>> + */
>>> + regulator-boot-on;
>>> + regulator-always-on;
>>
>> msm-5.4 maps this to bt-vdd-asd-supply (asd being a keyboard smash,
>> perhaps?) - what is its actual use?
>
> WiFI/BT RF front-end, a separate chip containing amplifiers, couplers,
> etc.
>
> It is a separate chip (or a module), it is not powered on by the PMU,
> etc.
Ah, that thing.. yeah I don't really know. Although it'd be a shame to
keep it powered forever, so maybe one day someone will revisit this
Konrad
^ permalink raw reply
* Re: [PATCH 0/4] input: misc: Add an initial driver for haptics inside Qcom PMIH010x PMIC
From: Krzysztof Kozlowski @ 2026-06-17 10:42 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <20260616-qcom-spmi-haptics-v1-0-d24e422de6b4@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 03:08:23AM -0700, Fenglin Wu wrote:
Here - the first sentence - is where you mention merging
constraints/strategy/dependencies. Your MFD patch depends on ealier
ones.
> Qualcomm PMIH010x PMIC has a haptics module inside and it could drive
> a LRA actuator with several play modes, including: DIRECT_PLAY, FIFO,
> PAT_MEM, SWR, etc. Add an initial driver to support two of the play
> modes using the input force-feedback framework:
>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
From: Konrad Dybcio @ 2026-06-17 10:41 UTC (permalink / raw)
To: webgeek1234, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260605-sm8750-ddr-bw-scaling-v1-1-f39f918c95a7@gmail.com>
On 6/6/26 12:36 AM, Aaron Kling via B4 Relay wrote:
> From: Aaron Kling <webgeek1234@gmail.com>
>
> Add the OPP tables for each CPU cluster (cpu0-1-2-3-4-5 & cpu6-7) to
> permit scaling the Last Level Cache Controller (LLCC) and DDR frequency
> by aggregating bandwidth requests of all CPU core with reference to the
> current OPP they are configured in by the hardware.
>
> The effect is proper caches & DDR frequency scaling when CPU cores
> change frequency.
>
> The OPP tables were built using the downstream memlat ddr & llcc tables
> for each cluster types with the actual cpufreq LUT tables from running a
> CQ8725S device.
>
> Also add the interconnect entry for each cpu, with 2 different paths:
> - CPU to Last Level Cache Controller (LLCC)
> - Last Level Cache Controller (LLCC) to DDR
>
> Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
> ---
> arm64: dts: qcom: sm8750: add cpu OPP table with DDR and LLCC bandwidths
> ---
[...]
> + cpu6_opp_table: opp-table-cpu6 {
> + compatible = "operating-points-v2";
> + opp-shared;
> +
> + opp-1017600000 {
> + opp-hz = /bits/ 64 <1017600000>;
> + opp-peak-kBps = <(1353000 * 16) (350000 * 4)>;
I think this should be * 4 in both cases since the interconnect driver
ignores the channel count for a node in peak voting. We may have a bug
in all other DTs here.
BTW, are there no lower OPPs for the fast cores?
Konrad
^ permalink raw reply
* Re: [PATCH v4 5/6] drm/verisilicon: add DCUltraLite chip identity to HWDB
From: Joey Lu @ 2026-06-17 10:37 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <62c0b8ab9b6d9f994daa8bb60b3b626688af7d5e.camel@iscas.ac.cn>
On 6/15/2026 4:57 PM, Icenowy Zheng wrote:
> 在 2026-06-15一的 14:50 +0800，Joey Lu写道：
>> Register the Nuvoton MA35D1 DCUltraLite chip identity in
>> vs_chip_identities[]:
>> model = 0x0 (DCUltraLite; Verisilicon uses 0 for this IP)
>> revision = 0x5560
>> customer_id = 0x305
>> generation = VSDC_GEN_DC8000
>> display_count = 1
>> max_cursor_size = 32
> I suggest make this more human-readable instead of replicating the
> machine-readable data of HWDB.
>
> My proposal here:
>
> ```
> The Nuvoton MA35D1 chip contains a DCUltraLite display controller with
> model number 0x0 (sic, the model name contains no number either),
> revision 0x5560 and customer ID 0x305. It has a similar register map
> with DC8000, only one display output and only 32x32 cursor supported.
> ```
Thanks. I will use your proposed wording for the commit message in v5
>> Placing this entry last makes it the gate that enables MA35D1
>> hardware
>> recognition only after all the supporting ops and DT binding changes
>> are
>> in place.
> It's a little ambiguous that "last" here means whether the last in the
> patchset or the last in the HWDB array, although I think it's not so
> needed to explain the reason of the place in the patchset.
>
> I propose just say `Adding it to the HWDB to enable it to be usable
> with the verisilicon driver.` .
I will simplify the placement sentence to "Adding it to the HWDB to
enable it to be usable with the verisilicon driver." in v5.
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> drivers/gpu/drm/verisilicon/vs_hwdb.c | 10 ++++++++++
>> 1 file changed, 10 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> b/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> index 91524d16f778..7d630a667a3f 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> @@ -129,6 +129,16 @@ static struct vs_chip_identity
>> vs_chip_identities[] = {
>> .max_cursor_size = 64,
>> .formats = &vs_formats_no_yuv444,
>> },
>> + {
>> + .model = 0x0, /* DCUltraLite */
>> + .revision = 0x5560,
>> + .customer_id = 0x305,
>> +
>> + .generation = VSDC_GEN_DC8000,
>> + .display_count = 1,
>> + .max_cursor_size = 32,
>> + .formats = &vs_formats_no_yuv444,
>> + },
>> };
>>
>> int vs_fill_chip_identity(struct regmap *regs,
^ permalink raw reply
* Re: [PATCH v3 2/2] interconnect: qcom: add MSM8x60 NoC driver
From: Konrad Dybcio @ 2026-06-17 10:36 UTC (permalink / raw)
To: Herman van Hazendonk, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <20260606-submit-interconnect-msm8660-v3-2-f9da0158cdf8@herrie.org>
On 6/6/26 2:34 PM, Herman van Hazendonk wrote:
> Add a Qualcomm interconnect driver for the MSM8x60 family modelling the
> four NoC fabrics (APPSS, System, MMSS, Daytona) that connect masters
> and slaves on these Scorpion-class SoCs. The driver implements the
> interconnect-provider API to manage bandwidth between specific masters
> and slaves via the RPM arbitration tables.
[...]
> +/*
> + * Minimum fabric clock rate to prevent bus starvation.
> + *
> + * When no consumers request bandwidth, the rate calculation yields 0,
> + * causing fabric clocks to drop to minimum. This creates bimodal
> + * performance: fast when other subsystems (like display) happen to
> + * request bandwidth, slow otherwise.
> + *
> + * 384 MHz keeps fabric fast during concurrent MDP display scanout
> + * and USB gadget traffic. legacy vendor kernel docs: "AXI bus frequency needs to be
> + * kept at maximum value while USB data transfers are happening."
> + * 266 MHz was insufficient - USB crashed during display activity.
> + */
> +#define MSM8660_FABRIC_MIN_RATE 384000000UL /* 384 MHz */
Can you ensure that through a vote in the USB driver?
Konrad
^ permalink raw reply
* Re: [PATCH v4 4/6] drm/verisilicon: add DC8000 (DCUltraLite) display controller support
From: Joey Lu @ 2026-06-17 10:35 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <d5df0e9df3a9a68aae982f2fce830a4b10468476.camel@iscas.ac.cn>
On 6/15/2026 4:51 PM, Icenowy Zheng wrote:
> 在 2026-06-15一的 14:50 +0800，Joey Lu写道：
>> The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltraLite display
>> controller whose register layout differs from the DC8200 in several
>> important ways:
>>
>> 1. No CONFIG_EX commit path: framebuffer updates use the enable (bit
>> 0)
>> and reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
>> registers (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT,
>> FB_BLEND_CONFIG, PANEL_CONFIG_EX).
>>
>> 2. No PANEL_START register: panel output starts when
>> PANEL_CONFIG.RUNNING is set; there is no multi-display sync start
>> register.
>>
>> 3. Different IRQ registers: DCUltraLite uses DISP_IRQ_STA (0x147C) /
>> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
>> TOP_IRQ_EN (0x0014).
>>
>> 4. Per-frame commit cycle: DCUltraLite requires the VALID bit in
>> FB_CONFIG to be set at the start of each atomic commit
>> (crtc_begin)
>> and cleared after (crtc_flush).
>>
>> 5. Simpler clock topology: only 'core' (bus gate) and 'pix0' (pixel
>> divider) clocks; no axi or ahb clocks required. Make axi_clk and
>> ahb_clk optional (devm_clk_get_optional_enabled) so DC8000 nodes
>> without those clocks are handled gracefully.
>>
>> Add vs_dc8000.c implementing the vs_dc_funcs vtable for the above
>> differences. The probe now selects vs_dc8000_funcs when the
>> identified
>> generation is VSDC_GEN_DC8000 (DCUltraLite reads model 0x0,
>> revision 0x5560, customer_id 0x305).
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> drivers/gpu/drm/verisilicon/Makefile | 2 +-
>> drivers/gpu/drm/verisilicon/vs_dc.c | 9 ++-
>> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
>> drivers/gpu/drm/verisilicon/vs_dc8000.c | 78
>> +++++++++++++++++++++++++
>> 4 files changed, 86 insertions(+), 4 deletions(-)
>> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8000.c
>>
>> diff --git a/drivers/gpu/drm/verisilicon/Makefile
>> b/drivers/gpu/drm/verisilicon/Makefile
>> index 9d4cd16452fa..d2fd8e4dff24 100644
>> --- a/drivers/gpu/drm/verisilicon/Makefile
>> +++ b/drivers/gpu/drm/verisilicon/Makefile
>> @@ -1,6 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>>
>> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
>> vs_drm.o vs_hwdb.o \
>> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
>> vs_dc8000.o vs_drm.o vs_hwdb.o \
>> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>>
>> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
>> b/drivers/gpu/drm/verisilicon/vs_dc.c
>> index 9729b693d360..9499fffbca58 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
>> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> return PTR_ERR(dc->core_clk);
>> }
>>
>> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
>> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
>> if (IS_ERR(dc->axi_clk)) {
>> dev_err(dev, "can't get axi clock\n");
>> return PTR_ERR(dc->axi_clk);
>> }
>>
>> - dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
>> + dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
> Please make the clock change a separated patch for atomicity.
>
> BTW the MA35D1 manual's clock tree shows that DCUltra appears on AXI2
> ACLK, AHB_HCLK2, behind a mux of SYS-PLL/EPLL-DIV2 (which seems to be
> the core clock), and behind a divider (which seems to be the pixel
> clock).
>
> However it's weird that only one DCUltra Clock Enable Bit exists
> despite both bus clocks have "ICG" (I think it means "Integrated Clock
> Gating"). In addition the linux clk-ma35d1 driver assigns "dcu_gate" as
> a downstream of "dcu_mux", although the Figure 6.5-2 in the TRM shows
> no ICG after the "Display core CLK" mux.
>
> Is the two bus clocks controlled by a single gate bit, and is the bit
> also gating DC core clock?
>
> Thanks,
> Icenowy
I will split the axi/ahb optional-clock change into its own patch in v5
for atomicity.
Regarding the MA35D1 clock tree: from the TRM, the single "dcu_gate" bit
gates both bus clocks (AXI ACLK and AHB HCLK) together with the display
core clock through the same ICG cell. The clk-ma35d1 driver exposes only
"dcu_gate" (downstream of "dcu_mux") and does not provide separate
axi/ahb clock entries. Therefore the MA35D1 DT binding will use only two
clocks ("core" and "pix0"); making axi and ahb optional in the driver is
the correct approach, and this will be stated clearly in the split-out
patch.
>> if (IS_ERR(dc->ahb_clk)) {
>> dev_err(dev, "can't get ahb clock\n");
>> return PTR_ERR(dc->ahb_clk);
>> @@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
>>> identity.model,
>> dc->identity.revision, dc->identity.customer_id);
>>
>> - dc->funcs = &vs_dc8200_funcs;
>> + if (dc->identity.generation == VSDC_GEN_DC8200)
>> + dc->funcs = &vs_dc8200_funcs;
>> + else
>> + dc->funcs = &vs_dc8000_funcs;
>>
>> if (port_count > dc->identity.display_count) {
>> dev_err(dev, "too many downstream ports than HW
>> capability\n");
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
>> b/drivers/gpu/drm/verisilicon/vs_dc.h
>> index 544e1a37065b..5218e8cf63e2 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
>> @@ -66,5 +66,6 @@ struct vs_dc {
>> };
>>
>> extern const struct vs_dc_funcs vs_dc8200_funcs;
>> +extern const struct vs_dc_funcs vs_dc8000_funcs;
>>
>> #endif /* _VS_DC_H_ */
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8000.c
>> b/drivers/gpu/drm/verisilicon/vs_dc8000.c
>> new file mode 100644
>> index 000000000000..be0c0d7baf52
>> --- /dev/null
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc8000.c
>> @@ -0,0 +1,78 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2026 Joey Lu <yclu4@nuvoton.com>
>> + */
>> +
>> +#include <linux/regmap.h>
>> +
>> +#include "vs_crtc_regs.h"
>> +#include "vs_dc.h"
>> +#include "vs_primary_plane_regs.h"
>> +
>> +static void vs_dc8000_panel_enable_ex(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_RESET);
>> +}
>> +
>> +static void vs_dc8000_panel_disable_ex(struct vs_dc *dc, unsigned
>> int output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_RESET);
>> +}
>> +
>> +static void vs_dc8000_crtc_begin(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_VALID);
>> +}
>> +
>> +static void vs_dc8000_crtc_flush(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_VALID);
>> +}
>> +
>> +static void vs_dc8000_crtc_enable(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_ENABLE);
>> +}
>> +
>> +static void vs_dc8000_crtc_disable(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_ENABLE);
>> +}
>> +
>> +static void vs_dc8000_enable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_DISP_IRQ_EN,
>> + VSDC_DISP_IRQ_VSYNC(output));
>> +}
>> +
>> +static void vs_dc8000_disable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_DISP_IRQ_EN,
>> + VSDC_DISP_IRQ_VSYNC(output));
>> +}
>> +
>> +static u32 vs_dc8000_irq_ack(struct vs_dc *dc)
>> +{
>> + u32 irqs;
>> +
>> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &irqs);
>> + return irqs;
>> +}
>> +
>> +const struct vs_dc_funcs vs_dc8000_funcs = {
>> + .panel_enable_ex = vs_dc8000_panel_enable_ex,
>> + .panel_disable_ex = vs_dc8000_panel_disable_ex,
>> + .crtc_begin = vs_dc8000_crtc_begin,
>> + .crtc_flush = vs_dc8000_crtc_flush,
>> + .crtc_enable = vs_dc8000_crtc_enable,
>> + .crtc_disable = vs_dc8000_crtc_disable,
>> + .enable_vblank = vs_dc8000_enable_vblank,
>> + .disable_vblank = vs_dc8000_disable_vblank,
>> + .irq_ack = vs_dc8000_irq_ack,
>> +};
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: input: Add binding for Qualcomm SPMI PMIC haptics
From: Krzysztof Kozlowski @ 2026-06-17 10:35 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <20260616-qcom-spmi-haptics-v1-1-d24e422de6b4@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 03:08:24AM -0700, Fenglin Wu wrote:
> Add binding document for the haptics module inside Qualcomm PMIH010X.
A nit, subject: drop second/last, redundant "binding for". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
>
> Assisted-by: Claude:claude-4-6-sonnet
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> .../bindings/input/qcom,spmi-haptics.yaml | 119 +++++++++++++++++++++
> 1 file changed, 119 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml b/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml
> new file mode 100644
> index 000000000000..0e26d68563dc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml
Filenamem should match compatible.
> @@ -0,0 +1,119 @@
> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/qcom,spmi-haptics.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Haptics device inside Qualcomm Technologies, Inc. PMIH010X
> +
> +maintainers:
> + - Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> +
...
> +properties:
> + compatible:
> + const: qcom,pmih010x-haptics
Don't use Claude. It does not understand DT. Please read writing
bindings document or DTS101 slides. You cannot have wildcards.
> +
> + reg:
> + items:
> + - description: HAP_CFG module base address
> + - description: HAP_PTN module base address
> +
> + reg-names:
> + items:
> + - const: hap-cfg
cfg
> + - const: hap-ptn
ptn
> +
> + interrupts:
> + maxItems: 1
> +
> + interrupt-names:
> + items:
> + - const: fifo-empty
> +
> + qcom,vmax-mv:
And claude did not tell you that this is not correct? If so, please
don't use it. It's crap tool if it cannot get the basics of DT (was
mentioned on talks many times, is documented etc).
You need proper suffix.
> + description:
> + Maximum allowed output driving voltage in millivolts, rounded to the
> + nearest 50 mV step. This is the peak driving voltage in DIRECT_PLAY mode
> + which outputs sinusoidal waveforms. The value should be equal to the square
> + root of 2 times the Vrms voltage of the LRA.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 50
> + maximum: 10000
> +
> + qcom,lra-period-us:
> + description:
> + LRA actuator initial resonance period in microseconds
> + (1,000,000 / resonant_freq_hz). Used to configure T_LRA-based play
> + rates and the auto-resonance zero-crossing window.
This does not feel like static characteristic. Isn't period depending on
intensity of vibration you want to have? Why would that be fixed per
board?
> + minimum: 5
> + maximum: 20475
> +
> +required:
> + - compatible
> + - reg
> + - reg-names
> + - interrupts
> + - interrupt-names
> + - qcom,vmax-mv
> + - qcom,lra-period-us
> +
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] PCI: rcar-gen4: Configure AXIINTC if iMSI-RX not used
From: Manivannan Sadhasivam @ 2026-06-17 10:33 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Marc Zyngier, Rob Herring,
devicetree, linux-arm-kernel, linux-doc, linux-kernel,
linux-renesas-soc
In-Reply-To: <20260617030008.154449-1-marek.vasut+renesas@mailbox.org>
On Wed, Jun 17, 2026 at 04:59:44AM +0200, Marek Vasut wrote:
> In case MSI are enabled, but DWC built-in iMSI-RX is not in use, the
> MSI are handled via GIC ITS. Configure all controller MSI registers
> fully.
>
> Set or clear MSI capability register MSICAP0 MSI enable MSIE bit and
> PCIe Interrupt Status 0 Enable register PCIEINTSTS0EN MSI interrupt
> enable MSI_CTRL_INT bit according to MSI enable state, set both bits
> if MSI are enabled, clear both bits if MSI are disabled.
>
> If MSI are disabled, or MSI are enabled and iMSI-RX is used, then
> deconfigure AXIINTCADDR and AXIINTCCONT to 0, which disables any
> pass through of MSI TLPs onto the AXI bus and then further into
> GIC ITS translation registers.
>
> If MSI are enabled and iMSI-RX is not used, the configure AXIINTCADDR
> with target address of GIC ITS translation registers, and configure
> AXIINTCCONT to enable MSI TLP pass through onto AXI bus and into the
> GIC ITS. This specific configuration allows handling of MSI via the
> GIC ITS instead of integrated iMSI-RX.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> ---
> NOTE: This would not be possible without prior work from Shimoda-san
> ---
> Cc: "Krzysztof Wilczyński" <kwilczynski@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
> Cc: Manivannan Sadhasivam <mani@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pci@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> drivers/pci/controller/dwc/pcie-rcar-gen4.c | 53 +++++++++++++++++++--
> 1 file changed, 48 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pcie-rcar-gen4.c b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> index 485cfa8bd9692..ba6e3bedd6d0a 100644
> --- a/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> +++ b/drivers/pci/controller/dwc/pcie-rcar-gen4.c
> @@ -31,6 +31,10 @@
> #define DEVICE_TYPE_RC BIT(4)
> #define BIFUR_MOD_SET_ON BIT(0)
>
> +/* MSI Capability */
> +#define MSICAP0 0x0050
> +#define MSICAP0_MSIE BIT(16)
> +
> /* PCIe Interrupt Status 0 */
> #define PCIEINTSTS0 0x0084
>
> @@ -55,6 +59,16 @@
> #define APP_HOLD_PHY_RST BIT(16)
> #define APP_LTSSM_ENABLE BIT(0)
>
> +/* INTC address */
> +#define AXIINTCADDR 0x0a00
> +/* GITS GIC ITS translation register */
> +#define AXIINTCADDR_VAL 0xf1050000
As Marc pointed out, this address should be fetched from DT, not hardcoded in
the driver.
> +
> +/* INTC control & mask */
> +#define AXIINTCCONT 0x0a04
> +#define INTC_EN BIT(31)
> +#define INTC_MASK GENMASK(11, 2)
> +
> /* PCIe Power Management Control */
> #define PCIEPWRMNGCTRL 0x0070
> #define APP_CLK_REQ_N BIT(11)
> @@ -305,6 +319,39 @@ static struct rcar_gen4_pcie *rcar_gen4_pcie_alloc(struct platform_device *pdev)
> return rcar;
> }
>
> +static void rcar_gen4_pcie_host_msi_init(struct dw_pcie_rp *pp)
> +{
> + struct dw_pcie *dw = to_dw_pcie_from_pp(pp);
> + struct rcar_gen4_pcie *rcar = to_rcar_gen4_pcie(dw);
> + u32 val;
> +
> + /* Make sure MSICAP0 MSIE is configured. */
> + val = dw_pcie_readl_dbi(dw, MSICAP0);
> + if (pci_msi_enabled())
> + val |= MSICAP0_MSIE;
> + else
> + val &= ~MSICAP0_MSIE;
> + dw_pcie_writel_dbi(dw, MSICAP0, val);
> +
> + if (!pci_msi_enabled() || pp->use_imsi_rx) {
If MSI is not enabled, then what's the point in clearing these registers (also
above)? I see it as a redundant code. Is there a necessity to clear them?
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v5 02/14] mfd: lm3533: Remove driver specific regmap wrappers
From: Andy Shevchenko @ 2026-06-17 10:32 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <20260617080031.99156-3-clamor95@gmail.com>
On Wed, Jun 17, 2026 at 11:00:19AM +0300, Svyatoslav Ryhel wrote:
> Remove driver-specific regmap wrappers in favor of using regmap helpers
> directly.
OK, let's go with this variant.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
Some side notes below for the record.
...
> struct lm3533_led *led = to_lm3533_led(led_cdev);
> unsigned enable;
Oh, besides using the old way of declaring unsigned int, it most likely
just needs to be kstrtobool().
> u8 reg;
> - u8 mask;
> - u8 val;
> int ret;
>
> if (kstrtouint(buf, 0, &enable))
> return -EINVAL;
We should unshadow error codes (it may return more than -EINVAL).
> reg = lm3533_led_get_lv_reg(led, LM3533_REG_CTRLBANK_BCONF_BASE);
> - mask = LM3533_REG_CTRLBANK_BCONF_ALS_EN_MASK;
>
> - if (enable)
> - val = mask;
> - else
> - val = 0;
> -
...
> - if (kstrtou8(buf, 0, &val))
> + if (kstrtou32(buf, 0, &val))
> return -EINVAL;
Like in the previous case we should unshadow error codes.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 3/6] drm/verisilicon: introduce per-variant hardware ops table
From: Joey Lu @ 2026-06-17 10:30 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <38d07e3b3c841d380c987800d8ef85065be94e79.camel@iscas.ac.cn>
On 6/15/2026 4:37 PM, Icenowy Zheng wrote:
> 在 2026-06-15一的 14:50 +0800，Joey Lu写道：
>
>> +
>> drm_crtc_vblank_on(crtc);
>> }
>>
>> @@ -119,7 +148,8 @@ static bool vs_crtc_mode_fixup(struct drm_crtc
>> *crtc,
>> }
>>
>> static const struct drm_crtc_helper_funcs vs_crtc_helper_funcs = {
>> - .atomic_flush = drm_crtc_vblank_atomic_flush,
>> + .atomic_begin = vs_crtc_atomic_begin,
>> + .atomic_flush = vs_crtc_atomic_flush,
>> .atomic_enable = vs_crtc_atomic_enable,
>> .atomic_disable = vs_crtc_atomic_disable,
>> .mode_set_nofb = vs_crtc_mode_set_nofb,
>> @@ -132,7 +162,7 @@ static int vs_crtc_enable_vblank(struct drm_crtc
>> *crtc)
>> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>> + dc->funcs->enable_vblank(dc, vcrtc->id);
>>
>> return 0;
>> }
>> @@ -142,7 +172,7 @@ static void vs_crtc_disable_vblank(struct
>> drm_crtc *crtc)
>> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>> + dc->funcs->disable_vblank(dc, vcrtc->id);
>> }
>>
>> static const struct drm_crtc_funcs vs_crtc_funcs = {
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
>> b/drivers/gpu/drm/verisilicon/vs_dc.c
>> index dad9967bc10b..9729b693d360 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
>> @@ -8,9 +8,7 @@
>> #include <linux/of.h>
>> #include <linux/of_graph.h>
>>
>> -#include "vs_crtc.h"
>> #include "vs_dc.h"
>> -#include "vs_dc_top_regs.h"
>> #include "vs_drm.h"
>> #include "vs_hwdb.h"
>>
>> @@ -33,7 +31,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void
>> *private)
>> struct vs_dc *dc = private;
>> u32 irqs;
>>
>> - regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
>> + irqs = dc->funcs->irq_ack(dc);
> The definition of bits in 0x0010 seems to be different to ones in
> 0x147C, although the first 2 bits are the same. (e.g. `BIT(2)` is
> "cursor interrupt" in DC8000 0x147C but "secure reset done" in DC8200
> 0x0010).
>
> Should some kind of translation be done in `irq_ack` ? (and add a
> unified interrupt definition that aims to be the translation target).
>
> Thanks,
> Icenowy
I will add a set of unified IRQ bit definitions (e.g.
`VSDC_IRQ_VSYNC(n)`) in a shared header. Each `irq_ack` implementation
will translate its hardware-specific register bits into those unified
bits before returning, so `vs_drm_handle_irq` can use the unified
definitions without knowing which register layout was used. Currently
the VSYNC bits (BIT(0)/BIT(1)) coincide between DC8200 0x0010 and DC8000
0x147C, so the translation is trivial; this change will prevent future
confusion from diverging bit meanings (such as BIT(2)).
>>
>> vs_drm_handle_irq(dc, irqs);
>>
>> @@ -136,6 +134,8 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
>>> identity.model,
>> dc->identity.revision, dc->identity.customer_id);
>>
>> + dc->funcs = &vs_dc8200_funcs;
>> +
>> if (port_count > dc->identity.display_count) {
>> dev_err(dev, "too many downstream ports than HW
>> capability\n");
>> ret = -EINVAL;
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
>> b/drivers/gpu/drm/verisilicon/vs_dc.h
>> index ed1016f18758..544e1a37065b 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
>> @@ -14,6 +14,7 @@
>> #include <linux/reset.h>
>>
>> #include <drm/drm_device.h>
>> +#include <drm/drm_plane.h>
>>
>> #include "vs_hwdb.h"
>>
>> @@ -22,6 +23,34 @@
>>
>> struct vs_drm_dev;
>> struct vs_crtc;
>> +struct vs_dc;
>> +
>> +struct vs_dc_funcs {
>> + /* Bridge: atomic_enable, atomic_disable */
>> + void (*panel_enable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> + void (*panel_disable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> +
>> + /* CRTC: atomic_begin, atomic_flush */
>> + void (*crtc_begin)(struct vs_dc *dc, unsigned int output);
>> + void (*crtc_flush)(struct vs_dc *dc, unsigned int output);
>> +
>> + /* CRTC: atomic_enable, atomic_disable */
>> + void (*crtc_enable)(struct vs_dc *dc, unsigned int output);
>> + void (*crtc_disable)(struct vs_dc *dc, unsigned int output);
>> +
>> + /* CRTC: enable_vblank, disable_vblank */
>> + void (*enable_vblank)(struct vs_dc *dc, unsigned int
>> output);
>> + void (*disable_vblank)(struct vs_dc *dc, unsigned int
>> output);
>> +
>> + /* Primary plane: atomic_enable, atomic_disable,
>> atomic_update */
>> + void (*primary_plane_enable_ex)(struct vs_dc *dc, unsigned
>> int output);
>> + void (*primary_plane_disable_ex)(struct vs_dc *dc, unsigned
>> int output);
>> + void (*primary_plane_update_ex)(struct vs_dc *dc, unsigned
>> int output,
>> + struct drm_plane_state
>> *state);
>> +
>> + /* IRQ acknowledge */
>> + u32 (*irq_ack)(struct vs_dc *dc);
>> +};
>>
>> struct vs_dc {
>> struct regmap *regs;
>> @@ -33,6 +62,9 @@ struct vs_dc {
>>
>> struct vs_drm_dev *drm_dev;
>> struct vs_chip_identity identity;
>> + const struct vs_dc_funcs *funcs;
>> };
>>
>> +extern const struct vs_dc_funcs vs_dc8200_funcs;
>> +
>> #endif /* _VS_DC_H_ */
>>
>>
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: adm1275: ROHM BD12780 hot-swap controller
From: Krzysztof Kozlowski @ 2026-06-17 10:28 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Matti Vaittinen, Guenter Roeck, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Shuah Khan,
Wensheng Wang, Ashish Yadav, Kim Seer Paller, Cedric Encarnacion,
Chris Packham, Yuxi Wang, Charles Hsu, ChiShih Tsai, linux-hwmon,
devicetree, linux-kernel, linux-doc
In-Reply-To: <d63c4df5e9df845bc4f94b4abdcd068a23929974.1781591132.git.mazziesaccount@gmail.com>
On Tue, Jun 16, 2026 at 09:35:35AM +0300, Matti Vaittinen wrote:
+
> + Datasheets:
> + https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780muv-lb-e.pdf
> + https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/power_switch/bd12780amuv-lb-e.pdf
> +
> properties:
> compatible:
> - enum:
> - - adi,adm1075
> - - adi,adm1272
> - - adi,adm1273
> - - adi,adm1275
> - - adi,adm1276
> - - adi,adm1278
> - - adi,adm1281
> - - adi,adm1293
> - - adi,adm1294
> - - silergy,mc09c
> + oneOf:
> + - items:
> + enum:
s/items/enum/, so:
oneOf:
- enum:
....
> + - adi,adm1075
> + - adi,adm1272
> + - adi,adm1273
> + - adi,adm1275
> + - adi,adm1276
> + - adi,adm1278
> + - adi,adm1281
> + - adi,adm1293
> + - adi,adm1294
> + - rohm,bd12780
> + - silergy,mc09c
> +
> +# Require BD12780 as a fall-back for BD12780A.
No need for the comment, schema is quite explicit.
> + - items:
> + - const: rohm,bd12780a
> + - const: rohm,bd12780
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 04/18] firmware: qcom: scm: Add minidump SRAM support
From: Konrad Dybcio @ 2026-06-17 10:27 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Marko, Guru Das Srinagesh,
cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260611172425.eejrdiv2zvhqkk5a@hu-mojha-hyd.qualcomm.com>
On 6/11/26 7:24 PM, Mukesh Ojha wrote:
> On Thu, Jun 11, 2026 at 01:45:53PM +0200, Konrad Dybcio wrote:
>> On 5/22/26 9:49 PM, Mukesh Ojha wrote:
>>> On most Qualcomm SoCs where minidump is supported, a word in always-on
>>> SRAM is shared between the kernel and boot firmware. Before DDR is
>>> initialised on the warm reset following a crash, firmware reads this
>>> word to decide if minidump is enabled and collect a minidump and where
>>> to deliver it (USB upload to a host, or save to local storage).
>>>
>>> The SRAM region is described by a 'sram' phandle on the SCM DT node.
>>> If the property is absent the feature is silently disabled, keeping
>>> existing SoCs unaffected.
>>>
>>> Expose a 'minidump_dest' module parameter (default: usb) so the user can
>>> select the destination. Only the string names "usb" or "storage" are
>>> acceptable values.
>>>
>>> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>
>>> + for (i = 0; i < ARRAY_SIZE(minidump_dest_map); i++)
>>> + if (sysfs_streq(val, minidump_dest_map[i].name))
>>
>> I'm not sure about sysfs_streq() specifically, but otherwise this lgtm
>
> It is used in quite a few places for the same purpose. Am I missing something?
Seems like some go left, some go right
anyway
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v4 3/6] drm/verisilicon: introduce per-variant hardware ops table
From: Joey Lu @ 2026-06-17 10:26 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <38d07e3b3c841d380c987800d8ef85065be94e79.camel@iscas.ac.cn>
On 6/15/2026 4:37 PM, Icenowy Zheng wrote:
> 在 2026-06-15一的 14:50 +0800，Joey Lu写道：
>> The DC8200 and DCUltraLite share a broadly similar register layout
>> but
>> differ in how the bridge, CRTC, primary plane and IRQ paths are
>> driven.
>> Introduce a vs_dc_funcs vtable so each variant can supply its own
>> implementation without scattering conditionals across multiple files.
>>
>> Add enum vs_dc_generation (VSDC_GEN_DC8000 / VSDC_GEN_DC8200) to
>> vs_hwdb.h and a generation field to struct vs_chip_identity.
>> Annotate
>> all four existing DC8200 HWDB entries with VSDC_GEN_DC8200.
>>
>> Extract the DC8200-specific hardware ops into a new vs_dc8200.c:
>> panel_enable_ex / panel_disable_ex - PANEL_CONFIG/START + CONFIG_EX
>> commit
>> enable_vblank / disable_vblank - TOP_IRQ_EN VSYNC bit
>> primary_plane_enable_ex / disable_ex / update_ex - FB_CONFIG_EX
>> path
>> irq_ack - reads TOP_IRQ_ACK
>>
>> Update vs_bridge.c, vs_crtc.c, vs_primary_plane.c and vs_dc.c to
>> dispatch through dc->funcs instead of directly touching registers.
>> vs_crtc.c gains atomic_begin and atomic_flush hooks to allow variants
>> to gate per-frame commit cycles.
>>
>> No behaviour change for existing DC8200 platforms.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> 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_dc.c | 6 +-
>> drivers/gpu/drm/verisilicon/vs_dc.h | 32 ++++++
>> drivers/gpu/drm/verisilicon/vs_dc8200.c | 107
>> ++++++++++++++++++
>> drivers/gpu/drm/verisilicon/vs_hwdb.c | 4 +
>> drivers/gpu/drm/verisilicon/vs_hwdb.h | 6 +
>> .../gpu/drm/verisilicon/vs_primary_plane.c | 32 +-----
>> 9 files changed, 196 insertions(+), 51 deletions(-)
>> create mode 100644 drivers/gpu/drm/verisilicon/vs_dc8200.c
>>
>> diff --git a/drivers/gpu/drm/verisilicon/Makefile
>> b/drivers/gpu/drm/verisilicon/Makefile
>> index 426f4bcaa834..9d4cd16452fa 100644
>> --- a/drivers/gpu/drm/verisilicon/Makefile
>> +++ b/drivers/gpu/drm/verisilicon/Makefile
>> @@ -1,6 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>>
>> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_drm.o
>> vs_hwdb.o \
>> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
>> vs_drm.o vs_hwdb.o \
>> vs_plane.o vs_primary_plane.o vs_cursor_plane.o
>>
>> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
>> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
>> b/drivers/gpu/drm/verisilicon/vs_bridge.c
>> index 7a93049368db..6ff2ac745b15 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
>> @@ -162,15 +162,8 @@ static void vs_bridge_enable_common(struct
>> vs_crtc *crtc,
>> VSDC_DISP_PANEL_CONFIG_DE_EN |
>> VSDC_DISP_PANEL_CONFIG_DAT_EN |
>> VSDC_DISP_PANEL_CONFIG_CLK_EN);
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> - VSDC_DISP_PANEL_CONFIG_RUNNING);
>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
>> - VSDC_DISP_PANEL_START_RUNNING(output));
>> -
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>> id),
>> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> +
>> + dc->funcs->panel_enable_ex(dc, output);
>> }
>>
>> static void vs_bridge_atomic_enable_dpi(struct drm_bridge *bridge,
>> @@ -228,14 +221,7 @@ static void vs_bridge_atomic_disable(struct
>> drm_bridge *bridge,
>> struct vs_dc *dc = crtc->dc;
>> unsigned int output = crtc->id;
>>
>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> - VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
>> - VSDC_DISP_PANEL_START_RUNNING(output));
>> - regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> - VSDC_DISP_PANEL_CONFIG_RUNNING);
>> -
>> - regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>> id),
>> - VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> + dc->funcs->panel_disable_ex(dc, output);
>> }
>>
>> static const struct drm_bridge_funcs vs_dpi_bridge_funcs = {
>> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc.c
>> b/drivers/gpu/drm/verisilicon/vs_crtc.c
>> index 0b8a35d09cd2..679d6541ba1b 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_crtc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
>> @@ -16,10 +16,33 @@
>> #include "vs_crtc_regs.h"
>> #include "vs_crtc.h"
>> #include "vs_dc.h"
>> -#include "vs_dc_top_regs.h"
>> #include "vs_drm.h"
>> #include "vs_plane.h"
>>
>> +static void vs_crtc_atomic_begin(struct drm_crtc *crtc,
>> + struct drm_atomic_commit *state)
>> +{
>> + struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> + struct vs_dc *dc = vcrtc->dc;
>> + unsigned int output = vcrtc->id;
>> +
>> + if (dc->funcs->crtc_begin)
>> + dc->funcs->crtc_begin(dc, output);
>> +}
>> +
>> +static void vs_crtc_atomic_flush(struct drm_crtc *crtc,
>> + struct drm_atomic_commit *state)
>> +{
>> + struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> + struct vs_dc *dc = vcrtc->dc;
>> + unsigned int output = vcrtc->id;
>> +
>> + if (dc->funcs->crtc_flush)
>> + dc->funcs->crtc_flush(dc, output);
>> +
>> + drm_crtc_vblank_atomic_flush(crtc, state);
>> +}
>> +
>> static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
>> struct drm_atomic_commit *state)
>> {
>> @@ -30,6 +53,9 @@ static void vs_crtc_atomic_disable(struct drm_crtc
>> *crtc,
>> drm_crtc_vblank_off(crtc);
>>
>> clk_disable_unprepare(dc->pix_clk[output]);
>> +
>> + if (dc->funcs->crtc_disable)
>> + dc->funcs->crtc_disable(dc, output);
> Should this be `crtc_disable_ex` ? Because the clock-related operation
> is shared.
I will rename `crtc_disable` to `crtc_disable_ex` and `crtc_enable` to
`crtc_enable_ex` in v5 to make clear these hooks extend the shared clock
operations rather than replace them.
>> }
>>
>> static void vs_crtc_atomic_enable(struct drm_crtc *crtc,
>> @@ -42,6 +68,9 @@ static void vs_crtc_atomic_enable(struct drm_crtc
>> *crtc,
>> drm_WARN_ON(&dc->drm_dev->base,
>> clk_prepare_enable(dc->pix_clk[output]));
>>
>> + if (dc->funcs->crtc_enable)
>> + dc->funcs->crtc_enable(dc, output);
> Ditto for appending `_ex` .
Addressed above.
>> +
>> drm_crtc_vblank_on(crtc);
>> }
>>
>> @@ -119,7 +148,8 @@ static bool vs_crtc_mode_fixup(struct drm_crtc
>> *crtc,
>> }
>>
>> static const struct drm_crtc_helper_funcs vs_crtc_helper_funcs = {
>> - .atomic_flush = drm_crtc_vblank_atomic_flush,
>> + .atomic_begin = vs_crtc_atomic_begin,
>> + .atomic_flush = vs_crtc_atomic_flush,
>> .atomic_enable = vs_crtc_atomic_enable,
>> .atomic_disable = vs_crtc_atomic_disable,
>> .mode_set_nofb = vs_crtc_mode_set_nofb,
>> @@ -132,7 +162,7 @@ static int vs_crtc_enable_vblank(struct drm_crtc
>> *crtc)
>> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>> + dc->funcs->enable_vblank(dc, vcrtc->id);
>>
>> return 0;
>> }
>> @@ -142,7 +172,7 @@ static void vs_crtc_disable_vblank(struct
>> drm_crtc *crtc)
>> struct vs_crtc *vcrtc = drm_crtc_to_vs_crtc(crtc);
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>> + dc->funcs->disable_vblank(dc, vcrtc->id);
>> }
>>
>> static const struct drm_crtc_funcs vs_crtc_funcs = {
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
>> b/drivers/gpu/drm/verisilicon/vs_dc.c
>> index dad9967bc10b..9729b693d360 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
>> @@ -8,9 +8,7 @@
>> #include <linux/of.h>
>> #include <linux/of_graph.h>
>>
>> -#include "vs_crtc.h"
>> #include "vs_dc.h"
>> -#include "vs_dc_top_regs.h"
>> #include "vs_drm.h"
>> #include "vs_hwdb.h"
>>
>> @@ -33,7 +31,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void
>> *private)
>> struct vs_dc *dc = private;
>> u32 irqs;
>>
>> - regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
>> + irqs = dc->funcs->irq_ack(dc);
> The definition of bits in 0x0010 seems to be different to ones in
> 0x147C, although the first 2 bits are the same. (e.g. `BIT(2)` is
> "cursor interrupt" in DC8000 0x147C but "secure reset done" in DC8200
> 0x0010).
>
> Should some kind of translation be done in `irq_ack` ? (and add a
> unified interrupt definition that aims to be the translation target).
>
> Thanks,
> Icenowy
>
>>
>> vs_drm_handle_irq(dc, irqs);
>>
>> @@ -136,6 +134,8 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
>>> identity.model,
>> dc->identity.revision, dc->identity.customer_id);
>>
>> + dc->funcs = &vs_dc8200_funcs;
>> +
>> if (port_count > dc->identity.display_count) {
>> dev_err(dev, "too many downstream ports than HW
>> capability\n");
>> ret = -EINVAL;
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
>> b/drivers/gpu/drm/verisilicon/vs_dc.h
>> index ed1016f18758..544e1a37065b 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
>> @@ -14,6 +14,7 @@
>> #include <linux/reset.h>
>>
>> #include <drm/drm_device.h>
>> +#include <drm/drm_plane.h>
>>
>> #include "vs_hwdb.h"
>>
>> @@ -22,6 +23,34 @@
>>
>> struct vs_drm_dev;
>> struct vs_crtc;
>> +struct vs_dc;
>> +
>> +struct vs_dc_funcs {
>> + /* Bridge: atomic_enable, atomic_disable */
>> + void (*panel_enable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> + void (*panel_disable_ex)(struct vs_dc *dc, unsigned int
>> output);
>> +
>> + /* CRTC: atomic_begin, atomic_flush */
>> + void (*crtc_begin)(struct vs_dc *dc, unsigned int output);
>> + void (*crtc_flush)(struct vs_dc *dc, unsigned int output);
>> +
>> + /* CRTC: atomic_enable, atomic_disable */
>> + void (*crtc_enable)(struct vs_dc *dc, unsigned int output);
>> + void (*crtc_disable)(struct vs_dc *dc, unsigned int output);
>> +
>> + /* CRTC: enable_vblank, disable_vblank */
>> + void (*enable_vblank)(struct vs_dc *dc, unsigned int
>> output);
>> + void (*disable_vblank)(struct vs_dc *dc, unsigned int
>> output);
>> +
>> + /* Primary plane: atomic_enable, atomic_disable,
>> atomic_update */
>> + void (*primary_plane_enable_ex)(struct vs_dc *dc, unsigned
>> int output);
>> + void (*primary_plane_disable_ex)(struct vs_dc *dc, unsigned
>> int output);
>> + void (*primary_plane_update_ex)(struct vs_dc *dc, unsigned
>> int output,
>> + struct drm_plane_state
>> *state);
>> +
>> + /* IRQ acknowledge */
>> + u32 (*irq_ack)(struct vs_dc *dc);
>> +};
>>
>> struct vs_dc {
>> struct regmap *regs;
>> @@ -33,6 +62,9 @@ struct vs_dc {
>>
>> struct vs_drm_dev *drm_dev;
>> struct vs_chip_identity identity;
>> + const struct vs_dc_funcs *funcs;
>> };
>>
>> +extern const struct vs_dc_funcs vs_dc8200_funcs;
>> +
>> #endif /* _VS_DC_H_ */
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc8200.c
>> b/drivers/gpu/drm/verisilicon/vs_dc8200.c
>> new file mode 100644
>> index 000000000000..800df9279e9b
>> --- /dev/null
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc8200.c
>> @@ -0,0 +1,107 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2025 Icenowy Zheng <uwu@icenowy.me>
>> + */
>> +
>> +#include <linux/regmap.h>
>> +
>> +#include "vs_bridge_regs.h"
>> +#include "vs_dc.h"
>> +#include "vs_dc_top_regs.h"
>> +#include "vs_plane.h"
>> +#include "vs_primary_plane_regs.h"
>> +
>> +static void vs_dc8200_panel_enable_ex(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> + VSDC_DISP_PANEL_CONFIG_RUNNING);
>> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> + VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_START,
>> + VSDC_DISP_PANEL_START_RUNNING(output));
>> +
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
>> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> +}
>> +
>> +static void vs_dc8200_panel_disable_ex(struct vs_dc *dc, unsigned
>> int output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_CONFIG(output),
>> + VSDC_DISP_PANEL_CONFIG_RUNNING);
>> + regmap_clear_bits(dc->regs, VSDC_DISP_PANEL_START,
>> + VSDC_DISP_PANEL_START_MULTI_DISP_SYNC |
>> + VSDC_DISP_PANEL_START_RUNNING(output));
>> +
>> + regmap_set_bits(dc->regs, VSDC_DISP_PANEL_CONFIG_EX(output),
>> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
>> +}
>> +
>> +static void vs_dc8200_enable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> + VSDC_TOP_IRQ_VSYNC(output));
>> +}
>> +
>> +static void vs_dc8200_disable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
>> + VSDC_TOP_IRQ_VSYNC(output));
>> +}
>> +
>> +static void vs_dc8200_plane_commit(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_COMMIT);
>> +}
>> +
>> +static void vs_dc8200_primary_plane_enable_ex(struct vs_dc *dc,
>> unsigned int output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_FB_EN);
>> + regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
>> + VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
>> +
>> + vs_dc8200_plane_commit(dc, output);
>> +}
>> +
>> +static void vs_dc8200_primary_plane_disable_ex(struct vs_dc *dc,
>> unsigned int output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> + VSDC_FB_CONFIG_EX_FB_EN);
>> +
>> + vs_dc8200_plane_commit(dc, output);
>> +}
>> +
>> +static void vs_dc8200_primary_plane_update_ex(struct vs_dc *dc,
>> unsigned int output,
>> + struct drm_plane_state
>> *state)
>> +{
>> + regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
>> + VSDC_MAKE_PLANE_POS(state->crtc_x, state-
>>> crtc_y));
>> + regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
>> + VSDC_MAKE_PLANE_POS(state->crtc_x + state-
>>> crtc_w,
>> + state->crtc_y + state-
>>> crtc_h));
>> + regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
>> + VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
>> +
>> + vs_dc8200_plane_commit(dc, output);
>> +}
>> +
>> +static u32 vs_dc8200_irq_ack(struct vs_dc *dc)
>> +{
>> + u32 irqs;
>> +
>> + regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
>> + return irqs;
>> +}
>> +
>> +const struct vs_dc_funcs vs_dc8200_funcs = {
>> + .panel_enable_ex = vs_dc8200_panel_enable_ex,
>> + .panel_disable_ex =
>> vs_dc8200_panel_disable_ex,
>> + .enable_vblank = vs_dc8200_enable_vblank,
>> + .disable_vblank =
>> vs_dc8200_disable_vblank,
>> + .primary_plane_enable_ex =
>> vs_dc8200_primary_plane_enable_ex,
>> + .primary_plane_disable_ex =
>> vs_dc8200_primary_plane_disable_ex,
>> + .primary_plane_update_ex =
>> vs_dc8200_primary_plane_update_ex,
>> + .irq_ack = vs_dc8200_irq_ack,
>> +};
>> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> b/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> index 2a0f7c59afa3..91524d16f778 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> @@ -94,6 +94,7 @@ static struct vs_chip_identity vs_chip_identities[]
>> = {
>> .revision = 0x5720,
>> .customer_id = ~0U,
>>
>> + .generation = VSDC_GEN_DC8200,
>> .display_count = 2,
>> .max_cursor_size = 64,
>> .formats = &vs_formats_no_yuv444,
>> @@ -103,6 +104,7 @@ static struct vs_chip_identity
>> vs_chip_identities[] = {
>> .revision = 0x5721,
>> .customer_id = 0x30B,
>>
>> + .generation = VSDC_GEN_DC8200,
>> .display_count = 2,
>> .max_cursor_size = 64,
>> .formats = &vs_formats_no_yuv444,
>> @@ -112,6 +114,7 @@ static struct vs_chip_identity
>> vs_chip_identities[] = {
>> .revision = 0x5720,
>> .customer_id = 0x310,
>>
>> + .generation = VSDC_GEN_DC8200,
>> .display_count = 2,
>> .max_cursor_size = 64,
>> .formats = &vs_formats_with_yuv444,
>> @@ -121,6 +124,7 @@ static struct vs_chip_identity
>> vs_chip_identities[] = {
>> .revision = 0x5720,
>> .customer_id = 0x311,
>>
>> + .generation = VSDC_GEN_DC8200,
>> .display_count = 2,
>> .max_cursor_size = 64,
>> .formats = &vs_formats_no_yuv444,
>> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> b/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> index 2065ecb73043..a15c8b565604 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> @@ -9,6 +9,11 @@
>> #include <linux/regmap.h>
>> #include <linux/types.h>
>>
>> +enum vs_dc_generation {
>> + VSDC_GEN_DC8000,
>> + VSDC_GEN_DC8200,
>> +};
>> +
>> struct vs_formats {
>> const u32 *array;
>> unsigned int num;
>> @@ -19,6 +24,7 @@ struct vs_chip_identity {
>> u32 revision;
>> u32 customer_id;
>>
>> + enum vs_dc_generation generation;
>> u32 display_count;
>> /*
>> * The hardware only supports square cursor planes, so this
>> field
>> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>> b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>> index 1f2be41ae496..f992cb277f61 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>> @@ -53,12 +53,6 @@ static int vs_primary_plane_atomic_check(struct
>> drm_plane *plane,
>> return 0;
>> }
>>
>> -static void vs_primary_plane_commit(struct vs_dc *dc, unsigned int
>> output)
>> -{
>> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> - VSDC_FB_CONFIG_EX_COMMIT);
>> -}
>> -
>> static void vs_primary_plane_atomic_enable(struct drm_plane *plane,
>> struct drm_atomic_commit
>> *atomic_state)
>> {
>> @@ -69,13 +63,8 @@ static void vs_primary_plane_atomic_enable(struct
>> drm_plane *plane,
>> unsigned int output = vcrtc->id;
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> - VSDC_FB_CONFIG_EX_FB_EN);
>> - regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> - VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
>> - VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
>> -
>> - vs_primary_plane_commit(dc, output);
>> + if (dc->funcs->primary_plane_enable_ex)
>> + dc->funcs->primary_plane_enable_ex(dc, output);
>> }
>>
>> static void vs_primary_plane_atomic_disable(struct drm_plane *plane,
>> @@ -88,10 +77,8 @@ static void vs_primary_plane_atomic_disable(struct
>> drm_plane *plane,
>> unsigned int output = vcrtc->id;
>> struct vs_dc *dc = vcrtc->dc;
>>
>> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>> - VSDC_FB_CONFIG_EX_FB_EN);
>> -
>> - vs_primary_plane_commit(dc, output);
>> + if (dc->funcs->primary_plane_disable_ex)
>> + dc->funcs->primary_plane_disable_ex(dc, output);
>> }
>>
>> static void vs_primary_plane_atomic_update(struct drm_plane *plane,
>> @@ -133,18 +120,11 @@ static void
>> vs_primary_plane_atomic_update(struct drm_plane *plane,
>> regmap_write(dc->regs, VSDC_FB_STRIDE(output),
>> fb->pitches[0]);
>>
>> - regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
>> - VSDC_MAKE_PLANE_POS(state->crtc_x, state-
>>> crtc_y));
>> - regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
>> - VSDC_MAKE_PLANE_POS(state->crtc_x + state-
>>> crtc_w,
>> - state->crtc_y + state-
>>> crtc_h));
>> regmap_write(dc->regs, VSDC_FB_SIZE(output),
>> VSDC_MAKE_PLANE_SIZE(state->crtc_w, state-
>>> crtc_h));
>>
>> - regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
>> - VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
>> -
>> - vs_primary_plane_commit(dc, output);
>> + if (dc->funcs->primary_plane_update_ex)
>> + dc->funcs->primary_plane_update_ex(dc, output,
>> state);
>> }
>>
>> static const struct drm_plane_helper_funcs
>> vs_primary_plane_helper_funcs = {
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox