* [RFC PATCH v2 1/2] Revert "treewide: Fix probing of devices in DT overlays"
From: Saravana Kannan @ 2024-04-09 5:37 UTC (permalink / raw)
To: Herve Codina, Geert Uytterhoeven
Cc: Saravana Kannan, Rob Herring, kernel-team, linux-kernel, imx,
linux-arm-kernel, linux-i2c, devicetree, linux-spi, linux-acpi
In-Reply-To: <20240409053704.428336-1-saravanak@google.com>
This reverts commit 1a50d9403fb90cbe4dea0ec9fd0351d2ecbd8924.
---
drivers/bus/imx-weim.c | 6 ------
drivers/i2c/i2c-core-of.c | 5 -----
drivers/of/dynamic.c | 1 -
drivers/of/platform.c | 5 -----
drivers/spi/spi.c | 5 -----
5 files changed, 22 deletions(-)
diff --git a/drivers/bus/imx-weim.c b/drivers/bus/imx-weim.c
index 837bf9d51c6e..caaf887e0ccc 100644
--- a/drivers/bus/imx-weim.c
+++ b/drivers/bus/imx-weim.c
@@ -331,12 +331,6 @@ static int of_weim_notify(struct notifier_block *nb, unsigned long action,
"Failed to setup timing for '%pOF'\n", rd->dn);
if (!of_node_check_flag(rd->dn, OF_POPULATED)) {
- /*
- * Clear the flag before adding the device so that
- * fw_devlink doesn't skip adding consumers to this
- * device.
- */
- rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE;
if (!of_platform_device_create(rd->dn, NULL, &pdev->dev)) {
dev_err(&pdev->dev,
"Failed to create child device '%pOF'\n",
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index a6c407d36800..a250921bbce0 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -178,11 +178,6 @@ static int of_i2c_notify(struct notifier_block *nb, unsigned long action,
return NOTIFY_OK;
}
- /*
- * Clear the flag before adding the device so that fw_devlink
- * doesn't skip adding consumers to this device.
- */
- rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE;
client = of_i2c_register_device(adap, rd->dn);
if (IS_ERR(client)) {
dev_err(&adap->dev, "failed to create client for '%pOF'\n",
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 4d57a4e34105..19a1a38554f2 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -224,7 +224,6 @@ static void __of_attach_node(struct device_node *np)
np->sibling = np->parent->child;
np->parent->child = np;
of_node_clear_flag(np, OF_DETACHED);
- np->fwnode.flags |= FWNODE_FLAG_NOT_DEVICE;
raw_spin_unlock_irqrestore(&devtree_lock, flags);
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 389d4ea6bfc1..efd861fa254f 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -743,11 +743,6 @@ static int of_platform_notify(struct notifier_block *nb,
if (of_node_check_flag(rd->dn, OF_POPULATED))
return NOTIFY_OK;
- /*
- * Clear the flag before adding the device so that fw_devlink
- * doesn't skip adding consumers to this device.
- */
- rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE;
/* pdev_parent may be NULL when no bus platform device */
pdev_parent = of_find_device_by_node(rd->dn->parent);
pdev = of_platform_device_create(rd->dn, NULL,
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index ff75838c1b5d..17cd417f7681 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -4761,11 +4761,6 @@ static int of_spi_notify(struct notifier_block *nb, unsigned long action,
return NOTIFY_OK;
}
- /*
- * Clear the flag before adding the device so that fw_devlink
- * doesn't skip adding consumers to this device.
- */
- rd->dn->fwnode.flags &= ~FWNODE_FLAG_NOT_DEVICE;
spi = of_register_spi_device(ctlr, rd->dn);
put_device(&ctlr->dev);
--
2.44.0.478.gd926399ef9-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH] soc: fsl: qe: Add check for platform_driver_register
From: Maxim Kochetkov @ 2024-04-09 5:38 UTC (permalink / raw)
To: Chen Ni, qiang.zhao, leoyang.li, saravanak
Cc: linuxppc-dev, linux-arm-kernel, linux-kernel
In-Reply-To: <20240409030840.666703-1-nichen@iscas.ac.cn>
09.04.2024 06:08, Chen Ni пишет:
> Return platform_driver_register() in order to transfer the error if
> it fails.
>
> Fixes: be7ecbd240b2 ("soc: fsl: qe: convert QE interrupt controller to platform_device")
> Signed-off-by: Chen Ni <nichen@iscas.ac.cn>
Reviewed-by: Maxim Kochetkov <fido_max@inbox.ru>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH RFC v2 3/5] of: unittest: add test for of_dma_get_cpu_limits() 'min' param
From: Baruch Siach @ 2024-04-09 6:17 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Rob Herring, Saravana Kannan,
Catalin Marinas, Will Deacon
Cc: Baruch Siach, Robin Murphy, iommu, devicetree, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, Petr Tesařík,
Ramon Fried, Elad Nachman
In-Reply-To: <cover.1712642324.git.baruch@tkos.co.il>
Verify that of_dma_get_cpu_limits() sets this new parameter to the
expected result.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/of/unittest.c | 13 ++++++++-----
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 2d632d4ec5b1..8fabb445a62a 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -924,7 +924,7 @@ static void __init of_unittest_changeset(void)
static void __init of_unittest_dma_get_cpu_limits(void)
{
struct device_node *np;
- phys_addr_t cpu_addr;
+ phys_addr_t cpu_addr_max, cpu_addr_min;
if (!IS_ENABLED(CONFIG_OF_ADDRESS))
return;
@@ -935,10 +935,13 @@ static void __init of_unittest_dma_get_cpu_limits(void)
return;
}
- of_dma_get_cpu_limits(np, &cpu_addr, NULL);
- unittest(cpu_addr == 0x4fffffff,
- "of_dma_get_cpu_limits: wrong CPU addr %pad (expecting %x)\n",
- &cpu_addr, 0x4fffffff);
+ of_dma_get_cpu_limits(np, &cpu_addr_max, &cpu_addr_min);
+ unittest(cpu_addr_max == 0x4fffffff,
+ "of_dma_get_cpu_limits: wrong CPU max addr %pad (expecting %x)\n",
+ &cpu_addr_max, 0x4fffffff);
+ unittest(cpu_addr_min == 0x40000000,
+ "of_dma_get_cpu_limits: wrong CPU min addr %pad (expecting %x)\n",
+ &cpu_addr_min, 0x40000000);
}
static void __init of_unittest_dma_ranges_one(const char *path,
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH RFC v2 0/5] arm64: support DMA zone starting above 4GB
From: Baruch Siach @ 2024-04-09 6:17 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Rob Herring, Saravana Kannan,
Catalin Marinas, Will Deacon
Cc: Baruch Siach, Robin Murphy, iommu, devicetree, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, Petr Tesařík,
Ramon Fried, Elad Nachman
DMA zones code assumes that DMA lower limit is zero. When there is no RAM
below 4GB, arm64 platform code sets DMA/DMA32 zone limits to cover the entire
RAM[0].
The platform I have has RAM starting at 32GB. Devices with 30-bit DMA mask are
mapped to 1GB at the bottom of RAM, between 32GB - 33GB. A DMA zone over the
entire RAM breaks DMA allocation for these devices.
In response to a previous RFC hack[1] Catalin Marinas suggested to add a
separate offset value as base address for the DMA zone. This RFC series
attempts to implement that suggestion.
With this series applied, the DMA zone covers the right RAM range for my
platform.
RFC v2:
* Add patch from Catalin[2] changing zone_dma_bits to zone_dma_limit to
simplify subsequent patches
* Test on real hardware
RFC v1: https://lore.kernel.org/all/cover.1703683642.git.baruch@tkos.co.il/
[0] See commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation")
[1] https://lore.kernel.org/all/9af8a19c3398e7dc09cfc1fbafed98d795d9f83e.1699464622.git.baruch@tkos.co.il/
[2] https://lore.kernel.org/all/ZZ2HnHJV3gdzu1Aj@arm.com/
Baruch Siach (4):
of: get dma area lower limit
of: unittest: add test for of_dma_get_cpu_limits() 'min' param
dma-direct: add base offset to zone_dma_bits
arm64: mm: take DMA zone offset into account
Catalin Marinas (1):
dma-mapping: replace zone_dma_bits by zone_dma_limit
arch/arm64/mm/init.c | 34 ++++++++++++----------------------
arch/powerpc/mm/mem.c | 9 ++++-----
arch/s390/mm/init.c | 2 +-
drivers/of/address.c | 38 +++++++++++++++++++++++++++-----------
drivers/of/unittest.c | 17 ++++++++++-------
include/linux/dma-direct.h | 3 ++-
include/linux/of.h | 11 ++++++++---
kernel/dma/direct.c | 11 ++++++-----
kernel/dma/pool.c | 2 +-
kernel/dma/swiotlb.c | 4 ++--
10 files changed, 73 insertions(+), 58 deletions(-)
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH RFC v2 5/5] arm64: mm: take DMA zone offset into account
From: Baruch Siach @ 2024-04-09 6:17 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Rob Herring, Saravana Kannan,
Catalin Marinas, Will Deacon
Cc: Baruch Siach, Robin Murphy, iommu, devicetree, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, Petr Tesařík,
Ramon Fried, Elad Nachman
In-Reply-To: <cover.1712642324.git.baruch@tkos.co.il>
Commit 791ab8b2e3db ("arm64: Ignore any DMA offsets in the
max_zone_phys() calculation") made DMA/DMA32 zones span the entire RAM
when RAM starts above 32-bits. This breaks hardware with DMA area that
start above 32-bits. But the commit log says that "we haven't noticed
any such hardware". It turns out that such hardware does exist.
One such platform has RAM starting at 32GB with an internal bus that has
the following DMA limits:
#address-cells = <2>;
#size-cells = <2>;
dma-ranges = <0x00 0xc0000000 0x08 0x00000000 0x00 0x40000000>;
Devices under this bus can see 1GB of DMA range between 3GB-4GB in each
device address space. This range is mapped to CPU memory at 32GB-33GB.
With current code DMA allocations for devices under this bus are not
limited to DMA area, leading to run-time allocation failure.
Modify 'zone_dma_bits' calculation (via dt_zone_dma_bits) to only cover
the actual DMA area starting at 'zone_dma_off'. Use the newly introduced
'min' parameter of of_dma_get_cpu_limits() to set 'zone_dma_off'.
DMA32 zone is useless in this configuration, so make its limit the same
as the DMA zone when the lower DMA limit is higher than 32-bits.
The result is DMA zone that properly reflects the hardware constraints
as follows:
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000800000000-0x000000083fffffff]
[ 0.000000] DMA32 empty
[ 0.000000] Normal [mem 0x0000000840000000-0x0000000bffffffff]
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
arch/arm64/mm/init.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 77e942ca578b..cd283ae0178d 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -128,9 +128,11 @@ static void __init zone_sizes_init(void)
#ifdef CONFIG_ZONE_DMA
acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
- of_dma_get_cpu_limits(NULL, &dt_zone_dma_limit, NULL);
+ of_dma_get_cpu_limits(NULL, &dt_zone_dma_limit, &zone_dma_base);
zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
+ if (zone_dma_base > U32_MAX)
+ dma32_phys_limit = arm64_dma_phys_limit;
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH RFC v2 4/5] dma-direct: add base offset to zone_dma_bits
From: Baruch Siach @ 2024-04-09 6:17 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Rob Herring, Saravana Kannan,
Catalin Marinas, Will Deacon
Cc: Baruch Siach, Robin Murphy, iommu, devicetree, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, Petr Tesařík,
Ramon Fried, Elad Nachman
In-Reply-To: <cover.1712642324.git.baruch@tkos.co.il>
Current code using zone_dma_bits assume that all addresses range in the
bits mask are suitable for DMA. For some existing platforms this
assumption is not correct. DMA range might have non zero lower limit.
Add 'zone_dma_base' for platform code to set base address for DMA zone.
Rename the dma_direct_supported() local 'min_mask' variable to better
describe its use as limit.
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
include/linux/dma-direct.h | 1 +
kernel/dma/direct.c | 9 +++++----
kernel/dma/pool.c | 2 +-
kernel/dma/swiotlb.c | 4 ++--
4 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 7cf76f1d3239..dd0330cbef81 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -13,6 +13,7 @@
#include <linux/swiotlb.h>
extern phys_addr_t zone_dma_limit;
+extern phys_addr_t zone_dma_base;
/*
* Record the mapping of CPU physical to DMA addresses for a given region.
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 3b2ebcd4f576..92bb241645d6 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -21,6 +21,7 @@
* override the variable below for dma-direct to work properly.
*/
phys_addr_t zone_dma_limit __ro_after_init = DMA_BIT_MASK(24);
+phys_addr_t zone_dma_base __ro_after_init;
static inline dma_addr_t phys_to_dma_direct(struct device *dev,
phys_addr_t phys)
@@ -59,7 +60,7 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev, u64 *phys_limit)
* zones.
*/
*phys_limit = dma_to_phys(dev, dma_limit);
- if (*phys_limit <= zone_dma_limit)
+ if (*phys_limit <= zone_dma_base + zone_dma_limit)
return GFP_DMA;
if (*phys_limit <= DMA_BIT_MASK(32))
return GFP_DMA32;
@@ -567,7 +568,7 @@ int dma_direct_mmap(struct device *dev, struct vm_area_struct *vma,
int dma_direct_supported(struct device *dev, u64 mask)
{
- u64 min_mask = (max_pfn - 1) << PAGE_SHIFT;
+ u64 min_limit = (max_pfn - 1) << PAGE_SHIFT;
/*
* Because 32-bit DMA masks are so common we expect every architecture
@@ -584,8 +585,8 @@ int dma_direct_supported(struct device *dev, u64 mask)
* part of the check.
*/
if (IS_ENABLED(CONFIG_ZONE_DMA))
- min_mask = min_t(u64, min_mask, zone_dma_limit);
- return mask >= phys_to_dma_unencrypted(dev, min_mask);
+ min_limit = min_t(u64, min_limit, zone_dma_base + zone_dma_limit);
+ return mask >= phys_to_dma_unencrypted(dev, min_limit);
}
/*
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index 410a7b40e496..61a86f3d83ae 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -70,7 +70,7 @@ static bool cma_in_zone(gfp_t gfp)
/* CMA can't cross zone boundaries, see cma_activate_area() */
end = cma_get_base(cma) + size - 1;
if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
- return end <= zone_dma_limit;
+ return end <= zone_dma_base + zone_dma_limit;
if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32))
return end <= DMA_BIT_MASK(32);
return true;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 96d6eee7d215..814052df07c5 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -446,7 +446,7 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
if (!remap)
io_tlb_default_mem.can_grow = true;
if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp_mask & __GFP_DMA))
- io_tlb_default_mem.phys_limit = zone_dma_limit;
+ io_tlb_default_mem.phys_limit = zone_dma_base + zone_dma_limit;
else if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp_mask & __GFP_DMA32))
io_tlb_default_mem.phys_limit = DMA_BIT_MASK(32);
else
@@ -625,7 +625,7 @@ static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
}
gfp &= ~GFP_ZONEMASK;
- if (phys_limit <= zone_dma_limit)
+ if (phys_limit <= zone_dma_base + zone_dma_limit)
gfp |= __GFP_DMA;
else if (phys_limit <= DMA_BIT_MASK(32))
gfp |= __GFP_DMA32;
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH RFC v2 1/5] dma-mapping: replace zone_dma_bits by zone_dma_limit
From: Baruch Siach @ 2024-04-09 6:17 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Rob Herring, Saravana Kannan,
Catalin Marinas, Will Deacon
Cc: Baruch Siach, Robin Murphy, iommu, devicetree, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, Petr Tesařík,
Ramon Fried, Elad Nachman
In-Reply-To: <cover.1712642324.git.baruch@tkos.co.il>
From: Catalin Marinas <catalin.marinas@arm.com>
Hardware DMA limit might not be power of 2. When RAM range starts above
0, say 4GB, DMA limit of 30 bits should end at 5GB. A single high bit
can not encode this limit.
Use direct phys_addr_t limit address for DMA zone limit.
Following commits will add explicit base address to DMA zone.
---
Catalin,
This is taken almost verbatim from your email:
https://lore.kernel.org/all/ZZ2HnHJV3gdzu1Aj@arm.com/
Would you provide your sign-off?
Thanks,
baruch
---
arch/arm64/mm/init.c | 32 ++++++++++----------------------
arch/powerpc/mm/mem.c | 9 ++++-----
arch/s390/mm/init.c | 2 +-
include/linux/dma-direct.h | 2 +-
kernel/dma/direct.c | 6 +++---
kernel/dma/pool.c | 2 +-
kernel/dma/swiotlb.c | 4 ++--
7 files changed, 22 insertions(+), 35 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 03efd86dce0a..00508c69ca9e 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -113,36 +113,24 @@ static void __init arch_reserve_crashkernel(void)
low_size, high);
}
-/*
- * Return the maximum physical address for a zone accessible by the given bits
- * limit. If DRAM starts above 32-bit, expand the zone to the maximum
- * available memory, otherwise cap it at 32-bit.
- */
-static phys_addr_t __init max_zone_phys(unsigned int zone_bits)
+static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit)
{
- phys_addr_t zone_mask = DMA_BIT_MASK(zone_bits);
- phys_addr_t phys_start = memblock_start_of_DRAM();
-
- if (phys_start > U32_MAX)
- zone_mask = PHYS_ADDR_MAX;
- else if (phys_start > zone_mask)
- zone_mask = U32_MAX;
-
- return min(zone_mask, memblock_end_of_DRAM() - 1) + 1;
+ return min(zone_limit, memblock_end_of_DRAM() - 1) + 1;
}
static void __init zone_sizes_init(void)
{
unsigned long max_zone_pfns[MAX_NR_ZONES] = {0};
- unsigned int __maybe_unused acpi_zone_dma_bits;
- unsigned int __maybe_unused dt_zone_dma_bits;
- phys_addr_t __maybe_unused dma32_phys_limit = max_zone_phys(32);
+ phys_addr_t __maybe_unused acpi_zone_dma_limit;
+ phys_addr_t __maybe_unused dt_zone_dma_limit;
+ phys_addr_t __maybe_unused dma32_phys_limit =
+ max_zone_phys(DMA_BIT_MASK(32));
#ifdef CONFIG_ZONE_DMA
- acpi_zone_dma_bits = fls64(acpi_iort_dma_get_max_cpu_address());
- dt_zone_dma_bits = fls64(of_dma_get_max_cpu_address(NULL));
- zone_dma_bits = min3(32U, dt_zone_dma_bits, acpi_zone_dma_bits);
- arm64_dma_phys_limit = max_zone_phys(zone_dma_bits);
+ acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
+ dt_zone_dma_limit = of_dma_get_max_cpu_address(NULL);
+ zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
+ arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
#endif
#ifdef CONFIG_ZONE_DMA32
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 3a440004b97d..4d6f575fd354 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -214,7 +214,7 @@ static int __init mark_nonram_nosave(void)
* everything else. GFP_DMA32 page allocations automatically fall back to
* ZONE_DMA.
*
- * By using 31-bit unconditionally, we can exploit zone_dma_bits to inform the
+ * By using 31-bit unconditionally, we can exploit zone_dma_limit to inform the
* generic DMA mapping code. 32-bit only devices (if not handled by an IOMMU
* anyway) will take a first dip into ZONE_NORMAL and get otherwise served by
* ZONE_DMA.
@@ -250,13 +250,12 @@ void __init paging_init(void)
* powerbooks.
*/
if (IS_ENABLED(CONFIG_PPC32))
- zone_dma_bits = 30;
+ zone_dma_limit = DMA_BIT_MASK(30);
else
- zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(31);
#ifdef CONFIG_ZONE_DMA
- max_zone_pfns[ZONE_DMA] = min(max_low_pfn,
- 1UL << (zone_dma_bits - PAGE_SHIFT));
+ max_zone_pfns[ZONE_DMA] = min(max_low_pfn, zone_dma_limit >> PAGE_SHIFT);
#endif
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
#ifdef CONFIG_HIGHMEM
diff --git a/arch/s390/mm/init.c b/arch/s390/mm/init.c
index f6391442c0c2..5feaa60933b7 100644
--- a/arch/s390/mm/init.c
+++ b/arch/s390/mm/init.c
@@ -95,7 +95,7 @@ void __init paging_init(void)
vmem_map_init();
sparse_init();
- zone_dma_bits = 31;
+ zone_dma_limit = DMA_BIT_MASK(31);
memset(max_zone_pfns, 0, sizeof(max_zone_pfns));
max_zone_pfns[ZONE_DMA] = virt_to_pfn(MAX_DMA_ADDRESS);
max_zone_pfns[ZONE_NORMAL] = max_low_pfn;
diff --git a/include/linux/dma-direct.h b/include/linux/dma-direct.h
index 3eb3589ff43e..7cf76f1d3239 100644
--- a/include/linux/dma-direct.h
+++ b/include/linux/dma-direct.h
@@ -12,7 +12,7 @@
#include <linux/mem_encrypt.h>
#include <linux/swiotlb.h>
-extern unsigned int zone_dma_bits;
+extern phys_addr_t zone_dma_limit;
/*
* Record the mapping of CPU physical to DMA addresses for a given region.
diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 4d543b1e9d57..3b2ebcd4f576 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -20,7 +20,7 @@
* it for entirely different regions. In that case the arch code needs to
* override the variable below for dma-direct to work properly.
*/
-unsigned int zone_dma_bits __ro_after_init = 24;
+phys_addr_t zone_dma_limit __ro_after_init = DMA_BIT_MASK(24);
static inline dma_addr_t phys_to_dma_direct(struct device *dev,
phys_addr_t phys)
@@ -59,7 +59,7 @@ static gfp_t dma_direct_optimal_gfp_mask(struct device *dev, u64 *phys_limit)
* zones.
*/
*phys_limit = dma_to_phys(dev, dma_limit);
- if (*phys_limit <= DMA_BIT_MASK(zone_dma_bits))
+ if (*phys_limit <= zone_dma_limit)
return GFP_DMA;
if (*phys_limit <= DMA_BIT_MASK(32))
return GFP_DMA32;
@@ -584,7 +584,7 @@ int dma_direct_supported(struct device *dev, u64 mask)
* part of the check.
*/
if (IS_ENABLED(CONFIG_ZONE_DMA))
- min_mask = min_t(u64, min_mask, DMA_BIT_MASK(zone_dma_bits));
+ min_mask = min_t(u64, min_mask, zone_dma_limit);
return mask >= phys_to_dma_unencrypted(dev, min_mask);
}
diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c
index d10613eb0f63..410a7b40e496 100644
--- a/kernel/dma/pool.c
+++ b/kernel/dma/pool.c
@@ -70,7 +70,7 @@ static bool cma_in_zone(gfp_t gfp)
/* CMA can't cross zone boundaries, see cma_activate_area() */
end = cma_get_base(cma) + size - 1;
if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp & GFP_DMA))
- return end <= DMA_BIT_MASK(zone_dma_bits);
+ return end <= zone_dma_limit;
if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp & GFP_DMA32))
return end <= DMA_BIT_MASK(32);
return true;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 86fe172b5958..96d6eee7d215 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -446,7 +446,7 @@ int swiotlb_init_late(size_t size, gfp_t gfp_mask,
if (!remap)
io_tlb_default_mem.can_grow = true;
if (IS_ENABLED(CONFIG_ZONE_DMA) && (gfp_mask & __GFP_DMA))
- io_tlb_default_mem.phys_limit = DMA_BIT_MASK(zone_dma_bits);
+ io_tlb_default_mem.phys_limit = zone_dma_limit;
else if (IS_ENABLED(CONFIG_ZONE_DMA32) && (gfp_mask & __GFP_DMA32))
io_tlb_default_mem.phys_limit = DMA_BIT_MASK(32);
else
@@ -625,7 +625,7 @@ static struct page *swiotlb_alloc_tlb(struct device *dev, size_t bytes,
}
gfp &= ~GFP_ZONEMASK;
- if (phys_limit <= DMA_BIT_MASK(zone_dma_bits))
+ if (phys_limit <= zone_dma_limit)
gfp |= __GFP_DMA;
else if (phys_limit <= DMA_BIT_MASK(32))
gfp |= __GFP_DMA32;
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH RFC v2 2/5] of: get dma area lower limit
From: Baruch Siach @ 2024-04-09 6:17 UTC (permalink / raw)
To: Christoph Hellwig, Marek Szyprowski, Rob Herring, Saravana Kannan,
Catalin Marinas, Will Deacon
Cc: Baruch Siach, Robin Murphy, iommu, devicetree, linux-arm-kernel,
linux-kernel, linuxppc-dev, linux-s390, Petr Tesařík,
Ramon Fried, Elad Nachman
In-Reply-To: <cover.1712642324.git.baruch@tkos.co.il>
of_dma_get_max_cpu_address() returns the highest CPU address that
devices can use for DMA. The implicit assumption is that all CPU
addresses below that limit are suitable for DMA. However the
'dma-ranges' property this code uses also encodes a lower limit for DMA
that is potentially non zero.
Rename to of_dma_get_cpu_limits(), and extend to retrieve also the lower
limit for the same 'dma-ranges' property describing the high limit.
Update callers of of_dma_get_max_cpu_address(). No functional change
intended.
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
arch/arm64/mm/init.c | 2 +-
drivers/of/address.c | 38 +++++++++++++++++++++++++++-----------
drivers/of/unittest.c | 8 ++++----
include/linux/of.h | 11 ++++++++---
4 files changed, 40 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 00508c69ca9e..77e942ca578b 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -128,7 +128,7 @@ static void __init zone_sizes_init(void)
#ifdef CONFIG_ZONE_DMA
acpi_zone_dma_limit = acpi_iort_dma_get_max_cpu_address();
- dt_zone_dma_limit = of_dma_get_max_cpu_address(NULL);
+ of_dma_get_cpu_limits(NULL, &dt_zone_dma_limit, NULL);
zone_dma_limit = min(dt_zone_dma_limit, acpi_zone_dma_limit);
arm64_dma_phys_limit = max_zone_phys(zone_dma_limit);
max_zone_pfns[ZONE_DMA] = PFN_DOWN(arm64_dma_phys_limit);
diff --git a/drivers/of/address.c b/drivers/of/address.c
index ae46a3605904..ac009b3bb63b 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -964,21 +964,25 @@ int of_dma_get_range(struct device_node *np, const struct bus_dma_region **map)
#endif /* CONFIG_HAS_DMA */
/**
- * of_dma_get_max_cpu_address - Gets highest CPU address suitable for DMA
+ * of_dma_get_cpu_limits - Gets highest CPU address suitable for DMA
* @np: The node to start searching from or NULL to start from the root
+ * @max: Pointer to high address limit or NULL if not needed
+ * @min: Pointer to low address limit or NULL if not needed
*
* Gets the highest CPU physical address that is addressable by all DMA masters
- * in the sub-tree pointed by np, or the whole tree if NULL is passed. If no
- * DMA constrained device is found, it returns PHYS_ADDR_MAX.
+ * in the sub-tree pointed by np, or the whole tree if @np in NULL. If no
+ * DMA constrained device is found, @*max is PHYS_ADDR_MAX, and @*low is 0.
*/
-phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
+void __init of_dma_get_cpu_limits(struct device_node *np,
+ phys_addr_t *max, phys_addr_t *min)
{
phys_addr_t max_cpu_addr = PHYS_ADDR_MAX;
struct of_range_parser parser;
- phys_addr_t subtree_max_addr;
+ phys_addr_t min_cpu_addr = 0;
struct device_node *child;
struct of_range range;
const __be32 *ranges;
+ u64 cpu_start = 0;
u64 cpu_end = 0;
int len;
@@ -988,21 +992,33 @@ phys_addr_t __init of_dma_get_max_cpu_address(struct device_node *np)
ranges = of_get_property(np, "dma-ranges", &len);
if (ranges && len) {
of_dma_range_parser_init(&parser, np);
- for_each_of_range(&parser, &range)
- if (range.cpu_addr + range.size > cpu_end)
+ for_each_of_range(&parser, &range) {
+ if (range.cpu_addr + range.size > cpu_end) {
cpu_end = range.cpu_addr + range.size - 1;
+ cpu_start = range.cpu_addr;
+ }
+ }
- if (max_cpu_addr > cpu_end)
+ if (max_cpu_addr > cpu_end) {
max_cpu_addr = cpu_end;
+ min_cpu_addr = cpu_start;
+ }
}
for_each_available_child_of_node(np, child) {
- subtree_max_addr = of_dma_get_max_cpu_address(child);
- if (max_cpu_addr > subtree_max_addr)
+ phys_addr_t subtree_max_addr, subtree_min_addr;
+
+ of_dma_get_cpu_limits(child, &subtree_max_addr, &subtree_min_addr);
+ if (max_cpu_addr > subtree_max_addr) {
max_cpu_addr = subtree_max_addr;
+ min_cpu_addr = subtree_min_addr;
+ }
}
- return max_cpu_addr;
+ if (max)
+ *max = max_cpu_addr;
+ if (min)
+ *min = min_cpu_addr;
}
/**
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 6b5c36b6a758..2d632d4ec5b1 100644
--- a/drivers/of/unittest.c
+++ b/drivers/of/unittest.c
@@ -921,7 +921,7 @@ static void __init of_unittest_changeset(void)
#endif
}
-static void __init of_unittest_dma_get_max_cpu_address(void)
+static void __init of_unittest_dma_get_cpu_limits(void)
{
struct device_node *np;
phys_addr_t cpu_addr;
@@ -935,9 +935,9 @@ static void __init of_unittest_dma_get_max_cpu_address(void)
return;
}
- cpu_addr = of_dma_get_max_cpu_address(np);
+ of_dma_get_cpu_limits(np, &cpu_addr, NULL);
unittest(cpu_addr == 0x4fffffff,
- "of_dma_get_max_cpu_address: wrong CPU addr %pad (expecting %x)\n",
+ "of_dma_get_cpu_limits: wrong CPU addr %pad (expecting %x)\n",
&cpu_addr, 0x4fffffff);
}
@@ -4109,7 +4109,7 @@ static int __init of_unittest(void)
of_unittest_changeset();
of_unittest_parse_interrupts();
of_unittest_parse_interrupts_extended();
- of_unittest_dma_get_max_cpu_address();
+ of_unittest_dma_get_cpu_limits();
of_unittest_parse_dma_ranges();
of_unittest_pci_dma_ranges();
of_unittest_bus_ranges();
diff --git a/include/linux/of.h b/include/linux/of.h
index a0bedd038a05..7756441d3ce0 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -454,7 +454,8 @@ int of_map_id(struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
struct device_node **target, u32 *id_out);
-phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
+void of_dma_get_cpu_limits(struct device_node *np, phys_addr_t *max,
+ phys_addr_t *min);
struct kimage;
void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
@@ -880,9 +881,13 @@ static inline int of_map_id(struct device_node *np, u32 id,
return -EINVAL;
}
-static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np)
+static inline void of_dma_get_cpu_limits(struct device_node *np,
+ phys_addr_t *max, phys_addr_t *min)
{
- return PHYS_ADDR_MAX;
+ if (max)
+ *max = PHYS_ADDR_MAX;
+ if (min)
+ *min = 0;
}
static inline const void *of_device_get_match_data(const struct device *dev)
--
2.43.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] thermal/drivers/mediatek/lvts_thermal: Improve some memory allocation
From: Dan Carpenter @ 2024-04-09 6:22 UTC (permalink / raw)
To: Christophe JAILLET
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Matthias Brugger, AngeloGioacchino Del Regno, linux-kernel,
kernel-janitors, linux-pm, linux-arm-kernel, linux-mediatek
In-Reply-To: <4ebbe227-38b1-4a1c-af34-9ba7bdfecad5@wanadoo.fr>
On Mon, Apr 08, 2024 at 08:41:26PM +0200, Christophe JAILLET wrote:
> Le 08/04/2024 à 10:09, Dan Carpenter a écrit :
> > On Sun, Apr 07, 2024 at 10:01:49PM +0200, Christophe JAILLET wrote:
> > > diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c
> > > index 3003dc350766..b133f731c5ba 100644
> > > --- a/drivers/thermal/mediatek/lvts_thermal.c
> > > +++ b/drivers/thermal/mediatek/lvts_thermal.c
> > > @@ -204,7 +204,7 @@ static const struct debugfs_reg32 lvts_regs[] = {
> > > static int lvts_debugfs_init(struct device *dev, struct lvts_domain *lvts_td)
> > > {
> > > - struct debugfs_regset32 *regset;
> > > + struct debugfs_regset32 *regsets;
> > > struct lvts_ctrl *lvts_ctrl;
> > > struct dentry *dentry;
> > > char name[64];
> > > @@ -214,8 +214,14 @@ static int lvts_debugfs_init(struct device *dev, struct lvts_domain *lvts_td)
> > > if (IS_ERR(lvts_td->dom_dentry))
> > > return 0;
> > > + regsets = devm_kcalloc(dev, lvts_td->num_lvts_ctrl,
> > > + sizeof(*regsets), GFP_KERNEL);
> > > + if (!regsets)
> > > + return 0;
> >
> > I understand that this preserved the behavior from the original code,
> > but the original code was wrong. This should return -ENOMEM.
>
> Hi Dan,
> I don't agree.
>
> For me, this memory allocation is of the same type as all debugfs functions
> that we ignore the error code.
>
> If it fails, it is not a reason good enough to have the probe fail. (anyway,
> if we are short on memory at this point other errors will likely occur)
>
Huh. It's an interesting point. Fair enough.
> >
> > > +
> > > for (i = 0; i < lvts_td->num_lvts_ctrl; i++) {
> > > + struct debugfs_regset32 *regset = ®sets[i];
> > > lvts_ctrl = &lvts_td->lvts_ctrl[i];
> >
> > The blank line should come after the declaration.
>
> The blank line was already there, and in this file, it looks like the
> preferred style (even if not completely consistent)
>
> Let see if there is some comment about 0 or -ENOMEM in case of memory
> allocation error, and if needed, I'll repost without the blank line.
>
There is supposed to be a blank line after declarations though so I
think if you re-run checkpatch.pl -f on the file there is a checkpatch
warning now.
regards,
dan carpenter
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Krzysztof Kozlowski @ 2024-04-09 6:30 UTC (permalink / raw)
To: Shengjiu Wang
Cc: Shengjiu Wang, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, linux-sound, devicetree,
linux-kernel, shawnguo, s.hauer, kernel, festevam, imx,
linux-arm-kernel
In-Reply-To: <CAA+D8AOP6D+xUNF_XJXt-8dMi2qFyVh-Sbe8k67CzvUbnzrwoQ@mail.gmail.com>
On 09/04/2024 03:37, Shengjiu Wang wrote:
> On Mon, Apr 8, 2024 at 11:06 PM Krzysztof Kozlowski
> <krzysztof.kozlowski@linaro.org> wrote:
>>
>> On 08/04/2024 10:01, Shengjiu Wang wrote:
>>>>> +
>>>>> +anyOf:
>>>>> + - required:
>>>>> + - spdif-in
>>>>> + - required:
>>>>> + - spdif-out
>>>>> + - required:
>>>>> + - spdif-out
>>>>> + - spdif-in
>>>>
>>>> Do you need the last required block?
>>>
>>> Yes, one of them or both are required.
>>
>> And? It's already there: that's the meaning of any. It is not oneOf...
>> Before answering please test your changes and ideas. I pointed issue
>> here and you responded just to close my comment. That does not make me
>> happy, just wastes my time.
>
> Maybe I didn't express clearly.
>
> we need at least one of them (spdif-in, spdif-out) in the node. which means
> that we need to select "spdif-in", or "spdif-out", or "spdif-in and
> spdif-out".
>
> So my understanding is that need to use "anyOf", if it is wrong, please let
> me know.
Third time: it is wrong.
Can you test the code instead continuing this discussion
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] arm64: dts: imx8qxp-mek: add cm40_i2c, wm8960/wm8962 and sai[0,1,4,5]
From: Krzysztof Kozlowski @ 2024-04-09 6:33 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <ZhQO979YpKA24pML@lizhi-Precision-Tower-5810>
On 08/04/2024 17:36, Frank Li wrote:
> On Fri, Apr 05, 2024 at 08:21:18PM +0200, Krzysztof Kozlowski wrote:
>> On 05/04/2024 16:46, Frank Li wrote:
>>> On Fri, Apr 05, 2024 at 08:41:59AM +0200, Krzysztof Kozlowski wrote:
>>>> On 04/04/2024 18:19, Frank Li wrote:
>>>>> imx8qxp-mek use two kind audio codec, wm8960 and wm8962. Using dummy gpio
>>>>> i2c bus mux to connect both i2c devices. One will probe failure and other
>>>>> will probe success when devices driver check whoami. So one dtb can cover
>>>>> both board configuration.
>>>>
>>>> I don't understand it. Either you add real device or not. If one board
>>>> has two devices, then why do you need to check for failures?
>>>>
>>>> Anyway, don't add fake stuff to DTS.
>>>
>>> NAK can't resolve the problem. It should be common problem for long time
>>> cycle boards. Some chipes will be out life cycle. such as some sensor. So
>>> chips on boards have been replace by some pin to pin compatible sensor. For
>>> example:
>>> old boards: use sensor A with address 0x1a
>>> new bench: use sensor B with address 0x1b.
>>>
>>> You can treat it as two kind boards, RevA or RevB. But most user want to
>>> use one dtb to handle such small differences. For this case, it should be
>>> simple. Just add a super set.
>>> i2c
>>> {
>>> sensorA@1a
>>> {
>>> }
>>> sensorB@1b
>>> {
>>> }
>>> }
>>>
>>> It also depend on whoami check by i2c devices. Only A or B will probe.
>>>
>>> wm8960 and wm8962 are more complex example. wm8960 is out of life. But
>>> wm8962 and wm8960 have the same i2c address. The current i2c frame can't
>>> allow the same i2c address in one i2c bus.
>>>
>>> You are feel to NAK my method, but I hope you also provide constructive
>>> solution to help resolve the problem.
>>
>> Yes, we resolved it long time ago. Your bootloader can (usually easily)
>> detect revision of the board and load appropriate DTS or DTS+DTSO.
>
> I knewn it. But the problem is one development boards A have many options,
> so create many child dts for files, A1, A2, ... An which base on A
So use DTSO, what's the problem? Other vendors, liek Rpi does not have
problem with it and it works well. No confusion.
>
> If there are difference happen at A, create new B. then create all child
> dtb, B1, B2, ... Bn. DTB number will increase exponent.
>
> If change is quite bit, we have to do that. But if change is quite small,
> One dtb can cover it by driver auto detect, which will work like some
> adaptor card have not plug into boards, or some sensor or NOR-flash have
> not installed because reduce cost.
You have two boards, not 20 here!
>
> Although boot loader can update dts or choose difference dts, It also cause
> many confusition, such as layerscape, uboot update many kernel dtb's
> information, which actually increase dependence between uboot and kernel.
> Also it confuse people, for example, when try to debug kernel dtb, why
> change have not token affect when change dts because not realized uboot
> over write it.
>
> What's I dide is that trying to reduce unnecessary dts.
There is no confusion. That's normal process, so if someone is confused
by having variants of board, this someone will be even more confused by
seeing non-existing hardware in his DTS.
This problem was solved long time ago and you do not bring any
reasonable new arguments. All vendors solved it (just look at ongoing
discussions on board id) but only you have problem with their solution.
NAK
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: mailbox: qcom: Add MSM8974 APCS compatible
From: Krzysztof Kozlowski @ 2024-04-09 6:37 UTC (permalink / raw)
To: Luca Weiss, ~postmarketos/upstreaming, phone-devel, Jassi Brar,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Matthias Brugger, AngeloGioacchino Del Regno,
Jacky Huang, Shan-Chun Hung
Cc: linux-arm-msm, linux-kernel, devicetree, linux-arm-kernel,
linux-mediatek
In-Reply-To: <20240408-msm8974-apcs-v1-1-90cb7368836e@z3ntu.xyz>
On 08/04/2024 21:32, Luca Weiss wrote:
> Add compatible for the Qualcomm MSM8974 APCS block.
"... The block is already used in DTS, but without any SoC specific
compatible."
Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2,0/5] media: change the calculation method of sizeimage
From: Yunfei Dong @ 2024-04-09 6:44 UTC (permalink / raw)
To: Nícolas F . R . A . Prado, Nicolas Dufresne, Hans Verkuil,
AngeloGioacchino Del Regno, Benjamin Gaignard, Nathan Hebert,
Sebastian Fricke
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, Yunfei Dong,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group
The bytesperline and sizeimage of each plan are different for 8bit
and 10bit bitstreams. Using v4l2 common interface to calculate them
independently.
---
compare with v1:
- add patch 1/2/3/4
- change the calculation method for sizeimage for patch 5
---
Yunfei Dong (5):
media: mediatek: vcodec: fix incorrect MT2T format information
media: mediatek: vcodec: fix incorrect MT2R format information
media: mediatek: vcodec: add MM21 format definition
media: mediatek: vcodec: add MT21 format definition
media: mediatek: vcodec: fix incorrect sizeimage for 10bit bitstream
.../mediatek/vcodec/decoder/mtk_vcodec_dec.c | 28 ++++++-------------
drivers/media/v4l2-core/v4l2-common.c | 12 +++++---
2 files changed, 16 insertions(+), 24 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2,1/5] media: mediatek: vcodec: fix incorrect MT2T format information
From: Yunfei Dong @ 2024-04-09 6:44 UTC (permalink / raw)
To: Nícolas F . R . A . Prado, Nicolas Dufresne, Hans Verkuil,
AngeloGioacchino Del Regno, Benjamin Gaignard, Nathan Hebert,
Sebastian Fricke
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, Yunfei Dong,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240409064431.16909-1-yunfei.dong@mediatek.com>
Changing the bpp and hdiv values to make sure the bytesperline
of plane[0] and plane[1] are the same. The width and height are
64 align.
Fixes: 6afcc2b0aebf ("media: mediatek: vcodec: Add capture format to support 10bit tile mode")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
drivers/media/v4l2-core/v4l2-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index d34d210908d9..8587cd14741c 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -265,8 +265,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
{ .format = V4L2_PIX_FMT_VYUY, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 2, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 1 },
{ .format = V4L2_PIX_FMT_Y212, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 4, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 1 },
{ .format = V4L2_PIX_FMT_YUV48_12, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 6, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
- { .format = V4L2_PIX_FMT_MT2110T, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
- .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
+ { .format = V4L2_PIX_FMT_MT2110T, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 5, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 1, .vdiv = 2,
+ .block_w = { 64, 64, 0, 0 }, .block_h = { 64, 64, 0, 0 }},
{ .format = V4L2_PIX_FMT_MT2110R, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
.block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2,5/5] media: mediatek: vcodec: fix incorrect sizeimage for 10bit bitstream
From: Yunfei Dong @ 2024-04-09 6:44 UTC (permalink / raw)
To: Nícolas F . R . A . Prado, Nicolas Dufresne, Hans Verkuil,
AngeloGioacchino Del Regno, Benjamin Gaignard, Nathan Hebert,
Sebastian Fricke
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, Yunfei Dong,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240409064431.16909-1-yunfei.dong@mediatek.com>
The sizeimage of each plane is calculated the same way for 8bit and
10bit bitstream. Using v4l2 common interface v4l2_fill_pixfmt_mp to
separate.
Fixes: 9d86be9bda6c ("media: mediatek: vcodec: Add driver to support 10bit")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
.../mediatek/vcodec/decoder/mtk_vcodec_dec.c | 28 ++++++-------------
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
index 9107707de6c4..fbfba69682ea 100644
--- a/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
+++ b/drivers/media/platform/mediatek/vcodec/decoder/mtk_vcodec_dec.c
@@ -262,40 +262,28 @@ static int vidioc_try_fmt(struct mtk_vcodec_dec_ctx *ctx, struct v4l2_format *f,
int tmp_w, tmp_h;
/*
- * Find next closer width align 64, height align 64, size align
- * 64 rectangle
+ * Find next closer width align 64, heign align 64, size align 64 rectangle
* Note: This only get default value, the real HW needed value
* only available when ctx in MTK_STATE_HEADER state
*/
tmp_w = pix_fmt_mp->width;
tmp_h = pix_fmt_mp->height;
+
v4l_bound_align_image(&pix_fmt_mp->width, MTK_VDEC_MIN_W, frmsize->max_width, 6,
&pix_fmt_mp->height, MTK_VDEC_MIN_H, frmsize->max_height, 6,
9);
- if (pix_fmt_mp->width < tmp_w &&
- (pix_fmt_mp->width + 64) <= frmsize->max_width)
+ if (pix_fmt_mp->width < tmp_w && (pix_fmt_mp->width + 64) <= frmsize->max_width)
pix_fmt_mp->width += 64;
- if (pix_fmt_mp->height < tmp_h &&
- (pix_fmt_mp->height + 64) <= frmsize->max_height)
+ if (pix_fmt_mp->height < tmp_h && (pix_fmt_mp->height + 64) <= frmsize->max_height)
pix_fmt_mp->height += 64;
+ v4l2_fill_pixfmt_mp(pix_fmt_mp, fmt->fourcc, pix_fmt_mp->width, pix_fmt_mp->height);
mtk_v4l2_vdec_dbg(0, ctx,
- "before resize wxh=%dx%d, after resize wxh=%dx%d, sizeimage=%d",
+ "before resize:%dx%d, after resize:%dx%d, sizeimage=0x%x_0x%x",
tmp_w, tmp_h, pix_fmt_mp->width, pix_fmt_mp->height,
- pix_fmt_mp->width * pix_fmt_mp->height);
-
- pix_fmt_mp->num_planes = fmt->num_planes;
- pix_fmt_mp->plane_fmt[0].sizeimage =
- pix_fmt_mp->width * pix_fmt_mp->height;
- pix_fmt_mp->plane_fmt[0].bytesperline = pix_fmt_mp->width;
-
- if (pix_fmt_mp->num_planes == 2) {
- pix_fmt_mp->plane_fmt[1].sizeimage =
- (pix_fmt_mp->width * pix_fmt_mp->height) / 2;
- pix_fmt_mp->plane_fmt[1].bytesperline =
- pix_fmt_mp->width;
- }
+ pix_fmt_mp->plane_fmt[0].sizeimage,
+ pix_fmt_mp->plane_fmt[1].sizeimage);
}
pix_fmt_mp->flags = 0;
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2,4/5] media: mediatek: vcodec: add MT21 format definition
From: Yunfei Dong @ 2024-04-09 6:44 UTC (permalink / raw)
To: Nícolas F . R . A . Prado, Nicolas Dufresne, Hans Verkuil,
AngeloGioacchino Del Regno, Benjamin Gaignard, Nathan Hebert,
Sebastian Fricke
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, Yunfei Dong,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240409064431.16909-1-yunfei.dong@mediatek.com>
Adding the definition of MT21 format to calculate bytesperline
and sizeimage of plane[0] and plane[1].
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
drivers/media/v4l2-core/v4l2-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index 0d5de132e07f..6dba989c2291 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -271,6 +271,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
.block_w = { 64, 64, 0, 0 }, .block_h = { 64, 64, 0, 0 }},
{ .format = V4L2_PIX_FMT_MM21, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 1, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 2,
.block_w = { 64, 64, 0, 0 }, .block_h = { 64, 64, 0, 0 }},
+ { .format = V4L2_PIX_FMT_MT21C, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 1, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 2,
+ .block_w = { 64, 64, 0, 0 }, .block_h = { 64, 64, 0, 0 }},
/* YUV planar formats */
{ .format = V4L2_PIX_FMT_NV12, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2,2/5] media: mediatek: vcodec: fix incorrect MT2R format information
From: Yunfei Dong @ 2024-04-09 6:44 UTC (permalink / raw)
To: Nícolas F . R . A . Prado, Nicolas Dufresne, Hans Verkuil,
AngeloGioacchino Del Regno, Benjamin Gaignard, Nathan Hebert,
Sebastian Fricke
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, Yunfei Dong,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240409064431.16909-1-yunfei.dong@mediatek.com>
Changing the bpp and hdiv values to make sure the bytesperline
of plane[0] and plane[1] are the same. The width and height are
64 align.
Fixes: 1dff2beb60d3 ("media: mediatek: vcodec: Add capture format to support 10bit raster mode")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
drivers/media/v4l2-core/v4l2-common.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index 8587cd14741c..cef1492dba22 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -267,8 +267,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
{ .format = V4L2_PIX_FMT_YUV48_12, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 1, .bpp = { 6, 0, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 1 },
{ .format = V4L2_PIX_FMT_MT2110T, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 5, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 1, .vdiv = 2,
.block_w = { 64, 64, 0, 0 }, .block_h = { 64, 64, 0, 0 }},
- { .format = V4L2_PIX_FMT_MT2110R, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 10, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 2, .vdiv = 2,
- .block_w = { 16, 8, 0, 0 }, .block_h = { 32, 16, 0, 0 }},
+ { .format = V4L2_PIX_FMT_MT2110R, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 5, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 1, .vdiv = 2,
+ .block_w = { 64, 64, 0, 0 }, .block_h = { 64, 64, 0, 0 }},
/* YUV planar formats */
{ .format = V4L2_PIX_FMT_NV12, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2,3/5] media: mediatek: vcodec: add MM21 format definition
From: Yunfei Dong @ 2024-04-09 6:44 UTC (permalink / raw)
To: Nícolas F . R . A . Prado, Nicolas Dufresne, Hans Verkuil,
AngeloGioacchino Del Regno, Benjamin Gaignard, Nathan Hebert,
Sebastian Fricke
Cc: Hsin-Yi Wang, Fritz Koenig, Daniel Vetter, Steve Cho, Yunfei Dong,
linux-media, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group
In-Reply-To: <20240409064431.16909-1-yunfei.dong@mediatek.com>
Adding the definition of MM21 format to calculate bytesperline
and sizeimage of plane[0] and plane[1].
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
drivers/media/v4l2-core/v4l2-common.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c
index cef1492dba22..0d5de132e07f 100644
--- a/drivers/media/v4l2-core/v4l2-common.c
+++ b/drivers/media/v4l2-core/v4l2-common.c
@@ -269,6 +269,8 @@ const struct v4l2_format_info *v4l2_format_info(u32 format)
.block_w = { 64, 64, 0, 0 }, .block_h = { 64, 64, 0, 0 }},
{ .format = V4L2_PIX_FMT_MT2110R, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 5, 5, 0, 0 }, .bpp_div = { 4, 4, 1, 1 }, .hdiv = 1, .vdiv = 2,
.block_w = { 64, 64, 0, 0 }, .block_h = { 64, 64, 0, 0 }},
+ { .format = V4L2_PIX_FMT_MM21, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 2, .comp_planes = 2, .bpp = { 1, 1, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 1, .vdiv = 2,
+ .block_w = { 64, 64, 0, 0 }, .block_h = { 64, 64, 0, 0 }},
/* YUV planar formats */
{ .format = V4L2_PIX_FMT_NV12, .pixel_enc = V4L2_PIXEL_ENC_YUV, .mem_planes = 1, .comp_planes = 2, .bpp = { 1, 2, 0, 0 }, .bpp_div = { 1, 1, 1, 1 }, .hdiv = 2, .vdiv = 2 },
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2] ASoC: dt-bindings: imx-audio-spdif: convert to YAML
From: Shengjiu Wang @ 2024-04-09 6:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Shengjiu Wang, lgirdwood, broonie, robh+dt,
krzysztof.kozlowski+dt, conor+dt, linux-sound, devicetree,
linux-kernel, shawnguo, s.hauer, kernel, festevam, imx,
linux-arm-kernel
In-Reply-To: <51e482b3-ffbf-46f9-972d-875d106c2474@linaro.org>
On Tue, Apr 9, 2024 at 2:30 PM Krzysztof Kozlowski
<krzysztof.kozlowski@linaro.org> wrote:
>
> On 09/04/2024 03:37, Shengjiu Wang wrote:
> > On Mon, Apr 8, 2024 at 11:06 PM Krzysztof Kozlowski
> > <krzysztof.kozlowski@linaro.org> wrote:
> >>
> >> On 08/04/2024 10:01, Shengjiu Wang wrote:
> >>>>> +
> >>>>> +anyOf:
> >>>>> + - required:
> >>>>> + - spdif-in
> >>>>> + - required:
> >>>>> + - spdif-out
> >>>>> + - required:
> >>>>> + - spdif-out
> >>>>> + - spdif-in
> >>>>
> >>>> Do you need the last required block?
> >>>
> >>> Yes, one of them or both are required.
> >>
> >> And? It's already there: that's the meaning of any. It is not oneOf...
> >> Before answering please test your changes and ideas. I pointed issue
> >> here and you responded just to close my comment. That does not make me
> >> happy, just wastes my time.
> >
> > Maybe I didn't express clearly.
> >
> > we need at least one of them (spdif-in, spdif-out) in the node. which means
> > that we need to select "spdif-in", or "spdif-out", or "spdif-in and
> > spdif-out".
> >
> > So my understanding is that need to use "anyOf", if it is wrong, please let
> > me know.
>
> Third time: it is wrong.
>
> Can you test the code instead continuing this discussion
Every time I change I definitely do dtbs_check test.
But There is no error reported by dtbs_check.
But finally I understand that
anyOf:
- required:
- spdif-in
- required:
- spdif-out
- required:
- spdif-out
- spdif-in
is equal to:
anyOf:
- required:
- spdif-in
- required:
- spdif-out
best regards
Shengjiu Wang
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v5 0/4] Update Energy Model after chip binning adjusted voltages
From: Lukasz Luba @ 2024-04-09 7:07 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: linux-kernel, linux-pm, dietmar.eggemann, linux-arm-kernel, sboyd,
nm, linux-samsung-soc, daniel.lezcano, viresh.kumar,
krzysztof.kozlowski, alim.akhtar, m.szyprowski, mhiramat
In-Reply-To: <CAJZ5v0jP8j3kcUFHx45_qpeOTa9THtP3qztC0oxuiohcYs5PPQ@mail.gmail.com>
On 4/8/24 15:06, Rafael J. Wysocki wrote:
> On Wed, Apr 3, 2024 at 5:49 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>>
>> Hi all,
>>
>> This is a follow-up patch aiming to add EM modification due to chip binning.
>> The first RFC and the discussion can be found here [1].
>>
>> It uses Exynos chip driver code as a 1st user. The EM framework has been
>> extended to handle this use case easily, when the voltage has been changed
>> after setup. On my Odroid-xu4 in some OPPs I can observe ~20% power difference.
>> According to that data in driver tables it could be up to ~29%.
>>
>> This chip binning is applicable to a lot of SoCs, so the EM framework should
>> make it easy to update. It uses the existing OPP and DT information to
>> re-calculate the new power values.
>>
>> It has dependency on Exynos SoC driver tree.
>>
>> Changes:
>> v5:
>> - adjusted aligning of the function arguments in patch 1/4 (Dietmar)
>> - adjusted the in-code comment patch 4/4 (Dietmar)
>> - added Reviewed-by to all patches (Dietmar)
>> v4:
>> - added asterisk in the comment section (test robot)
>> - change the patch 2/4 header name and use 'Refactor'
>> v3:
>> - updated header description patch 2/4 (Dietmar)
>> - removed 2 sentences from comment and adjusted in patch 3/4 (Dietmar)
>> - patch 4/4 re-phrased code comment (Dietmar)
>> - collected tags (Krzysztof, Viresh)
>> v2:
>> - removed 'ret' from error message which wasn't initialized (Christian)
>> v1:
>> - exported the OPP calculation function from the OPP/OF so it can be
>> used from EM fwk (Viresh)
>> - refactored EM updating function to re-use common code
>> - added new EM function which can be used by chip device drivers which
>> modify the voltage in OPPs
>> RFC is at [1]
>>
>> Regards,
>> Lukasz Luba
>>
>> [1] https://lore.kernel.org/lkml/20231220110339.1065505-1-lukasz.luba@arm.com/
>>
>> Lukasz Luba (4):
>> OPP: OF: Export dev_opp_pm_calc_power() for usage from EM
>> PM: EM: Refactor em_adjust_new_capacity()
>> PM: EM: Add em_dev_update_chip_binning()
>> soc: samsung: exynos-asv: Update Energy Model after adjusting voltage
>>
>> drivers/opp/of.c | 17 +++--
>> drivers/soc/samsung/exynos-asv.c | 10 ++-
>> include/linux/energy_model.h | 5 ++
>> include/linux/pm_opp.h | 8 +++
>> kernel/power/energy_model.c | 106 +++++++++++++++++++++++++------
>> 5 files changed, 121 insertions(+), 25 deletions(-)
>>
>> --
>
> All patches in the series applied as 6.10 material, thanks!
Thank you Rafael!
Regards,
Lukasz
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3] arm64: dts: imx8ulp: add caam jr
From: Pankaj Gupta @ 2024-04-09 7:06 UTC (permalink / raw)
To: robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo, s.hauer,
kernel, festevam, linux-imx, peng.fan, ping.bai, haibo.chen,
devicetree, linux-arm-kernel, linux-kernel
Cc: Pankaj Gupta, Varun Sethi
Add crypto node in device tree for:
- CAAM job-ring
Signed-off-by: Varun Sethi <v.sethi@nxp.com>
Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 32 ++++++++++++++++++++++
1 file changed, 32 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
index 8a6596d5a581..946f2b68d16f 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
@@ -252,6 +252,38 @@ pcc3: clock-controller@292d0000 {
#reset-cells = <1>;
};
+ crypto: crypto@292e0000 {
+ compatible = "fsl,sec-v4.0";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x292e0000 0x10000>;
+ ranges = <0 0x292e0000 0x10000>;
+
+ sec_jr0: jr@1000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x1000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr1: jr@2000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x2000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr2: jr@3000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x3000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+
+ sec_jr3: jr@4000 {
+ compatible = "fsl,sec-v4.0-job-ring";
+ reg = <0x4000 0x1000>;
+ interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
tpm5: tpm@29340000 {
compatible = "fsl,imx8ulp-tpm", "fsl,imx7ulp-tpm";
reg = <0x29340000 0x1000>;
--
2.34.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/4] coresight: Add support for multiple output ports on the funnel
From: Suzuki K Poulose @ 2024-04-09 7:13 UTC (permalink / raw)
To: Tao Zhang, Mathieu Poirier, Alexander Shishkin, Konrad Dybcio,
Mike Leach, Rob Herring, Krzysztof Kozlowski
Cc: Jinlong Mao, Leo Yan, Greg Kroah-Hartman, coresight,
linux-arm-kernel, linux-kernel, devicetree, Tingwei Zhang,
Yuanfang Zhang, Trilok Soni, Song Chai, linux-arm-msm, andersson
In-Reply-To: <ffce4577-b0f9-4af3-a379-0385a02ddae8@quicinc.com>
Hi
On 29/03/2024 09:27, Tao Zhang wrote:
>
> On 3/22/2024 12:41 AM, Suzuki K Poulose wrote:
>> On 21/03/2024 08:32, Tao Zhang wrote:
>>> Funnel devices are now capable of supporting multiple-inputs and
>>> multiple-outputs configuration with in built hardware filtering
>>> for TPDM devices. Add software support to this function. Output
>>> port is selected according to the source in the trace path.
>>>
>>> The source of the input port on funnels will be marked in the
>>> device tree.
>>> e.g.
>>> tpdm@xxxxxxx {
>>> ... ... ... ...
>>> };
>>>
>>> funnel_XXX: funnel@xxxxxxx {
>>> ... ... ... ...
>>> out-ports {
>>> ... ... ... ...
>>> port@x {
>>> ... ... ... ...
>>> label = "xxxxxxx.tpdm"; <-- To label the source
>>> }; corresponding to the output
>>> ... ... ... ... connection "port@x". And this
>>> }; is a hardware static connections.
>>> ... ... ... ... Here needs to refer to hardware
>>> }; design.
>>>
>>> Then driver will parse the source label marked in the device tree, and
>>> save it to the coresight path. When the function needs to know the
>>> source label, it could obtain it from coresight path parameter. Finally,
>>> the output port knows which source it corresponds to, and it also knows
>>> which input port it corresponds to.
>>
>> Why do we need labels ? We have connection information for all devices
>> (both in and out), so, why do we need this label to find a device ?
>
> Because our funnel's design has multi-output ports, the data stream will
> not
>
> know which output port should pass in building the data trace path. This
> source
>
> label can make the data stream find the right output port to go.
>
>>
>> And also, I thought TPDM is a source device, why does a funnel output
>> port link to a source ?
>
> No, this label doesn't mean this funnel output port link to a source, it
> just let
>
> the output port know its data source.
>
>>
>> Are these funnels programmable ? Or, are they static ? If they are
>> static, do these need to be described in the DT ? If they are simply
>> acting as a "LINK" (or HWFIFO ?)
>
> These funnels are static, and we will add the "label" to the DT to
> describe the
>
> multi-output ports for these funnels.
I think there is still a bit of confusion. By "Dynamic" I mean,
the "dynamic funnel" (explicit port enablement via MMIO) vs "static
funnel" (no programming, always ON).
So, coming to your example, do we need to "explicitly" enable trace flow
for an "input" and/or an "output" port in your "funnel" ?
>
> "If they are simply acting as a "LINK" (or HWFIFO ?) " I'm not sure
> what's the meaning
i.e, Like TMC-ETF in HWFIFO mode. In this mode, the TMC-ETF is acting
like a cache for easing ATB data load, by providing h/w buffering.
(In your case, it may not be providing any buffering, it doesn't matter
either way, as it is not visible to the driver).
Suzuki
>
> of this. Could you describe it in detail?
>
>
> Best,
>
> Tao
>
>>
>> Suzuki
>>
>>>
>>> Signed-off-by: Tao Zhang <quic_taozha@quicinc.com>
>>> ---
>>> drivers/hwtracing/coresight/coresight-core.c | 81 ++++++++++++++++---
>>> .../hwtracing/coresight/coresight-platform.c | 5 ++
>>> include/linux/coresight.h | 2 +
>>> 3 files changed, 75 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/hwtracing/coresight/coresight-core.c
>>> b/drivers/hwtracing/coresight/coresight-core.c
>>> index 5dde597403b3..b1b5e6d9ec7a 100644
>>> --- a/drivers/hwtracing/coresight/coresight-core.c
>>> +++ b/drivers/hwtracing/coresight/coresight-core.c
>>> @@ -113,15 +113,63 @@ struct coresight_device
>>> *coresight_get_percpu_sink(int cpu)
>>> }
>>> EXPORT_SYMBOL_GPL(coresight_get_percpu_sink);
>>> +static struct coresight_device *coresight_get_source(struct
>>> list_head *path)
>>> +{
>>> + struct coresight_device *csdev;
>>> +
>>> + if (!path)
>>> + return NULL;
>>> +
>>> + csdev = list_first_entry(path, struct coresight_node, link)->csdev;
>>> + if (csdev->type != CORESIGHT_DEV_TYPE_SOURCE)
>>> + return NULL;
>>> +
>>> + return csdev;
>>> +}
>>> +
>>> +/**
>>> + * coresight_source_filter - checks whether the connection matches
>>> the source
>>> + * of path if connection is binded to specific source.
>>> + * @path: The list of devices
>>> + * @conn: The connection of one outport
>>> + *
>>> + * Return zero if the connection doesn't have a source binded or
>>> source of the
>>> + * path matches the source binds to connection.
>>> + */
>>> +static int coresight_source_filter(struct list_head *path,
>>> + struct coresight_connection *conn)
>>> +{
>>> + int ret = 0;
>>> + struct coresight_device *source = NULL;
>>> +
>>> + if (conn->source_label == NULL)
>>> + return ret;
>>> +
>>> + source = coresight_get_source(path);
>>> + if (source == NULL)
>>> + return ret;
>>> +
>>> + if (strstr(kobject_get_path(&source->dev.kobj, GFP_KERNEL),
>>> + conn->source_label))
>>> + ret = 0;
>>> + else
>>> + ret = -1;
>>> +
>>> + return ret;
>>> +}
>>> +
>>> static struct coresight_connection *
>>> coresight_find_out_connection(struct coresight_device *src_dev,
>>> - struct coresight_device *dest_dev)
>>> + struct coresight_device *dest_dev,
>>> + struct list_head *path)
>>> {
>>> int i;
>>> struct coresight_connection *conn;
>>> for (i = 0; i < src_dev->pdata->nr_outconns; i++) {
>>> conn = src_dev->pdata->out_conns[i];
>>> + if (coresight_source_filter(path, conn))
>>> + continue;
>>> if (conn->dest_dev == dest_dev)
>>> return conn;
>>> }
>>> @@ -312,7 +360,8 @@ static void coresight_disable_sink(struct
>>> coresight_device *csdev)
>>> static int coresight_enable_link(struct coresight_device *csdev,
>>> struct coresight_device *parent,
>>> - struct coresight_device *child)
>>> + struct coresight_device *child,
>>> + struct list_head *path)
>>> {
>>> int ret = 0;
>>> int link_subtype;
>>> @@ -321,8 +370,8 @@ static int coresight_enable_link(struct
>>> coresight_device *csdev,
>>> if (!parent || !child)
>>> return -EINVAL;
>>> - inconn = coresight_find_out_connection(parent, csdev);
>>> - outconn = coresight_find_out_connection(csdev, child);
>>> + inconn = coresight_find_out_connection(parent, csdev, path);
>>> + outconn = coresight_find_out_connection(csdev, child, path);
>>> link_subtype = csdev->subtype.link_subtype;
>>> if (link_subtype == CORESIGHT_DEV_SUBTYPE_LINK_MERG &&
>>> IS_ERR(inconn))
>>> @@ -341,7 +390,8 @@ static int coresight_enable_link(struct
>>> coresight_device *csdev,
>>> static void coresight_disable_link(struct coresight_device *csdev,
>>> struct coresight_device *parent,
>>> - struct coresight_device *child)
>>> + struct coresight_device *child,
>>> + struct list_head *path)
>>> {
>>> int i;
>>> int link_subtype;
>>> @@ -350,8 +400,8 @@ static void coresight_disable_link(struct
>>> coresight_device *csdev,
>>> if (!parent || !child)
>>> return;
>>> - inconn = coresight_find_out_connection(parent, csdev);
>>> - outconn = coresight_find_out_connection(csdev, child);
>>> + inconn = coresight_find_out_connection(parent, csdev, path);
>>> + outconn = coresight_find_out_connection(csdev, child, path);
>>> link_subtype = csdev->subtype.link_subtype;
>>> if (link_ops(csdev)->disable) {
>>> @@ -507,7 +557,7 @@ static void coresight_disable_path_from(struct
>>> list_head *path,
>>> case CORESIGHT_DEV_TYPE_LINK:
>>> parent = list_prev_entry(nd, link)->csdev;
>>> child = list_next_entry(nd, link)->csdev;
>>> - coresight_disable_link(csdev, parent, child);
>>> + coresight_disable_link(csdev, parent, child, path);
>>> break;
>>> default:
>>> break;
>>> @@ -588,7 +638,7 @@ int coresight_enable_path(struct list_head *path,
>>> enum cs_mode mode,
>>> case CORESIGHT_DEV_TYPE_LINK:
>>> parent = list_prev_entry(nd, link)->csdev;
>>> child = list_next_entry(nd, link)->csdev;
>>> - ret = coresight_enable_link(csdev, parent, child);
>>> + ret = coresight_enable_link(csdev, parent, child, path);
>>> if (ret)
>>> goto err;
>>> break;
>>> @@ -802,7 +852,8 @@ static void coresight_drop_device(struct
>>> coresight_device *csdev)
>>> */
>>> static int _coresight_build_path(struct coresight_device *csdev,
>>> struct coresight_device *sink,
>>> - struct list_head *path)
>>> + struct list_head *path,
>>> + struct coresight_device *source)
>>> {
>>> int i, ret;
>>> bool found = false;
>>> @@ -814,7 +865,7 @@ static int _coresight_build_path(struct
>>> coresight_device *csdev,
>>> if (coresight_is_percpu_source(csdev) &&
>>> coresight_is_percpu_sink(sink) &&
>>> sink == per_cpu(csdev_sink,
>>> source_ops(csdev)->cpu_id(csdev))) {
>>> - if (_coresight_build_path(sink, sink, path) == 0) {
>>> + if (_coresight_build_path(sink, sink, path, source) == 0) {
>>> found = true;
>>> goto out;
>>> }
>>> @@ -825,8 +876,12 @@ static int _coresight_build_path(struct
>>> coresight_device *csdev,
>>> struct coresight_device *child_dev;
>>> child_dev = csdev->pdata->out_conns[i]->dest_dev;
>>> + if (csdev->pdata->out_conns[i]->source_label &&
>>> + !strstr(kobject_get_path(&source->dev.kobj, GFP_KERNEL),
>>> + csdev->pdata->out_conns[i]->source_label))
>>> + continue;
>>> if (child_dev &&
>>> - _coresight_build_path(child_dev, sink, path) == 0) {
>>> + _coresight_build_path(child_dev, sink, path, source) ==
>>> 0) {
>>> found = true;
>>> break;
>>> }
>>> @@ -871,7 +926,7 @@ struct list_head *coresight_build_path(struct
>>> coresight_device *source,
>>> INIT_LIST_HEAD(path);
>>> - rc = _coresight_build_path(source, sink, path);
>>> + rc = _coresight_build_path(source, sink, path, source);
>>> if (rc) {
>>> kfree(path);
>>> return ERR_PTR(rc);
>>> diff --git a/drivers/hwtracing/coresight/coresight-platform.c
>>> b/drivers/hwtracing/coresight/coresight-platform.c
>>> index 9d550f5697fa..f553fb20966d 100644
>>> --- a/drivers/hwtracing/coresight/coresight-platform.c
>>> +++ b/drivers/hwtracing/coresight/coresight-platform.c
>>> @@ -205,6 +205,7 @@ static int of_coresight_parse_endpoint(struct
>>> device *dev,
>>> struct fwnode_handle *rdev_fwnode;
>>> struct coresight_connection conn = {};
>>> struct coresight_connection *new_conn;
>>> + const char *label;
>>> do {
>>> /* Parse the local port details */
>>> @@ -243,6 +244,10 @@ static int of_coresight_parse_endpoint(struct
>>> device *dev,
>>> conn.dest_fwnode = fwnode_handle_get(rdev_fwnode);
>>> conn.dest_port = rendpoint.port;
>>> + conn.source_label = NULL;
>>> + if (!of_property_read_string(ep, "label", &label))
>>> + conn.source_label = label;
>>> +
>>> new_conn = coresight_add_out_conn(dev, pdata, &conn);
>>> if (IS_ERR_VALUE(new_conn)) {
>>> fwnode_handle_put(conn.dest_fwnode);
>>> diff --git a/include/linux/coresight.h b/include/linux/coresight.h
>>> index e8b6e388218c..a9c06ef9bbb2 100644
>>> --- a/include/linux/coresight.h
>>> +++ b/include/linux/coresight.h
>>> @@ -167,6 +167,7 @@ struct coresight_desc {
>>> * struct coresight_connection - representation of a single connection
>>> * @src_port: a connection's output port number.
>>> * @dest_port: destination's input port number @src_port is
>>> connected to.
>>> + * @source_label: source component's label.
>>> * @dest_fwnode: destination component's fwnode handle.
>>> * @dest_dev: a @coresight_device representation of the component
>>> connected to @src_port. NULL until the device is created
>>> @@ -195,6 +196,7 @@ struct coresight_desc {
>>> struct coresight_connection {
>>> int src_port;
>>> int dest_port;
>>> + const char *source_label;
>>> struct fwnode_handle *dest_fwnode;
>>> struct coresight_device *dest_dev;
>>> struct coresight_sysfs_link *link;
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH net-next v11 00/13] Introduce PHY listing and link_topology tracking
From: Maxime Chevallier @ 2024-04-09 7:22 UTC (permalink / raw)
To: Andrew Lunn
Cc: patchwork-bot+netdevbpf, davem, netdev, linux-kernel,
thomas.petazzoni, kuba, edumazet, pabeni, linux, linux-arm-kernel,
christophe.leroy, herve.codina, f.fainelli, hkallweit1,
vladimir.oltean, kory.maincent, jesse.brandeburg, corbet, kabel,
piergiorgio.beruto, o.rempel, nicveronese, horms, mwojtas
In-Reply-To: <6c5f731e-a21e-4a4c-87a4-9585b2267c9e@lunn.ch>
On Tue, 9 Apr 2024 01:50:54 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> > > Here is the summary with links:
> > > - [net-next,v11,01/13] net: phy: Introduce ethernet link topology representation
> > > https://git.kernel.org/netdev/net-next/c/6916e461e793
> > > - [net-next,v11,02/13] net: sfp: pass the phy_device when disconnecting an sfp module's PHY
> > > https://git.kernel.org/netdev/net-next/c/0ec5ed6c130e
> > > - [net-next,v11,03/13] net: phy: add helpers to handle sfp phy connect/disconnect
> > > https://git.kernel.org/netdev/net-next/c/e75e4e074c44
> > > - [net-next,v11,04/13] net: sfp: Add helper to return the SFP bus name
> > > https://git.kernel.org/netdev/net-next/c/fdd353965b52
> > > - [net-next,v11,05/13] net: ethtool: Allow passing a phy index for some commands
> > > https://git.kernel.org/netdev/net-next/c/841942bc6212
> > > - [net-next,v11,06/13] netlink: specs: add phy-index as a header parameter
> > > (no matching commit)
> > > - [net-next,v11,07/13] net: ethtool: Introduce a command to list PHYs on an interface
> > > (no matching commit)
> > > - [net-next,v11,08/13] netlink: specs: add ethnl PHY_GET command set
> > > (no matching commit)
> > > - [net-next,v11,09/13] net: ethtool: plca: Target the command to the requested PHY
> > > (no matching commit)
> > > - [net-next,v11,10/13] net: ethtool: pse-pd: Target the command to the requested PHY
> > > (no matching commit)
> > > - [net-next,v11,11/13] net: ethtool: cable-test: Target the command to the requested PHY
> > > (no matching commit)
> > > - [net-next,v11,12/13] net: ethtool: strset: Allow querying phy stats by index
> > > (no matching commit)
> > > - [net-next,v11,13/13] Documentation: networking: document phy_link_topology
> > > (no matching commit)
> >
> > It looks like commits 6 to 13 didn't make it upstream with (the "no
> > matching commit" messages above). Is that expected ?
>
> They are not in net-next, unlike 1-5.
>
> You probably need to repost them.
I'll repost indeed.
Thanks Andrew BTW for all the reviews !
Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3] arm64: dts: imx8ulp: add caam jr
From: Krzysztof Kozlowski @ 2024-04-09 7:26 UTC (permalink / raw)
To: Pankaj Gupta, robh+dt, krzysztof.kozlowski+dt, conor+dt, shawnguo,
s.hauer, kernel, festevam, linux-imx, peng.fan, ping.bai,
haibo.chen, devicetree, linux-arm-kernel, linux-kernel
Cc: Varun Sethi
In-Reply-To: <20240409070616.3868152-1-pankaj.gupta@nxp.com>
On 09/04/2024 09:06, Pankaj Gupta wrote:
> Add crypto node in device tree for:
> - CAAM job-ring
>
> Signed-off-by: Varun Sethi <v.sethi@nxp.com>
> Signed-off-by: Pankaj Gupta <pankaj.gupta@nxp.com>
v3? Where is the changelog? What was happening here?
> ---
> arch/arm64/boot/dts/freescale/imx8ulp.dtsi | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> index 8a6596d5a581..946f2b68d16f 100644
> --- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> @@ -252,6 +252,38 @@ pcc3: clock-controller@292d0000 {
> #reset-cells = <1>;
> };
>
> + crypto: crypto@292e0000 {
> + compatible = "fsl,sec-v4.0";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0x292e0000 0x10000>;
> + ranges = <0 0x292e0000 0x10000>;
Keep the order as requested in DTS coding style.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v14 2/4] dt-bindings: remoteproc: add Tightly Coupled Memory (TCM) bindings
From: Krzysztof Kozlowski @ 2024-04-09 7:29 UTC (permalink / raw)
To: Tanmay Shah, andersson, mathieu.poirier, robh,
krzysztof.kozlowski+dt, conor+dt, michal.simek, ben.levinsky
Cc: linux-remoteproc, devicetree, linux-arm-kernel, linux-kernel,
Radhey Shyam Pandey
In-Reply-To: <20240408205313.3552165-3-tanmay.shah@amd.com>
On 08/04/2024 22:53, Tanmay Shah wrote:
> From: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
>
> Introduce bindings for TCM memory address space on AMD-xilinx Zynq
> UltraScale+ platform. It will help in defining TCM in device-tree
> and make it's access platform agnostic and data-driven.
>
> Tightly-coupled memories(TCMs) are low-latency memory that provides
> predictable instruction execution and predictable data load/store
> timing. Each Cortex-R5F processor contains two 64-bit wide 64 KB memory
> banks on the ATCM and BTCM ports, for a total of 128 KB of memory.
>
> The TCM resources(reg, reg-names and power-domain) are documented for
> each TCM in the R5 node. The reg and reg-names are made as required
> properties as we don't want to hardcode TCM addresses for future
> platforms and for zu+ legacy implementation will ensure that the
> old dts w/o reg/reg-names works and stable ABI is maintained.
>
> It also extends the examples for TCM split and lockstep modes.
>
> Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
> Signed-off-by: Tanmay Shah <tanmay.shah@amd.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ 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