* [PATCH v4 02/13] dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
From: Aneesh Kumar K.V (Arm) @ 2026-05-12 9:03 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260512090408.794195-1-aneesh.kumar@kernel.org>
Propagate force_dma_unencrypted() into DMA_ATTR_CC_SHARED in the
dma-direct allocation path and use the attribute to drive the related
decisions.
This updates dma_direct_alloc(), dma_direct_free(), and
dma_direct_alloc_pages() to fold the forced unencrypted case into attrs.
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
kernel/dma/direct.c | 44 ++++++++++++++++++++++++++++++++++++--------
1 file changed, 36 insertions(+), 8 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index b958f150718a..0c2e1f8436ce 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -201,16 +201,31 @@ void *dma_direct_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
{
bool remap = false, set_uncached = false;
- bool mark_mem_decrypt = true;
+ bool mark_mem_decrypt = false;
struct page *page;
void *ret;
+ /*
+ * DMA_ATTR_CC_SHARED is not a caller-visible dma_alloc_*()
+ * attribute. The direct allocator uses it internally after it has
+ * decided that the backing pages must be shared/decrypted, so the
+ * rest of the allocation path can consistently select DMA addresses,
+ * choose compatible pools and restore encryption on free.
+ */
+ if (attrs & DMA_ATTR_CC_SHARED)
+ return NULL;
+
+ if (force_dma_unencrypted(dev)) {
+ attrs |= DMA_ATTR_CC_SHARED;
+ mark_mem_decrypt = true;
+ }
+
size = PAGE_ALIGN(size);
if (attrs & DMA_ATTR_NO_WARN)
gfp |= __GFP_NOWARN;
- if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
- !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev))
+ if (((attrs & (DMA_ATTR_NO_KERNEL_MAPPING | DMA_ATTR_CC_SHARED)) ==
+ DMA_ATTR_NO_KERNEL_MAPPING) && !is_swiotlb_for_alloc(dev))
return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
if (!dev_is_dma_coherent(dev)) {
@@ -244,7 +259,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
* Remapping or decrypting memory may block, allocate the memory from
* the atomic pools instead if we aren't allowed block.
*/
- if ((remap || force_dma_unencrypted(dev)) &&
+ if ((remap || (attrs & DMA_ATTR_CC_SHARED)) &&
dma_direct_use_pool(dev, gfp))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
@@ -318,11 +333,20 @@ void *dma_direct_alloc(struct device *dev, size_t size,
void dma_direct_free(struct device *dev, size_t size,
void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
{
- bool mark_mem_encrypted = true;
+ bool mark_mem_encrypted = false;
unsigned int page_order = get_order(size);
- if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
- !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev)) {
+ /*
+ * if the device had requested for an unencrypted buffer,
+ * convert it to encrypted on free
+ */
+ if (force_dma_unencrypted(dev)) {
+ attrs |= DMA_ATTR_CC_SHARED;
+ mark_mem_encrypted = true;
+ }
+
+ if (((attrs & (DMA_ATTR_NO_KERNEL_MAPPING | DMA_ATTR_CC_SHARED)) ==
+ DMA_ATTR_NO_KERNEL_MAPPING) && !is_swiotlb_for_alloc(dev)) {
/* cpu_addr is a struct page cookie, not a kernel address */
dma_free_contiguous(dev, cpu_addr, size);
return;
@@ -365,10 +389,14 @@ void dma_direct_free(struct device *dev, size_t size,
struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
dma_addr_t *dma_handle, enum dma_data_direction dir, gfp_t gfp)
{
+ unsigned long attrs = 0;
struct page *page;
void *ret;
- if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
+ if (force_dma_unencrypted(dev))
+ attrs |= DMA_ATTR_CC_SHARED;
+
+ if ((attrs & DMA_ATTR_CC_SHARED) && dma_direct_use_pool(dev, gfp))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
if (is_swiotlb_for_alloc(dev)) {
--
2.43.0
^ permalink raw reply related
* [PATCH v4 01/13] dma-direct: swiotlb: handle swiotlb alloc/free outside __dma_direct_alloc_pages
From: Aneesh Kumar K.V (Arm) @ 2026-05-12 9:03 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260512090408.794195-1-aneesh.kumar@kernel.org>
Move swiotlb allocation out of __dma_direct_alloc_pages() and handle it in
dma_direct_alloc() / dma_direct_alloc_pages().
This is needed for follow-up changes that simplify the handling of
memory encryption/decryption based on the DMA attribute flags.
swiotlb backing pages are already mapped decrypted by
swiotlb_update_mem_attributes() and rmem_swiotlb_device_init(), so
dma-direct should not call dma_set_decrypted() on allocation nor
dma_set_encrypted() on free for swiotlb-backed memory.
Update alloc/free paths to detect swiotlb-backed pages and skip
encrypt/decrypt transitions for those paths. Keep the existing highmem
rejection in dma_direct_alloc_pages() for swiotlb allocations.
Only for "restricted-dma-pool", we currently set `for_alloc = true`, while
rmem_swiotlb_device_init() decrypts the whole pool up front. This pool is
typically used together with "shared-dma-pool", where the shared region is
accessed after remap/ioremap and the returned address is suitable for
decrypted memory access. So existing code paths remain valid.
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
kernel/dma/direct.c | 44 +++++++++++++++++++++++++++++++++++++-------
1 file changed, 37 insertions(+), 7 deletions(-)
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index ec887f443741..b958f150718a 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -125,9 +125,6 @@ static struct page *__dma_direct_alloc_pages(struct device *dev, size_t size,
WARN_ON_ONCE(!PAGE_ALIGNED(size));
- if (is_swiotlb_for_alloc(dev))
- return dma_direct_alloc_swiotlb(dev, size);
-
gfp |= dma_direct_optimal_gfp_mask(dev, &phys_limit);
page = dma_alloc_contiguous(dev, size, gfp);
if (page) {
@@ -204,6 +201,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t gfp, unsigned long attrs)
{
bool remap = false, set_uncached = false;
+ bool mark_mem_decrypt = true;
struct page *page;
void *ret;
@@ -250,11 +248,21 @@ void *dma_direct_alloc(struct device *dev, size_t size,
dma_direct_use_pool(dev, gfp))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+ if (is_swiotlb_for_alloc(dev)) {
+ page = dma_direct_alloc_swiotlb(dev, size);
+ if (page) {
+ mark_mem_decrypt = false;
+ goto setup_page;
+ }
+ return NULL;
+ }
+
/* we always manually zero the memory once we are done */
page = __dma_direct_alloc_pages(dev, size, gfp & ~__GFP_ZERO, true);
if (!page)
return NULL;
+setup_page:
/*
* dma_alloc_contiguous can return highmem pages depending on a
* combination the cma= arguments and per-arch setup. These need to be
@@ -281,7 +289,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
goto out_free_pages;
} else {
ret = page_address(page);
- if (dma_set_decrypted(dev, ret, size))
+ if (mark_mem_decrypt && dma_set_decrypted(dev, ret, size))
goto out_leak_pages;
}
@@ -298,7 +306,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
return ret;
out_encrypt_pages:
- if (dma_set_encrypted(dev, page_address(page), size))
+ if (mark_mem_decrypt && dma_set_encrypted(dev, page_address(page), size))
return NULL;
out_free_pages:
__dma_direct_free_pages(dev, page, size);
@@ -310,6 +318,7 @@ void *dma_direct_alloc(struct device *dev, size_t size,
void dma_direct_free(struct device *dev, size_t size,
void *cpu_addr, dma_addr_t dma_addr, unsigned long attrs)
{
+ bool mark_mem_encrypted = true;
unsigned int page_order = get_order(size);
if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
@@ -338,12 +347,15 @@ void dma_direct_free(struct device *dev, size_t size,
dma_free_from_pool(dev, cpu_addr, PAGE_ALIGN(size)))
return;
+ if (swiotlb_find_pool(dev, dma_to_phys(dev, dma_addr)))
+ mark_mem_encrypted = false;
+
if (is_vmalloc_addr(cpu_addr)) {
vunmap(cpu_addr);
} else {
if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
arch_dma_clear_uncached(cpu_addr, size);
- if (dma_set_encrypted(dev, cpu_addr, size))
+ if (mark_mem_encrypted && dma_set_encrypted(dev, cpu_addr, size))
return;
}
@@ -359,6 +371,19 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
if (force_dma_unencrypted(dev) && dma_direct_use_pool(dev, gfp))
return dma_direct_alloc_from_pool(dev, size, dma_handle, gfp);
+ if (is_swiotlb_for_alloc(dev)) {
+ page = dma_direct_alloc_swiotlb(dev, size);
+ if (!page)
+ return NULL;
+
+ if (PageHighMem(page)) {
+ swiotlb_free(dev, page, size);
+ return NULL;
+ }
+ ret = page_address(page);
+ goto setup_page;
+ }
+
page = __dma_direct_alloc_pages(dev, size, gfp, false);
if (!page)
return NULL;
@@ -366,6 +391,7 @@ struct page *dma_direct_alloc_pages(struct device *dev, size_t size,
ret = page_address(page);
if (dma_set_decrypted(dev, ret, size))
goto out_leak_pages;
+setup_page:
memset(ret, 0, size);
*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
return page;
@@ -378,13 +404,17 @@ void dma_direct_free_pages(struct device *dev, size_t size,
enum dma_data_direction dir)
{
void *vaddr = page_address(page);
+ bool mark_mem_encrypted = true;
/* If cpu_addr is not from an atomic pool, dma_free_from_pool() fails */
if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL) &&
dma_free_from_pool(dev, vaddr, size))
return;
- if (dma_set_encrypted(dev, vaddr, size))
+ if (swiotlb_find_pool(dev, page_to_phys(page)))
+ mark_mem_encrypted = false;
+
+ if (mark_mem_encrypted && dma_set_encrypted(dev, vaddr, size))
return;
__dma_direct_free_pages(dev, page, size);
}
--
2.43.0
^ permalink raw reply related
* [PATCH v4 00/13] dma-mapping: Use DMA_ATTR_CC_SHARED through direct, pool and swiotlb paths
From: Aneesh Kumar K.V (Arm) @ 2026-05-12 9:03 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Aneesh Kumar K.V (Arm), Robin Murphy, Marek Szyprowski,
Will Deacon, Marc Zyngier, Steven Price, Suzuki K Poulose,
Catalin Marinas, Jiri Pirko, Jason Gunthorpe, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
This series propagates DMA_ATTR_CC_SHARED through the dma-direct,
dma-pool, and swiotlb paths so that encrypted and decrypted DMA buffers
are handled consistently.
Today, the direct DMA path mostly relies on force_dma_unencrypted() for
shared/decrypted buffer handling. This series consolidates the
force_dma_unencrypted() checks in the top-level functions and ensures
that the remaining DMA interfaces use DMA attributes to make the correct
decisions.
The series:
- moves swiotlb-backed allocations out of __dma_direct_alloc_pages(),
- propagates DMA_ATTR_CC_SHARED through the dma-direct alloc/free
paths
- teaches the atomic DMA pools to track encrypted versus decrypted
state
- tracks swiotlb pool encryption state and enforces strict pool
selection
- centralizes encrypted/decrypted pgprot handling in dma_pgprot() using
DMA attributes
- passes DMA attributes down to dma_capable() so capability checks can
validate whether the selected DMA address encoding matches
DMA_ATTR_CC_SHARED
- makes dma_direct_map_phys() choose the DMA address encoding from
DMA_ATTR_CC_SHARED and fall back to swiotlb when a shared DMA request
cannot use the direct mapping, which lets arm64 and x86 CCA guests stop
relying on SWIOTLB_FORCE for DMA mappings
- use the selected swiotlb pool state to derive the returned DMA
address.
Changes from v3:
https://lore.kernel.org/all/20260427055509.898190-1-aneesh.kumar@kernel.org
* Handle DMA_ATTR_MMIO correctly in dma_direct_map_phys()
* Address most of sashiko review
* Rebase to latest kernel
* drop SWIOTLB_FORCE for s390 and powerpc secure guest.
Changes from v2:
https://lore.kernel.org/all/20260420061415.3650870-1-aneesh.kumar@kernel.org
* pass attrs to dma_capable() and update direct, swiotlb, Xen swiotlb, and
x86 GART paths so the capability checks see the DMA address attr value
DMA_ATTR_CC_SHARED.
* rework dma_direct_map_phys() so DMA_ATTR_CC_SHARED selects
phys_to_dma_unencrypted() while the default path uses
phys_to_dma_encrypted(), with swiotlb fallback when the requested
shared/private state cannot be satisfied by a direct DMA address.
* stop relying on SWIOTLB_FORCE for arm64 and x86 CC guest DMA mappings;
swiotlb is still enabled there, but shared mappings is now selected
through the generic dma_direct_map_phys()/dma_capable() decision instead
of a global force-bounce flag.
Changes from v1:
https://lore.kernel.org/all/20260417085900.3062416-1-aneesh.kumar@kernel.org
* rebased to latest kernel (change from DMA_ATTR_CC_DECRYPTED -> DMA_ATTR_CC_SHARED)
* update the alloc path so DMA_ATTR_CC_SHARED is not a caller-visible attribute.
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Steven Price <steven.price@arm.com>
Cc: Suzuki K Poulose <Suzuki.Poulose@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jiri Pirko <jiri@resnulli.us>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Mostafa Saleh <smostafa@google.com>
Cc: Petr Tesarik <ptesarik@suse.com>
Cc: Alexey Kardashevskiy <aik@amd.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Xu Yilun <yilun.xu@linux.intel.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-s390@vger.kernel.org
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: x86@kernel.org
Aneesh Kumar K.V (Arm) (13):
dma-direct: swiotlb: handle swiotlb alloc/free outside
__dma_direct_alloc_pages
dma-direct: use DMA_ATTR_CC_SHARED in alloc/free paths
dma-pool: track decrypted atomic pools and select them via attrs
dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
dma-mapping: make dma_pgprot() honor DMA_ATTR_CC_SHARED
dma-direct: pass attrs to dma_capable() for DMA_ATTR_CC_SHARED checks
dma-direct: make dma_direct_map_phys() honor DMA_ATTR_CC_SHARED
dma-direct: set decrypted flag for remapped DMA allocations
dma-direct: select DMA address encoding from DMA_ATTR_CC_SHARED
dma-pool: fix page leak in atomic_pool_expand() cleanup
dma-direct: rename ret to cpu_addr in alloc helpers
dma-direct: return struct page from dma_direct_alloc_from_pool()
x86/amd-gart: preserve the direct DMA address until GART mapping
succeeds
arch/arm64/mm/init.c | 4 +-
arch/powerpc/platforms/pseries/svm.c | 2 +-
arch/s390/mm/init.c | 2 +-
arch/x86/kernel/amd_gart_64.c | 36 ++--
arch/x86/kernel/pci-dma.c | 4 +-
drivers/iommu/dma-iommu.c | 2 +-
drivers/xen/swiotlb-xen.c | 10 +-
include/linux/dma-direct.h | 19 ++-
include/linux/dma-map-ops.h | 2 +-
include/linux/swiotlb.h | 8 +-
kernel/dma/direct.c | 243 ++++++++++++++++++++-------
kernel/dma/direct.h | 40 ++---
kernel/dma/mapping.c | 16 +-
kernel/dma/pool.c | 165 +++++++++++-------
kernel/dma/swiotlb.c | 109 +++++++++---
15 files changed, 459 insertions(+), 203 deletions(-)
base-commit: 50897c955902c93ae71c38698abb910525ebdc89
--
2.43.0
^ permalink raw reply
* Re: [PATCH 3/4] drm/mediatek: mtk_cec: Fix non-static global variable
From: CK Hu (胡俊光) @ 2026-05-12 9:04 UTC (permalink / raw)
To: chunkuang.hu@kernel.org, simona@ffwll.ch, Alexandre Mergnat,
AngeloGioacchino Del Regno, airlied@gmail.com,
p.zabel@pengutronix.de, matthias.bgg@gmail.com,
Louis-Alexis Eyraud
Cc: dri-devel@lists.freedesktop.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, kernel@collabora.com,
linux-kernel@vger.kernel.org
In-Reply-To: <20260429-mediatek-drm-fix-sparse-warnings-v1-3-d95c4d118b83@collabora.com>
On Wed, 2026-04-29 at 11:59 +0200, Louis-Alexis Eyraud wrote:
> The struct 'mtk_cec_driver' is not used outside of the
> mtk_cec.c file, so make it static to silence sparse warning:
> ```
> drivers/gpu/drm/mediatek/mtk_cec.c:243:24: sparse: warning: symbol
> 'mtk_cec_driver' was not declared. Should it be static?
> ```
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Fixes: 1e914a89ab7e ("drm/mediatek: mtk_cec: Switch to register as module_platform_driver")
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> drivers/gpu/drm/mediatek/mtk_cec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_cec.c b/drivers/gpu/drm/mediatek/mtk_cec.c
> index c7be530ca041..b8ccd6e55bed 100644
> --- a/drivers/gpu/drm/mediatek/mtk_cec.c
> +++ b/drivers/gpu/drm/mediatek/mtk_cec.c
> @@ -240,7 +240,7 @@ static const struct of_device_id mtk_cec_of_ids[] = {
> };
> MODULE_DEVICE_TABLE(of, mtk_cec_of_ids);
>
> -struct platform_driver mtk_cec_driver = {
> +static struct platform_driver mtk_cec_driver = {
> .probe = mtk_cec_probe,
> .remove = mtk_cec_remove,
> .driver = {
>
^ permalink raw reply
* Re: [RFC v1 PATCH 0/11] Optimize this_cpu_*() ops for non-x86 (ARM64 for this series)
From: David Hildenbrand (Arm) @ 2026-05-12 9:02 UTC (permalink / raw)
To: Yang Shi, cl, dennis, tj, urezki, catalin.marinas, will,
ryan.roberts, akpm, hca, gor, agordeev
Cc: linux-mm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260429170758.3018959-1-yang@os.amperecomputing.com>
> =========
> The benchmarks are done on 160 core AmpereOne machine. The baseline is
> v7.1-rc1 kernel.
>
> 1. Kernel Build
> ---------------
> Run kernel build (make -j160) with the default Fedora kernel config in a
> memcg.
> 13% - 18% sys time improvment
> 3% - 7% wall time improvement
This is pretty impressive!
There was quite some feedback during the LSF/MM session, what's the current plan?
Also, it was raised that Linus so far didn't enjoy per-process page tables. Is
there a way forward?
Finally, in the LSF/MM session, there was the question why the preemption
handling is even required. Can you describe what the problem is?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Bryan O'Donoghue @ 2026-05-12 9:01 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
In-Reply-To: <f649f4a8-df16-4fed-b1ca-4362680252a4@oss.qualcomm.com>
On 12/05/2026 09:52, Taniya Das wrote:
> The clock controller drivers only request the minimum operating level
> for the power domains. Since the cx and mx rails are already at the
> minimum operating level when APPS is active, explicit voting for these
> power domains is not required from camcc.
>
> --
> Thanks,
> Taniya Das
Great, I'll drop those references.
Thank you for the information.
---
bod
^ permalink raw reply
* Re: [PATCH 2/4] drm/mediatek: mtk_hdmi_v2: Fix non-static global variable
From: CK Hu (胡俊光) @ 2026-05-12 8:59 UTC (permalink / raw)
To: chunkuang.hu@kernel.org, simona@ffwll.ch, Alexandre Mergnat,
AngeloGioacchino Del Regno, airlied@gmail.com,
p.zabel@pengutronix.de, matthias.bgg@gmail.com,
Louis-Alexis Eyraud
Cc: dri-devel@lists.freedesktop.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, kernel@collabora.com,
linux-kernel@vger.kernel.org, lkp@intel.com
In-Reply-To: <20260429-mediatek-drm-fix-sparse-warnings-v1-2-d95c4d118b83@collabora.com>
On Wed, 2026-04-29 at 11:59 +0200, Louis-Alexis Eyraud wrote:
> The struct 'mtk_hdmi_v2_clk_names' is not used outside of the
> mtk_hdmi_v2.c file, so make it static to silence sparse warning:
> ```
> drivers/gpu/drm/mediatek/mtk_hdmi_v2.c:53:12: sparse: warning: symbol
> 'mtk_hdmi_v2_clk_names' was not declared. Should it be static?
> ```
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202604132044.fcYjEcU8-lkp@intel.com/
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c b/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
> index b5c738380dc2..a8eb6fd0908b 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
> @@ -50,7 +50,7 @@ enum mtk_hdmi_v2_clk_id {
> MTK_HDMI_V2_CLK_COUNT,
> };
>
> -const char *const mtk_hdmi_v2_clk_names[MTK_HDMI_V2_CLK_COUNT] = {
> +static const char *const mtk_hdmi_v2_clk_names[MTK_HDMI_V2_CLK_COUNT] = {
> [MTK_HDMI_V2_CLK_HDMI_APB_SEL] = "bus",
> [MTK_HDMI_V2_CLK_HDCP_SEL] = "hdcp",
> [MTK_HDMI_V2_CLK_HDCP_24M_SEL] = "hdcp24m",
>
^ permalink raw reply
* Re: [PATCH v5 8/8] unwind: arm64: Use sframe to unwind interrupt frames
From: Jens Remus @ 2026-05-12 8:55 UTC (permalink / raw)
To: Dylan Hatch, Mark Rutland
Cc: Roman Gushchin, Weinan Liu, Will Deacon, Josh Poimboeuf,
Indu Bhagat, Peter Zijlstra, Steven Rostedt, Catalin Marinas,
Jiri Kosina, Prasanna Kumar T S M, Puranjay Mohan, Song Liu,
joe.lawrence, linux-toolchains, linux-kernel, live-patching,
linux-arm-kernel, Randy Dunlap, Heiko Carstens
In-Reply-To: <CADBMgpx9YxNUO6wLP7mYKxWW8L78Hk9gPwHrMjXUwPyUmGEu9w@mail.gmail.com>
Hello Dylan and Mark!
On 5/12/2026 5:00 AM, Dylan Hatch wrote:
> On Fri, May 1, 2026 at 9:46 AM Mark Rutland <mark.rutland@arm.com>
> wrote:
>> More generally, there are a few things that aren't addressed by
>> this series that we will also need to address. Importantly:
>>
>> (1) For correctness, we'll need to address a latent issue with
>> unwinding across an fgraph return trampoline, where the return
>> address is transiently unrecoverable.
>>
>> Before this series, that doesn't matter for livepatching because
>> the livepatching code isn't called synchronously within the fgraph
>> handler, and unwinds which cross an exception boundary are marked
>> as unreliable.
>>
>> After this series, that does matter as we can unwind across an
>> exception boundary, and might happen to interrupt that transient
>> window.
>>
>> I think we can solve that with some restructuring of that code,
>> restoring the original address *before* removing that from the
>> fgraph return stack, and ensuring that the unwinder can find it.
>
> If my understanding is correct, the issue arrises in
> return_to_handler as the return address is recovered:
>
> mov x0, sp bl ftrace_return_to_handler // addr =
> ftrace_return_to_hander(fregs); mov x30, x0 // restore the original
> return address
>
> Because ftrace_return_to_handler pops the return address from the
> return stack before it can be restored into the LR, it cannot be
> recovered.
Based on reliable-stacktrace.rst section "4.4 Rewriting of return
addresses" I wonder whether the following might work:
- If an unwound RA points at return_to_handler the actual RA needs to
be obtained using ftrace_graph_ret_addr(). This might already be
taken into account if ftrace_graph_ret_addr() is used unconditionally.
- If an unwound RA points into return_to_handler() mark the stack trace
as unreliable. This could be accomplished by marking LR in
return_to_handler() as undefined (i.e. .cfi_undefined 30) to use
SFrame's outermost frame indication to stop and mark the stack trace
as unreliable:
diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
@@ -329,8 +329,12 @@ SYM_FUNC_END(ftrace_stub_graph)
* @fp is checked against the value passed by ftrace_graph_caller().
*/
SYM_CODE_START(return_to_handler)
+ .cfi_startproc
+ /* Mark unwinding of LR as unreliable */
+ .cfi_undefined 30
/* Make room for ftrace_regs */
sub sp, sp, #FREGS_SIZE
+ .cfi_adjust_cfa_offset -FREGS_SIZE
/* Save return value regs */
stp x0, x1, [sp, #FREGS_X0]
@@ -344,6 +348,8 @@ SYM_CODE_START(return_to_handler)
mov x0, sp
bl ftrace_return_to_handler // addr = ftrace_return_to_hander(fregs);
mov x30, x0 // restore the original return address
+ /* Mark unwinding of LR as reliable */
+ .cfi_restore 30
/* Restore return value regs */
ldp x0, x1, [sp, #FREGS_X0]
@@ -351,7 +357,9 @@ SYM_CODE_START(return_to_handler)
ldp x4, x5, [sp, #FREGS_X4]
ldp x6, x7, [sp, #FREGS_X6]
add sp, sp, #FREGS_SIZE
+ .cfi_adjust_cfa_offset FREGS_SIZE
ret
+ .cfi_endproc
SYM_CODE_END(return_to_handler)
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
Notes regarding above:
- return_to_handler() saves the caller's FP in ftrace_regs but never
restores it. I suppose this is because ftrace_regs is an input to
ftrace_return_to_handler(). The DWARF CFI above assumes SP and FP
can be restored at all times as SP=CFA and FP=FP.
- One might be tempted to add a .cfi_register 30, 0 after the call to
ftrace_return_to_handler. This would be wrong, because if unwinding
comes from ftrace_return_to_handler() the unwound RA will point there
and the unwinding logic would erroneously assume x0 to contain the RA.
- The DWARF CFI could be simplified as follows to just convey that
unwinding through return_to_handler is impossible at all times:
diff --git a/arch/arm64/kernel/entry-ftrace.S b/arch/arm64/kernel/entry-ftrace.S
@@ -329,6 +329,9 @@ SYM_FUNC_END(ftrace_stub_graph)
* @fp is checked against the value passed by ftrace_graph_caller().
*/
SYM_CODE_START(return_to_handler)
+ .cfi_startproc simple
+ /* Mark unwinding of LR as unreliable */
+ .cfi_undefined 30
/* Make room for ftrace_regs */
sub sp, sp, #FREGS_SIZE
@@ -353,5 +356,6 @@ SYM_CODE_START(return_to_handler)
add sp, sp, #FREGS_SIZE
ret
+ .cfi_endproc
SYM_CODE_END(return_to_handler)
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
>
> Based on this, I believe you are suggesting to restructure this code
> path such that the return address is removed from the return stack
> only after it has been restored to LR. But since kernel/trace/
> fgraph.c is core kernel code, will this end up requiring either (1)
> a similar restructuring of other arches supporting ftrace, or (2) an
> arm64-specific implementation of this recovery logic?
>
> It looks to me like there is essentially the same recovery pattern
> on other arches; is there a reason this transient unrecoverability
> isn't an issue for reliable unwind on other platforms?
>
>>
>> I'm not immediately sure whether kretprobes has a similar issue.
Regards,
Jens
--
Jens Remus
Linux on Z Development (D3303)
jremus@de.ibm.com / jremus@linux.ibm.com
IBM Deutschland Research & Development GmbH; Vorsitzender des Aufsichtsrats: Wolfgang Wendt; Geschäftsführung: David Faller; Sitz der Gesellschaft: Ehningen; Registergericht: Amtsgericht Stuttgart, HRB 243294
IBM Data Privacy Statement: https://www.ibm.com/privacy/
^ permalink raw reply
* Re: [PATCH v2 07/16] thermal: mediatek: add PMIC thermal support
From: Roman Vivchar @ 2026-05-12 8:55 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <CAHp75VfgrbEDLavMKFp2maFCH08RBUxF2wYhh56GG1HCq4ogmA@mail.gmail.com>
On Tuesday, May 12th, 2026 at 10:05 AM, Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
> On Tue, May 12, 2026 at 8:21 AM Roman Vivchar via B4 Relay
> <devnull+rva333.protonmail.com@kernel.org> wrote:
...
> > +#include <linux/kernel.h>
>
> No way the driver(s) nowadays use this header. Please, drop it and add
> the ones that are really in use (there are missing ones).
Is there a tool or script that can check for IWYU? For example,
the u32 and s32 types are defined in the asm-generic/int-ll64.h, which
is not used by any device driver. Instead, types.h should be used.
It's difficult to guess which header to use for a given type/function.
I've tried include-what-you-use [1], but it gives bad results like
"add #include <asm-generic/int-ll64.h> // for u32".
> > +#include <linux/module.h>
> > +#include <linux/nvmem-consumer.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/property.h>
> > +#include <linux/regmap.h>
>
> > +#include <linux/slab.h>
>
> Is it used?
Yes, without slab.h the __free would complain about missing __free_kfree,
which is DEFINE_FREE(kfree, void *, if (!IS_ERR_OR_NULL(_T)) kfree(_T)).
...
> > +#define MT6323_ADC_VOLTAGE_RANGE 1800
> > +#define MT6323_ADC_RESOLUTION 32768
>
> These two ring a bell with the first code patch. Are they the same?
> Can they be deduplicated?
They can, but I doubt it's worth creating a header just for 2 constants.
It would look too small compared to the other headers in the include/linux/iio/adc.
1: https://github.com/include-what-you-use/include-what-you-use
Best regards,
Roman
^ permalink raw reply
* Re: [PATCH v4 1/4] kernel: param: initialize module_kset before do_initcalls()
From: Jon Hunter @ 2026-05-12 8:55 UTC (permalink / raw)
To: Shashank Balaji, Thierry Reding, Sumit Gupta
Cc: Gary Guo, Suzuki K Poulose, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, Miguel Ojeda, Boqun Feng,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Richard Cochran, Jonathan Corbet, Shuah Khan,
Luis Chamberlain, Petr Pavlu, Daniel Gomez, Sami Tolvanen,
Aaron Tomlin, Mike Leach, Leo Yan, Rahul Bukte, linux-kernel,
coresight, linux-arm-kernel, driver-core, rust-for-linux,
linux-doc, Daniel Palmer, Tim Bird, linux-modules, linux-tegra
In-Reply-To: <agKMcA7a_UqMua5V@JPC00244420>
Hi Shashank,
On 12/05/2026 03:12, Shashank Balaji wrote:
...
>> Hi Thierry and Jonathan,
>>
>> You can find the context for this email in this patch:
>> https://lore.kernel.org/all/20260427-acpi_mod_name-v4-1-22b42240c9bf@sony.com/
>>
>> TL;DR: tegra194_cbb_driver and tegra234_cbb_driver are the only drivers
>> registering themselves as early as in a pure_initcall. This is a problem
>> on two fronts:
>> 1. Philosophical: As Gary pointed out, pure_initcalls are intended to purely
>> initialize variables that couldn't be statically initialized. But these
>> are doing driver registrations.
>> 2. module_kset not initialized at pure_initcall stage: This is needed to
>> set the module sysfs symlink. Since module_kset is not alive yet during
>> pure_initcalls, registering these drivers panics the kernel.
Where exactly is this panic seen? Ie. why are we not seeing this?
>> We would like to do the tegra cbb driver registration in a core_initcall
>> (or some later initcall works too), and move module_kset initialization
>> to a pure_initcall. Like this:
>>
>> diff --git a/drivers/soc/tegra/cbb/tegra194-cbb.c b/drivers/soc/tegra/cbb/tegra194-cbb.c
>> index ab75d50cc85c..2f69e104c838 100644
>> --- a/drivers/soc/tegra/cbb/tegra194-cbb.c
>> +++ b/drivers/soc/tegra/cbb/tegra194-cbb.c
>> @@ -2342,7 +2342,7 @@ static int __init tegra194_cbb_init(void)
>> {
>> return platform_driver_register(&tegra194_cbb_driver);
>> }
>> -pure_initcall(tegra194_cbb_init);
>> +core_initcall(tegra194_cbb_init);
>>
>> static void __exit tegra194_cbb_exit(void)
>> {
>> diff --git a/drivers/soc/tegra/cbb/tegra234-cbb.c b/drivers/soc/tegra/cbb/tegra234-cbb.c
>> index fb26f085f691..785072fa4e85 100644
>> --- a/drivers/soc/tegra/cbb/tegra234-cbb.c
>> +++ b/drivers/soc/tegra/cbb/tegra234-cbb.c
>> @@ -1774,7 +1774,7 @@ static int __init tegra234_cbb_init(void)
>> {
>> return platform_driver_register(&tegra234_cbb_driver);
>> }
>> -pure_initcall(tegra234_cbb_init);
>> +core_initcall(tegra234_cbb_init);
>>
>> static void __exit tegra234_cbb_exit(void)
>> {
>>
>> Would this work?
I am adding Sumit who has been doing a lot of the Tegra CBB driver work.
Sumit, any concerns here? We could run this change through our internal
testing to confirm.
Jon
--
nvpublic
^ permalink raw reply
* Re: [PATCH v2 3/8] dt-bindings: clock: qcom: Add support for CAMCC for Eliza
From: Taniya Das @ 2026-05-12 8:54 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Ajit Pandey, Imran Shaik, Jagadeesh Kona,
linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20260410-hasty-pony-of-tempering-4f0a47@quoll>
On 4/10/2026 1:17 PM, Krzysztof Kozlowski wrote:
> On Thu, Apr 09, 2026 at 11:40:44PM +0530, Taniya Das wrote:
>> Update the compatible and the bindings for CAMCC support on Eliza SoC.
>
> I do not see any update here. Also, no improvements after v1 comments.
Sorry for missing that update the reason for Eliza not compatible with
Pakala. I will update the commit in the next patch.
--
Thanks,
Taniya Das
^ permalink raw reply
* [PATCH v3 6/6] regulator: mt6359: Add proper ldo_vcn33_[12] regulators
From: Chen-Yu Tsai @ 2026-05-12 8:53 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260512085358.1693208-1-wenst@chromium.org>
The ldo_vcn33_[12]_wifi and ldo_vcn33_[12]_bt are just two regulator
outputs instead of four. The wifi and bt parts refer to separate enable
bits that are OR-ed together to affect the actual regulator output. The
separate bits allow the wifi and bt stacks to enable their power without
coordination between them. These have been deprecated in favor of proper
nodes matching the output.
Add proper ldo_vcn33_[12] regulators to replace the existing ones. The
enable status is synced to just one of the two enable bits, and the
other is forced off. This makes the handling in other bits simpler.
The existing *_(bt|wifi) regulators are converted to no-op regulators
that are fed from their new respective ldo_vcn33_[12] regulator. This
allows existing device trees to continue to work.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- Instead of dropping one regulator from each output, add a new one for
each output; the existing *_(bt|wifi) ones are then supplied from the
new one
---
drivers/regulator/mt6359-regulator.c | 179 +++++++++++++++++----
include/linux/regulator/mt6359-regulator.h | 10 +-
2 files changed, 154 insertions(+), 35 deletions(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index fa97c3189df5..cd489adf9a2a 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -166,6 +166,20 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
+#define MT6359_LDO_NOOP(match, _name, supply) \
+[MT6359_ID_##_name] = { \
+ .desc = { \
+ .name = #_name, \
+ .supply_name = supply, \
+ .of_match = of_match_ptr(match), \
+ .regulators_node = of_match_ptr("regulators"), \
+ .ops = &mt6359_noop_ops, \
+ .type = REGULATOR_VOLTAGE, \
+ .id = MT6359_ID_##_name, \
+ .owner = THIS_MODULE, \
+ }, \
+}
+
static const unsigned int vsim1_voltages[] = {
0, 0, 0, 1700000, 1800000, 0, 0, 0, 2700000, 0, 0, 3000000, 3100000,
};
@@ -475,6 +489,9 @@ static const struct regulator_ops mt6359p_vemc_ops = {
.get_status = mt6359_get_status,
};
+/* Used for backward-compatible placeholder regulators */
+static const struct regulator_ops mt6359_noop_ops = {};
+
/* The array is indexed by id(MT6359_ID_XXX) */
static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_BUCK("buck_vs1", VS1, "vsys-vs1", 800000, 2200000, 12500,
@@ -596,18 +613,12 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_DA_VCN13_B_EN_ADDR, MT6359_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1", VCN33_1, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_1_EN_1_SHIFT,
- MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
- MT6359_RG_VCN33_1_VOSEL_MASK <<
- MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359_RG_LDO_VAUX18_EN_ADDR,
MT6359_DA_VAUX18_B_EN_ADDR, 1800000),
MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
@@ -644,18 +655,12 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_DA_VEMC_B_EN_ADDR, MT6359_RG_VEMC_VOSEL_ADDR,
MT6359_RG_VEMC_VOSEL_MASK << MT6359_RG_VEMC_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2", VCN33_2, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
- MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
- MT6359_RG_VCN33_2_VOSEL_MASK <<
- MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359_RG_LDO_VA12_EN_ADDR, MT6359_RG_LDO_VA12_EN_SHIFT,
MT6359_DA_VA12_B_EN_ADDR, MT6359_RG_VA12_VOSEL_ADDR,
@@ -711,6 +716,11 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
+ /* Placeholders for DT backward compatibility */
+ MT6359_LDO_NOOP("ldo_vcn33_1_bt", VCN33_1_BT, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_1_wifi", VCN33_1_WIFI, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_bt", VCN33_2_BT, "LDO_VCN33_2"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_wifi", VCN33_2_WIFI, "LDO_VCN33_2"),
};
static const struct mt6359_regulator_info mt6359p_regulators[] = {
@@ -835,18 +845,12 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_DA_VCN13_B_EN_ADDR, MT6359P_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1", VCN33_1, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
- MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT,
- MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
- MT6359_RG_VCN33_1_VOSEL_MASK <<
- MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359P_RG_LDO_VAUX18_EN_ADDR,
MT6359P_DA_VAUX18_B_EN_ADDR, 1800000),
MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
@@ -885,18 +889,12 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_RG_LDO_VEMC_VOSEL_0_ADDR,
MT6359P_RG_LDO_VEMC_VOSEL_0_MASK <<
MT6359P_RG_LDO_VEMC_VOSEL_0_SHIFT),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2", VCN33_2, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
- MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
- MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
- MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
- MT6359_RG_VCN33_2_VOSEL_MASK <<
- MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359P_RG_LDO_VA12_EN_ADDR, MT6359P_RG_LDO_VA12_EN_SHIFT,
MT6359P_DA_VA12_B_EN_ADDR, MT6359P_RG_VA12_VOSEL_ADDR,
@@ -951,27 +949,114 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359P_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_VOSEL_SHIFT),
+ /* Placeholders for DT backward compatibility */
+ MT6359_LDO_NOOP("ldo_vcn33_1_bt", VCN33_1_BT, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_1_wifi", VCN33_1_WIFI, "LDO_VCN33_1"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_bt", VCN33_2_BT, "LDO_VCN33_2"),
+ MT6359_LDO_NOOP("ldo_vcn33_2_wifi", VCN33_2_WIFI, "LDO_VCN33_2"),
+};
+
+struct mt6359_vcn33_regs {
+ u32 wifi_en_reg;
+ u32 wifi_en_mask;
+ u32 bt_en_reg;
+ u32 bt_en_mask;
+};
+
+static const struct mt6359_vcn33_regs vcn33_regs[][2] = {
+ { /* MT6359 */
+ {
+ .wifi_en_reg = MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_1_SHIFT),
+ .bt_en_reg = MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_0_SHIFT),
+ }, {
+ .wifi_en_reg = MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_1_SHIFT),
+ .bt_en_reg = MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_0_SHIFT),
+ }
+ }, { /* MT6359P */
+ {
+ .wifi_en_reg = MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT),
+ .bt_en_reg = MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359_RG_LDO_VCN33_1_EN_0_SHIFT),
+ }, {
+ .wifi_en_reg = MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
+ .wifi_en_mask = BIT(MT6359_RG_LDO_VCN33_2_EN_1_SHIFT),
+ .bt_en_reg = MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
+ .bt_en_mask = BIT(MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT),
+ }
+ }
};
+static int mt6359_sync_vcn33_setting(struct device *dev, unsigned int idx)
+{
+ struct mt6397_chip *mt6397 = dev_get_drvdata(dev->parent);
+ unsigned int val;
+ int ret;
+
+ /*
+ * VCN33_[12]_WIFI and VCN33_[12]_BT are two separate enable bits for
+ * the same regulator. They share the same voltage setting and output
+ * pin. Instead of having two potentially conflicting regulators, just
+ * have one regulator. Sync the two enable bits and only use one in
+ * the regulator device.
+ */
+ for (unsigned int i = 0; i < ARRAY_SIZE(vcn33_regs[0]); i++) {
+ u32 bt_en_mask = vcn33_regs[idx][i].bt_en_mask;
+ u32 wifi_en_mask = vcn33_regs[idx][i].wifi_en_mask;
+
+ ret = regmap_read(mt6397->regmap, vcn33_regs[idx][i].wifi_en_reg, &val);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to read VCN33_%u_WIFI setting\n", i);
+
+ if (!(val & wifi_en_mask))
+ continue;
+
+ /* Sync VCN33_[12]_WIFI enable status to VCN33_[12]_BT */
+ ret = regmap_update_bits(mt6397->regmap, vcn33_regs[idx][i].bt_en_reg,
+ bt_en_mask, bt_en_mask);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to sync VCN33_%u_WIFI setting to VCN33_%u_BT\n",
+ i, i);
+
+ /* Disable VCN33_[12]_WIFI */
+ ret = regmap_update_bits(mt6397->regmap, vcn33_regs[idx][i].wifi_en_reg,
+ wifi_en_mask, 0);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to disable VCN33_%u_WIFI\n", i);
+ }
+
+ return 0;
+}
+
static int mt6359_regulator_probe(struct platform_device *pdev)
{
struct mt6397_chip *mt6397 = dev_get_drvdata(pdev->dev.parent);
struct regulator_config config = {};
struct regulator_dev *rdev;
const struct mt6359_regulator_info *mt6359_info;
- const char *vio18_name;
+ const char *vio18_name, *vcn33_1_name, *vcn33_2_name;
int i, hw_ver, ret;
ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
if (ret)
return ret;
- if (hw_ver >= MT6359P_CHIP_VER)
+ if (hw_ver >= MT6359P_CHIP_VER) {
mt6359_info = mt6359p_regulators;
- else
+ mt6359_sync_vcn33_setting(&pdev->dev, 1);
+ } else {
mt6359_info = mt6359_regulators;
+ mt6359_sync_vcn33_setting(&pdev->dev, 0);
+ }
vio18_name = mt6359_info[MT6359_ID_VIO18].desc.name;
+ vcn33_1_name = mt6359_info[MT6359_ID_VCN33_1].desc.name;
+ vcn33_2_name = mt6359_info[MT6359_ID_VCN33_2].desc.name;
config.dev = mt6397->dev;
config.regmap = mt6397->regmap;
@@ -993,6 +1078,30 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
desc = _desc;
}
+ /* Use vcn33_1's actual name as supply_name for vcn33_1_(bt|wifi) */
+ if ((i == MT6359_ID_VCN33_1_BT || i == MT6359_ID_VCN33_1_WIFI) &&
+ strcmp(desc->supply_name, vcn33_1_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vcn33_1_name;
+ desc = _desc;
+ }
+
+ /* Use vcn33_2's actual name as supply_name for vcn33_2_(bt|wifi) */
+ if ((i == MT6359_ID_VCN33_2_BT || i == MT6359_ID_VCN33_2_WIFI) &&
+ strcmp(desc->supply_name, vcn33_2_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vcn33_2_name;
+ desc = _desc;
+ }
+
rdev = devm_regulator_register(&pdev->dev, desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "failed to register %s\n", mt6359_info->desc.name);
@@ -1002,6 +1111,14 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
/* Save vio18 name for vbbck */
if (i == MT6359_ID_VIO18)
vio18_name = rdev_get_name(rdev);
+
+ /* Save vcn33_1 name for vbbck */
+ if (i == MT6359_ID_VCN33_1)
+ vcn33_1_name = rdev_get_name(rdev);
+
+ /* Save vcn33_2 name for vbbck */
+ if (i == MT6359_ID_VCN33_2)
+ vcn33_2_name = rdev_get_name(rdev);
}
return 0;
diff --git a/include/linux/regulator/mt6359-regulator.h b/include/linux/regulator/mt6359-regulator.h
index 6d6e5a58f482..ce2cd0fc9d95 100644
--- a/include/linux/regulator/mt6359-regulator.h
+++ b/include/linux/regulator/mt6359-regulator.h
@@ -29,8 +29,7 @@ enum {
MT6359_ID_VCN18,
MT6359_ID_VFE28,
MT6359_ID_VCN13,
- MT6359_ID_VCN33_1_BT,
- MT6359_ID_VCN33_1_WIFI,
+ MT6359_ID_VCN33_1,
MT6359_ID_VAUX18,
MT6359_ID_VSRAM_OTHERS,
MT6359_ID_VEFUSE,
@@ -39,8 +38,7 @@ enum {
MT6359_ID_VBIF28,
MT6359_ID_VIO28,
MT6359_ID_VEMC,
- MT6359_ID_VCN33_2_BT,
- MT6359_ID_VCN33_2_WIFI,
+ MT6359_ID_VCN33_2,
MT6359_ID_VA12,
MT6359_ID_VA09,
MT6359_ID_VRF18,
@@ -51,6 +49,10 @@ enum {
MT6359_ID_VSRAM_PROC1,
MT6359_ID_VSIM2,
MT6359_ID_VSRAM_OTHERS_SSHUB,
+ MT6359_ID_VCN33_1_BT,
+ MT6359_ID_VCN33_1_WIFI,
+ MT6359_ID_VCN33_2_BT,
+ MT6359_ID_VCN33_2_WIFI,
MT6359_ID_RG_MAX,
};
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v3 5/6] regulator: mt6359: Add regulator supply names
From: Chen-Yu Tsai @ 2026-05-12 8:53 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
In-Reply-To: <20260512085358.1693208-1-wenst@chromium.org>
The MT6359 regulator DT binding defines the supply names for the PMIC.
Add support for them by adding .supply_name field settings for each
regulator. The buck regulators each have their own supply. The name
of the supply is related to the name of the buck regulator. The LDOs
have shared supplies.
Add the supply name to the declaration of each regulator. At the moment
they are declared explicitly, but the buck regulator macro can be made
to derive both the match string and supply name from the base name once
the *_sshub regulators are figured out and removed. For context, the
*_sshub regulators are not separate regulators, but separate settings
for the same name regulators without the "_sshub" suffix.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
Changes since v1:
- Handle vbbck's supply internally
---
drivers/regulator/mt6359-regulator.c | 220 +++++++++++++++------------
1 file changed, 125 insertions(+), 95 deletions(-)
diff --git a/drivers/regulator/mt6359-regulator.c b/drivers/regulator/mt6359-regulator.c
index bcf9a476a34e..fa97c3189df5 100644
--- a/drivers/regulator/mt6359-regulator.c
+++ b/drivers/regulator/mt6359-regulator.c
@@ -38,7 +38,7 @@ struct mt6359_regulator_info {
u32 lp_mode_mask;
};
-#define MT6359_BUCK(match, _name, min, max, step, \
+#define MT6359_BUCK(match, _name, supply, min, max, step, \
_enable_reg, _status_reg, \
_vsel_reg, _vsel_mask, \
_lp_mode_reg, _lp_mode_shift, \
@@ -46,6 +46,7 @@ struct mt6359_regulator_info {
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &mt6359_volt_linear_ops, \
@@ -69,11 +70,12 @@ struct mt6359_regulator_info {
.modeset_mask = BIT(_modeset_shift), \
}
-#define MT6359_LDO_LINEAR(match, _name, min, max, step, \
+#define MT6359_LDO_LINEAR(match, _name, supply, min, max, step, \
_enable_reg, _status_reg, _vsel_reg, _vsel_mask) \
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &mt6359_volt_linear_ops, \
@@ -92,12 +94,13 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
-#define MT6359_LDO(match, _name, _volt_table, \
+#define MT6359_LDO(match, _name, supply, _volt_table, \
_enable_reg, _enable_mask, _status_reg, \
_vsel_reg, _vsel_mask, _en_delay) \
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &mt6359_volt_table_ops, \
@@ -116,11 +119,13 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
-#define MT6359_REG_FIXED(match, _name, _enable_reg, \
- _status_reg, _fixed_volt) \
+#define MT6359_REG_FIXED(match, _name, supply, \
+ _enable_reg, _status_reg, \
+ _fixed_volt) \
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &mt6359_volt_fixed_ops, \
@@ -136,12 +141,14 @@ struct mt6359_regulator_info {
.qi = BIT(0), \
}
-#define MT6359P_LDO1(match, _name, _ops, _volt_table, \
- _enable_reg, _enable_mask, _status_reg, \
- _vsel_reg, _vsel_mask) \
+#define MT6359P_LDO1(match, _name, supply, _ops, \
+ _volt_table, _enable_reg, \
+ _enable_mask, _status_reg, \
+ _vsel_reg, _vsel_mask) \
[MT6359_ID_##_name] = { \
.desc = { \
.name = #_name, \
+ .supply_name = supply, \
.of_match = of_match_ptr(match), \
.regulators_node = of_match_ptr("regulators"), \
.ops = &_ops, \
@@ -470,14 +477,14 @@ static const struct regulator_ops mt6359p_vemc_ops = {
/* The array is indexed by id(MT6359_ID_XXX) */
static const struct mt6359_regulator_info mt6359_regulators[] = {
- MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
+ MT6359_BUCK("buck_vs1", VS1, "vsys-vs1", 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
MT6359_RG_BUCK_VS1_VOSEL_MASK <<
MT6359_RG_BUCK_VS1_VOSEL_SHIFT,
MT6359_RG_BUCK_VS1_LP_ADDR, MT6359_RG_BUCK_VS1_LP_SHIFT,
MT6359_RG_VS1_FPWM_ADDR, MT6359_RG_VS1_FPWM_SHIFT),
- MT6359_BUCK("buck_vgpu11", VGPU11, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vgpu11", VGPU11, "vsys-vgpu11", 400000, 1193750, 6250,
MT6359_RG_BUCK_VGPU11_EN_ADDR,
MT6359_DA_VGPU11_EN_ADDR, MT6359_RG_BUCK_VGPU11_VOSEL_ADDR,
MT6359_RG_BUCK_VGPU11_VOSEL_MASK <<
@@ -485,7 +492,7 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VGPU11_LP_ADDR,
MT6359_RG_BUCK_VGPU11_LP_SHIFT,
MT6359_RG_VGPU11_FCCM_ADDR, MT6359_RG_VGPU11_FCCM_SHIFT),
- MT6359_BUCK("buck_vmodem", VMODEM, 400000, 1100000, 6250,
+ MT6359_BUCK("buck_vmodem", VMODEM, "vsys-vmodem", 400000, 1100000, 6250,
MT6359_RG_BUCK_VMODEM_EN_ADDR,
MT6359_DA_VMODEM_EN_ADDR, MT6359_RG_BUCK_VMODEM_VOSEL_ADDR,
MT6359_RG_BUCK_VMODEM_VOSEL_MASK <<
@@ -493,35 +500,35 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VMODEM_LP_ADDR,
MT6359_RG_BUCK_VMODEM_LP_SHIFT,
MT6359_RG_VMODEM_FCCM_ADDR, MT6359_RG_VMODEM_FCCM_SHIFT),
- MT6359_BUCK("buck_vpu", VPU, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vpu", VPU, "vsys-vpu", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPU_EN_ADDR,
MT6359_DA_VPU_EN_ADDR, MT6359_RG_BUCK_VPU_VOSEL_ADDR,
MT6359_RG_BUCK_VPU_VOSEL_MASK <<
MT6359_RG_BUCK_VPU_VOSEL_SHIFT,
MT6359_RG_BUCK_VPU_LP_ADDR, MT6359_RG_BUCK_VPU_LP_SHIFT,
MT6359_RG_VPU_FCCM_ADDR, MT6359_RG_VPU_FCCM_SHIFT),
- MT6359_BUCK("buck_vcore", VCORE, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vcore", VCORE, "vsys-vcore", 400000, 1193750, 6250,
MT6359_RG_BUCK_VCORE_EN_ADDR,
MT6359_DA_VCORE_EN_ADDR, MT6359_RG_BUCK_VCORE_VOSEL_ADDR,
MT6359_RG_BUCK_VCORE_VOSEL_MASK <<
MT6359_RG_BUCK_VCORE_VOSEL_SHIFT,
MT6359_RG_BUCK_VCORE_LP_ADDR, MT6359_RG_BUCK_VCORE_LP_SHIFT,
MT6359_RG_VCORE_FCCM_ADDR, MT6359_RG_VCORE_FCCM_SHIFT),
- MT6359_BUCK("buck_vs2", VS2, 800000, 1600000, 12500,
+ MT6359_BUCK("buck_vs2", VS2, "vsys-vs2", 800000, 1600000, 12500,
MT6359_RG_BUCK_VS2_EN_ADDR,
MT6359_DA_VS2_EN_ADDR, MT6359_RG_BUCK_VS2_VOSEL_ADDR,
MT6359_RG_BUCK_VS2_VOSEL_MASK <<
MT6359_RG_BUCK_VS2_VOSEL_SHIFT,
MT6359_RG_BUCK_VS2_LP_ADDR, MT6359_RG_BUCK_VS2_LP_SHIFT,
MT6359_RG_VS2_FPWM_ADDR, MT6359_RG_VS2_FPWM_SHIFT),
- MT6359_BUCK("buck_vpa", VPA, 500000, 3650000, 50000,
+ MT6359_BUCK("buck_vpa", VPA, "vsys-vpa", 500000, 3650000, 50000,
MT6359_RG_BUCK_VPA_EN_ADDR,
MT6359_DA_VPA_EN_ADDR, MT6359_RG_BUCK_VPA_VOSEL_ADDR,
MT6359_RG_BUCK_VPA_VOSEL_MASK <<
MT6359_RG_BUCK_VPA_VOSEL_SHIFT,
MT6359_RG_BUCK_VPA_LP_ADDR, MT6359_RG_BUCK_VPA_LP_SHIFT,
MT6359_RG_VPA_MODESET_ADDR, MT6359_RG_VPA_MODESET_SHIFT),
- MT6359_BUCK("buck_vproc2", VPROC2, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vproc2", VPROC2, "vsys-vproc2", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPROC2_EN_ADDR,
MT6359_DA_VPROC2_EN_ADDR, MT6359_RG_BUCK_VPROC2_VOSEL_ADDR,
MT6359_RG_BUCK_VPROC2_VOSEL_MASK <<
@@ -529,7 +536,7 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VPROC2_LP_ADDR,
MT6359_RG_BUCK_VPROC2_LP_SHIFT,
MT6359_RG_VPROC2_FCCM_ADDR, MT6359_RG_VPROC2_FCCM_SHIFT),
- MT6359_BUCK("buck_vproc1", VPROC1, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vproc1", VPROC1, "vsys-vproc1", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPROC1_EN_ADDR,
MT6359_DA_VPROC1_EN_ADDR, MT6359_RG_BUCK_VPROC1_VOSEL_ADDR,
MT6359_RG_BUCK_VPROC1_VOSEL_MASK <<
@@ -537,7 +544,7 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VPROC1_LP_ADDR,
MT6359_RG_BUCK_VPROC1_LP_SHIFT,
MT6359_RG_VPROC1_FCCM_ADDR, MT6359_RG_VPROC1_FCCM_SHIFT),
- MT6359_BUCK("buck_vcore_sshub", VCORE_SSHUB, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vcore_sshub", VCORE_SSHUB, "vsys-vcore", 400000, 1193750, 6250,
MT6359_RG_BUCK_VCORE_SSHUB_EN_ADDR,
MT6359_DA_VCORE_EN_ADDR,
MT6359_RG_BUCK_VCORE_SSHUB_VOSEL_ADDR,
@@ -545,158 +552,159 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
MT6359_RG_BUCK_VCORE_SSHUB_VOSEL_SHIFT,
MT6359_RG_BUCK_VCORE_LP_ADDR, MT6359_RG_BUCK_VCORE_LP_SHIFT,
MT6359_RG_VCORE_FCCM_ADDR, MT6359_RG_VCORE_FCCM_SHIFT),
- MT6359_REG_FIXED("ldo_vaud18", VAUD18, MT6359_RG_LDO_VAUD18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vaud18", VAUD18, "vs1-ldo1", MT6359_RG_LDO_VAUD18_EN_ADDR,
MT6359_DA_VAUD18_B_EN_ADDR, 1800000),
- MT6359_LDO("ldo_vsim1", VSIM1, vsim1_voltages,
+ MT6359_LDO("ldo_vsim1", VSIM1, "vsys-ldo2", vsim1_voltages,
MT6359_RG_LDO_VSIM1_EN_ADDR, MT6359_RG_LDO_VSIM1_EN_SHIFT,
MT6359_DA_VSIM1_B_EN_ADDR, MT6359_RG_VSIM1_VOSEL_ADDR,
MT6359_RG_VSIM1_VOSEL_MASK << MT6359_RG_VSIM1_VOSEL_SHIFT,
480),
- MT6359_LDO("ldo_vibr", VIBR, vibr_voltages,
+ MT6359_LDO("ldo_vibr", VIBR, "vsys-ldo1", vibr_voltages,
MT6359_RG_LDO_VIBR_EN_ADDR, MT6359_RG_LDO_VIBR_EN_SHIFT,
MT6359_DA_VIBR_B_EN_ADDR, MT6359_RG_VIBR_VOSEL_ADDR,
MT6359_RG_VIBR_VOSEL_MASK << MT6359_RG_VIBR_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vrf12", VRF12, vrf12_voltages,
+ MT6359_LDO("ldo_vrf12", VRF12, "vs2-ldo2", vrf12_voltages,
MT6359_RG_LDO_VRF12_EN_ADDR, MT6359_RG_LDO_VRF12_EN_SHIFT,
MT6359_DA_VRF12_B_EN_ADDR, MT6359_RG_VRF12_VOSEL_ADDR,
MT6359_RG_VRF12_VOSEL_MASK << MT6359_RG_VRF12_VOSEL_SHIFT,
120),
- MT6359_REG_FIXED("ldo_vusb", VUSB, MT6359_RG_LDO_VUSB_EN_0_ADDR,
+ MT6359_REG_FIXED("ldo_vusb", VUSB, "vsys-ldo2", MT6359_RG_LDO_VUSB_EN_0_ADDR,
MT6359_DA_VUSB_B_EN_ADDR, 3000000),
- MT6359_LDO_LINEAR("ldo_vsram_proc2", VSRAM_PROC2, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_proc2", VSRAM_PROC2, "vs2-ldo1", 500000, 1293750, 6250,
MT6359_RG_LDO_VSRAM_PROC2_EN_ADDR,
MT6359_DA_VSRAM_PROC2_B_EN_ADDR,
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_SHIFT),
- MT6359_LDO("ldo_vio18", VIO18, volt18_voltages,
+ MT6359_LDO("ldo_vio18", VIO18, "vs1-ldo2", volt18_voltages,
MT6359_RG_LDO_VIO18_EN_ADDR, MT6359_RG_LDO_VIO18_EN_SHIFT,
MT6359_DA_VIO18_B_EN_ADDR, MT6359_RG_VIO18_VOSEL_ADDR,
MT6359_RG_VIO18_VOSEL_MASK << MT6359_RG_VIO18_VOSEL_SHIFT,
960),
- MT6359_LDO("ldo_vcamio", VCAMIO, volt18_voltages,
+ MT6359_LDO("ldo_vcamio", VCAMIO, "vs1-ldo1", volt18_voltages,
MT6359_RG_LDO_VCAMIO_EN_ADDR, MT6359_RG_LDO_VCAMIO_EN_SHIFT,
MT6359_DA_VCAMIO_B_EN_ADDR, MT6359_RG_VCAMIO_VOSEL_ADDR,
MT6359_RG_VCAMIO_VOSEL_MASK << MT6359_RG_VCAMIO_VOSEL_SHIFT,
1290),
- MT6359_REG_FIXED("ldo_vcn18", VCN18, MT6359_RG_LDO_VCN18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vcn18", VCN18, "vs1-ldo2", MT6359_RG_LDO_VCN18_EN_ADDR,
MT6359_DA_VCN18_B_EN_ADDR, 1800000),
- MT6359_REG_FIXED("ldo_vfe28", VFE28, MT6359_RG_LDO_VFE28_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vfe28", VFE28, "vsys-ldo1", MT6359_RG_LDO_VFE28_EN_ADDR,
MT6359_DA_VFE28_B_EN_ADDR, 2800000),
- MT6359_LDO("ldo_vcn13", VCN13, vcn13_voltages,
+ MT6359_LDO("ldo_vcn13", VCN13, "vs2-ldo2", vcn13_voltages,
MT6359_RG_LDO_VCN13_EN_ADDR, MT6359_RG_LDO_VCN13_EN_SHIFT,
MT6359_DA_VCN13_B_EN_ADDR, MT6359_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_1_EN_1_ADDR,
MT6359_RG_LDO_VCN33_1_EN_1_SHIFT,
MT6359_DA_VCN33_1_B_EN_ADDR, MT6359_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_REG_FIXED("ldo_vaux18", VAUX18, MT6359_RG_LDO_VAUX18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359_RG_LDO_VAUX18_EN_ADDR,
MT6359_DA_VAUX18_B_EN_ADDR, 1800000),
- MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, 500000, 1293750,
+ MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
6250,
MT6359_RG_LDO_VSRAM_OTHERS_EN_ADDR,
MT6359_DA_VSRAM_OTHERS_B_EN_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_SHIFT),
- MT6359_LDO("ldo_vefuse", VEFUSE, vefuse_voltages,
+ MT6359_LDO("ldo_vefuse", VEFUSE, "vs1-ldo2", vefuse_voltages,
MT6359_RG_LDO_VEFUSE_EN_ADDR, MT6359_RG_LDO_VEFUSE_EN_SHIFT,
MT6359_DA_VEFUSE_B_EN_ADDR, MT6359_RG_VEFUSE_VOSEL_ADDR,
MT6359_RG_VEFUSE_VOSEL_MASK << MT6359_RG_VEFUSE_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vxo22", VXO22, vxo22_voltages,
+ MT6359_LDO("ldo_vxo22", VXO22, "vsys-ldo2", vxo22_voltages,
MT6359_RG_LDO_VXO22_EN_ADDR, MT6359_RG_LDO_VXO22_EN_SHIFT,
MT6359_DA_VXO22_B_EN_ADDR, MT6359_RG_VXO22_VOSEL_ADDR,
MT6359_RG_VXO22_VOSEL_MASK << MT6359_RG_VXO22_VOSEL_SHIFT,
120),
- MT6359_LDO("ldo_vrfck", VRFCK, vrfck_voltages,
+ MT6359_LDO("ldo_vrfck", VRFCK, "vsys-ldo2", vrfck_voltages,
MT6359_RG_LDO_VRFCK_EN_ADDR, MT6359_RG_LDO_VRFCK_EN_SHIFT,
MT6359_DA_VRFCK_B_EN_ADDR, MT6359_RG_VRFCK_VOSEL_ADDR,
MT6359_RG_VRFCK_VOSEL_MASK << MT6359_RG_VRFCK_VOSEL_SHIFT,
480),
- MT6359_REG_FIXED("ldo_vbif28", VBIF28, MT6359_RG_LDO_VBIF28_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vbif28", VBIF28, "vsys-ldo2", MT6359_RG_LDO_VBIF28_EN_ADDR,
MT6359_DA_VBIF28_B_EN_ADDR, 2800000),
- MT6359_LDO("ldo_vio28", VIO28, vio28_voltages,
+ MT6359_LDO("ldo_vio28", VIO28, "vsys-ldo2", vio28_voltages,
MT6359_RG_LDO_VIO28_EN_ADDR, MT6359_RG_LDO_VIO28_EN_SHIFT,
MT6359_DA_VIO28_B_EN_ADDR, MT6359_RG_VIO28_VOSEL_ADDR,
MT6359_RG_VIO28_VOSEL_MASK << MT6359_RG_VIO28_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vemc", VEMC, vemc_voltages,
+ MT6359_LDO("ldo_vemc", VEMC, "vsys-ldo2", vemc_voltages,
MT6359_RG_LDO_VEMC_EN_ADDR, MT6359_RG_LDO_VEMC_EN_SHIFT,
MT6359_DA_VEMC_B_EN_ADDR, MT6359_RG_VEMC_VOSEL_ADDR,
MT6359_RG_VEMC_VOSEL_MASK << MT6359_RG_VEMC_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
MT6359_RG_LDO_VCN33_2_EN_1_ADDR,
MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
MT6359_DA_VCN33_2_B_EN_ADDR, MT6359_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_va12", VA12, va12_voltages,
+ MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359_RG_LDO_VA12_EN_ADDR, MT6359_RG_LDO_VA12_EN_SHIFT,
MT6359_DA_VA12_B_EN_ADDR, MT6359_RG_VA12_VOSEL_ADDR,
MT6359_RG_VA12_VOSEL_MASK << MT6359_RG_VA12_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_va09", VA09, va09_voltages,
+ MT6359_LDO("ldo_va09", VA09, "vs2-ldo2", va09_voltages,
MT6359_RG_LDO_VA09_EN_ADDR, MT6359_RG_LDO_VA09_EN_SHIFT,
MT6359_DA_VA09_B_EN_ADDR, MT6359_RG_VA09_VOSEL_ADDR,
MT6359_RG_VA09_VOSEL_MASK << MT6359_RG_VA09_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vrf18", VRF18, vrf18_voltages,
+ MT6359_LDO("ldo_vrf18", VRF18, "vs1-ldo2", vrf18_voltages,
MT6359_RG_LDO_VRF18_EN_ADDR, MT6359_RG_LDO_VRF18_EN_SHIFT,
MT6359_DA_VRF18_B_EN_ADDR, MT6359_RG_VRF18_VOSEL_ADDR,
MT6359_RG_VRF18_VOSEL_MASK << MT6359_RG_VRF18_VOSEL_SHIFT,
120),
- MT6359_LDO_LINEAR("ldo_vsram_md", VSRAM_MD, 500000, 1100000, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_md", VSRAM_MD, "vs2-ldo1", 500000, 1100000, 6250,
MT6359_RG_LDO_VSRAM_MD_EN_ADDR,
MT6359_DA_VSRAM_MD_B_EN_ADDR,
MT6359_RG_LDO_VSRAM_MD_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_MD_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_MD_VOSEL_SHIFT),
- MT6359_LDO("ldo_vufs", VUFS, volt18_voltages,
+ MT6359_LDO("ldo_vufs", VUFS, "vs1-ldo1", volt18_voltages,
MT6359_RG_LDO_VUFS_EN_ADDR, MT6359_RG_LDO_VUFS_EN_SHIFT,
MT6359_DA_VUFS_B_EN_ADDR, MT6359_RG_VUFS_VOSEL_ADDR,
MT6359_RG_VUFS_VOSEL_MASK << MT6359_RG_VUFS_VOSEL_SHIFT,
1920),
- MT6359_LDO("ldo_vm18", VM18, volt18_voltages,
+ MT6359_LDO("ldo_vm18", VM18, "vs1-ldo1", volt18_voltages,
MT6359_RG_LDO_VM18_EN_ADDR, MT6359_RG_LDO_VM18_EN_SHIFT,
MT6359_DA_VM18_B_EN_ADDR, MT6359_RG_VM18_VOSEL_ADDR,
MT6359_RG_VM18_VOSEL_MASK << MT6359_RG_VM18_VOSEL_SHIFT,
1920),
- MT6359_LDO("ldo_vbbck", VBBCK, vbbck_voltages,
+ /* vbbck is fed from vio18 internally. */
+ MT6359_LDO("ldo_vbbck", VBBCK, "LDO_VIO18", vbbck_voltages,
MT6359_RG_LDO_VBBCK_EN_ADDR, MT6359_RG_LDO_VBBCK_EN_SHIFT,
MT6359_DA_VBBCK_B_EN_ADDR, MT6359_RG_VBBCK_VOSEL_ADDR,
MT6359_RG_VBBCK_VOSEL_MASK << MT6359_RG_VBBCK_VOSEL_SHIFT,
240),
- MT6359_LDO_LINEAR("ldo_vsram_proc1", VSRAM_PROC1, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_proc1", VSRAM_PROC1, "vs2-ldo1", 500000, 1293750, 6250,
MT6359_RG_LDO_VSRAM_PROC1_EN_ADDR,
MT6359_DA_VSRAM_PROC1_B_EN_ADDR,
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_SHIFT),
- MT6359_LDO("ldo_vsim2", VSIM2, vsim2_voltages,
+ MT6359_LDO("ldo_vsim2", VSIM2, "vsys-ldo2", vsim2_voltages,
MT6359_RG_LDO_VSIM2_EN_ADDR, MT6359_RG_LDO_VSIM2_EN_SHIFT,
MT6359_DA_VSIM2_B_EN_ADDR, MT6359_RG_VSIM2_VOSEL_ADDR,
MT6359_RG_VSIM2_VOSEL_MASK << MT6359_RG_VSIM2_VOSEL_SHIFT,
480),
- MT6359_LDO_LINEAR("ldo_vsram_others_sshub", VSRAM_OTHERS_SSHUB,
+ MT6359_LDO_LINEAR("ldo_vsram_others_sshub", VSRAM_OTHERS_SSHUB, "vs2-ldo1",
500000, 1293750, 6250,
MT6359_RG_LDO_VSRAM_OTHERS_SSHUB_EN_ADDR,
MT6359_DA_VSRAM_OTHERS_B_EN_ADDR,
@@ -706,14 +714,14 @@ static const struct mt6359_regulator_info mt6359_regulators[] = {
};
static const struct mt6359_regulator_info mt6359p_regulators[] = {
- MT6359_BUCK("buck_vs1", VS1, 800000, 2200000, 12500,
+ MT6359_BUCK("buck_vs1", VS1, "vsys-vs1", 800000, 2200000, 12500,
MT6359_RG_BUCK_VS1_EN_ADDR,
MT6359_DA_VS1_EN_ADDR, MT6359_RG_BUCK_VS1_VOSEL_ADDR,
MT6359_RG_BUCK_VS1_VOSEL_MASK <<
MT6359_RG_BUCK_VS1_VOSEL_SHIFT,
MT6359_RG_BUCK_VS1_LP_ADDR, MT6359_RG_BUCK_VS1_LP_SHIFT,
MT6359_RG_VS1_FPWM_ADDR, MT6359_RG_VS1_FPWM_SHIFT),
- MT6359_BUCK("buck_vgpu11", VGPU11, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vgpu11", VGPU11, "vsys-vgpu11", 400000, 1193750, 6250,
MT6359_RG_BUCK_VGPU11_EN_ADDR,
MT6359_DA_VGPU11_EN_ADDR, MT6359P_RG_BUCK_VGPU11_VOSEL_ADDR,
MT6359_RG_BUCK_VGPU11_VOSEL_MASK <<
@@ -721,7 +729,7 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VGPU11_LP_ADDR,
MT6359_RG_BUCK_VGPU11_LP_SHIFT,
MT6359_RG_VGPU11_FCCM_ADDR, MT6359_RG_VGPU11_FCCM_SHIFT),
- MT6359_BUCK("buck_vmodem", VMODEM, 400000, 1100000, 6250,
+ MT6359_BUCK("buck_vmodem", VMODEM, "vsys-vmodem", 400000, 1100000, 6250,
MT6359_RG_BUCK_VMODEM_EN_ADDR,
MT6359_DA_VMODEM_EN_ADDR, MT6359_RG_BUCK_VMODEM_VOSEL_ADDR,
MT6359_RG_BUCK_VMODEM_VOSEL_MASK <<
@@ -729,35 +737,35 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VMODEM_LP_ADDR,
MT6359_RG_BUCK_VMODEM_LP_SHIFT,
MT6359_RG_VMODEM_FCCM_ADDR, MT6359_RG_VMODEM_FCCM_SHIFT),
- MT6359_BUCK("buck_vpu", VPU, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vpu", VPU, "vsys-vpu", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPU_EN_ADDR,
MT6359_DA_VPU_EN_ADDR, MT6359_RG_BUCK_VPU_VOSEL_ADDR,
MT6359_RG_BUCK_VPU_VOSEL_MASK <<
MT6359_RG_BUCK_VPU_VOSEL_SHIFT,
MT6359_RG_BUCK_VPU_LP_ADDR, MT6359_RG_BUCK_VPU_LP_SHIFT,
MT6359_RG_VPU_FCCM_ADDR, MT6359_RG_VPU_FCCM_SHIFT),
- MT6359_BUCK("buck_vcore", VCORE, 506250, 1300000, 6250,
+ MT6359_BUCK("buck_vcore", VCORE, "vsys-vcore", 506250, 1300000, 6250,
MT6359_RG_BUCK_VCORE_EN_ADDR,
MT6359_DA_VCORE_EN_ADDR, MT6359P_RG_BUCK_VCORE_VOSEL_ADDR,
MT6359_RG_BUCK_VCORE_VOSEL_MASK <<
MT6359_RG_BUCK_VCORE_VOSEL_SHIFT,
MT6359_RG_BUCK_VCORE_LP_ADDR, MT6359_RG_BUCK_VCORE_LP_SHIFT,
MT6359_RG_VCORE_FCCM_ADDR, MT6359_RG_VCORE_FCCM_SHIFT),
- MT6359_BUCK("buck_vs2", VS2, 800000, 1600000, 12500,
+ MT6359_BUCK("buck_vs2", VS2, "vsys-vs2", 800000, 1600000, 12500,
MT6359_RG_BUCK_VS2_EN_ADDR,
MT6359_DA_VS2_EN_ADDR, MT6359_RG_BUCK_VS2_VOSEL_ADDR,
MT6359_RG_BUCK_VS2_VOSEL_MASK <<
MT6359_RG_BUCK_VS2_VOSEL_SHIFT,
MT6359_RG_BUCK_VS2_LP_ADDR, MT6359_RG_BUCK_VS2_LP_SHIFT,
MT6359_RG_VS2_FPWM_ADDR, MT6359_RG_VS2_FPWM_SHIFT),
- MT6359_BUCK("buck_vpa", VPA, 500000, 3650000, 50000,
+ MT6359_BUCK("buck_vpa", VPA, "vsys-vpa", 500000, 3650000, 50000,
MT6359_RG_BUCK_VPA_EN_ADDR,
MT6359_DA_VPA_EN_ADDR, MT6359_RG_BUCK_VPA_VOSEL_ADDR,
MT6359_RG_BUCK_VPA_VOSEL_MASK <<
MT6359_RG_BUCK_VPA_VOSEL_SHIFT,
MT6359_RG_BUCK_VPA_LP_ADDR, MT6359_RG_BUCK_VPA_LP_SHIFT,
MT6359_RG_VPA_MODESET_ADDR, MT6359_RG_VPA_MODESET_SHIFT),
- MT6359_BUCK("buck_vproc2", VPROC2, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vproc2", VPROC2, "vsys-vproc2", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPROC2_EN_ADDR,
MT6359_DA_VPROC2_EN_ADDR, MT6359_RG_BUCK_VPROC2_VOSEL_ADDR,
MT6359_RG_BUCK_VPROC2_VOSEL_MASK <<
@@ -765,7 +773,7 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VPROC2_LP_ADDR,
MT6359_RG_BUCK_VPROC2_LP_SHIFT,
MT6359_RG_VPROC2_FCCM_ADDR, MT6359_RG_VPROC2_FCCM_SHIFT),
- MT6359_BUCK("buck_vproc1", VPROC1, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vproc1", VPROC1, "vsys-vproc1", 400000, 1193750, 6250,
MT6359_RG_BUCK_VPROC1_EN_ADDR,
MT6359_DA_VPROC1_EN_ADDR, MT6359_RG_BUCK_VPROC1_VOSEL_ADDR,
MT6359_RG_BUCK_VPROC1_VOSEL_MASK <<
@@ -773,7 +781,7 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VPROC1_LP_ADDR,
MT6359_RG_BUCK_VPROC1_LP_SHIFT,
MT6359_RG_VPROC1_FCCM_ADDR, MT6359_RG_VPROC1_FCCM_SHIFT),
- MT6359_BUCK("buck_vgpu11_sshub", VGPU11_SSHUB, 400000, 1193750, 6250,
+ MT6359_BUCK("buck_vgpu11_sshub", VGPU11_SSHUB, "vsys-vgpu11", 400000, 1193750, 6250,
MT6359P_RG_BUCK_VGPU11_SSHUB_EN_ADDR,
MT6359_DA_VGPU11_EN_ADDR,
MT6359P_RG_BUCK_VGPU11_SSHUB_VOSEL_ADDR,
@@ -782,161 +790,161 @@ static const struct mt6359_regulator_info mt6359p_regulators[] = {
MT6359_RG_BUCK_VGPU11_LP_ADDR,
MT6359_RG_BUCK_VGPU11_LP_SHIFT,
MT6359_RG_VGPU11_FCCM_ADDR, MT6359_RG_VGPU11_FCCM_SHIFT),
- MT6359_REG_FIXED("ldo_vaud18", VAUD18, MT6359P_RG_LDO_VAUD18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vaud18", VAUD18, "vs1-ldo1", MT6359P_RG_LDO_VAUD18_EN_ADDR,
MT6359P_DA_VAUD18_B_EN_ADDR, 1800000),
- MT6359_LDO("ldo_vsim1", VSIM1, vsim1_voltages,
+ MT6359_LDO("ldo_vsim1", VSIM1, "vsys-ldo2", vsim1_voltages,
MT6359P_RG_LDO_VSIM1_EN_ADDR, MT6359P_RG_LDO_VSIM1_EN_SHIFT,
MT6359P_DA_VSIM1_B_EN_ADDR, MT6359P_RG_VSIM1_VOSEL_ADDR,
MT6359_RG_VSIM1_VOSEL_MASK << MT6359_RG_VSIM1_VOSEL_SHIFT,
480),
- MT6359_LDO("ldo_vibr", VIBR, vibr_voltages,
+ MT6359_LDO("ldo_vibr", VIBR, "vsys-ldo1", vibr_voltages,
MT6359P_RG_LDO_VIBR_EN_ADDR, MT6359P_RG_LDO_VIBR_EN_SHIFT,
MT6359P_DA_VIBR_B_EN_ADDR, MT6359P_RG_VIBR_VOSEL_ADDR,
MT6359_RG_VIBR_VOSEL_MASK << MT6359_RG_VIBR_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vrf12", VRF12, vrf12_voltages,
+ MT6359_LDO("ldo_vrf12", VRF12, "vs2-ldo2", vrf12_voltages,
MT6359P_RG_LDO_VRF12_EN_ADDR, MT6359P_RG_LDO_VRF12_EN_SHIFT,
MT6359P_DA_VRF12_B_EN_ADDR, MT6359P_RG_VRF12_VOSEL_ADDR,
MT6359_RG_VRF12_VOSEL_MASK << MT6359_RG_VRF12_VOSEL_SHIFT,
480),
- MT6359_REG_FIXED("ldo_vusb", VUSB, MT6359P_RG_LDO_VUSB_EN_0_ADDR,
+ MT6359_REG_FIXED("ldo_vusb", VUSB, "vsys-ldo2", MT6359P_RG_LDO_VUSB_EN_0_ADDR,
MT6359P_DA_VUSB_B_EN_ADDR, 3000000),
- MT6359_LDO_LINEAR("ldo_vsram_proc2", VSRAM_PROC2, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_proc2", VSRAM_PROC2, "vs2-ldo1", 500000, 1293750, 6250,
MT6359P_RG_LDO_VSRAM_PROC2_EN_ADDR,
MT6359P_DA_VSRAM_PROC2_B_EN_ADDR,
MT6359P_RG_LDO_VSRAM_PROC2_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_PROC2_VOSEL_SHIFT),
- MT6359_LDO("ldo_vio18", VIO18, volt18_voltages,
+ MT6359_LDO("ldo_vio18", VIO18, "vs1-ldo2", volt18_voltages,
MT6359P_RG_LDO_VIO18_EN_ADDR, MT6359P_RG_LDO_VIO18_EN_SHIFT,
MT6359P_DA_VIO18_B_EN_ADDR, MT6359P_RG_VIO18_VOSEL_ADDR,
MT6359_RG_VIO18_VOSEL_MASK << MT6359_RG_VIO18_VOSEL_SHIFT,
960),
- MT6359_LDO("ldo_vcamio", VCAMIO, volt18_voltages,
+ MT6359_LDO("ldo_vcamio", VCAMIO, "vs1-ldo1", volt18_voltages,
MT6359P_RG_LDO_VCAMIO_EN_ADDR,
MT6359P_RG_LDO_VCAMIO_EN_SHIFT,
MT6359P_DA_VCAMIO_B_EN_ADDR, MT6359P_RG_VCAMIO_VOSEL_ADDR,
MT6359_RG_VCAMIO_VOSEL_MASK << MT6359_RG_VCAMIO_VOSEL_SHIFT,
1290),
- MT6359_REG_FIXED("ldo_vcn18", VCN18, MT6359P_RG_LDO_VCN18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vcn18", VCN18, "vs1-ldo2", MT6359P_RG_LDO_VCN18_EN_ADDR,
MT6359P_DA_VCN18_B_EN_ADDR, 1800000),
- MT6359_REG_FIXED("ldo_vfe28", VFE28, MT6359P_RG_LDO_VFE28_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vfe28", VFE28, "vsys-ldo1", MT6359P_RG_LDO_VFE28_EN_ADDR,
MT6359P_DA_VFE28_B_EN_ADDR, 2800000),
- MT6359_LDO("ldo_vcn13", VCN13, vcn13_voltages,
+ MT6359_LDO("ldo_vcn13", VCN13, "vs2-ldo2", vcn13_voltages,
MT6359P_RG_LDO_VCN13_EN_ADDR, MT6359P_RG_LDO_VCN13_EN_SHIFT,
MT6359P_DA_VCN13_B_EN_ADDR, MT6359P_RG_VCN13_VOSEL_ADDR,
MT6359_RG_VCN13_VOSEL_MASK << MT6359_RG_VCN13_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1_bt", VCN33_1_BT, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_1_EN_0_ADDR,
MT6359_RG_LDO_VCN33_1_EN_0_SHIFT,
MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_1_wifi", VCN33_1_WIFI, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_1_EN_1_ADDR,
MT6359P_RG_LDO_VCN33_1_EN_1_SHIFT,
MT6359P_DA_VCN33_1_B_EN_ADDR, MT6359P_RG_VCN33_1_VOSEL_ADDR,
MT6359_RG_VCN33_1_VOSEL_MASK <<
MT6359_RG_VCN33_1_VOSEL_SHIFT, 240),
- MT6359_REG_FIXED("ldo_vaux18", VAUX18, MT6359P_RG_LDO_VAUX18_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vaux18", VAUX18, "vsys-ldo2", MT6359P_RG_LDO_VAUX18_EN_ADDR,
MT6359P_DA_VAUX18_B_EN_ADDR, 1800000),
- MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, 500000, 1293750,
+ MT6359_LDO_LINEAR("ldo_vsram_others", VSRAM_OTHERS, "vs2-ldo1", 500000, 1293750,
6250,
MT6359P_RG_LDO_VSRAM_OTHERS_EN_ADDR,
MT6359P_DA_VSRAM_OTHERS_B_EN_ADDR,
MT6359P_RG_LDO_VSRAM_OTHERS_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_OTHERS_VOSEL_SHIFT),
- MT6359_LDO("ldo_vefuse", VEFUSE, vefuse_voltages,
+ MT6359_LDO("ldo_vefuse", VEFUSE, "vs1-ldo2", vefuse_voltages,
MT6359P_RG_LDO_VEFUSE_EN_ADDR,
MT6359P_RG_LDO_VEFUSE_EN_SHIFT,
MT6359P_DA_VEFUSE_B_EN_ADDR, MT6359P_RG_VEFUSE_VOSEL_ADDR,
MT6359_RG_VEFUSE_VOSEL_MASK << MT6359_RG_VEFUSE_VOSEL_SHIFT,
240),
- MT6359_LDO("ldo_vxo22", VXO22, vxo22_voltages,
+ MT6359_LDO("ldo_vxo22", VXO22, "vsys-ldo2", vxo22_voltages,
MT6359P_RG_LDO_VXO22_EN_ADDR, MT6359P_RG_LDO_VXO22_EN_SHIFT,
MT6359P_DA_VXO22_B_EN_ADDR, MT6359P_RG_VXO22_VOSEL_ADDR,
MT6359_RG_VXO22_VOSEL_MASK << MT6359_RG_VXO22_VOSEL_SHIFT,
480),
- MT6359_LDO("ldo_vrfck_1", VRFCK, vrfck_voltages_1,
+ MT6359_LDO("ldo_vrfck_1", VRFCK, "vsys-ldo2", vrfck_voltages_1,
MT6359P_RG_LDO_VRFCK_EN_ADDR, MT6359P_RG_LDO_VRFCK_EN_SHIFT,
MT6359P_DA_VRFCK_B_EN_ADDR, MT6359P_RG_VRFCK_VOSEL_ADDR,
MT6359_RG_VRFCK_VOSEL_MASK << MT6359_RG_VRFCK_VOSEL_SHIFT,
480),
- MT6359_REG_FIXED("ldo_vbif28", VBIF28, MT6359P_RG_LDO_VBIF28_EN_ADDR,
+ MT6359_REG_FIXED("ldo_vbif28", VBIF28, "vsys-ldo2", MT6359P_RG_LDO_VBIF28_EN_ADDR,
MT6359P_DA_VBIF28_B_EN_ADDR, 2800000),
- MT6359_LDO("ldo_vio28", VIO28, vio28_voltages,
+ MT6359_LDO("ldo_vio28", VIO28, "vsys-ldo2", vio28_voltages,
MT6359P_RG_LDO_VIO28_EN_ADDR, MT6359P_RG_LDO_VIO28_EN_SHIFT,
MT6359P_DA_VIO28_B_EN_ADDR, MT6359P_RG_VIO28_VOSEL_ADDR,
MT6359_RG_VIO28_VOSEL_MASK << MT6359_RG_VIO28_VOSEL_SHIFT,
1920),
- MT6359P_LDO1("ldo_vemc_1", VEMC, mt6359p_vemc_ops, vemc_voltages_1,
+ MT6359P_LDO1("ldo_vemc_1", VEMC, "vsys-ldo2", mt6359p_vemc_ops, vemc_voltages_1,
MT6359P_RG_LDO_VEMC_EN_ADDR, MT6359P_RG_LDO_VEMC_EN_SHIFT,
MT6359P_DA_VEMC_B_EN_ADDR,
MT6359P_RG_LDO_VEMC_VOSEL_0_ADDR,
MT6359P_RG_LDO_VEMC_VOSEL_0_MASK <<
MT6359P_RG_LDO_VEMC_VOSEL_0_SHIFT),
- MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2_bt", VCN33_2_BT, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_2_EN_0_ADDR,
MT6359P_RG_LDO_VCN33_2_EN_0_SHIFT,
MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, vcn33_voltages,
+ MT6359_LDO("ldo_vcn33_2_wifi", VCN33_2_WIFI, "vsys-ldo1", vcn33_voltages,
MT6359P_RG_LDO_VCN33_2_EN_1_ADDR,
MT6359_RG_LDO_VCN33_2_EN_1_SHIFT,
MT6359P_DA_VCN33_2_B_EN_ADDR, MT6359P_RG_VCN33_2_VOSEL_ADDR,
MT6359_RG_VCN33_2_VOSEL_MASK <<
MT6359_RG_VCN33_2_VOSEL_SHIFT, 240),
- MT6359_LDO("ldo_va12", VA12, va12_voltages,
+ MT6359_LDO("ldo_va12", VA12, "vs2-ldo2", va12_voltages,
MT6359P_RG_LDO_VA12_EN_ADDR, MT6359P_RG_LDO_VA12_EN_SHIFT,
MT6359P_DA_VA12_B_EN_ADDR, MT6359P_RG_VA12_VOSEL_ADDR,
MT6359_RG_VA12_VOSEL_MASK << MT6359_RG_VA12_VOSEL_SHIFT,
960),
- MT6359_LDO("ldo_va09", VA09, va09_voltages,
+ MT6359_LDO("ldo_va09", VA09, "vs2-ldo2", va09_voltages,
MT6359P_RG_LDO_VA09_EN_ADDR, MT6359P_RG_LDO_VA09_EN_SHIFT,
MT6359P_DA_VA09_B_EN_ADDR, MT6359P_RG_VA09_VOSEL_ADDR,
MT6359_RG_VA09_VOSEL_MASK << MT6359_RG_VA09_VOSEL_SHIFT,
960),
- MT6359_LDO("ldo_vrf18", VRF18, vrf18_voltages,
+ MT6359_LDO("ldo_vrf18", VRF18, "vs1-ldo2", vrf18_voltages,
MT6359P_RG_LDO_VRF18_EN_ADDR, MT6359P_RG_LDO_VRF18_EN_SHIFT,
MT6359P_DA_VRF18_B_EN_ADDR, MT6359P_RG_VRF18_VOSEL_ADDR,
MT6359_RG_VRF18_VOSEL_MASK << MT6359_RG_VRF18_VOSEL_SHIFT,
240),
- MT6359_LDO_LINEAR("ldo_vsram_md", VSRAM_MD, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_md", VSRAM_MD, "vs2-ldo1", 500000, 1293750, 6250,
MT6359P_RG_LDO_VSRAM_MD_EN_ADDR,
MT6359P_DA_VSRAM_MD_B_EN_ADDR,
MT6359P_RG_LDO_VSRAM_MD_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_MD_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_MD_VOSEL_SHIFT),
- MT6359_LDO("ldo_vufs", VUFS, volt18_voltages,
+ MT6359_LDO("ldo_vufs", VUFS, "vs1-ldo1", volt18_voltages,
MT6359P_RG_LDO_VUFS_EN_ADDR, MT6359P_RG_LDO_VUFS_EN_SHIFT,
MT6359P_DA_VUFS_B_EN_ADDR, MT6359P_RG_VUFS_VOSEL_ADDR,
MT6359_RG_VUFS_VOSEL_MASK << MT6359_RG_VUFS_VOSEL_SHIFT,
1920),
- MT6359_LDO("ldo_vm18", VM18, volt18_voltages,
+ MT6359_LDO("ldo_vm18", VM18, "vs1-ldo1", volt18_voltages,
MT6359P_RG_LDO_VM18_EN_ADDR, MT6359P_RG_LDO_VM18_EN_SHIFT,
MT6359P_DA_VM18_B_EN_ADDR, MT6359P_RG_VM18_VOSEL_ADDR,
MT6359_RG_VM18_VOSEL_MASK << MT6359_RG_VM18_VOSEL_SHIFT,
1920),
- MT6359_LDO("ldo_vbbck", VBBCK, vbbck_voltages,
+ MT6359_LDO("ldo_vbbck", VBBCK, "LDO_VIO18", vbbck_voltages,
MT6359P_RG_LDO_VBBCK_EN_ADDR, MT6359P_RG_LDO_VBBCK_EN_SHIFT,
MT6359P_DA_VBBCK_B_EN_ADDR, MT6359P_RG_VBBCK_VOSEL_ADDR,
MT6359P_RG_VBBCK_VOSEL_MASK << MT6359P_RG_VBBCK_VOSEL_SHIFT,
480),
- MT6359_LDO_LINEAR("ldo_vsram_proc1", VSRAM_PROC1, 500000, 1293750, 6250,
+ MT6359_LDO_LINEAR("ldo_vsram_proc1", VSRAM_PROC1, "vs2-ldo1", 500000, 1293750, 6250,
MT6359P_RG_LDO_VSRAM_PROC1_EN_ADDR,
MT6359P_DA_VSRAM_PROC1_B_EN_ADDR,
MT6359P_RG_LDO_VSRAM_PROC1_VOSEL_ADDR,
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_MASK <<
MT6359_RG_LDO_VSRAM_PROC1_VOSEL_SHIFT),
- MT6359_LDO("ldo_vsim2", VSIM2, vsim2_voltages,
+ MT6359_LDO("ldo_vsim2", VSIM2, "vsys-ldo2", vsim2_voltages,
MT6359P_RG_LDO_VSIM2_EN_ADDR, MT6359P_RG_LDO_VSIM2_EN_SHIFT,
MT6359P_DA_VSIM2_B_EN_ADDR, MT6359P_RG_VSIM2_VOSEL_ADDR,
MT6359_RG_VSIM2_VOSEL_MASK << MT6359_RG_VSIM2_VOSEL_SHIFT,
480),
- MT6359_LDO_LINEAR("ldo_vsram_others_sshub", VSRAM_OTHERS_SSHUB,
+ MT6359_LDO_LINEAR("ldo_vsram_others_sshub", VSRAM_OTHERS_SSHUB, "vs2-ldo1",
500000, 1293750, 6250,
MT6359P_RG_LDO_VSRAM_OTHERS_SSHUB_EN_ADDR,
MT6359P_DA_VSRAM_OTHERS_B_EN_ADDR,
@@ -951,6 +959,7 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
struct regulator_config config = {};
struct regulator_dev *rdev;
const struct mt6359_regulator_info *mt6359_info;
+ const char *vio18_name;
int i, hw_ver, ret;
ret = regmap_read(mt6397->regmap, MT6359P_HWCID, &hw_ver);
@@ -962,16 +971,37 @@ static int mt6359_regulator_probe(struct platform_device *pdev)
else
mt6359_info = mt6359_regulators;
+ vio18_name = mt6359_info[MT6359_ID_VIO18].desc.name;
+
config.dev = mt6397->dev;
config.regmap = mt6397->regmap;
for (i = 0; i < MT6359_MAX_REGULATOR; i++, mt6359_info++) {
+ const struct regulator_desc *desc = &mt6359_info->desc;
+ struct regulator_desc *_desc;
+
/* drop const here, but all uses in the driver are const */
config.driver_data = (void *)mt6359_info;
- rdev = devm_regulator_register(&pdev->dev, &mt6359_info->desc, &config);
+
+ /* Use vio18's actual name as supply_name for vbbck */
+ if (i == MT6359_ID_VBBCK && strcmp(desc->supply_name, vio18_name) != 0) {
+ _desc = devm_kzalloc(&pdev->dev, sizeof(*_desc), GFP_KERNEL);
+ if (!_desc)
+ return -ENOMEM;
+
+ memcpy(_desc, desc, sizeof(*_desc));
+ _desc->supply_name = vio18_name;
+ desc = _desc;
+ }
+
+ rdev = devm_regulator_register(&pdev->dev, desc, &config);
if (IS_ERR(rdev)) {
dev_err(&pdev->dev, "failed to register %s\n", mt6359_info->desc.name);
return PTR_ERR(rdev);
}
+
+ /* Save vio18 name for vbbck */
+ if (i == MT6359_ID_VIO18)
+ vio18_name = rdev_get_name(rdev);
}
return 0;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v3 3/6] regulator: dt-bindings: mt6359: Deprecate bogus vcn33_[12]_* split regulators
From: Chen-Yu Tsai @ 2026-05-12 8:53 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree,
Krzysztof Kozlowski
In-Reply-To: <20260512085358.1693208-1-wenst@chromium.org>
vcn33_[12]_bt and vcn33_[12]_wifi refer to the same output. There are
two enable bits in the registers so that BT and WiFi drivers can toggle
them separately without any coordination. If either bit is set, then the
regulator output is enabled.
Deprecate the existing regulators, and add proper regulators matching
the outputs: vcn33_1 and vcn33_2.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/regulator/mt6359-regulator.yaml | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
index ac925334ae83..eb62d6a0355d 100644
--- a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
@@ -30,7 +30,7 @@ patternProperties:
$ref: regulator.yaml#
unevaluatedProperties: false
- "^ldo_vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$":
+ "^ldo_vcn(18|13|33_[12])$":
type: object
$ref: regulator.yaml#
unevaluatedProperties: false
@@ -55,6 +55,15 @@ patternProperties:
$ref: regulator.yaml#
unevaluatedProperties: false
+ "^ldo_vcn33_[12]_(bt|wifi)":
+ type: object
+ $ref: regulator.yaml#
+ description:
+ vcn33_[12]_(bt|wifi) are incorrect representations.
+ Use vcn33_[12] instead.
+ deprecated: true
+ unevaluatedProperties: false
+
additionalProperties: false
examples:
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v3 2/6] regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions
From: Chen-Yu Tsai @ 2026-05-12 8:53 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree,
Krzysztof Kozlowski
In-Reply-To: <20260512085358.1693208-1-wenst@chromium.org>
The name of the regulator should match what the board design specifies
for the power rail. There should be no limitations on what the name can
be, and they definitely don't always follow the PMIC's own names.
Drop the restrictions on regulator-name.
Fixes: 8771456635d5 ("dt-bindings: regulator: Add document for MT6359 regulator")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
---
.../bindings/regulator/mt6359-regulator.yaml | 43 -------------------
1 file changed, 43 deletions(-)
diff --git a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
index fe4ac9350ba0..ac925334ae83 100644
--- a/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
+++ b/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
@@ -18,84 +18,41 @@ patternProperties:
"^buck_v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(s1|gpu11|modem|pu|core|s2|pa|proc2|proc1|core_sshub)$"
-
unevaluatedProperties: false
"^ldo_v(ibr|rf12|usb|camio|efuse|xo22)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(ibr|rf12|usb|camio|efuse|xo22)$"
-
unevaluatedProperties: false
"^ldo_v(rfck|emc|a12|a09|ufs|bbck)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(rfck|emc|a12|a09|ufs|bbck)$"
-
unevaluatedProperties: false
"^ldo_vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^vcn(18|13|33_1_bt|13_1_wifi|33_2_bt|33_2_wifi)$"
-
unevaluatedProperties: false
"^ldo_vsram_(proc2|others|md|proc1|others_sshub)$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^vsram_(proc2|others|md|proc1|others_sshub)$"
-
unevaluatedProperties: false
"^ldo_v(fe|bif|io)28$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(fe|bif|io)28$"
-
unevaluatedProperties: false
"^ldo_v(aud|io|aux|rf|m)18$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^v(aud|io|aux|rf|m)18$"
-
unevaluatedProperties: false
"^ldo_vsim[12]$":
type: object
$ref: regulator.yaml#
-
- properties:
- regulator-name:
- pattern: "^vsim[12]$"
-
- required:
- - regulator-name
-
unevaluatedProperties: false
additionalProperties: false
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v3 1/6] mfd: dt-bindings: mt6397: Add regulator supplies
From: Chen-Yu Tsai @ 2026-05-12 8:53 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree,
Krzysztof Kozlowski
In-Reply-To: <20260512085358.1693208-1-wenst@chromium.org>
On the MT6397 family each buck regulator has a separate supply. LDOs are
split into various groups with independent supplies. There is also a
supply for the regulator control logic.
Add descriptions for all of the supplies for the MT6359.
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Lee, request from Mark:
Lee, this seems like mostly a regulator series - OK for me to apply this
patch and send you a tag for it?
Changes since v2:
- Fix vsys-vsmps-supply property name
Changes since v1:
- Use regular expression to describe vcn33_* names
- Moved regulator supplies to top level PMIC node
- Moved changes to mfd binding
---
.../bindings/mfd/mediatek,mt6397.yaml | 50 +++++++++++++++++++
1 file changed, 50 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
index 05c121b0cb3d..9e6053677981 100644
--- a/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
+++ b/Documentation/devicetree/bindings/mfd/mediatek,mt6397.yaml
@@ -225,12 +225,62 @@ properties:
description:
Pin controller
+ vsys-smps-supply:
+ description: Supply for regulator control logic
+
+patternProperties:
+ "^vsys-v[a-z]+[0-9]*-supply$":
+ description: Supplies for PMIC buck regulators
+ "^vs(ys|[12])-ldo[1-9]-supply$":
+ description: Supplies for PMIC LDO regulators
+
required:
- compatible
- regulators
additionalProperties: false
+allOf:
+ - if:
+ properties:
+ "compatible":
+ contains:
+ const: mediatek,mt6359
+ then:
+ properties:
+ vsys-ldo1-supply:
+ description: Supply for LDOs vcn33_[12], vio28, vfe28, vibr
+ vsys-ldo2-supply:
+ description: Supply for LDOs va09, vaux18, vbif28, vxo22, vrfck, vrfck_1,
+ vemc, vsim1, vsim2, vusb
+ vsys-vcore-supply:
+ description: Supply for buck regulator vcore
+ vsys-vgpu11-supply:
+ description: Supply for buck regulator vgpu11
+ vsys-vmodem-supply:
+ description: Supply for buck regulator vmodem
+ vsys-vpa-supply:
+ description: Supply for buck regulator vpa
+ vsys-vproc1-supply:
+ description: Supply for buck regulator vproc1
+ vsys-vproc2-supply:
+ description: Supply for buck regulator vproc2
+ vsys-vpu-supply:
+ description: Supply for buck regulator vpu
+ vsys-vs1-supply:
+ description: Supply for buck regulator vs1
+ vsys-vs2-supply:
+ description: Supply for buck regulator vs2
+ vs1-ldo1-supply:
+ description: Supply for LDOs vaud18, vcamio, vm18, vufs
+ vs1-ldo2-supply:
+ description: Supply for LDOs vcn18, vefuse, vio18, vrf18
+ vs2-ldo1-supply:
+ description:
+ Supply for LDOs vsram_proc1, vsram_proc2, vsram_others, vsram_md
+ vs2-ldo2-supply:
+ description: Supply for LDOs va09, va12, vcn13, vrf12
+
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v3 0/6] regulator: mt6359: cleanup and add supplies
From: Chen-Yu Tsai @ 2026-05-12 8:53 UTC (permalink / raw)
To: Mark Brown, Liam Girdwood, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: Chen-Yu Tsai, linux-arm-kernel, linux-mediatek, devicetree
Hi,
This is v3 of my "MT6359 PMIC cleanup and add supplies" series.
Changes since v2:
- Fixed vsys-smps-supply property name (from "vspms-supply")
- Collected reviewed-by on patch 3
- Included Lee in recipients (sorry about that)
- Link to v2:
https://lore.kernel.org/all/20260429074113.3720271-1-wenst@chromium.org/
Changes since v1:
- Moved regulator supply properties up to the PMIC mfd node
- This requires moving the properties to the mfd bindings
- deprecated vcn33_[12]_(bt|wifi) regulators and added vcn33_[12]
- model the deprecated ones as downstream to the new ones
(vcn33_[12] -> vcn33_[12]_(bt|wifi)
- Handle internal supply of vbbck directly in the driver, instead of
specifying it in the binding
- Added patch to constify data structures in the regulator driver
- Link to v1:
https://lore.kernel.org/all/20260320072440.2403318-1-wenst@chromium.org/
This series is part of a broader collection of regulator related
cleanups for MediaTek Chromebooks. This one covers the MT6359 PMIC.
The MT6359 PMIC is similar to the MT6358 and MT6366 PMICs. I've done
cleanups for those in the past.
Patch 1 adds the names of the power supply inputs to the binding.
Patch 2 drops the restrictions on the regulator-name property from the
binding. The name of the supply rail ideally should match the design
schematics, not the PMIC's output name. The DT should be free to set
whatever name it needs.
Patch 3 deprecates the vcn33_[12]_(bt|wifi) regulators, and adds new
proper vcn33_[12] regulators. The two *real* VCN33 regulator outputs
each have two enable bits that are OR-ed together to control the
output. This allowed WiFi and BT stacks to separately control power
output without coordination.
Patch 4 constifies the data structures used throughout the regulator
driver. While not directly related, it touches the same context and
it is easier to include it in the series.
Patch 5 adds the supply names from the DT binding change in patch 2
to the regulator descriptions in the driver. This patch has a whole
bunch of checkpatch.pl warnings, but I wonder if it's because the
context size for checking complex macros is not large enough.
Patch 6 implements the changes of the DT binding change in patch 3.
One part not yet covered in this series is the removal of the *_sshub
regulators. These are not actual regulators, but a set of separate
configurations to be used by the low power sensor hub or embedded
controller. How these combine with the standard set of configurations
set by the main processor is TBD.
Device tree changes will be sent separately. The goal is to get the
regulator tree as complete as possible. This includes adding supply
names to other regulator DT bindings, and adding all the supply links
to the existing DTs.
Please have a look.
Thanks
ChenYu
Chen-Yu Tsai (6):
mfd: dt-bindings: mt6397: Add regulator supplies
regulator: dt-bindings: mt6359: Drop regulator-name pattern
restrictions
regulator: dt-bindings: mt6359: Deprecate bogus vcn33_[12]_* split
regulators
regulator: mt6359: const-ify regulator descriptions
regulator: mt6359: Add regulator supply names
regulator: mt6359: Add proper ldo_vcn33_[12] regulators
.../bindings/mfd/mediatek,mt6397.yaml | 50 +++
.../bindings/regulator/mt6359-regulator.yaml | 52 +--
drivers/regulator/mt6359-regulator.c | 400 ++++++++++++------
include/linux/regulator/mt6359-regulator.h | 10 +-
4 files changed, 339 insertions(+), 173 deletions(-)
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply
* Re: [PATCH 1/4] drm/mediatek: mtk_hdmi_ddc_v2: Fix non-static global variable
From: CK Hu (胡俊光) @ 2026-05-12 8:52 UTC (permalink / raw)
To: chunkuang.hu@kernel.org, simona@ffwll.ch, Alexandre Mergnat,
AngeloGioacchino Del Regno, airlied@gmail.com,
p.zabel@pengutronix.de, matthias.bgg@gmail.com,
Louis-Alexis Eyraud
Cc: dri-devel@lists.freedesktop.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, kernel@collabora.com,
linux-kernel@vger.kernel.org, lkp@intel.com
In-Reply-To: <20260429-mediatek-drm-fix-sparse-warnings-v1-1-d95c4d118b83@collabora.com>
On Wed, 2026-04-29 at 11:58 +0200, Louis-Alexis Eyraud wrote:
> The struct 'mtk_hdmi_ddc_v2_driver' is not used outside of the
> mtk_hdmi_ddc_v2.c file, so make it static to silence sparse warning:
> ```
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c:392:24: sparse: warning:
> symbol 'mtk_hdmi_ddc_v2_driver' was not declared. Should it be
> static?
> ```
Reviewed-by: CK Hu <ck.hu@mediatek.com>
>
> Fixes: 8d0f79886273 ("drm/mediatek: Introduce HDMI/DDC v2 for MT8195/MT8188")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202604132044.fcYjEcU8-lkp@intel.com/
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>
> ---
> drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c
> index d937219fdb7e..31e81a6de6d8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c
> +++ b/drivers/gpu/drm/mediatek/mtk_hdmi_ddc_v2.c
> @@ -389,7 +389,7 @@ static const struct of_device_id mtk_hdmi_ddc_v2_match[] = {
> };
> MODULE_DEVICE_TABLE(of, mtk_hdmi_ddc_v2_match);
>
> -struct platform_driver mtk_hdmi_ddc_v2_driver = {
> +static struct platform_driver mtk_hdmi_ddc_v2_driver = {
> .probe = mtk_hdmi_ddc_v2_probe,
> .driver = {
> .name = "mediatek-hdmi-ddc-v2",
>
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: qcom: eliza: Add support for MM clock controllers
From: Taniya Das @ 2026-05-12 8:52 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: <b280ad04-d4ae-4904-9e99-3d057e3d221b@kernel.org>
On 4/10/2026 1:56 PM, Bryan O'Donoghue wrote:
> On 10/04/2026 04:55, Taniya Das wrote:
>>> Why do these two controllers have no power-domains ?
>> Bryan, on Eliza the videocc and camcc are connected on CX and MXA.
>
> Shouldn't you at least have:
>
> power-domains = <&rpmhpd RPMHPD_CX> ?
>
> And even
>
> power-domains = <&rpmhpd RPMHPD_MX>,
> <&rpmhpd RPMHPD_CX>;
> power-domain-names = "mx",
> "cx";
>
> Konrad's suggestion to me was that MXA should have a vote in my CSIPHY
> series I think he and Jagadeesh discussed it but I'm not sure if they
> _concluded_ what was the right thing to do.
>
> Right now I'm representing the dependency. MXA is always on ... and
> there's nothing to do voting for it @ MX ?
>
The clock controller drivers only request the minimum operating level
for the power domains. Since the cx and mx rails are already at the
minimum operating level when APPS is active, explicit voting for these
power domains is not required from camcc.
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH 0/7] soc: aspeed: Add AST2600 eSPI controller support
From: Shulzhenko, Oleksandr @ 2026-05-12 8:45 UTC (permalink / raw)
To: YH Chung, Arnd Bergmann, Andrew Jeffery, Conor Dooley
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Ryan Chen, Philipp Zabel, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org, maciej.lawniczak@intel.com, Mark Brown
In-Reply-To: <KL1PR0601MB4276AB799EC03BB00C4C0E5490392@KL1PR0601MB4276.apcprd06.prod.outlook.com>
On 5/12/2026 9:08 AM, YH Chung wrote:
> Hi Shulzhenko,
>
> Thanks for the follow-up.
>
>> Integrating this driver into the SPI subsystem may allow reusing some existing
>> definitions, e.g.|spi_controller|,|spi_message|, and perhaps parts related to
>> single/dual/quad I/O handling. At the same time, parts such as the Flash channel
>> (included in the current series), and OOB / Virtual Wire support (I would expect
>> to come later), appear to be specific to the Intel eSPI protocol. Modeling all of
>> that as just another SPI IP driver may introduce some awkward layering and
>> overhead.
> Agreed. eSPI introduces two additional pins, RESET# and ALERT#, beyond the
> standard SPI signals. More importantly, eSPI functionality is described
> primarily in terms of four logical channels, rather than generic low-level
> bus signaling or pure data transfers.
>
>> Also, the current series already seems to separate common eSPI logic from
>> AST2600-specific pieces, assuming that 2700 driver is also coming at some point.
>>
>> This makes me wonder whether a dedicated eSPI layer/subsystem could be a
>> better fit — either under the SPI or as something separate (but not SoC driver).
>>
>> Given my limited experience with SPI/eSPI, could you help clarify a few points for
>> me (and probably others as well)?
>>
>> * How much of the SPI subsystem can be reused for this implementation,
>> both for the current patchset and for likely future extensions?
> I believe only a limited portion of the SPI subsystem can be reused. Some
> generic framework elements, such as controller registration and basic
> scaffolding, may be useful initially. But this reuse appears to be mostly
> mechanical rather than semantic. Once eSPI-specific features like Flash
> channels, OOB messaging, and Virtual Wire semantics are involved, the SPI
> transaction model does not seem to map very naturally.
>
>> * Are there any pitfalls or abstraction mismatches in trying to reuse
>> the SPI core here?
> Our main concern is an abstraction mismatch. SPI is designed as a generic
> peripheral bus, while eSPI is more of a system-management interface with
> explicit host-BMC-specific semantics. Reusing the SPI core would likely
> require treating eSPI packets as generic bus-level transfers in the kernel.
>
> However, some eSPI transactions and protocol handling, such as LPC bridge
> accesses, are performed autonomously by the hardware rather than being fully
> driven as low-level bus operations by the driver. This makes the eSPI driver
> somewhat different from a conventional serial bus controller driver
> maintained under the SPI core.
>
Hi YH,
My main concern is trying to understand whether it is completely
impossible (or introduces too much effort that we'd better not to take)
integrating this to SPI subsystem.
From your reply I understand there are two potential blockers:
a) Treating eSPI transfers as bus-level transfers (meaning that it will
be necessary probably making separate driver for OOB/VW/Flash channels
as they essentially use eSPI as a transport);
b) Some logic being done by the hardware (i.e. LPC bridge).
Please confirm my understanding:
(a) is feasible, but requires many effort to re-define architecture
(b) If something is done by the hardware - what is the driver impact? I
recall eDAF use case when the driver wasn't involved at all - and flash
access was fully done by the hardware (unless the controller is
configured to handle it in SW mode).
P.S. I guess we can talk about host-BMC communication only when talking
about hardware-dependent stuff (i.e. ast2600-espi files). eSPI core
should be (it seems to be already is) at least BMC agnostic and this is
the reason not having it under SOC/aspeed (ast2600-espi.* may stay here
though).
^ permalink raw reply
* Re: [PATCH v4 03/15] clk: scmi: Use new determine_rate clock operation
From: Sudeep Holla @ 2026-05-12 8:43 UTC (permalink / raw)
To: Cristian Marussi, Michael Turquette, Stephen Boyd
Cc: linux-kernel, linux-arm-kernel, arm-scmi, linux-clk,
linux-renesas-soc, philip.radford, james.quinlan, f.fainelli,
vincent.guittot, etienne.carriere, peng.fan, michal.simek,
geert+renesas, kuninori.morimoto.gx, marek.vasut+renesas,
Brian Masney
In-Reply-To: <20260508153300.2224715-4-cristian.marussi@arm.com>
On Fri, May 08, 2026 at 04:32:48PM +0100, Cristian Marussi wrote:
> Use the Clock protocol layer determine_rate logic to calculate the closest
> rate that can be supported by a specific clock.
>
> No functional change.
>
Hi Stephen/Mike,
I have potentially queued this and 5/15 to take it via Arm SoC unless you
have any objections. It is mainly simplifying the SCMI clock driver.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Thomas Zimmermann @ 2026-05-12 8:24 UTC (permalink / raw)
To: Joey Lu, zhengxingda, maarten.lankhorst, mripard, airlied, simona,
robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260511075142.54752-3-a0987203069@gmail.com>
Hi,
instead of this if-else branchery, I strongly recommend to add a new
file with a new mode-setting pipeline for the new chipset. You can
share existing helpers where possible, and implement variants where
chips differ. It's a bit more code, but will be a lot easier to
maintain in the future.
See ast and mgag200 for example. Both drivers support various revisions
of their chipset, where each rev has its oddities.
Best regards
Thomas
Am 11.05.26 um 09:51 schrieb Joey Lu:
> The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltra Lite display
> controller, which is a previous generation of the DC8000 series. While
> the general register layout is similar to the DC8000, there are several
> key differences that require per-variant handling in the driver.
>
> Add a vs_dc_info platform data structure (in vs_hwdb.h) to describe
> per-IP-variant capabilities, and use it throughout the driver to select
> the correct code paths at runtime.
>
> Key differences between DC8000 and DCUltra Lite handled:
>
> 1. No chip identity registers (0x0020-0x0030): DCUltra Lite uses static
> platform data instead of reading model/revision/customer_id from HW.
>
> 2. No CONFIG_EX commit mechanism: DC8000 uses registers at 0x1CC0
> (FB_CONFIG_EX), 0x24D8 (FB_TOP_LEFT), 0x24E0 (FB_BOTTOM_RIGHT),
> 0x2510 (FB_BLEND_CONFIG), 0x2518 (PANEL_CONFIG_EX). DCUltra Lite
> omits all of these and instead uses enable/reset bits in FB_CONFIG
> (bit 0 = enable, bit 4 = reset) for direct framebuffer updates.
>
> 3. No PANEL_START register (0x1CCC): DCUltra Lite panel output starts
> when PANEL_CONFIG.RUNNING is set; no separate multi-display sync
> start register is needed.
>
> 4. Different IRQ registers: DCUltra Lite uses 0x147C (IRQ_STA) /
> 0x1480 (IRQ_EN); DC8000 uses 0x0010 (IRQ_ACK) / 0x0014 (IRQ_EN).
>
> 5. Different clock/reset topology: DCUltra Lite requires only "core"
> (bus gate) and "pix0" (pixel divider) clocks with no reset lines
> managed by the driver. DC8000 needs core/axi/ahb clocks and three
> resets.
>
> 6. Single output only: DCUltra Lite has one display output; per-output
> index logic is still in place but display_count is fixed at 1.
>
> 7. Reduced register space: max_register is 0x2000 vs DC8000's 0x2544.
>
> Add the "nuvoton,ma35d1-dcu" compatible string to the OF match table,
> extend Kconfig to allow building on ARCH_MA35 platforms, and expose
> vs_formats_no_yuv444 as the default format table for DCUltra Lite
> (YUV444 blending is a DC8000-only feature).
>
> All changes have been tested on Nuvoton MA35D1 hardware and are
> functioning correctly.
>
> Signed-off-by: Joey Lu <a0987203069@gmail.com>
> ---
> drivers/gpu/drm/verisilicon/Kconfig | 2 +-
> drivers/gpu/drm/verisilicon/vs_bridge.c | 28 ++--
> drivers/gpu/drm/verisilicon/vs_crtc.c | 13 +-
> drivers/gpu/drm/verisilicon/vs_dc.c | 129 ++++++++++++------
> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
> drivers/gpu/drm/verisilicon/vs_drm.c | 16 ++-
> drivers/gpu/drm/verisilicon/vs_hwdb.c | 2 +-
> drivers/gpu/drm/verisilicon/vs_hwdb.h | 25 ++++
> .../gpu/drm/verisilicon/vs_primary_plane.c | 43 +++---
> .../drm/verisilicon/vs_primary_plane_regs.h | 2 +
> 10 files changed, 187 insertions(+), 74 deletions(-)
>
> diff --git a/drivers/gpu/drm/verisilicon/Kconfig b/drivers/gpu/drm/verisilicon/Kconfig
> index 7cce86ec8603..295d246eb4b4 100644
> --- a/drivers/gpu/drm/verisilicon/Kconfig
> +++ b/drivers/gpu/drm/verisilicon/Kconfig
> @@ -2,7 +2,7 @@
> config DRM_VERISILICON_DC
> tristate "DRM Support for Verisilicon DC-series display controllers"
> depends on DRM && COMMON_CLK
> - depends on RISCV || COMPILE_TEST
> + depends on RISCV || ARCH_MA35 || COMPILE_TEST
> select DRM_BRIDGE_CONNECTOR
> select DRM_CLIENT_SELECTION
> select DRM_DISPLAY_HELPER
> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c b/drivers/gpu/drm/verisilicon/vs_bridge.c
> index 7a93049368db..225af322de32 100644
> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
> @@ -164,13 +164,16 @@ static void vs_bridge_enable_common(struct vs_crtc *crtc,
> 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);
> + if (dc->info->has_config_ex) {
> + 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);
> + }
> }
>
> static void vs_bridge_atomic_enable_dpi(struct drm_bridge *bridge,
> @@ -228,14 +231,17 @@ 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);
> + if (dc->info->has_config_ex) {
> + 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(crtc->id),
> + VSDC_DISP_PANEL_CONFIG_EX_COMMIT);
> + }
> }
>
> 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 9080344398ca..2f3e6d41c657 100644
> --- a/drivers/gpu/drm/verisilicon/vs_crtc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_crtc.c
> @@ -18,6 +18,7 @@
> #include "vs_dc.h"
> #include "vs_dc_top_regs.h"
> #include "vs_drm.h"
> +#include "vs_hwdb.h"
> #include "vs_plane.h"
>
> static void vs_crtc_atomic_disable(struct drm_crtc *crtc,
> @@ -132,7 +133,11 @@ 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));
> + if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE)
> + regmap_write(dc->regs, VSDC_DISP_IRQ_EN, BIT(0));
> + else
> + regmap_set_bits(dc->regs, VSDC_TOP_IRQ_EN,
> + VSDC_TOP_IRQ_VSYNC(vcrtc->id));
>
> return 0;
> }
> @@ -142,7 +147,11 @@ 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));
> + if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE)
> + regmap_write(dc->regs, VSDC_DISP_IRQ_EN, 0);
> + else
> + regmap_clear_bits(dc->regs, VSDC_TOP_IRQ_EN,
> + VSDC_TOP_IRQ_VSYNC(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..82a6a26f6d81 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
> @@ -9,21 +9,45 @@
> #include <linux/of_graph.h>
>
> #include "vs_crtc.h"
> +#include "vs_crtc_regs.h"
> #include "vs_dc.h"
> #include "vs_dc_top_regs.h"
> #include "vs_drm.h"
> #include "vs_hwdb.h"
>
> -static const struct regmap_config vs_dc_regmap_cfg = {
> +static const struct regmap_config vs_dc8000_regmap_cfg = {
> .reg_bits = 32,
> .val_bits = 32,
> .reg_stride = sizeof(u32),
> - /* VSDC_OVL_CONFIG_EX(1) */
> .max_register = 0x2544,
> };
>
> +static const struct regmap_config vs_dcultra_lite_regmap_cfg = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = sizeof(u32),
> + .max_register = 0x2000,
> +};
> +
> +static const struct vs_dc_info vs_dc8000_info = {
> + .family = VS_DC_FAMILY_DC8000,
> + .has_chip_id = true,
> + .has_config_ex = true,
> + .regmap_cfg = &vs_dc8000_regmap_cfg,
> +};
> +
> +static const struct vs_dc_info vs_dcultra_lite_info = {
> + .family = VS_DC_FAMILY_DCULTRA_LITE,
> + .display_count = 1,
> + .has_chip_id = false,
> + .has_config_ex = false,
> + .regmap_cfg = &vs_dcultra_lite_regmap_cfg,
> + .formats = &vs_formats_no_yuv444,
> +};
> +
> static const struct of_device_id vs_dc_driver_dt_match[] = {
> - { .compatible = "verisilicon,dc" },
> + { .compatible = "verisilicon,dc", .data = &vs_dc8000_info },
> + { .compatible = "nuvoton,ma35d1-dcu", .data = &vs_dcultra_lite_info },
> {},
> };
> MODULE_DEVICE_TABLE(of, vs_dc_driver_dt_match);
> @@ -33,6 +57,13 @@ static irqreturn_t vs_dc_irq_handler(int irq, void *private)
> struct vs_dc *dc = private;
> u32 irqs;
>
> + if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE) {
> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &irqs);
> + if (irqs & BIT(0))
> + vs_drm_handle_irq(dc, VSDC_TOP_IRQ_VSYNC(0));
> + return IRQ_HANDLED;
> + }
> +
> regmap_read(dc->regs, VSDC_TOP_IRQ_ACK, &irqs);
>
> vs_drm_handle_irq(dc, irqs);
> @@ -43,6 +74,7 @@ static irqreturn_t vs_dc_irq_handler(int irq, void *private)
> static int vs_dc_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> + const struct vs_dc_info *info;
> struct vs_dc *dc;
> void __iomem *regs;
> unsigned int port_count, i;
> @@ -55,6 +87,10 @@ static int vs_dc_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> + info = of_device_get_match_data(dev);
> + if (!info)
> + return -ENODEV;
> +
> port_count = of_graph_get_port_count(dev->of_node);
> if (!port_count) {
> dev_err(dev, "can't find DC downstream ports\n");
> @@ -75,15 +111,31 @@ static int vs_dc_probe(struct platform_device *pdev)
> if (!dc)
> return -ENOMEM;
>
> - dc->rsts[0].id = "core";
> - dc->rsts[1].id = "axi";
> - dc->rsts[2].id = "ahb";
> + dc->info = info;
>
> - ret = devm_reset_control_bulk_get_optional_shared(dev, VSDC_RESET_COUNT,
> - dc->rsts);
> - if (ret) {
> - dev_err(dev, "can't get reset lines\n");
> - return ret;
> + if (info->family == VS_DC_FAMILY_DC8000) {
> + dc->rsts[0].id = "core";
> + dc->rsts[1].id = "axi";
> + dc->rsts[2].id = "ahb";
> +
> + ret = devm_reset_control_bulk_get_optional_shared(dev,
> + VSDC_RESET_COUNT, dc->rsts);
> + if (ret) {
> + dev_err(dev, "can't get reset lines\n");
> + return ret;
> + }
> +
> + dc->axi_clk = devm_clk_get_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");
> + if (IS_ERR(dc->ahb_clk)) {
> + dev_err(dev, "can't get ahb clock\n");
> + return PTR_ERR(dc->ahb_clk);
> + }
> }
>
> dc->core_clk = devm_clk_get_enabled(dev, "core");
> @@ -92,28 +144,18 @@ static int vs_dc_probe(struct platform_device *pdev)
> return PTR_ERR(dc->core_clk);
> }
>
> - dc->axi_clk = devm_clk_get_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");
> - if (IS_ERR(dc->ahb_clk)) {
> - dev_err(dev, "can't get ahb clock\n");
> - return PTR_ERR(dc->ahb_clk);
> - }
> -
> irq = platform_get_irq(pdev, 0);
> if (irq < 0) {
> dev_err(dev, "can't get irq\n");
> return irq;
> }
>
> - ret = reset_control_bulk_deassert(VSDC_RESET_COUNT, dc->rsts);
> - if (ret) {
> - dev_err(dev, "can't deassert reset lines\n");
> - return ret;
> + if (info->family == VS_DC_FAMILY_DC8000) {
> + ret = reset_control_bulk_deassert(VSDC_RESET_COUNT, dc->rsts);
> + if (ret) {
> + dev_err(dev, "can't deassert reset lines\n");
> + return ret;
> + }
> }
>
> regs = devm_platform_ioremap_resource(pdev, 0);
> @@ -123,23 +165,30 @@ static int vs_dc_probe(struct platform_device *pdev)
> goto err_rst_assert;
> }
>
> - dc->regs = devm_regmap_init_mmio(dev, regs, &vs_dc_regmap_cfg);
> + dc->regs = devm_regmap_init_mmio(dev, regs, info->regmap_cfg);
> if (IS_ERR(dc->regs)) {
> ret = PTR_ERR(dc->regs);
> goto err_rst_assert;
> }
>
> - ret = vs_fill_chip_identity(dc->regs, &dc->identity);
> - if (ret)
> - goto err_rst_assert;
> + if (info->has_chip_id) {
> + ret = vs_fill_chip_identity(dc->regs, &dc->identity);
> + if (ret)
> + goto err_rst_assert;
>
> - dev_info(dev, "Found DC%x rev %x customer %x\n", dc->identity.model,
> - dc->identity.revision, dc->identity.customer_id);
> + dev_info(dev, "Found DC%x rev %x customer %x\n",
> + dc->identity.model, dc->identity.revision,
> + dc->identity.customer_id);
>
> - if (port_count > dc->identity.display_count) {
> - dev_err(dev, "too many downstream ports than HW capability\n");
> - ret = -EINVAL;
> - goto err_rst_assert;
> + if (port_count > dc->identity.display_count) {
> + dev_err(dev, "too many downstream ports than HW capability\n");
> + ret = -EINVAL;
> + goto err_rst_assert;
> + }
> + } else {
> + /* Fill identity from platform data */
> + dc->identity.display_count = info->display_count;
> + dc->identity.formats = info->formats;
> }
>
> for (i = 0; i < dc->identity.display_count; i++) {
> @@ -168,7 +217,8 @@ static int vs_dc_probe(struct platform_device *pdev)
> return 0;
>
> err_rst_assert:
> - reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
> + if (info->family == VS_DC_FAMILY_DC8000)
> + reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
> return ret;
> }
>
> @@ -180,7 +230,8 @@ static void vs_dc_remove(struct platform_device *pdev)
>
> dev_set_drvdata(&pdev->dev, NULL);
>
> - reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
> + if (dc->info->family == VS_DC_FAMILY_DC8000)
> + reset_control_bulk_assert(VSDC_RESET_COUNT, dc->rsts);
> }
>
> static void vs_dc_shutdown(struct platform_device *pdev)
> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h b/drivers/gpu/drm/verisilicon/vs_dc.h
> index ed1016f18758..f0613519af37 100644
> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
> @@ -31,6 +31,7 @@ struct vs_dc {
> struct clk *pix_clk[VSDC_MAX_OUTPUTS];
> struct reset_control_bulk_data rsts[VSDC_RESET_COUNT];
>
> + const struct vs_dc_info *info;
> struct vs_drm_dev *drm_dev;
> struct vs_chip_identity identity;
> };
> diff --git a/drivers/gpu/drm/verisilicon/vs_drm.c b/drivers/gpu/drm/verisilicon/vs_drm.c
> index fd259d53f49f..ff0fc6673006 100644
> --- a/drivers/gpu/drm/verisilicon/vs_drm.c
> +++ b/drivers/gpu/drm/verisilicon/vs_drm.c
> @@ -27,6 +27,7 @@
> #include "vs_dc.h"
> #include "vs_dc_top_regs.h"
> #include "vs_drm.h"
> +#include "vs_hwdb.h"
>
> #define DRIVER_NAME "verisilicon"
> #define DRIVER_DESC "Verisilicon DC-series display controller driver"
> @@ -72,12 +73,19 @@ static struct drm_mode_config_helper_funcs vs_mode_config_helper_funcs = {
> .atomic_commit_tail = drm_atomic_helper_commit_tail,
> };
>
> -static void vs_mode_config_init(struct drm_device *drm)
> +static void vs_mode_config_init(struct drm_device *drm, struct vs_dc *dc)
> {
> drm->mode_config.min_width = 0;
> drm->mode_config.min_height = 0;
> - drm->mode_config.max_width = 8192;
> - drm->mode_config.max_height = 8192;
> +
> + if (dc->info->family == VS_DC_FAMILY_DCULTRA_LITE) {
> + drm->mode_config.max_width = 1920;
> + drm->mode_config.max_height = 1080;
> + } else {
> + drm->mode_config.max_width = 8192;
> + drm->mode_config.max_height = 8192;
> + }
> +
> drm->mode_config.funcs = &vs_mode_config_funcs;
> drm->mode_config.helper_private = &vs_mode_config_helper_funcs;
> }
> @@ -125,7 +133,7 @@ int vs_drm_initialize(struct vs_dc *dc, struct platform_device *pdev)
> if (ret)
> return ret;
>
> - vs_mode_config_init(drm);
> + vs_mode_config_init(drm, dc);
>
> /* Enable connectors polling */
> drm_kms_helper_poll_init(drm);
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> index 09336af0900a..39402d75d841 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
> @@ -78,7 +78,7 @@ static const u32 vs_formats_array_with_yuv444[] = {
> /* TODO: non-RGB formats */
> };
>
> -static const struct vs_formats vs_formats_no_yuv444 = {
> +const struct vs_formats vs_formats_no_yuv444 = {
> .array = vs_formats_array_no_yuv444,
> .num = ARRAY_SIZE(vs_formats_array_no_yuv444)
> };
> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h b/drivers/gpu/drm/verisilicon/vs_hwdb.h
> index 92192e4fa086..655cf93ca3aa 100644
> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
> @@ -14,6 +14,29 @@ struct vs_formats {
> unsigned int num;
> };
>
> +enum vs_dc_family {
> + VS_DC_FAMILY_DC8000,
> + VS_DC_FAMILY_DCULTRA_LITE,
> +};
> +
> +/**
> + * struct vs_dc_info - per-SoC DC platform data
> + * @family: DC IP family (DC8000, DCUltra Lite, etc.)
> + * @display_count: number of display outputs (0 = auto-detect from DT/HW)
> + * @has_chip_id: whether chip identity registers exist
> + * @has_config_ex: whether CONFIG_EX commit mechanism exists
> + * @regmap_cfg: regmap configuration for this variant
> + * @formats: supported pixel formats (NULL = auto-detect from chip ID)
> + */
> +struct vs_dc_info {
> + enum vs_dc_family family;
> + u32 display_count;
> + bool has_chip_id;
> + bool has_config_ex;
> + const struct regmap_config *regmap_cfg;
> + const struct vs_formats *formats;
> +};
> +
> struct vs_chip_identity {
> u32 model;
> u32 revision;
> @@ -23,6 +46,8 @@ struct vs_chip_identity {
> const struct vs_formats *formats;
> };
>
> +extern const struct vs_formats vs_formats_no_yuv444;
> +
> int vs_fill_chip_identity(struct regmap *regs,
> struct vs_chip_identity *ident);
>
> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> index 1f2be41ae496..197d5d683e22 100644
> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
> @@ -55,8 +55,9 @@ static int vs_primary_plane_atomic_check(struct drm_plane *plane,
>
> 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);
> + if (dc->info->has_config_ex)
> + 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,
> @@ -69,11 +70,13 @@ 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));
> + if (dc->info->has_config_ex) {
> + 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);
> }
> @@ -88,8 +91,9 @@ 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);
> + if (dc->info->has_config_ex)
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
> + VSDC_FB_CONFIG_EX_FB_EN);
>
> vs_primary_plane_commit(dc, output);
> }
> @@ -126,6 +130,11 @@ static void vs_primary_plane_atomic_update(struct drm_plane *plane,
> VSDC_FB_CONFIG_UV_SWIZZLE_EN,
> vs_state->format.uv_swizzle);
>
> + /* DCUltra Lite requires explicit enable/reset bits in FB_CONFIG */
> + if (!dc->info->has_config_ex)
> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
> + VSDC_FB_CONFIG_ENABLE | VSDC_FB_CONFIG_RESET);
> +
> dma_addr = vs_fb_get_dma_addr(fb, &state->src);
>
> regmap_write(dc->regs, VSDC_FB_ADDRESS(output),
> @@ -133,16 +142,18 @@ 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);
> + if (dc->info->has_config_ex) {
> + 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_primary_plane_commit(dc, output);
> }
> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> index cbb125c46b39..288064760b48 100644
> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
> @@ -16,6 +16,8 @@
> #define VSDC_FB_STRIDE(n) (0x1408 + 0x4 * (n))
>
> #define VSDC_FB_CONFIG(n) (0x1518 + 0x4 * (n))
> +#define VSDC_FB_CONFIG_ENABLE BIT(0)
> +#define VSDC_FB_CONFIG_RESET BIT(4)
> #define VSDC_FB_CONFIG_CLEAR_EN BIT(8)
> #define VSDC_FB_CONFIG_ROT_MASK GENMASK(13, 11)
> #define VSDC_FB_CONFIG_ROT(v) ((v) << 11)
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Icenowy Zheng @ 2026-05-12 8:11 UTC (permalink / raw)
To: Joey Lu, 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: <de35406e-874d-4bdd-be7f-3d74dc37b13f@gmail.com>
在 2026-05-12二的 15:45 +0800，Joey Lu写道：
>
> On 5/11/2026 5:47 PM, Icenowy Zheng wrote:
> > 在 2026-05-11一的 15:51 +0800，Joey Lu写道：
> > > The Nuvoton MA35D1 SoC integrates a Verisilicon DCUltra Lite
> > > display
> > > controller, which is a previous generation of the DC8000 series.
> > > While
> > > the general register layout is similar to the DC8000, there are
> > > several
> > > key differences that require per-variant handling in the driver.
> > >
> > > Add a vs_dc_info platform data structure (in vs_hwdb.h) to
> > > describe
> > > per-IP-variant capabilities, and use it throughout the driver to
> > > select
> > > the correct code paths at runtime.
> > >
> > > Key differences between DC8000 and DCUltra Lite handled:
> > What the driver supports now is DC8200, DC8000 have the following
> > point
> > 1~4 the same with DCUltraLite (different to DC8200).
> Understood. I'll rename all `vs_dc8000_*` identifiers to
> `vs_dc8200_*` in v2. The commit message will also be corrected to say
> that points 1~4 are differences from DC8200, not DC8000.
> > > 1. No chip identity registers (0x0020-0x0030): DCUltra Lite uses
> > > static
> > > platform data instead of reading model/revision/customer_id
> > > from
> > > HW.
> > My test shows that revision and customer_id is correctly present,
> > only
> > model is 0 -- I think this can be also considered as a valid model
> > value because the IP name has also no model number.
> >
> > The revision number is 0x5560 and customer id is 0x305 .
> Thank you for testing. I'll drop the `has_chip_id` flag
> entirely. In v2, `vs_fill_chip_identity()` will be called for all
> variants. A new entry will be added to `vs_chip_identities[]` in
> vs_hwdb.c with model=0x0, revision=0x5560, customer_id=0x305,
> display_count=1, and `vs_formats_no_yuv444`.
> e.g. verisilicon-dc 40260000.display: Found DC0 rev 5560 customer 305
> >
> > > 2. No CONFIG_EX commit mechanism: DC8000 uses registers at 0x1CC0
> > > (FB_CONFIG_EX), 0x24D8 (FB_TOP_LEFT), 0x24E0
> > > (FB_BOTTOM_RIGHT),
> > > 0x2510 (FB_BLEND_CONFIG), 0x2518 (PANEL_CONFIG_EX). DCUltra
> > > Lite
> > > omits all of these and instead uses enable/reset bits in
> > > FB_CONFIG
> > > (bit 0 = enable, bit 4 = reset) for direct framebuffer
> > > updates.
> > >
> > > 3. No PANEL_START register (0x1CCC): DCUltra Lite panel output
> > > starts
> > > when PANEL_CONFIG.RUNNING is set; no separate multi-display
> > > sync
> > > start register is needed.
> > >
> > > 4. Different IRQ registers: DCUltra Lite uses 0x147C (IRQ_STA) /
> > > 0x1480 (IRQ_EN); DC8000 uses 0x0010 (IRQ_ACK) / 0x0014
> > > (IRQ_EN).
> > >
> > > 5. Different clock/reset topology: DCUltra Lite requires only
> > > "core"
> > > (bus gate) and "pix0" (pixel divider) clocks with no reset
> > > lines
> > > managed by the driver. DC8000 needs core/axi/ahb clocks and
> > > three
> > > resets.
> > It's possible that your SoC integration combines core clock gate
> > with
> > bus clock gate instead of bus clock gate not existing.
> Agreed. In v2 I'll remove the family-gated clock handling and
> instead use `devm_clk_get_optional_enabled()` for the axi and ahb
> clocks, so they are simply skipped if not present in DT. Resets are
> already optional. This keeps the probe path uniform and handles any
> SoC-specific clock combinations naturally.
Maybe this could be splitted as another patch, to make single commits
smaller.
> > > 6. Single output only: DCUltra Lite has one display output; per-
> > > output
> > > index logic is still in place but display_count is fixed at
> > > 1.
> > >
> > > 7. Reduced register space: max_register is 0x2000 vs DC8000's
> > > 0x2544.
> > >
> > > Add the "nuvoton,ma35d1-dcu" compatible string to the OF match
> > > table,
> > > extend Kconfig to allow building on ARCH_MA35 platforms, and
> > > expose
> > > vs_formats_no_yuv444 as the default format table for DCUltra Lite
> > > (YUV444 blending is a DC8000-only feature).
> > >
> > > All changes have been tested on Nuvoton MA35D1 hardware and are
> > > functioning correctly.
> > >
> > > Signed-off-by: Joey Lu <a0987203069@gmail.com>
> > > ---
> > > drivers/gpu/drm/verisilicon/Kconfig | 2 +-
> > > drivers/gpu/drm/verisilicon/vs_bridge.c | 28 ++--
> > > drivers/gpu/drm/verisilicon/vs_crtc.c | 13 +-
> > > drivers/gpu/drm/verisilicon/vs_dc.c | 129
> > > ++++++++++++----
> > > --
> > > drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
> > > drivers/gpu/drm/verisilicon/vs_drm.c | 16 ++-
> > > drivers/gpu/drm/verisilicon/vs_hwdb.c | 2 +-
> > > drivers/gpu/drm/verisilicon/vs_hwdb.h | 25 ++++
> > > .../gpu/drm/verisilicon/vs_primary_plane.c | 43 +++---
> > > .../drm/verisilicon/vs_primary_plane_regs.h | 2 +
> > > 10 files changed, 187 insertions(+), 74 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/verisilicon/Kconfig
> > > b/drivers/gpu/drm/verisilicon/Kconfig
> > > index 7cce86ec8603..295d246eb4b4 100644
> > > --- a/drivers/gpu/drm/verisilicon/Kconfig
> > > +++ b/drivers/gpu/drm/verisilicon/Kconfig
> > > @@ -2,7 +2,7 @@
> > > config DRM_VERISILICON_DC
> > > tristate "DRM Support for Verisilicon DC-series display
> > > controllers"
> > > depends on DRM && COMMON_CLK
> > > - depends on RISCV || COMPILE_TEST
> > > + depends on RISCV || ARCH_MA35 || COMPILE_TEST
> > > select DRM_BRIDGE_CONNECTOR
> > > select DRM_CLIENT_SELECTION
> > > select DRM_DISPLAY_HELPER
> > > diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > b/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > index 7a93049368db..225af322de32 100644
> > > --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
> > > @@ -164,13 +164,16 @@ static void vs_bridge_enable_common(struct
> > > vs_crtc *crtc,
> > > 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);
> > > + if (dc->info->has_config_ex) {
> > > + 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(ou
> > > tput
> > > ));
> > > +
> > > + regmap_set_bits(dc->regs,
> > > VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
> > > + VSDC_DISP_PANEL_CONFIG_EX_COMMIT
> > > );
> > Should the commit operation happen on DC8000/DCUltraLite too? (By
> > writing to DcregFrameBufferConfig0.VALID).
> >
> > Many registers written has "Note: This field is double buffered" in
> > the
> > DCUltraLite documentation.
> >
> > I suggest create a static function for commit -- write to the
> > corresponding commit bit on DC8200, and write to
> > DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite.
> [a] There is no commit operation for DCUltra Lite.
> I'll not add a `VSDC_FB_CONFIG_VALID` macro. VALID (BIT(3)) is a
> hardware-managed double-buffer status bit: hardware writes 1=PENDING
> when a new register set is ready and clears to 0=WORKING after the
> VBLANK copy. Software must never write it, and there is no polling
> use
It seems to be writable and controls whether register buffering is
enabled, see [1].
The description of this bit in MA35D1 TRM says "This ensures a frame
will always start with a valid working set if this register is
programmed last, which reduces the need for SW to wait for the start of
a VBLANK signal in order to ensure all states are loaded before the
next VBLANK", which indicates some kind of "committing write", although
the code at [1] seems to indicate that double buffering is only enabled
when bit is cleared.
Anyway this bit should be programmable, and "Software must never write
it" contradicts with the MA35D1 TRM.
Thanks,
Icenowy
[1]
https://github.com/rockos-riscv/rockos-kernel/blob/rockos-v6.6.y/drivers/gpu/drm/eswin/es_dc_hw.c#L993
> case in the driver that requires a named constant. For non-config_ex
> variants, `vs_primary_plane_commit()` performs no commit operation —
> `VSDC_FB_CONFIG_ENABLE` (OUTPUT, BIT(0)) is set in
> `vs_crtc_atomic_enable()` and `VSDC_FB_CONFIG_RESET` (BIT(4)) is
> set/cleared in the bridge enable/disable paths.
========= 8< ==========
^ permalink raw reply
* Re: [PATCH] ARM: OMAP2+: Make OMAP4 finish_suspend callback CFI-safe
From: Andreas Kemnade @ 2026-05-12 8:02 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Mithil Bavishi, Aaro Koskinen, Kevin Hilman, Roger Quadros,
Tony Lindgren, Russell King, Sami Tolvanen, Kees Cook,
linux-arm-kernel, linux-omap, llvm, linux-kernel
In-Reply-To: <20260512073442.GA570003@ax162>
On Tue, 12 May 2026 16:34:42 +0900
Nathan Chancellor <nathan@kernel.org> wrote:
> On Tue, May 12, 2026 at 12:23:41AM -0400, Mithil Bavishi wrote:
> > With CONFIG_CFI enabled, OMAP4 can trap in omap4_enter_lowpower()
> > because omap_pm_ops.finish_suspend points directly to the assembly
> > routine omap4_finish_suspend, which lacks the expected KCFI type
> > metadata.
>
> It sounds like omap4_finish_suspend() should be defined with
> SYM_TYPED_FUNC_START then? Is that the case for all of the other
> functions that are added to omap_pm_ops?
>
omap_cpu_resume: the address is written to some cpu register and
on that way casted to u32. So therefore does not trigger CFI.
Same for secondary_startup which is also assembler code.
scu_prepare is C.
DO you have a pointer to any documentation:
:~/linux$ grep -R SYM_TYPED_FUNC_START Documentation/
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: display: verisilicon,dc: generalize for DCUltra Lite variant
From: Joey Lu @ 2026-05-12 8:02 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: <cb69490652409eb4f07b3ee642d478e1b2e28c5b.camel@iscas.ac.cn>
On 5/11/2026 5:59 PM, Icenowy Zheng wrote:
> 在 2026-05-11一的 15:51 +0800，Joey Lu写道：
>> Extend the verisilicon,dc base schema to accommodate the Nuvoton
>> MA35D1
>> DCUltra Lite (a previous generation of the DC8000 series) which has a
>> different clock topology, no reset control, and a single output.
>>
>> - Replace the fixed clock/reset item lists with minItems/maxItems
>> ranges
>> so sub-schemas can enforce variant-specific constraints
>> - Add a 'port' property (single-port alias) alongside the existing
>> 'ports'
>> for single-output variants
>> - Remove the mandatory 'ports' requirement from the base schema; sub-
>> schemas
>> shall enforce their own port topology
>> - Add a 'select' stanza so the validator matches any node whose
>> compatible
>> contains a known Verisilicon DC string, including SoC-specific glue
>> - Relax additionalProperties to allow unevaluatedProperties
>> enforcement in
>> sub-schemas
>> - Fix a minor whitespace issue in the port@0 description
>>
>> Add nuvoton,ma35d1-dcu.yaml as a sub-schema for the Nuvoton MA35D1
>> DCUltra
>> Lite display controller:
>>
>> The Nuvoton MA35D1 integrates the Verisilicon DCUltra Lite display
>> controller. It is a single-output display controller with a 32-bit
>> RGB (DPI) interface. Unlike the DC8000, it does not have discoverable
>> chip identity registers, does not support the CONFIG_EX commit path,
>> and uses dedicated IRQ status/enable registers at offsets
>> 0x147C/0x1480.
>> The clock topology uses two clocks (bus gate and pixel divider) and
>> does not require explicit reset control from the driver.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> .../bindings/display/nuvoton,ma35d1-dcu.yaml | 94
>> +++++++++++++++++++
>> .../bindings/display/verisilicon,dc.yaml | 64 +++++++------
>> 2 files changed, 131 insertions(+), 27 deletions(-)
>> create mode 100644
>> Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
>>
>> diff --git
>> a/Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
>> b/Documentation/devicetree/bindings/display/nuvoton,ma35d1-dcu.yaml
>> new file mode 100644
>> index 000000000000..9279004ae27c
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/display/nuvoton,ma35d1-
>> dcu.yaml
>> @@ -0,0 +1,94 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/display/nuvoton,ma35d1-dcu.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Nuvoton MA35D1 DCUltra Lite display controller
>> +
>> +maintainers:
>> + - Joey Lu <yclu4@nuvoton.com>
>> +
>> +description:
>> + The Nuvoton MA35D1 integrates the Verisilicon DCUltra Lite display
>> + controller. It is a single-output display controller with a 32-bit
>> + RGB (DPI) interface.
> You'd better write this in verisilicon,dc.yaml with if clauses. See
> Documentation/devicetree/bindings/mmc/snps,dwcmshc-sdhci.yaml for an
> example for a generic IP with different integrations, and how it
> constraints different SoC's integration.
Understood. I'll drop both the separate nuvoton,ma35d1-dcu.yaml
file and the `nuvoton,ma35d1-dcu` compatible string entirely. Since the
chip identity registers are present on the DCUltra Lite (model=0x0,
rev=0x5560, customer=0x305), the MA35D1 DT node will use
`compatible = "verisilicon,dc"` directly. The YAML will use a single
`if/then/else` block in `allOf:` keyed on whether `thead,th1520-dc8200`
is present in the compatible list: the `then` branch enforces DC8200
constraints (5 clocks, 3 resets, `ports` required), and the `else`
branch enforces DCUltra Lite / generic constraints (2 clocks, 1 reset,
`port` required, `ports` forbidden). The Nuvoton MA35D1 example will use
`compatible = "verisilicon,dc"` and fall into the `else` branch.
>> +
>> +select:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - nuvoton,ma35d1-dcu
>> + required:
>> + - compatible
>> +
>> +allOf:
>> + - $ref: http://devicetree.org/schemas/display/verisilicon,dc.yaml#
>> +
>> +properties:
>> + compatible:
>> + const: nuvoton,ma35d1-dcu
>> +
>> + reg:
>> + maxItems: 1
>> + description:
>> + Register range of the DCUltra Lite controller. The address
>> space
>> + is 0x2000 bytes.
> Is it really 0x2000 bytes? The next peripherals in the address space,
> the GC520L 2D GPU, is 0x20000 bytes away from the start of DCU
> registers space.
Good point. The 0x2000 figure is the driver's `max_register`,
not the full hardware block size. I'll remove the description text
claiming "0x2000 bytes" and update the example to use `0x20000` to
match the actual hardware address space.
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + clocks:
>> + items:
>> + - description: Bus clock that gates register access (DCU_GATE)
>> + - description: Pixel clock divider for display timing
>> (DCUP_DIV)
>> +
>> + clock-names:
>> + items:
>> + - const: core
>> + - const: pix0
>> +
>> + resets:
>> + maxItems: 1
>> + description:
>> + Optional reset for the display controller. The driver does not
>> + assert or deassert this reset; it may be used by firmware or
>> + boot loaders to bring the hardware to a clean state.
> Why is there a reset in hardware but not toggled in the software?
The driver will handle the reset in v2. The probe path will call
`devm_reset_control_bulk_get_optional_shared()` unconditionally with all
three names ("core", "axi", "ahb"). Since the MA35D1 DT only provides a
single reset named "core", the "axi" and "ahb" entries will be no-op
handles — optional bulk reset lookup skips absent entries silently.
>> +
>> + port:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description:
>> + Output port to the downstream display device (e.g. RGB panel).
>> + The DCUltra Lite supports a single parallel RGB output.
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - interrupts
>> + - clocks
>> + - clock-names
>> + - port
>> +
>> +unevaluatedProperties: false
>> +
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>> + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
>> +
>> + display@40260000 {
>> + compatible = "nuvoton,ma35d1-dcu";
>> + reg = <0x40260000 0x2000>;
>> + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
>> + clocks = <&clk DCU_GATE>, <&clk DCUP_DIV>;
>> + clock-names = "core", "pix0";
>> + resets = <&sys MA35D1_RESET_DISP>;
>> +
>> + port {
>> + dpi_out: endpoint {
>> + remote-endpoint = <&panel_in>;
>> + };
>> + };
>> + };
>> diff --git
>> a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>> b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>> index 9dc35ab973f2..00884529f8c1 100644
>> --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>> +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>> @@ -9,15 +9,34 @@ title: Verisilicon DC-series display controllers
>> maintainers:
>> - Icenowy Zheng <uwu@icenowy.me>
>>
>> +description:
>> + Verisilicon DC-series display controllers.
>> +
>> +# Select any node whose compatible contains one of the known
>> Verisilicon DC
>> +# or DC-derived compatible strings, including SoC-specific glue
>> variants.
>> +select:
>> + properties:
>> + compatible:
>> + contains:
>> + enum:
>> + - verisilicon,dc
>> + - thead,th1520-dc8200
>> + - nuvoton,ma35d1-dcu
>> + required:
>> + - compatible
>> +
>> properties:
>> $nodename:
>> pattern: "^display@[0-9a-f]+$"
>>
>> compatible:
>> - items:
>> - - enum:
>> - - thead,th1520-dc8200
>> - - const: verisilicon,dc # DC IPs have discoverable ID/revision
>> registers
>> + # Enumerated in full so the schema validator can verify any
>> compatible
>> + # string against this list, including those from child schemas.
>> + contains:
>> + enum:
>> + - verisilicon,dc
>> + - thead,th1520-dc8200
>> + - nuvoton,ma35d1-dcu
>>
>> reg:
>> maxItems: 1
>> @@ -26,32 +45,24 @@ properties:
>> maxItems: 1
>>
>> clocks:
>> - items:
>> - - description: DC Core clock
>> - - description: DMA AXI bus clock
>> - - description: Configuration AHB bus clock
>> - - description: Pixel clock of output 0
>> - - description: Pixel clock of output 1
>> + minItems: 2
>> + maxItems: 5
>>
>> clock-names:
>> - items:
>> - - const: core
>> - - const: axi
>> - - const: ahb
>> - - const: pix0
>> - - const: pix1
>> + minItems: 2
>> + maxItems: 5
>>
>> resets:
>> - items:
>> - - description: DC Core reset
>> - - description: DMA AXI bus reset
>> - - description: Configuration AHB bus reset
>> + minItems: 1
>> + maxItems: 3
>>
>> reset-names:
>> - items:
>> - - const: core
>> - - const: axi
>> - - const: ahb
>> + minItems: 1
>> + maxItems: 3
>> +
>> + port:
>> + $ref: /schemas/graph.yaml#/properties/port
>> + description: Single video output port for single-output
>> variants.
>>
>> ports:
>> $ref: /schemas/graph.yaml#/properties/ports
>> @@ -59,7 +70,7 @@ properties:
>> properties:
>> port@0:
>> $ref: /schemas/graph.yaml#/properties/port
>> - description: The first output channel , endpoint 0 should be
>> + description: The first output channel, endpoint 0 should be
>> used for DPI format output and endpoint 1 should be used
>> for DP format output.
>>
>> @@ -75,9 +86,8 @@ required:
>> - interrupts
>> - clocks
>> - clock-names
>> - - ports
>>
>> -additionalProperties: false
>> +additionalProperties: true
>>
>> examples:
>> - |
^ 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