* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Taniya Das @ 2026-04-10 3:55 UTC (permalink / raw)
To: Bryan O'Donoghue, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <cb5a40e8-e2e3-4ed9-a9c6-0daa9f408710@nxsw.ie>
On 4/10/2026 12:10 AM, Bryan O'Donoghue wrote:
> On 09/04/2026 19:10, Taniya Das wrote:
>> + videocc: clock-controller@aaf0000 {
>> + compatible = "qcom,eliza-videocc";
>> + reg = <0x0 0xaaf0000 0x0 0x10000>;
>> +
>> + clocks = <&bi_tcxo_div2>,
>> + <&sleep_clk>,
>> + <&gcc GCC_VIDEO_AHB_CLK>;
>> +
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + #power-domain-cells = <1>;
>> + };
>> +
>> + camcc: clock-controller@ade0000 {
>> + compatible = "qcom,eliza-camcc";
>> + reg = <0x0 0x0ade0000 0x0 0x20000>;
>> +
>> + clocks = <&gcc GCC_CAMERA_AHB_CLK>,
>> + <&bi_tcxo_div2>,
>> + <&sleep_clk>;
>> +
>> + #clock-cells = <1>;
>> + #reset-cells = <1>;
>> + };
>
> This looks odd.
>
> Why do these two controllers have no power-domains ?
Bryan, on Eliza the videocc and camcc are connected on CX and MXA.
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [RFC V1 11/16] arm64/mm: Route all pgtable atomics to central helpers
From: Anshuman Khandual @ 2026-04-10 4:02 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm
In-Reply-To: <aeb1972c-57ba-4f21-8289-66424e4e619b@kernel.org>
On 08/04/26 5:58 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Route all cmpxchg() operations performed on various page table entries to a
>> new ptdesc_cmpxchg_relaxed() helper. Similarly route all xchg() operations
>> performed on page table entries to a new ptdesc_xchg_relaxed() helper.
>>
>> Currently these helpers just forward to the same APIs that were previously
>> called direct, but in future we will change the routing for D128 which is
>> too long to use the standard APIs.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> arch/arm64/include/asm/pgtable.h | 23 +++++++++++++++++------
>> arch/arm64/mm/fault.c | 2 +-
>> 2 files changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
>> index 42124d2f323d..cf69ce68f951 100644
>> --- a/arch/arm64/include/asm/pgtable.h
>> +++ b/arch/arm64/include/asm/pgtable.h
>> @@ -87,6 +87,17 @@ static inline void arch_leave_lazy_mmu_mode(void)
>> #define ptdesc_get(x) READ_ONCE(x)
>> #define ptdesc_set(x, val) WRITE_ONCE(x, val)
>>
>> +static inline ptdesc_t ptdesc_cmpxchg_relaxed(ptdesc_t *ptep, ptdesc_t old,
>> + ptdesc_t new)
>> +{
>> + return cmpxchg_relaxed(ptep, old, new);
>> +}
>> +
>> +static inline ptdesc_t ptdesc_xchg_relaxed(ptdesc_t *ptep, ptdesc_t new)
>> +{
>> + return xchg_relaxed(ptep, new);
>> +}
>> +
>
> We really want the rename of ptdesc_t before this change.
>
Planning to rename ptdesc_t as ptent_t in a pre-requisite
patch early in the series.
^ permalink raw reply
* Re: [RFC V1 12/16] arm64/mm: Abstract printing of pxd_val()
From: Anshuman Khandual @ 2026-04-10 4:05 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm
In-Reply-To: <4290fcdb-47d1-4f74-97f3-51ac581efeaf@kernel.org>
On 08/04/26 5:58 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>
> Subject: you probably mean "pxx_val()" ?
Yes - sounds better will change.
>
>> Ahead of adding support for D128 pgtables, refactor places that print
>> PTE values to use the new __PRIpte format specifier and __PRIpte_args()
>> macro to prepare the argument(s). When using D128 pgtables in future,
>> we can simply redefine __PRIpte and __PTIpte_args().
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> arch/arm64/include/asm/pgtable-types.h | 3 +++
>> arch/arm64/include/asm/pgtable.h | 22 +++++++++++-----------
>> arch/arm64/mm/fault.c | 10 +++++-----
>> 3 files changed, 19 insertions(+), 16 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/pgtable-types.h b/arch/arm64/include/asm/pgtable-types.h
>> index 265e8301d7ba..dc3791dc9f14 100644
>> --- a/arch/arm64/include/asm/pgtable-types.h
>> +++ b/arch/arm64/include/asm/pgtable-types.h
>> @@ -11,6 +11,9 @@
>>
>> #include <asm/types.h>
>>
>> +#define __PRIpte "016llx"
>> +#define __PRIpte_args(val) ((u64)val)
>
> Same comment regarding "pte" being misleading.
Sure - will rename __PRIpte as PRIpxx instead.
>
>
^ permalink raw reply
* Re: [RFC V1 01/16] mm: Abstract printing of pxd_val()
From: Anshuman Khandual @ 2026-04-10 4:21 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Mark Rutland, Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Linu Cherian, linux-kernel, linux-mm
In-Reply-To: <adeAhYW-hJ7-6-Xy@kernel.org>
On 09/04/26 4:03 PM, Mike Rapoport wrote:
> Hi Anshuman,
>
> On Tue, Feb 24, 2026 at 10:41:38AM +0530, Anshuman Khandual wrote:
>> Ahead of adding support for D128 pgtables, refactor places that print
>> PTE values to use the new __PRIpte format specifier and __PRIpte_args()
>> macro to prepare the argument(s). When using D128 pgtables in future,
>> we can simply redefine __PRIpte and __PTIpte_args().
>>
>> Besides there is also an assumption about pxd_val() being always capped
>> at 'unsigned long long' size but that will not work for D128 pgtables.
>> Just increase its size to u128 if the compiler supports via a separate
>> data type pxdval_t which also defaults to existing 'unsigned long long'.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: David Hildenbrand <david@kernel.org>
>> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> Cc: Mike Rapoport <rppt@kernel.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> include/linux/pgtable.h | 5 +++++
>> mm/memory.c | 29 +++++++++++++++++++----------
>> 2 files changed, 24 insertions(+), 10 deletions(-)
>>
>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>> index a50df42a893f..da17139a1279 100644
>> --- a/include/linux/pgtable.h
>> +++ b/include/linux/pgtable.h
>> @@ -17,6 +17,11 @@
>> #include <asm-generic/pgtable_uffd.h>
>> #include <linux/page_table_check.h>
>>
>> +#ifndef __PRIpte
>> +#define __PRIpte "016llx"
>> +#define __PRIpte_args(val) ((u64)val)
>> +#endif
>> +
>> #if 5 - defined(__PAGETABLE_P4D_FOLDED) - defined(__PAGETABLE_PUD_FOLDED) - \
>> defined(__PAGETABLE_PMD_FOLDED) != CONFIG_PGTABLE_LEVELS
>> #error CONFIG_PGTABLE_LEVELS is not consistent with __PAGETABLE_{P4D,PUD,PMD}_FOLDED
>> diff --git a/mm/memory.c b/mm/memory.c
>> index 07778814b4a8..cfc3077fc52f 100644
>> --- a/mm/memory.c
>> +++ b/mm/memory.c
>> @@ -532,9 +532,15 @@ static bool is_bad_page_map_ratelimited(void)
>> return false;
>> }
>>
>> +#ifdef __SIZEOF_INT128__
>> + typedef u128 pxdval_t;
>
> I don't think the typedef should be indented.
Sure will drop the indent from pxdval_t.
>
>> +#else
>> + typedef unsigned long long pxdval_t;
>> +#endif
>
> Don't we want this in, say, include/linux/pgtable.h?
>
Sure will move the typedef into the above header.
^ permalink raw reply
* Re: [RFC V1 02/16] mm: Add read-write accessors for vm_page_prot
From: Anshuman Khandual @ 2026-04-10 4:29 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-arm-kernel, Catalin Marinas, Will Deacon, Ryan Roberts,
Mark Rutland, Lorenzo Stoakes, Andrew Morton, David Hildenbrand,
Linu Cherian, linux-kernel, linux-mm
In-Reply-To: <adeBg_eZvmz-ST67@kernel.org>
On 09/04/26 4:07 PM, Mike Rapoport wrote:
> Hi Anshuman,
>
> On Tue, Feb 24, 2026 at 10:41:39AM +0530, Anshuman Khandual wrote:
>> Currently vma->vm_page_prot is safely read from and written to, without any
>> locks with READ_ONCE() and WRITE_ONCE(). But with introduction of D128 page
>> tables on arm64 platform, vm_page_prot grows to 128 bits which can't safely
>> be handled with READ_ONCE() and WRITE_ONCE().
>>
>> Add read and write accessors for vm_page_prot like pgprot_read/write_once()
>> which any platform can override when required, although still defaulting as
>> READ_ONCE() and WRITE_ONCE(), thus preserving the functionality for others.
>>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: David Hildenbrand <david@kernel.org>
>> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> Cc: Mike Rapoport <rppt@kernel.org>
>> Cc: linux-mm@kvack.org
>> Cc: linux-kernel@vger.kernel.org
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>> include/linux/pgtable.h | 14 ++++++++++++++
>> mm/huge_memory.c | 4 ++--
>> mm/memory.c | 2 +-
>> mm/migrate.c | 2 +-
>> mm/mmap.c | 2 +-
>> 5 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
>> index da17139a1279..8858b8b03a02 100644
>> --- a/include/linux/pgtable.h
>> +++ b/include/linux/pgtable.h
>> @@ -495,6 +495,20 @@ static inline pgd_t pgdp_get(pgd_t *pgdp)
>> }
>> #endif
>>
>> +#ifndef pgprot_read_once
>> +static inline pgprot_t pgprot_read_once(pgprot_t *prot)
>
> I don't think we need _once in the helper name. Presence of the helper
> already implies that pointer should not be just dereferenced from one side
> and that using the helper will do The Right Thing from the other side.
Makes sense - will drop __once from the helper name.
^ permalink raw reply
* Re: [PATCH v3 4/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Vignesh Raghavendra @ 2026-04-10 4:30 UTC (permalink / raw)
To: Markus Schneider-Pargmann (TI), Bjorn Andersson, Mathieu Poirier,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Suman Anna,
Nishanth Menon, Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260318-topic-am62a-ioddr-dt-v6-19-v3-4-c41473cb23c3@baylibre.com>
Hi Markus
On 18/03/26 20:43, Markus Schneider-Pargmann (TI) wrote:
> Split the firmware memory region in more specific parts so it is better
> described where to find which information. Specifically the LPM metadata
> region is important as bootloader software like U-Boot has to know where
> that data is to be able to read that data.
>
> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
> ---
> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 40 +++++++++++++++++++++++++++++++--
> 1 file changed, 38 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..c381cc33064ec427751a9ac5bcdff745a9559a89 100644
> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
> @@ -59,9 +59,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
> no-map;
> };
>
> - wkup_r5fss0_core0_memory_region: memory@9c900000 {
> + wkup_r5fss0_core0_ipc_region: memory@9c900000 {
There are still references to wkup_r5fss0_core0_memory_region in
k3-am62a-ti-ipc-firmware.dtsi (same comment applies to next 2 patches as
well)
Dont those need to be updated too?
> compatible = "shared-dma-pool";
> - reg = <0x00 0x9c900000 0x00 0xf00000>;
> + reg = <0x00 0x9c900000 0x00 0x100000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_lpm_fs_stub_region: memory@9ca00000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9ca00000 0x00 0x8000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_lpm_metadata_region: memory@9ca08000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9ca08000 0x00 0x1000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_lpm_rest_region: memory@9ca09000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9ca09000 0x00 0x97000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_dm_region: memory@9caa0000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0x9caa0000 0x00 0xd60000>;
> no-map;
> };
>
> @@ -922,3 +946,15 @@ &mcu_uart0 {
> };
>
> #include "k3-am62a-ti-ipc-firmware.dtsi"
> +
> +&wkup_r5fss0_core0 {
> + memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
> + <&wkup_r5fss0_core0_ipc_region>,
> + <&wkup_r5fss0_core0_lpm_fs_stub_region>,
> + <&wkup_r5fss0_core0_lpm_metadata_region>,
> + <&wkup_r5fss0_core0_lpm_rest_region>,
> + <&wkup_r5fss0_core0_dm_region>;
> + memory-region-names = "dma", "ipc", "lpm-stub",
> + "lpm-metadata", "lpm-context",
> + "dm-firmware";
> +};
>
--
Regards
Vignesh
https://ti.com/opensource
^ permalink raw reply
* RE: [PATCH v1] clk: imx95-blk-ctl: Add func_out_en clock for i.MX9x PCIe
From: Peng Fan @ 2026-04-10 4:35 UTC (permalink / raw)
To: Hongxing Zhu, abelvesa@kernel.org, mturquette@baylibre.com,
sboyd@kernel.org, Frank Li, s.hauer@pengutronix.de,
festevam@gmail.com
Cc: linux-clk@vger.kernel.org, imx@nxp.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, kernel@pengutronix.de
In-Reply-To: <20260410031656.2578632-1-hongxing.zhu@nxp.com>
> Subject: [PATCH v1] clk: imx95-blk-ctl: Add func_out_en clock for
> i.MX9x PCIe
>
> When internal PLL clock is used as PCIe REF clock, the BIT6(CREF_EN)
> and
> BIT2(FUNC_OUTPUT_EN) control the PCIE_REF_OUT_CLK.
>
> If the default value of BIT6(CREF_EN)&BIT2(FUNC_OUTPUT_EN) is 1b'1.
> With the typical 100-ohm termination on the board, this results in
> approximately 6mA of power consumption.
>
> When PCIe internal PLL clock is not enabled, these two bits should be
> cleared to 1b'0 to eliminate this power consumption.
>
> Add a func_out_en clock for i.MX9x PCIe to serve as the parent gate
> clock of the CREF_EN (BIT6) gate clock. Both of these two gate clocks
> enable the output of the internal 100MHz differential reference clock.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
^ permalink raw reply
* Re: [RFC V1 05/16] arm64/mm: Convert READ_ONCE() as pmdp_get() while accessing PMD
From: Anshuman Khandual @ 2026-04-10 4:48 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm, kasan-dev
In-Reply-To: <628a1d9b-cc16-4cf6-8c19-b6ed49af8492@kernel.org>
On 08/04/26 5:41 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Convert all READ_ONCE() based PMD accesses as pmdp_get() instead which will
>> support both D64 and D128 translation regime going forward.
>
> You should mention the move from pmdp_test_and_clear_young(), and why it
> is performed.
Sure will do that. Actually there as a build problem while accessing
pmdp_get() from pmdp_test_and_clear_young() while being inside the
header which necessitated this move.
>
> Nothing else jumped at me :)
>
^ permalink raw reply
* Re: [PATCH v2 4/8] clk: qcom: videocc: Add video clock controller driver for Eliza
From: Jie Gan @ 2026-04-10 4:48 UTC (permalink / raw)
To: Taniya Das, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Konrad Dybcio
In-Reply-To: <20260409-eliza_mm_cc_v2-v2-4-bc0c6dd77bc5@oss.qualcomm.com>
On 4/10/2026 2:10 AM, Taniya Das wrote:
> Add support for the video clock controller for video clients to be able
> to request for videocc clocks on Eliza platform.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 9 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/videocc-eliza.c | 403 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 413 insertions(+)
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 22eb80be60ad3bde897f2c507ac9897951fbb8fe..4b0d40a38a6328fe9c41ebb15ae6821012223920 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -45,6 +45,15 @@ config CLK_ELIZA_TCSRCC
> Support for the TCSR clock controller on Eliza devices.
> Say Y if you want to use peripheral devices such as USB/PCIe/UFS.
>
> +config CLK_ELIZA_VIDEOCC
> + tristate "Eliza Video Clock Controller"
> + depends on ARM64 || COMPILE_TEST
> + select CLK_GLYMUR_GCC
Hi,
My bot found a [BUG] here, please ignore it if it's a false positive issue.
CLK_ELIZA_VIDEOCC selects CLK_GLYMUR_GCC instead of CLK_ELIZA_GCC
- select CLK_GLYMUR_GCC pulls in gcc-glymur.c instead of gcc-eliza.c
- On an Eliza system, gcc-glymur.c will never probe (no matching DTS
node), so GCC_VIDEO_AHB_CLK from the Eliza GCC will never be available
to videocc
- The videocc driver's clocks = <&gcc GCC_VIDEO_AHB_CLK> will fail to
resolve at runtime
- The correct fix is select CLK_ELIZA_GCC, consistent with all other
Eliza clock controllers
Thanks,
Jie
> + help
> + Support for the video clock controller on Eliza devices.
> + Say Y if you want to support video devices and functionality such as
> + video encode and decode.
> +
> config CLK_GLYMUR_DISPCC
> tristate "Glymur Display Clock Controller"
> depends on ARM64 || COMPILE_TEST
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index b818fd5af8bfb85a51ee90fdc3baa93af30dc39a..e7e239c5a0d088b2e78354bf421d871a4e4e6d9d 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_APQ_MMCC_8084) += mmcc-apq8084.o
> obj-$(CONFIG_CLK_ELIZA_DISPCC) += dispcc-eliza.o
> obj-$(CONFIG_CLK_ELIZA_GCC) += gcc-eliza.o
> obj-$(CONFIG_CLK_ELIZA_TCSRCC) += tcsrcc-eliza.o
> +obj-$(CONFIG_CLK_ELIZA_VIDEOCC) += videocc-eliza.o
> obj-$(CONFIG_CLK_GFM_LPASS_SM8250) += lpass-gfm-sm8250.o
> obj-$(CONFIG_CLK_GLYMUR_DISPCC) += dispcc-glymur.o
> obj-$(CONFIG_CLK_GLYMUR_GCC) += gcc-glymur.o
> diff --git a/drivers/clk/qcom/videocc-eliza.c b/drivers/clk/qcom/videocc-eliza.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..cb541cfec50c12761251a822e32094e763922cdb
> --- /dev/null
> +++ b/drivers/clk/qcom/videocc-eliza.c
> @@ -0,0 +1,403 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +#include <dt-bindings/clock/qcom,eliza-videocc.h>
> +
> +#include "clk-alpha-pll.h"
> +#include "clk-branch.h"
> +#include "clk-pll.h"
> +#include "clk-rcg.h"
> +#include "clk-regmap.h"
> +#include "clk-regmap-divider.h"
> +#include "clk-regmap-mux.h"
> +#include "common.h"
> +#include "gdsc.h"
> +#include "reset.h"
> +
> +enum {
> + DT_BI_TCXO,
> + DT_SLEEP_CLK,
> + DT_AHB_CLK,
> +};
> +
> +enum {
> + P_BI_TCXO,
> + P_SLEEP_CLK,
> + P_VIDEO_CC_PLL0_OUT_MAIN,
> +};
> +
> +static const struct pll_vco lucid_ole_vco[] = {
> + { 249600000, 2300000000, 0 },
> +};
> +
> +/* 576.0 MHz Configuration */
> +static const struct alpha_pll_config video_cc_pll0_config = {
> + .l = 0x1e,
> + .alpha = 0x0,
> + .config_ctl_val = 0x20485699,
> + .config_ctl_hi_val = 0x00182261,
> + .config_ctl_hi1_val = 0x82aa299c,
> + .test_ctl_val = 0x00000000,
> + .test_ctl_hi_val = 0x00000003,
> + .test_ctl_hi1_val = 0x00009000,
> + .test_ctl_hi2_val = 0x00000034,
> + .user_ctl_val = 0x00000000,
> + .user_ctl_hi_val = 0x00000005,
> +};
> +
> +static struct clk_alpha_pll video_cc_pll0 = {
> + .offset = 0x0,
> + .config = &video_cc_pll0_config,
> + .vco_table = lucid_ole_vco,
> + .num_vco = ARRAY_SIZE(lucid_ole_vco),
> + .regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID_OLE],
> + .clkr = {
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_pll0",
> + .parent_data = &(const struct clk_parent_data) {
> + .index = DT_BI_TCXO,
> + },
> + .num_parents = 1,
> + .ops = &clk_alpha_pll_lucid_evo_ops,
> + },
> + },
> +};
> +
> +static const struct parent_map video_cc_parent_map_0[] = {
> + { P_BI_TCXO, 0 },
> +};
> +
> +static const struct clk_parent_data video_cc_parent_data_0[] = {
> + { .index = DT_BI_TCXO },
> +};
> +
> +static const struct parent_map video_cc_parent_map_1[] = {
> + { P_BI_TCXO, 0 },
> + { P_VIDEO_CC_PLL0_OUT_MAIN, 1 },
> +};
> +
> +static const struct clk_parent_data video_cc_parent_data_1[] = {
> + { .index = DT_BI_TCXO },
> + { .hw = &video_cc_pll0.clkr.hw },
> +};
> +
> +static const struct parent_map video_cc_parent_map_2[] = {
> + { P_SLEEP_CLK, 0 },
> +};
> +
> +static const struct clk_parent_data video_cc_parent_data_2[] = {
> + { .index = DT_SLEEP_CLK },
> +};
> +
> +static const struct freq_tbl ftbl_video_cc_ahb_clk_src[] = {
> + F(19200000, P_BI_TCXO, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 video_cc_ahb_clk_src = {
> + .cmd_rcgr = 0x8018,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_0,
> + .freq_tbl = ftbl_video_cc_ahb_clk_src,
> + .hw_clk_ctrl = true,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_ahb_clk_src",
> + .parent_data = video_cc_parent_data_0,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_0),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static const struct freq_tbl ftbl_video_cc_mvs0_clk_src[] = {
> + F(576000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(633000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(720000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1014000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1098000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1113000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1332000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + F(1600000000, P_VIDEO_CC_PLL0_OUT_MAIN, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 video_cc_mvs0_clk_src = {
> + .cmd_rcgr = 0x8000,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_1,
> + .freq_tbl = ftbl_video_cc_mvs0_clk_src,
> + .hw_clk_ctrl = true,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_clk_src",
> + .parent_data = video_cc_parent_data_1,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_1),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static const struct freq_tbl ftbl_video_cc_sleep_clk_src[] = {
> + F(32000, P_SLEEP_CLK, 1, 0, 0),
> + { }
> +};
> +
> +static struct clk_rcg2 video_cc_sleep_clk_src = {
> + .cmd_rcgr = 0x8110,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_2,
> + .freq_tbl = ftbl_video_cc_sleep_clk_src,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_sleep_clk_src",
> + .parent_data = video_cc_parent_data_2,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_2),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static struct clk_rcg2 video_cc_xo_clk_src = {
> + .cmd_rcgr = 0x80f4,
> + .mnd_width = 0,
> + .hid_width = 5,
> + .parent_map = video_cc_parent_map_0,
> + .freq_tbl = ftbl_video_cc_ahb_clk_src,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_xo_clk_src",
> + .parent_data = video_cc_parent_data_0,
> + .num_parents = ARRAY_SIZE(video_cc_parent_data_0),
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_rcg2_shared_ops,
> + },
> +};
> +
> +static struct clk_regmap_div video_cc_mvs0_div_clk_src = {
> + .reg = 0x80ac,
> + .shift = 0,
> + .width = 4,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_div_clk_src",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_regmap_div_ro_ops,
> + },
> +};
> +
> +static struct clk_regmap_div video_cc_mvs0c_div2_div_clk_src = {
> + .reg = 0x8058,
> + .shift = 0,
> + .width = 4,
> + .clkr.hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0c_div2_div_clk_src",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_regmap_div_ro_ops,
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0_clk = {
> + .halt_reg = 0x80a0,
> + .halt_check = BRANCH_HALT_VOTED,
> + .hwcg_reg = 0x80a0,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0x80a0,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0_div_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0_shift_clk = {
> + .halt_reg = 0x8144,
> + .halt_check = BRANCH_HALT_VOTED,
> + .hwcg_reg = 0x8144,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0x8144,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0_shift_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_xo_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0c_clk = {
> + .halt_reg = 0x804c,
> + .halt_check = BRANCH_HALT,
> + .clkr = {
> + .enable_reg = 0x804c,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0c_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_mvs0c_div2_div_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct clk_branch video_cc_mvs0c_shift_clk = {
> + .halt_reg = 0x8148,
> + .halt_check = BRANCH_HALT_VOTED,
> + .hwcg_reg = 0x8148,
> + .hwcg_bit = 1,
> + .clkr = {
> + .enable_reg = 0x8148,
> + .enable_mask = BIT(0),
> + .hw.init = &(const struct clk_init_data) {
> + .name = "video_cc_mvs0c_shift_clk",
> + .parent_hws = (const struct clk_hw*[]) {
> + &video_cc_xo_clk_src.clkr.hw,
> + },
> + .num_parents = 1,
> + .flags = CLK_SET_RATE_PARENT,
> + .ops = &clk_branch2_ops,
> + },
> + },
> +};
> +
> +static struct gdsc video_cc_mvs0c_gdsc = {
> + .gdscr = 0x8034,
> + .en_rest_wait_val = 0x2,
> + .en_few_wait_val = 0x2,
> + .clk_dis_wait_val = 0x6,
> + .pd = {
> + .name = "video_cc_mvs0c_gdsc",
> + },
> + .pwrsts = PWRSTS_OFF_ON,
> + .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE,
> +};
> +
> +static struct gdsc video_cc_mvs0_gdsc = {
> + .gdscr = 0x808c,
> + .en_rest_wait_val = 0x2,
> + .en_few_wait_val = 0x2,
> + .clk_dis_wait_val = 0x6,
> + .pd = {
> + .name = "video_cc_mvs0_gdsc",
> + },
> + .pwrsts = PWRSTS_OFF_ON,
> + .parent = &video_cc_mvs0c_gdsc.pd,
> + .flags = POLL_CFG_GDSCR | RETAIN_FF_ENABLE | HW_CTRL_TRIGGER,
> +};
> +
> +static struct clk_regmap *video_cc_eliza_clocks[] = {
> + [VIDEO_CC_AHB_CLK_SRC] = &video_cc_ahb_clk_src.clkr,
> + [VIDEO_CC_MVS0_CLK] = &video_cc_mvs0_clk.clkr,
> + [VIDEO_CC_MVS0_CLK_SRC] = &video_cc_mvs0_clk_src.clkr,
> + [VIDEO_CC_MVS0_DIV_CLK_SRC] = &video_cc_mvs0_div_clk_src.clkr,
> + [VIDEO_CC_MVS0_SHIFT_CLK] = &video_cc_mvs0_shift_clk.clkr,
> + [VIDEO_CC_MVS0C_CLK] = &video_cc_mvs0c_clk.clkr,
> + [VIDEO_CC_MVS0C_DIV2_DIV_CLK_SRC] = &video_cc_mvs0c_div2_div_clk_src.clkr,
> + [VIDEO_CC_MVS0C_SHIFT_CLK] = &video_cc_mvs0c_shift_clk.clkr,
> + [VIDEO_CC_PLL0] = &video_cc_pll0.clkr,
> + [VIDEO_CC_SLEEP_CLK_SRC] = &video_cc_sleep_clk_src.clkr,
> + [VIDEO_CC_XO_CLK_SRC] = &video_cc_xo_clk_src.clkr,
> +};
> +
> +static struct gdsc *video_cc_eliza_gdscs[] = {
> + [VIDEO_CC_MVS0_GDSC] = &video_cc_mvs0_gdsc,
> + [VIDEO_CC_MVS0C_GDSC] = &video_cc_mvs0c_gdsc,
> +};
> +
> +static const struct qcom_reset_map video_cc_eliza_resets[] = {
> + [VIDEO_CC_INTERFACE_BCR] = { 0x80d8 },
> + [VIDEO_CC_MVS0_CLK_ARES] = { 0x80a0, 2 },
> + [VIDEO_CC_MVS0_BCR] = { 0x8088 },
> + [VIDEO_CC_MVS0C_CLK_ARES] = { 0x804c, 2 },
> + [VIDEO_CC_MVS0C_BCR] = { 0x8030 },
> + [VIDEO_CC_XO_CLK_ARES] = { 0x810c, 2 },
> +};
> +
> +static struct clk_alpha_pll *video_cc_eliza_plls[] = {
> + &video_cc_pll0,
> +};
> +
> +static u32 video_cc_eliza_critical_cbcrs[] = {
> + 0x80dc, /* VIDEO_CC_AHB_CLK */
> + 0x8128, /* VIDEO_CC_SLEEP_CLK */
> + 0x810c, /* VIDEO_CC_XO_CLK */
> +};
> +
> +static const struct regmap_config video_cc_eliza_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> + .max_register = 0x9f50,
> + .fast_io = true,
> +};
> +
> +static struct qcom_cc_driver_data video_cc_eliza_driver_data = {
> + .alpha_plls = video_cc_eliza_plls,
> + .num_alpha_plls = ARRAY_SIZE(video_cc_eliza_plls),
> + .clk_cbcrs = video_cc_eliza_critical_cbcrs,
> + .num_clk_cbcrs = ARRAY_SIZE(video_cc_eliza_critical_cbcrs),
> +};
> +
> +static const struct qcom_cc_desc video_cc_eliza_desc = {
> + .config = &video_cc_eliza_regmap_config,
> + .clks = video_cc_eliza_clocks,
> + .num_clks = ARRAY_SIZE(video_cc_eliza_clocks),
> + .resets = video_cc_eliza_resets,
> + .num_resets = ARRAY_SIZE(video_cc_eliza_resets),
> + .gdscs = video_cc_eliza_gdscs,
> + .num_gdscs = ARRAY_SIZE(video_cc_eliza_gdscs),
> + .driver_data = &video_cc_eliza_driver_data,
> +};
> +
> +static const struct of_device_id video_cc_eliza_match_table[] = {
> + { .compatible = "qcom,eliza-videocc" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, video_cc_eliza_match_table);
> +
> +static int video_cc_eliza_probe(struct platform_device *pdev)
> +{
> + return qcom_cc_probe(pdev, &video_cc_eliza_desc);
> +}
> +
> +static struct platform_driver video_cc_eliza_driver = {
> + .probe = video_cc_eliza_probe,
> + .driver = {
> + .name = "videocc-eliza",
> + .of_match_table = video_cc_eliza_match_table,
> + },
> +};
> +
> +module_platform_driver(video_cc_eliza_driver);
> +
> +MODULE_DESCRIPTION("QTI VIDEOCC Eliza Driver");
> +MODULE_LICENSE("GPL");
>
^ permalink raw reply
* Re: [RFC V1 06/16] arm64/mm: Convert READ_ONCE() as pudp_get() while accessing PUD
From: Anshuman Khandual @ 2026-04-10 4:50 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm, kasan-dev
In-Reply-To: <b1e1783c-3621-41e4-b65d-38cf66a1124c@kernel.org>
On 08/04/26 5:45 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Convert all READ_ONCE() based PUD accesses as pudp_get() instead which will
>> support both D64 and D128 translation regime going forward.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: kasan-dev@googlegroups.com
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>
> I was wondering for a second whether it would be better to structure
> this as "convert READ_ONCE to use pxxxp_get() in fault.c" instead,
> essentially, to touch each file only once.
But will not that create too many patches ?
>
> Anyhow
>
> Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
>
Thanks !
^ permalink raw reply
* Re: [PATCH 3/4] perf arm_spe: Decode Arm N1 IMPDEF events
From: Namhyung Kim @ 2026-04-10 4:51 UTC (permalink / raw)
To: James Clark
Cc: Ian Rogers, John Garry, Will Deacon, Mike Leach, Leo Yan,
Peter Zijlstra, Ingo Molnar, Arnaldo Carvalho de Melo,
Mark Rutland, Alexander Shishkin, Jiri Olsa, Adrian Hunter,
Al Grant, linux-arm-kernel, linux-perf-users, linux-kernel
In-Reply-To: <1b40ec9a-a003-4acc-9399-1a8d96fc4e42@linaro.org>
On Wed, Apr 08, 2026 at 09:47:41AM +0100, James Clark wrote:
>
>
> On 07/04/2026 7:26 pm, Ian Rogers wrote:
> > On Tue, Apr 7, 2026 at 5:35 AM James Clark <james.clark@linaro.org> wrote:
> > >
> > >
> > >
> > > On 02/04/2026 4:26 pm, Ian Rogers wrote:
> > > > On Wed, Apr 1, 2026 at 7:26 AM James Clark <james.clark@linaro.org> wrote:
> > > > >
> > > > > From the TRM [1], N1 has one IMPDEF event which isn't covered by the
> > > > > common list. Add a framework so that more cores can be added in the
> > > > > future and that the N1 IMPDEF event can be decoded. Also increase the
> > > > > size of the buffer because we're adding more strings and if it gets
> > > > > truncated it falls back to a hex dump only.
> > > > >
> > > > > [1]: https://developer.arm.com/documentation/100616/0401/Statistical-Profiling-Extension/implementation-defined-features-of-SPE
> > > > > Suggested-by: Al Grant <al.grant@arm.com>
> > > > > Signed-off-by: James Clark <james.clark@linaro.org>
> > > > > ---
> > > > > tools/perf/util/arm-spe-decoder/Build | 2 +
> > > > > .../util/arm-spe-decoder/arm-spe-pkt-decoder.c | 45 ++++++++++++++++++++--
> > > > > .../util/arm-spe-decoder/arm-spe-pkt-decoder.h | 5 ++-
> > > > > tools/perf/util/arm-spe.c | 13 ++++---
> > > > > 4 files changed, 54 insertions(+), 11 deletions(-)
> > > > >
> > > > > diff --git a/tools/perf/util/arm-spe-decoder/Build b/tools/perf/util/arm-spe-decoder/Build
> > > > > index ab500e0efe24..97a298d1e279 100644
> > > > > --- a/tools/perf/util/arm-spe-decoder/Build
> > > > > +++ b/tools/perf/util/arm-spe-decoder/Build
> > > > > @@ -1 +1,3 @@
> > > > > perf-util-y += arm-spe-pkt-decoder.o arm-spe-decoder.o
> > > > > +
> > > > > +CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/ -I$(OUTPUT)arch/arm64/include/generated/
> > > > > diff --git a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > index c880b0dec3a1..42a7501d4dfe 100644
> > > > > --- a/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > +++ b/tools/perf/util/arm-spe-decoder/arm-spe-pkt-decoder.c
> > > > > @@ -15,6 +15,8 @@
> > > > >
> > > > > #include "arm-spe-pkt-decoder.h"
> > > > >
> > > > > +#include "../../arm64/include/asm/cputype.h"
> > > >
> > > > Sashiko spotted:
> > > > https://sashiko.dev/#/patchset/20260401-james-spe-impdef-decode-v1-0-ad0d372c220c%40linaro.org
> > > > """
> > > > This isn't a bug, but does this include directive rely on accidental
> > > > path normalization?
> > > >
> > > > The relative path ../../arm64/include/asm/cputype.h does not exist relative
> > > > to arm-spe-pkt-decoder.c. It only compiles because the Build file adds
> > > > -I$(srctree)/tools/arch/arm64/include/ to CFLAGS.
> > > >
> > > > Would it be cleaner to use #include <asm/cputype.h> to explicitly rely on
> > > > the include path?
> > > > [ ... ]
> > > > """
> > > > I wouldn't use <asm/cputype.h> due to cross-compilation and the like,
> > > > instead just add the extra "../" into the include path.
> > > >
> > >
> > > Do you mean change the #include to this?
> > >
> > > #include "../../../arm64/include/asm/cputype.h"
> > >
> > > I still need to add:
> > >
> > > CFLAGS_arm-spe-pkt-decoder.o += -I$(srctree)/tools/arch/arm64/include/
> > >
> > > To make the this include in cputype.h work:
> > >
> > > #include <asm/sysreg.h>
> > >
> > > Which probably only works because there isn't a sysreg.h on other
> > > architectures. But I'm not sure what the significance of ../../ vs
> > > ../../../ is if either compile? arm-spe.c already does it with ../../
> > > which is what I copied.
> >
> > Hmm.. maybe the path should be
> > "../../../arch/arm64/include/asm/cputype.h". The include preference is
> > for a path relative to the source file and
> > ../../arm64/include/asm/cputype.h doesn't exist. It is kind of horrid
>
> Up 3 dirs from arm-spe-pkt-decoder.c would be
> "tools/arm64/include/asm/cputype.h" which doesn't exist either unless I'm
> missing something?
>
> If get the compiler to print the path it uses with 3 then it would use the
> x86 uapi include path which doesn't seem any less weird to me:
>
> ...
> In file included from util/arm-spe-decoder/arm-spe-pkt-decoder.c:19:
>
> linux/tools/arch/x86/include/uapi/../../../arm64/include/asm/cputype.h:254:10:
>
>
> > to add an include path and then use a relative path to escape into a
> > higher-level directory. arm-spe.c is a little different as it is one
> > directory higher in the directory layout.
> >
>
> It is one folder higher, but arm-spe.c still relies on adding a special
> include path to CFLAGS_arm-spe.o to make it work. It's not including a real
> path relative to the source either.
>
> Yeah it's a bit horrible but I don't think the asm/ thing combined with
> copying headers from the kernel to tools expected to handle the case where
> we would want to use asm/ stuff for a different arch than the compile one.
> It might not be normal to use relative include paths to escape to higher
> directories, but it's not a normal situation either. I think it's a special
> case for a special scenario. I'm not sure of a better way, but this is
> working for now.
I hope we can cleanup the header inclusion path someday. My idea is
that it always starts from the root of the perf directory. So it'd
include "util/xxx.h" even if the source file is already in util/.
Thanks,
Namhyung
^ permalink raw reply
* Re: [RFC V1 07/16] arm64/mm: Convert READ_ONCE() as p4dp_get() while accessing P4D
From: Anshuman Khandual @ 2026-04-10 5:05 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm, kasan-dev
In-Reply-To: <238ab437-06b1-43ef-86bb-9341c02040b1@kernel.org>
On 08/04/26 5:47 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Convert all READ_ONCE() based P4D accesses as p4dp_get() instead which will
>> support both D64 and D128 translation regime going forward.
>>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Will Deacon <will@kernel.org>
>> Cc: Ryan Roberts <ryan.roberts@arm.com>
>> Cc: Mark Rutland <mark.rutland@arm.com>
>> Cc: linux-arm-kernel@lists.infradead.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: kasan-dev@googlegroups.com
>> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
>> ---
>
>
> [...]
>
>> static void __init kasan_pgd_populate(unsigned long addr, unsigned long end,
>> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
>> index a80d06db4de6..16ae11b29f66 100644
>> --- a/arch/arm64/mm/mmu.c
>> +++ b/arch/arm64/mm/mmu.c
>> @@ -354,7 +354,7 @@ static int alloc_init_pud(p4d_t *p4dp, unsigned long addr, unsigned long end,
>> {
>> int ret = 0;
>> unsigned long next;
>> - p4d_t p4d = READ_ONCE(*p4dp);
>> + p4d_t p4d = p4dp_get(p4dp);
>> pud_t *pudp;
>>
>> if (p4d_none(p4d)) {
>> @@ -443,7 +443,7 @@ static int alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
>> }
>>
>> do {
>> - p4d_t old_p4d = READ_ONCE(*p4dp);
>> + p4d_t old_p4d = p4dp_get(p4dp);
>>
>> next = p4d_addr_end(addr, end);
>>
>> @@ -453,7 +453,7 @@ static int alloc_init_p4d(pgd_t *pgdp, unsigned long addr, unsigned long end,
>> goto out;
>>
>> BUG_ON(p4d_val(old_p4d) != 0 &&
>> - p4d_val(old_p4d) != READ_ONCE(p4d_val(*p4dp)));
>> + p4d_val(old_p4d) != (p4d_val(p4dp_get(p4dp))));
>
> Same here, while at it remove the BUG_ON. (see below)
>
>>
>> phys += next - addr;
>> } while (p4dp++, addr = next, addr != end);
>> @@ -1541,7 +1541,7 @@ static void unmap_hotplug_p4d_range(pgd_t *pgdp, unsigned long addr,
>> do {
>> next = p4d_addr_end(addr, end);
>> p4dp = p4d_offset(pgdp, addr);
>> - p4d = READ_ONCE(*p4dp);
>> + p4d = p4dp_get(p4dp);
>> if (p4d_none(p4d))
>> continue;
>>
>> @@ -1703,7 +1703,7 @@ static void free_empty_p4d_table(pgd_t *pgdp, unsigned long addr,
>> do {
>> next = p4d_addr_end(addr, end);
>> p4dp = p4d_offset(pgdp, addr);
>> - p4d = READ_ONCE(*p4dp);
>> + p4d = p4dp_get(p4dp);
>> if (p4d_none(p4d))
>> continue;
>>
>> @@ -1724,7 +1724,7 @@ static void free_empty_p4d_table(pgd_t *pgdp, unsigned long addr,
>> */
>> p4dp = p4d_offset(pgdp, 0UL);
>> for (i = 0; i < PTRS_PER_P4D; i++) {
>> - if (!p4d_none(READ_ONCE(p4dp[i])))
>> + if (!p4d_none(p4dp_get(p4dp + i)))
>> return;
>> }
>>
>> @@ -2258,4 +2258,21 @@ int pmdp_test_and_clear_young(struct vm_area_struct *vma,
>> }
>> #endif /* CONFIG_TRANSPARENT_HUGEPAGE || CONFIG_ARCH_HAS_NONLEAF_PMD_YOUNG */
>>
>> +#if CONFIG_PGTABLE_LEVELS > 3
>> +phys_addr_t pud_offset_phys(p4d_t *p4dp, unsigned long addr)
>> +{
>> + p4d_t p4d = p4dp_get(p4dp);
>> +
>> + BUG_ON(!pgtable_l4_enabled());
>
> Heh, while at it, convert that to a VM_WARN_ON_ONCE() or anything else
> that is not a BUG.
>
> I strongly assume CONFIG_DEBUG_VM checks are sufficient.
There are multiple similar BUG_ON() instances
arch/arm64/include/asm/pgtable.h: BUG_ON(!pgtable_l4_enabled());
arch/arm64/include/asm/pgtable.h: BUG_ON(!pgtable_l5_enabled());
arch/arm64/mm/mmu.c: BUG_ON(pmd_val(old_pmd) != 0 &&
arch/arm64/mm/mmu.c: BUG_ON(pud_val(old_pud) != 0 &&
arch/arm64/mm/mmu.c: BUG_ON(p4d_val(old_p4d) != 0 &&
Shall we convert all of them as VM_WARN_ON_ONCE() in a separate patch
as a pre-requisite ?
>
>> +
>> + return p4d_page_paddr(p4d) + pud_index(addr) * sizeof(pud_t);
>> +}
>> +
>
^ permalink raw reply
* Re: [PATCH v5 0/4] perf arm_spe: Extend SIMD operations
From: Namhyung Kim @ 2026-04-10 5:06 UTC (permalink / raw)
To: Leo Yan
Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Mark Rutland, Arnaldo Carvalho de Melo,
linux-perf-users, linux-arm-kernel
In-Reply-To: <20260408-perf_support_arm_spev1-3-v5-0-b5bcea6217bb@arm.com>
Hi Leo,
On Wed, Apr 08, 2026 at 10:42:30AM +0100, Leo Yan wrote:
> This series extends SIMD flag for Arm SPE and updated the document.
>
> Since I failed to get perf core maintainer's review for uAPI header
> updating for data source fields (since last year's Sepetember), this
> series I dropped uAPI changes and sent only SIMD flag changes, hope
> it is easier for perf tool maintainer's picking up.
Sure, I believe these SIMD flags are independent from the kernel and
uAPI changes as they are from ARM SPE formats directly.
>
> Anyway, uAPI patches will be sent out separately.
>
> This version is rebased onto the latest perf-tools-next branch.
Thanks for your work,
Namhyung
>
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
> Changes in v5:
> - Dropped uAPI header changes for data source fields updating.
> - Link to v4: https://lore.kernel.org/r/20260106-perf_support_arm_spev1-3-v4-0-b887bb999f6e@arm.com
>
> Changes in v4 (resend):
> - Updated for Ian and James' review tags.
> - Link to v4: https://lore.kernel.org/r/20260106-perf_support_arm_spev1-3-v4-0-bb2d143b3860@arm.com
>
> Changes in v4:
> - Updated for Ian and James' review tags.
> - Rebased on the latest perf-tools-next branch.
> - Link to v3: https://lore.kernel.org/r/20251112-perf_support_arm_spev1-3-v3-0-e63c9829f9d9@arm.com
>
> Changes in v3:
> - Rebased on the latest perf-tools-next branch.
> - Link to v2: https://lore.kernel.org/r/20251017-perf_support_arm_spev1-3-v2-0-2d41e4746e1b@arm.com
>
> Changes in v2:
> - Refined to use enums for 2nd operation types. (James)
> - Avoided adjustment bit positions for operations. (James)
> - Used enum for extended operation type in uapi header and defined
> individual bit field for operation details in uaip header. (James)
> - Refined SIMD flag definitions. (James)
> - Extracted a separate commit for updating tool's header. (James/Arnaldo)
> - Minor improvement for printing memory events.
> - Rebased on the latest perf-tools-next branch.
> - Link to v1: https://lore.kernel.org/r/20250929-perf_support_arm_spev1-3-v1-0-1150b3c83857@arm.com
>
> ---
> Leo Yan (4):
> perf sort: Support sort ASE and SME
> perf sort: Sort disabled and full predicated flags
> perf report: Update document for SIMD flags
> perf arm_spe: Improve SIMD flags setting
>
> tools/perf/Documentation/perf-report.txt | 5 ++++-
> tools/perf/util/arm-spe.c | 26 ++++++++++++++++++++------
> tools/perf/util/sample.h | 21 ++++++++++++++++-----
> tools/perf/util/sort.c | 21 +++++++++++++++------
> 4 files changed, 55 insertions(+), 18 deletions(-)
> ---
> base-commit: dc647eb00969cd213c84d6caee90c480317e857d
> change-id: 20250820-perf_support_arm_spev1-3-b6efd6fc77b2
>
> Best regards,
> --
> Leo Yan <leo.yan@arm.com>
>
^ permalink raw reply
* Re: [PATCH v5 0/4] perf arm_spe: Extend SIMD operations
From: Namhyung Kim @ 2026-04-10 5:10 UTC (permalink / raw)
To: Leo Yan
Cc: Arnaldo Carvalho de Melo, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Mark Rutland, Arnaldo Carvalho de Melo,
linux-perf-users, linux-arm-kernel
In-Reply-To: <20260408-perf_support_arm_spev1-3-v5-0-b5bcea6217bb@arm.com>
On Wed, Apr 08, 2026 at 10:42:30AM +0100, Leo Yan wrote:
> This series extends SIMD flag for Arm SPE and updated the document.
>
> Since I failed to get perf core maintainer's review for uAPI header
> updating for data source fields (since last year's Sepetember), this
> series I dropped uAPI changes and sent only SIMD flag changes, hope
> it is easier for perf tool maintainer's picking up.
>
> Anyway, uAPI patches will be sent out separately.
>
> This version is rebased onto the latest perf-tools-next branch.
Unfortunately it doesn't apply due to a recent change. Can you please
rebase it once again?
Thanks,
Namhyung
>
> Signed-off-by: Leo Yan <leo.yan@arm.com>
> ---
> Changes in v5:
> - Dropped uAPI header changes for data source fields updating.
> - Link to v4: https://lore.kernel.org/r/20260106-perf_support_arm_spev1-3-v4-0-b887bb999f6e@arm.com
>
> Changes in v4 (resend):
> - Updated for Ian and James' review tags.
> - Link to v4: https://lore.kernel.org/r/20260106-perf_support_arm_spev1-3-v4-0-bb2d143b3860@arm.com
>
> Changes in v4:
> - Updated for Ian and James' review tags.
> - Rebased on the latest perf-tools-next branch.
> - Link to v3: https://lore.kernel.org/r/20251112-perf_support_arm_spev1-3-v3-0-e63c9829f9d9@arm.com
>
> Changes in v3:
> - Rebased on the latest perf-tools-next branch.
> - Link to v2: https://lore.kernel.org/r/20251017-perf_support_arm_spev1-3-v2-0-2d41e4746e1b@arm.com
>
> Changes in v2:
> - Refined to use enums for 2nd operation types. (James)
> - Avoided adjustment bit positions for operations. (James)
> - Used enum for extended operation type in uapi header and defined
> individual bit field for operation details in uaip header. (James)
> - Refined SIMD flag definitions. (James)
> - Extracted a separate commit for updating tool's header. (James/Arnaldo)
> - Minor improvement for printing memory events.
> - Rebased on the latest perf-tools-next branch.
> - Link to v1: https://lore.kernel.org/r/20250929-perf_support_arm_spev1-3-v1-0-1150b3c83857@arm.com
>
> ---
> Leo Yan (4):
> perf sort: Support sort ASE and SME
> perf sort: Sort disabled and full predicated flags
> perf report: Update document for SIMD flags
> perf arm_spe: Improve SIMD flags setting
>
> tools/perf/Documentation/perf-report.txt | 5 ++++-
> tools/perf/util/arm-spe.c | 26 ++++++++++++++++++++------
> tools/perf/util/sample.h | 21 ++++++++++++++++-----
> tools/perf/util/sort.c | 21 +++++++++++++++------
> 4 files changed, 55 insertions(+), 18 deletions(-)
> ---
> base-commit: dc647eb00969cd213c84d6caee90c480317e857d
> change-id: 20250820-perf_support_arm_spev1-3-b6efd6fc77b2
>
> Best regards,
> --
> Leo Yan <leo.yan@arm.com>
>
^ permalink raw reply
* Re: [RFC V1 08/16] arm64/mm: Convert READ_ONCE() as pgdp_get() while accessing PGD
From: Anshuman Khandual @ 2026-04-10 5:30 UTC (permalink / raw)
To: David Hildenbrand (Arm), linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, Mark Rutland,
Lorenzo Stoakes, Andrew Morton, Mike Rapoport, Linu Cherian,
linux-kernel, linux-mm, kasan-dev
In-Reply-To: <e294a87b-392b-4b12-bd12-70c66c793fcd@kernel.org>
On 08/04/26 5:49 PM, David Hildenbrand (Arm) wrote:
> On 2/24/26 06:11, Anshuman Khandual wrote:
>> Convert all READ_ONCE() based PGD accesses as pgdp_get() instead which will
>> support both D64 and D128 translation regime going forward.
>
> Please mention here why you move p4d_offset_phys/p4d_offset. (same
> applies to other patches)
Will do that.
>
> Do we get additional function calls that might degrade some page table
> walkers?
Sorry did not get it. Are you asking if D128 adds new page table
function paths thus increasing memory access latency etc ?
>
> Same comment regarding BUG_ON.
>
As mentioned earlier it might be better to have a separate change
converting similar BUG_ON() in various arm64 page table helpers.
^ permalink raw reply
* Re: [PATCH v9 02/11] drm/fourcc: Add DRM_FORMAT_XV20
From: Tomi Valkeinen @ 2026-04-10 5:32 UTC (permalink / raw)
To: Simon Ser
Cc: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, dri-devel, linux-kernel, linux-arm-kernel,
Geert Uytterhoeven, Dmitry Baryshkov, Pekka Paalanen,
Dmitry Baryshkov
In-Reply-To: <aocdbgbLe5WhUEOGeLg3P7fRDM8i72H9zBuUnoAjjsuvBLfMPofrPtaUEjII_43KXf1wCbv1G9UutJKMkWLaEcBSnrlUV78Wrhu6l_Z0xi8=@emersion.fr>
Hi,
On 26/03/2026 16:26, Simon Ser wrote:
> On Wednesday, March 25th, 2026 at 15:02, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
>
>> XV20 is 2 plane 10 bit per component YCbCr 2x1 subsampled format. XV20
>> is similar to the already existing P030 format, which is 2x2 subsampled.
>
> I don't know for sure the multi-planar YCbCr format name scheme we're
> using, but here are my observations looking at P, Q and S formats:
>
> - The first digit indicates sub-sampling. 0 for 2x2, 2 for 2x1, 4 for none.
> - The two other digits indicate bits for the Y channel, one of 10, 12, 16.
> One exception: Q401 indicates reverse order for Cb and Cr planes when compared
> to Q410.
>
> P030 is a bit of an outlier here since it's the only one with multiple
> Y samples. NV formats are also multi-planar but seem to use a completely
> separate scheme.
>
> Given the above I'd say what would make most sense to me is to use P230:
> keep the last two digits and change the first one to indicate that the
> only difference is the sub-sampling. Does that make sense to you?
I'm fine with that.
Tomi
^ permalink raw reply
* Re: [PATCH v2 4/8] clk: qcom: videocc: Add video clock controller driver for Eliza
From: Taniya Das @ 2026-04-10 5:46 UTC (permalink / raw)
To: Jie Gan, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Maxime Coquelin, Alexandre Torgue
Cc: Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel, Konrad Dybcio
In-Reply-To: <c7706c41-d855-4ed4-92c4-dca43c8f6d2a@oss.qualcomm.com>
On 4/10/2026 10:18 AM, Jie Gan wrote:
>> + depends on ARM64 || COMPILE_TEST
>> + select CLK_GLYMUR_GCC
>
> Hi,
>
> My bot found a [BUG] here, please ignore it if it's a false positive issue.
>
> CLK_ELIZA_VIDEOCC selects CLK_GLYMUR_GCC instead of CLK_ELIZA_GCC
>
> - select CLK_GLYMUR_GCC pulls in gcc-glymur.c instead of gcc-eliza.c
> - On an Eliza system, gcc-glymur.c will never probe (no matching DTS
> node), so GCC_VIDEO_AHB_CLK from the Eliza GCC will never be available
> to videocc
> - The videocc driver's clocks = <&gcc GCC_VIDEO_AHB_CLK> will fail to
> resolve at runtime
> - The correct fix is select CLK_ELIZA_GCC, consistent with all other
> Eliza clock controllers
>
Thanks, Jie for pointing out, will fix this.
GCC of ELIZA is already 'y' and Video driver probes as this
GCC_VIDEO_AHB_CLK is kept enabled/critical.
Please find the 'clk_summary' from device.
bi-tcxo-div2-clk 1 1 0 19200000
0 0 50000 Y deviceless
no_connection_id
video_cc_xo_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
video_cc_mvs0_shift_clk 0 0 0 19200000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0c_shift_clk 0 0 0 19200000
0 0 50000 N deviceless
no_connection_id
video_cc_pll0 0 0 0 576000000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
video_cc_mvs0c_div2_div_clk_src 0 0 0
9600000 0 0 50000 Y deviceless
no_connection_id
video_cc_mvs0c_clk 0 0 0 9600000
0 0 50000 N deviceless
no_connection_id
video_cc_mvs0_div_clk_src 0 0 0 6400000
0 0 50000 Y deviceless
no_connection_id
video_cc_mvs0_clk 0 0 0 6400000
0 0 50000 N deviceless
no_connection_id
video_cc_ahb_clk_src 0 0 0 19200000
0 0 50000 ? deviceless
no_connection_id
--
Thanks,
Taniya Das
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
From: Anushka Badhe @ 2026-04-10 5:55 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: linux-sound, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Anushka Badhe
Convert the rockchip,rk3399-gru-sound.txt DT binding to DT Schema
format.
Update rockchip,cpu from a single I2S controller phandle to a
phandle-array. Add an optional second entry for the SPDIF controller,
as seen in rk3399-gru.dtsi, required by boards with DisplayPort audio.
Signed-off-by: Anushka Badhe <anushkabadhe@gmail.com>
---
Changes in v2:
- Fix subject and body: "YAML Schema" -> "DT Schema"
- Fix title: "ROCKCHIP" -> "Rockchip"
- List items for rockchip,cpu with I2S and SPDIF descriptions
- List items for rockchip,codec
- Update descriptions for rockchip,cpu, rockchip,codec and
dmic-wakeup-delay-ms
.../sound/rockchip,rk3399-gru-sound.txt | 22 -------
.../sound/rockchip,rk3399-gru-sound.yaml | 60 +++++++++++++++++++
2 files changed, 60 insertions(+), 22 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
create mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
deleted file mode 100644
index 72d3cf4c2606..000000000000
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
-
-Required properties:
-- compatible: "rockchip,rk3399-gru-sound"
-- rockchip,cpu: The phandle of the Rockchip I2S controller that's
- connected to the codecs
-- rockchip,codec: The phandle of the audio codecs
-
-Optional properties:
-- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
- If this option is specified, which means it's required dmic need
- delay for DMIC to ready so that rt5514 can avoid recording before
- DMIC send valid data
-
-Example:
-
-sound {
- compatible = "rockchip,rk3399-gru-sound";
- rockchip,cpu = <&i2s0>;
- rockchip,codec = <&max98357a &rt5514 &da7219>;
- dmic-wakeup-delay-ms = <20>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
new file mode 100644
index 000000000000..e9d13695cc77
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/rockchip,rk3399-gru-sound.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Rockchip with MAX98357A/RT5514/DA7219 codecs on GRU boards
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-gru-sound
+
+ rockchip,cpu:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ List of phandles to the Rockchip CPU DAI controllers connected to codecs
+ minItems: 1
+ items:
+ - items:
+ - description: Phandle to the Rockchip I2S controllers
+ - items:
+ - description: |
+ Phandle to the Rockchip SPDIF controller. Required when a
+ DisplayPort audio codec is referenced in rockchip,codec
+
+ rockchip,codec:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: |
+ The phandles of the audio codecs connected to the Rockchip CPU DAI
+ controllers
+ minItems: 1
+ maxItems: 6
+ items:
+ maxItems: 1
+
+ dmic-wakeup-delay-ms:
+ description: |
+ specify delay time (ms) for DMIC ready.
+ If this option is specified, a delay is required for DMIC to get ready
+ so that rt5514 can avoid recording before DMIC sends valid data
+
+required:
+ - compatible
+ - rockchip,cpu
+ - rockchip,codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "rockchip,rk3399-gru-sound";
+ rockchip,cpu = <&i2s0 &spdif>;
+ rockchip,codec = <&max98357a &rt5514 &da7219 &cdn_dp>;
+ dmic-wakeup-delay-ms = <20>;
+ };
+
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v9 05/11] drm/fourcc: Add DRM_FORMAT_X403
From: Tomi Valkeinen @ 2026-04-10 6:07 UTC (permalink / raw)
To: Simon Ser
Cc: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, dri-devel, linux-kernel, linux-arm-kernel,
Geert Uytterhoeven, Dmitry Baryshkov, Pekka Paalanen
In-Reply-To: <jCbIrZ5-fvx73de8DmjQ7xpuEw63kTCQ5p88cdF7yRcUk7uNbE9y0YU7uZbPXNotQAB9y6c0u5n3TrnXckvQ8Oje_J3QGxEwBSr_liQVDK0=@emersion.fr>
Hi,
On 26/03/2026 16:43, Simon Ser wrote:
> On Wednesday, March 25th, 2026 at 15:02, Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> wrote:
>
>> +/*
>> + * 3 plane non-subsampled (444) YCbCr
>> + * 10 bpc, 30 bits per sample image data in a single contiguous buffer.
>> + * index 0: Y plane, [31:0] x:Y2:Y1:Y0 [2:10:10:10] little endian
>> + * index 1: Cb plane, [31:0] x:Cb2:Cb1:Cb0 [2:10:10:10] little endian
>> + * index 2: Cr plane, [31:0] x:Cr2:Cr1:Cr0 [2:10:10:10] little endian
>> + */
>> +#define DRM_FORMAT_X403 fourcc_code('X', '4', '0', '3')
>
> So, this one is different from the Q family, because Q has padding in
Any idea where the letters (P, Q, S) come from?
> LSB rather than MSB. Speaking of, maybe we should add "LSB aligned" to
> the doc comment to make that clear?
Yes, I can add that.
> Re-reading the sibling thread about DRM_FORMAT_XV20, sounds like the
> first digit matches my expectations for sub-sampling. How did you pick
I just used the name in Xilinx's BSP kernel.
> the last two digits? I think I would've expected "30" here rather than
> "03", since the last two planes are Cb Cr rather than Cr Cb.
Hmm, but X403 is Cb:Cr, and P030 is Cr:Cb, so doesn't 03 make sense
here? Oh, but Q401 is Cr:Cb, and it's 01...
Now that I look at this... I think I have to go back and do more
testing. From the Xilinx docs, it looks to me that the XV15/XV20 should
have the same CrCb order than X403. But the comments in these patches
say otherwise. I'm pretty sure my tests conformed to the comments here,
but now I don't feel so sure anymore. It's been more than a year since I
wrote the tests and properly tested these, so I have to spend a bit time
to get everything up again.
> Has the first "X" letter been picked arbitrarily? It's already used to
> denote padding in other formats so I wonder if we should pick that
> instead of, say, "T".
I didn't invent the name, I just took the naming Xilinx used. I don't
know the history behind it. I assume the "X" is for Xilinx, but I could
be wrong here. What would "T" be for? "Tomi"? =)
Tomi
^ permalink raw reply
* RE: [PATCH rc v1 3/4] iommu/arm-smmu-v3: Retain SMMUEN during kdump device reset
From: Tian, Kevin @ 2026-04-10 6:21 UTC (permalink / raw)
To: Nicolin Chen, jgg@nvidia.com, will@kernel.org,
robin.murphy@arm.com
Cc: jamien@nvidia.com, joro@8bytes.org, praan@google.com,
baolu.lu@linux.intel.com, smostafa@google.com,
miko.lenczewski@arm.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <c116eba01bcd88ba3b8ba47dc08132c4546e91f5.1775763475.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Friday, April 10, 2026 3:47 AM
>
> /* Clear CR0 and sync (disables SMMU and queue processing) */
> reg = readl_relaxed(smmu->base + ARM_SMMU_CR0);
> if (reg & CR0_SMMUEN) {
> dev_warn(smmu->dev, "SMMU currently enabled!
> Resetting...\n");
move to after the check of kdump kernel
> @@ -5038,6 +5064,11 @@ static int arm_smmu_device_reset(struct
> arm_smmu_device *smmu)
> return ret;
> }
>
> + /*
> + * Disable EVTQ and PRIQ in kdump kernel. The old kernel's CDs and
> page
> + * tables may be corrupted, which could trigger event spamming.
> PRIQ is
> + * also useless since we cannot service page requests during kdump.
> + */
> if (is_kdump_kernel())
> enables &= ~(CR0_EVTQEN | CR0_PRIQEN);
>
then just don't enable them in earlier lines?
^ permalink raw reply
* RE: [PATCH rc v1 4/4] iommu/arm-smmu-v3: Detect ARM_SMMU_OPT_KDUMP in arm_smmu_device_hw_probe()
From: Tian, Kevin @ 2026-04-10 6:22 UTC (permalink / raw)
To: Nicolin Chen, jgg@nvidia.com, will@kernel.org,
robin.murphy@arm.com
Cc: jamien@nvidia.com, joro@8bytes.org, praan@google.com,
baolu.lu@linux.intel.com, smostafa@google.com,
miko.lenczewski@arm.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <2572aa7fdd3b32eefe48693668c146f4a68ce50c.1775763475.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Friday, April 10, 2026 3:47 AM
> +
> + /*
> + * If SMMU is already active in kdump case, there could be in-flight
> DMA
> + * from devices initiated by the crashed kernel. Mark
> ARM_SMMU_OPT_KDUMP
> + * to let the init functions adopt the crashed kernel's stream table.
> + *
> + * Note that arm_smmu_adopt_strtab() uses memremap that can
> only work on
> + * a coherent SMMU. A non-coherent SMMU has no choice but to
> continue to
> + * abort any in-flight DMA.
> + */
> + if (is_kdump_kernel() && coherent &&
> + (readl_relaxed(smmu->base + ARM_SMMU_CR0) &
> CR0_SMMUEN))
> + smmu->options |= ARM_SMMU_OPT_KDUMP;
> +
> return 0;
A warning message for the non-coherent case?
^ permalink raw reply
* Re: [PATCH v1] phy: rockchip-snps-pcie3:phy: Configure clkreq_n and PowerDown for all lanes
From: Anand Moon @ 2026-04-10 6:26 UTC (permalink / raw)
To: Shawn Lin
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner,
open list:GENERIC PHY FRAMEWORK,
moderated list:ARM/Rockchip SoC support,
open list:ARM/Rockchip SoC support, open list, Niklas Cassel
In-Reply-To: <0ee54525-928e-a1ce-ec2d-1f85cf15abbc@rock-chips.com>
Hi Shawn,
Thanks for your review comments
On Fri, 10 Apr 2026 at 06:16, Shawn Lin <shawn.lin@rock-chips.com> wrote:
>
> Hi Anand
>
> 在 2026/04/09 星期四 12:49, Anand Moon 写道:
> > During the rk3588_p3phy_init sequence, the driver now explicitly
> > configures each lane's CON0 register to ensure
> > - PIPE 4.3 Compliance: clkreq_n (bit 6) is forced low (asserted) to meet
> > sideband signal requirements.
>
> clkreq_n is now force asserted via controller driver if supports_clkreq
> is not set.
>
> > - Active Power State: PowerDown[3:0] (bits 11:8) is set to P0
> > (Normal Operational State) to ensure the PHY is fully powered and ready
> > for link training.
> >
>
> P0 is the nature state when linking up. I don't know why it should be P0
> before we even don't know whether the device is present.
>
Ok understood. This step resets the lanes to their default state for
initialization.
I’ll collect additional input and verify if any configurations are
still missing.
Thanks
-Anand
^ permalink raw reply
* Re: [PATCH 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-10 6:27 UTC (permalink / raw)
To: Andrea della Porta
Cc: linux-pwm, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Broadcom internal kernel review list,
devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
Naushir Patuck, Stanimir Varbanov
In-Reply-To: <adfQ6Tvst3Vd1Mxe@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 1641 bytes --]
Hello Andrea,
On Thu, Apr 09, 2026 at 06:16:41PM +0200, Andrea della Porta wrote:
> On 23:45 Sun 05 Apr , Uwe Kleine-König wrote:
> > On Fri, Apr 03, 2026 at 04:31:55PM +0200, Andrea della Porta wrote:
> > > +static void rp1_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
> > > +{
> > > + struct rp1_pwm *rp1 = pwmchip_get_drvdata(chip);
> > > + u32 value;
> > > +
> > > + value = readl(rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > + value &= ~PWM_MODE_MASK;
> > > + writel(value, rp1->base + PWM_CHANNEL_CTRL(pwm->hwpwm));
> > > +
> > > + rp1_pwm_apply_config(chip, pwm);
> >
> > What is the purpose of this call?
>
> To update the configuration on the next PWM strobe in order to avoid
> glitches. I'll add a short comment in the code.
.pwm_free() should not touch the hardware configuration. Changing the
pinmuxing (which I guess is the purpose of clearing PWM_MODE_MASK) is
somewhat a grey area. If that saves energy, that's okish. Otherwise
not interfering with the operation of the PWM (e.g. to keep a display on
during kexec or so) is preferred.
> > > +static int rp1_pwm_resume(struct device *dev)
> > > +{
> > > + struct rp1_pwm *rp1 = dev_get_drvdata(dev);
> > > +
> > > + return clk_prepare_enable(rp1->clk);
> >
> > Hmm, if this fails and then the driver is unbound, the clk operations
> > are not balanced.
>
> I'll add some flags to check if the clock is really enabled or not.
To be honest, I guess that is a problem of several drivers, not only in
drivers/pwm. If this complicates the driver, I guess addressing this
isn't very critical.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* RE: [PATCH v6 02/10] reset: Add Realtek basic reset support
From: Yu-Chun Lin [林祐君] @ 2026-04-10 6:49 UTC (permalink / raw)
To: Philipp Zabel, mturquette@baylibre.com, sboyd@kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Edgar Lee [李承諭], afaerber@suse.com,
Jyan Chou [周芷安]
Cc: devicetree@vger.kernel.org, linux-clk@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-realtek-soc@lists.infradead.org,
James Tai [戴志峰],
CY_Huang[黃鉦晏],
Stanley Chang[昌育德]
In-Reply-To: <5dd7ddb50b71de737aae6ad4d11bd28fa52443a9.camel@pengutronix.de>
> On Do, 2026-04-02 at 15:39 +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Define the reset operations backed by a regmap-based register
> > interface and prepare the reset controller to be registered through
> > the reset framework.
> >
> > Since the reset controllers on Realtek SoCs often share the same
> > register space with the clock controllers, this common framework is
> > designed to extract the regmap and device tree node from the parent
> > device (e.g., an auxiliary device parent).
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Remove the global header include/linux/reset/realtek.h and use a
> > local common.h instead.
> > - Extract regmap and of_node directly from the parent device.
> > - Remove struct rtk_reset_initdata. Now, pass struct rtk_reset_data
> > directly when calling rtk_reset_controller_add().
> > ---
> > MAINTAINERS | 1 +
> > drivers/reset/Kconfig | 1 +
> > drivers/reset/Makefile | 1 +
> > drivers/reset/realtek/Kconfig | 3 ++
> > drivers/reset/realtek/Makefile | 2 + drivers/reset/realtek/common.c
> > | 85 ++++++++++++++++++++++++++++++++++
> > drivers/reset/realtek/common.h | 29 ++++++++++++
> > 7 files changed, 122 insertions(+)
> > create mode 100644 drivers/reset/realtek/Kconfig create mode 100644
> > drivers/reset/realtek/Makefile create mode 100644
> > drivers/reset/realtek/common.c create mode 100644
> > drivers/reset/realtek/common.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > 07e73bf621b0..8f355896583b 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -22240,6 +22240,7 @@ L: devicetree@vger.kernel.org
> > L: linux-clk@vger.kernel.org
> > S: Supported
> > F: Documentation/devicetree/bindings/clock/realtek*
> > +F: drivers/reset/realtek/*
> > F: include/dt-bindings/clock/realtek*
> > F: include/dt-bindings/reset/realtek*
> >
> > diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> > 7ce151f6a7e4..03be1931f264 100644
> > --- a/drivers/reset/Kconfig
> > +++ b/drivers/reset/Kconfig
> > @@ -398,6 +398,7 @@ config RESET_ZYNQMP
> >
> > source "drivers/reset/amlogic/Kconfig"
> > source "drivers/reset/hisilicon/Kconfig"
> > +source "drivers/reset/realtek/Kconfig"
> > source "drivers/reset/spacemit/Kconfig"
> > source "drivers/reset/starfive/Kconfig"
> > source "drivers/reset/sti/Kconfig"
> > diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile index
> > fc0cc99f8514..4407d1630070 100644
> > --- a/drivers/reset/Makefile
> > +++ b/drivers/reset/Makefile
> > @@ -2,6 +2,7 @@
> > obj-y += core.o
> > obj-y += amlogic/
> > obj-y += hisilicon/
> > +obj-y += realtek/
> > obj-y += spacemit/
> > obj-y += starfive/
> > obj-y += sti/
> > diff --git a/drivers/reset/realtek/Kconfig
> > b/drivers/reset/realtek/Kconfig new file mode 100644 index
> > 000000000000..99a14d355803
> > --- /dev/null
> > +++ b/drivers/reset/realtek/Kconfig
> > @@ -0,0 +1,3 @@
> > +# SPDX-License-Identifier: GPL-2.0-only config RESET_RTK_COMMON
> > + bool
>
> Please make this build-testable with COMPILE_TEST.
>
I will change Kconfig to
config RESET_RTK_COMMON
tristate "Realtek common reset driver" if COMPILE_TEST
help
Common helper code shared by Realtek reset controller drivers.
config COMMON_RESET_RTD1625
tristate "RTD1625 Reset Controller"
depends on ARCH_REALTEK || COMPILE_TEST
select RESET_RTK_COMMON
select AUXILIARY_BUS
help
This enables the reset controller driver for Realtek RTD1625 SoC.
> > diff --git a/drivers/reset/realtek/Makefile
> > b/drivers/reset/realtek/Makefile new file mode 100644 index
> > 000000000000..b59a3f7f2453
> > --- /dev/null
> > +++ b/drivers/reset/realtek/Makefile
> > @@ -0,0 +1,2 @@
> > +# SPDX-License-Identifier: GPL-2.0-only
> > +obj-$(CONFIG_RESET_RTK_COMMON) += common.o
> > diff --git a/drivers/reset/realtek/common.c
> > b/drivers/reset/realtek/common.c new file mode 100644 index
> > 000000000000..ea7ff27117e7
> > --- /dev/null
> > +++ b/drivers/reset/realtek/common.c
> > @@ -0,0 +1,85 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2019 Realtek Semiconductor Corporation */
> > +
> > +#include <linux/device.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/regmap.h>
> > +#include "common.h"
> > +
> > +static inline struct rtk_reset_data *to_rtk_reset_controller(struct
> > +reset_controller_dev *r) {
> > + return container_of(r, struct rtk_reset_data, rcdev); }
> > +
> > +static inline struct rtk_reset_desc *rtk_reset_get_desc(struct rtk_reset_data
> *data,
> > + unsigned
> long
> > +idx) {
> > + return &data->descs[idx];
> > +}
> > +
> > +static int rtk_reset_assert(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + struct rtk_reset_desc *desc = rtk_reset_get_desc(data, idx);
> > + u32 mask = desc->write_en ? (0x3 << desc->bit) : BIT(desc->bit);
> > + u32 val = desc->write_en ? (0x2 << desc->bit) : 0;
> > +
> > + return regmap_update_bits(data->regmap, desc->ofs, mask, val); }
> > +
> > +static int rtk_reset_deassert(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + struct rtk_reset_desc *desc = rtk_reset_get_desc(data, idx);
> > + u32 mask = desc->write_en ? (0x3 << desc->bit) : BIT(desc->bit);
> > + u32 val = mask;
> > +
> > + return regmap_update_bits(data->regmap, desc->ofs, mask, val); }
> > +
> > +static int rtk_reset_status(struct reset_controller_dev *rcdev,
> > + unsigned long idx) {
> > + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> > + struct rtk_reset_desc *desc = rtk_reset_get_desc(data, idx);
> > + u32 val;
> > + int ret;
> > +
> > + ret = regmap_read(data->regmap, desc->ofs, &val);
> > + if (ret)
> > + return ret;
> > +
> > + return !((val >> desc->bit) & 1); }
> > +
> > +static const struct reset_control_ops rtk_reset_ops = {
> > + .assert = rtk_reset_assert,
> > + .deassert = rtk_reset_deassert,
> > + .status = rtk_reset_status,
> > +};
> > +
> > +/* The caller must initialize data->rcdev.nr_resets and data->descs
> > +before
> > + * calling rtk_reset_controller_add().
> > + */
> > +int rtk_reset_controller_add(struct device *dev,
> > + struct rtk_reset_data *data) {
> > + struct device *parent = dev->parent;
> > +
> > + data->regmap = dev_get_regmap(parent, NULL);
> > + if (!data->regmap)
> > + return -ENODEV;
> > +
> > + data->rcdev.owner = THIS_MODULE;
>
> The rtk_reset_desc arrays used by this code live in the calling module, so it
> would be better to let the caller initialize .owner as well.
>
> It doesn't make a difference in practice, since CONFIG_RESET_RTK_COMMON
> isn't tristate (right now).
>
I will move 'data->rcdev.owner = THIS_MODULE' to the caller.
Best Regards,
Yu-Chun
>
> regards
> Philipp
^ permalink raw reply
* Re: [PATCH v9 05/11] drm/fourcc: Add DRM_FORMAT_X403
From: Tomi Valkeinen @ 2026-04-10 6:54 UTC (permalink / raw)
To: Simon Ser
Cc: Vishal Sagar, Anatoliy Klymenko, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Laurent Pinchart,
Michal Simek, dri-devel, linux-kernel, linux-arm-kernel,
Geert Uytterhoeven, Dmitry Baryshkov, Pekka Paalanen
In-Reply-To: <94283390-29cb-4640-b5b4-6a332dd7f2a4@ideasonboard.com>
On 10/04/2026 09:07, Tomi Valkeinen wrote:
> Hi,
>
> On 26/03/2026 16:43, Simon Ser wrote:
>> On Wednesday, March 25th, 2026 at 15:02, Tomi Valkeinen
>> <tomi.valkeinen@ideasonboard.com> wrote:
>>
>>> +/*
>>> + * 3 plane non-subsampled (444) YCbCr
>>> + * 10 bpc, 30 bits per sample image data in a single contiguous buffer.
>>> + * index 0: Y plane, [31:0] x:Y2:Y1:Y0 [2:10:10:10] little endian
>>> + * index 1: Cb plane, [31:0] x:Cb2:Cb1:Cb0 [2:10:10:10] little endian
>>> + * index 2: Cr plane, [31:0] x:Cr2:Cr1:Cr0 [2:10:10:10] little endian
>>> + */
>>> +#define DRM_FORMAT_X403 fourcc_code('X', '4', '0', '3')
>>
>> So, this one is different from the Q family, because Q has padding in
>
> Any idea where the letters (P, Q, S) come from?
>
>> LSB rather than MSB. Speaking of, maybe we should add "LSB aligned" to
>> the doc comment to make that clear?
>
> Yes, I can add that.
>
>> Re-reading the sibling thread about DRM_FORMAT_XV20, sounds like the
>> first digit matches my expectations for sub-sampling. How did you pick
>
> I just used the name in Xilinx's BSP kernel.
>
>> the last two digits? I think I would've expected "30" here rather than
>> "03", since the last two planes are Cb Cr rather than Cr Cb.
>
> Hmm, but X403 is Cb:Cr, and P030 is Cr:Cb, so doesn't 03 make sense
> here? Oh, but Q401 is Cr:Cb, and it's 01...
>
> Now that I look at this... I think I have to go back and do more
> testing. From the Xilinx docs, it looks to me that the XV15/XV20 should
> have the same CrCb order than X403. But the comments in these patches
> say otherwise. I'm pretty sure my tests conformed to the comments here,
> but now I don't feel so sure anymore. It's been more than a year since I
> wrote the tests and properly tested these, so I have to spend a bit time
> to get everything up again.
I think the comments are correct. I guess it depends on which way you
look at this: for P030 etc, starting from the lowest bit, the order is
Cb:Cr. For X403, starting from the lowest plane, the order is Cb:Cr. And
that's probably how Xilinx HW "sees" it and thus they use the same Cb:Cr
order.
But in the comments we describe P030's components starting from the
highest bit, and thus it's Cr:Cb.
>> Has the first "X" letter been picked arbitrarily? It's already used to
>> denote padding in other formats so I wonder if we should pick that
>> instead of, say, "T".
> I didn't invent the name, I just took the naming Xilinx used. I don't
> know the history behind it. I assume the "X" is for Xilinx, but I could
> be wrong here. What would "T" be for? "Tomi"? =)
So... While the Cb:Cr order can be seen both ways, perhaps the Q formats
are a good reference here to follow, and thus it should be "430", not
"403", as you suggest. As for the letter... Anything that's not
currently in use is fine for me =).
Tomi
^ 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