Re: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
On 7/8/2013 3:42 AM, Russell King - ARM Linux wrote: The problem is the way the arm_dma_limit is set up, all dma allocations are currently broken regardless of if the actual device supports 64-bit addresses or not. Please explain this statement. The statement was a bit shortsighted given recent discussions. My point was that on LPAE systems right now without ZONE_DMA, the allocation fails by default (i.e. no call to set_mask) even if the device could support 64-bit physical memory. Based on this thread though, drivers should stop assuming the dma_mask will be set up properly and always set the mask appropriately. The conclusion also seems to be that if devices on an LPAE system can't handle > 32-bit addresses and want to limit via mask, ZONE_DMA must be set up. Please correct me if I misunderstood anything. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
On 7/3/2013 7:15 AM, Ming Lei wrote: On Sat, Apr 27, 2013 at 5:32 AM, Rob Herring wrote: On 04/26/2013 03:31 PM, Laura Abbott wrote: Currently, of_platform_device_create_pdata always sets the coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA, arm_dma_limit gets set to ~0 or 0x on LPAE based systems. Since arm_dma_limit represents the smallest dma_mask on the system, the default of 32 bits prevents any dma_coherent allocation from succeeding unless clients manually set the dma mask first. Rather than make every client on an LPAE system set the mask manually, account for the size of dma_addr_t when setting the coherent mask. Signed-off-by: Laura Abbott --- drivers/of/platform.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..5f0ba94 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,7 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev->archdata.dma_mask = 0xUL; #endif - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); + dev->dev.coherent_dma_mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8); This is going to change the mask from 32 to 64 bits on 64-bit powerpc and others possibly. Maybe it doesn't matter. I think it doesn't, but I'm not sure enough to apply for 3.10. So I'll queue it for 3.11. Without the patch, LPAE enabled board may not boot at all, but looks it still isn't in -next tree. But I am wondering if it is a correct approach, because enabling LPAE doesn't mean the I/O devices can support DMA to/from 64bit address, and it is very probably devices can't do it at all. The problem is the way the arm_dma_limit is set up, all dma allocations are currently broken regardless of if the actual device supports 64-bit addresses or not. Another way is to always set arm_dma_limit as 0x when CONFIG_ZONE_DMA is unset, and let driver override device's dma mask if the device supports 64bit DMA. I previously asked about the arm_dma_limit and was told that the current behavior is the correct approach (see https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-April/032729.html and https://lists.ozlabs.org/pipermail/devicetree-discuss/2013-April/032690.html) The point here is to set the mask to something reasonable such that allocations can succeed by default. If devices can't use part of the memory space they can adjust the limit accordingly. Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH V3] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
Currently, of_platform_device_create_pdata always sets the coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA, arm_dma_limit gets set to ~0 or 0x on LPAE based systems. Since arm_dma_limit represents the smallest dma_mask on the system, the default of 32 bits prevents any dma_coherent allocation from succeeding unless clients manually set the dma mask first. Rather than make every client on an LPAE system set the mask manually, account for the size of dma_addr_t when setting the coherent mask. Signed-off-by: Laura Abbott --- drivers/of/platform.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..5f0ba94 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,7 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev->archdata.dma_mask = 0xUL; #endif - dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); + dev->dev.coherent_dma_mask = DMA_BIT_MASK(sizeof(dma_addr_t) * 8); dev->dev.bus = &platform_bus_type; dev->dev.platform_data = platform_data; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
On 4/26/2013 1:03 PM, Rob Herring wrote: On 04/26/2013 01:06 PM, Laura Abbott wrote: Currently, of_platform_device_create_pdata always sets the coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA, arm_dma_limit gets set to ~0 or 0x on LPAE based systems. Since arm_dma_limit represents the smallest dma_mask on the system, the default of 32 bits prevents any dma_coherent allocation from succeeding unless clients manually set the dma mask first. Rather than make every client on an LPAE system set the mask, set the mask to a 64 bit value on systems with 64-bit dma addresses. Signed-off-by: Laura Abbott --- drivers/of/platform.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..c669ab4 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev->archdata.dma_mask = 0xUL; #endif +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT + dev->dev.coherent_dma_mask = DMA_BIT_MASK(64); +#else dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); +#endif How about "DMA_BIT_MASK(sizeof(dma_addr_t) * 8))" and avoid the ifdef. Sounds good. Rob Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2] of: Set the DMA mask to 64 bits when dma_addr_t is 64-bits
Currently, of_platform_device_create_pdata always sets the coherent DMA mask to 32 bits. On ARM systems without CONFIG_ZONE_DMA, arm_dma_limit gets set to ~0 or 0x on LPAE based systems. Since arm_dma_limit represents the smallest dma_mask on the system, the default of 32 bits prevents any dma_coherent allocation from succeeding unless clients manually set the dma mask first. Rather than make every client on an LPAE system set the mask, set the mask to a 64 bit value on systems with 64-bit dma addresses. Signed-off-by: Laura Abbott --- drivers/of/platform.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..c669ab4 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev->archdata.dma_mask = 0xUL; #endif +#ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT + dev->dev.coherent_dma_mask = DMA_BIT_MASK(64); +#else dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); +#endif dev->dev.bus = &platform_bus_type; dev->dev.platform_data = platform_data; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
On 4/26/2013 3:00 AM, Catalin Marinas wrote: On Thu, Apr 25, 2013 at 06:09:57PM +0100, Laura Abbott wrote: On 4/25/2013 6:33 AM, Catalin Marinas wrote: On Wed, Apr 24, 2013 at 01:50:49AM +0100, Laura Abbott wrote: By default on ARM systems, the coherent DMA mask (lowest address) is set to ~0 or 0x. Currently, of_platform_device_create_pdata sets the coherent DMA mask to 32 bits. This prevents coherent dma allocations from working by default without clients setting the DMA mask. Rather than make every client on an LPAE system set the mask, set the mask to a 64 bit value on ARM LPAE systems. Signed-off-by: Laura Abbott --- drivers/of/platform.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..18b69c1 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev->archdata.dma_mask = 0xUL; #endif +#ifdef CONFIG_ARM_LPAE + dev->dev.coherent_dma_mask = DMA_BIT_MASK(64); +#else dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); +#endif I wouldn't add CONFIG_ARM_LPAE checks in here, you can use CONFIG_ARCH_DMA_ADDR_T_64BIT (types.h uses this for the dma_addr_t definition). I thought about this as well but in arch/arm/mm/mm.h: #ifdef CONFIG_ZONE_DMA extern phys_addr_t arm_dma_limit; #else #define arm_dma_limit ((phys_addr_t)~0) #endif Russell replied already on the meaning of this variable, so I don't think its type is relevant here. It is also used when calling dma_contiguous_reserve() which takes a phys_addr_t. arm_dma_limit is explicitly cast to phys_addr_t, which means that arm_dma_limit will be always be sizeof(phys_addr_t) regardless of sizeof(dma_addr_t). Is it safe to assume that CONFIG_ARCH_DMA_ADDR_T_64BIT will always be selected if sizeof(phys_addr_t) == 8? If not, we've defeated the point of the patch. sizeof(dma_addr_t) <= sizeof(phys_addr_t). I had this discussion with Russell when upstreaming the LPAE patches and the conclusion was that while the phys_addr_t is 64-bit with LPAE, the dma_addr_t size is a feature of the SoC and must be selected independently. However, I think with multi-platform support and LPAE enabled, we should probably set the dma_addr_t to 64-bit. Alternatively, should the type of arm_dma_limit be dma_addr_t instead of phys_addr_t? arm_dma_limit should be phys_addr_t since this is an address as seen by the CPU. dma_addr_t OTOH is a bus address as seen by the device. You can in theory have a DMA buffer with physical address beyond 32-bit (from a CPU perspective) but with a bus address withing 32-bit as seen by the device. There is some confusion in the kernel (you can google for past discussions) around the meaning of the DMA mask. If your RAM starts at 0, it doesn't matter much and there are several such assumptions in the kernel. So I still consider that you should use #ifdef CONFIG_ARCH_DMA_ADDR_T_64BIT and select this option on your platform. Thanks for the clarification on all this. It's non-obvious but I see why things are set up the way they are. I'll re-submit with CONFIG_ARCH_DMA_ADDR_T_64BIT. Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
On 4/25/2013 6:33 AM, Catalin Marinas wrote: On Wed, Apr 24, 2013 at 01:50:49AM +0100, Laura Abbott wrote: By default on ARM systems, the coherent DMA mask (lowest address) is set to ~0 or 0x. Currently, of_platform_device_create_pdata sets the coherent DMA mask to 32 bits. This prevents coherent dma allocations from working by default without clients setting the DMA mask. Rather than make every client on an LPAE system set the mask, set the mask to a 64 bit value on ARM LPAE systems. Signed-off-by: Laura Abbott --- drivers/of/platform.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..18b69c1 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev->archdata.dma_mask = 0xUL; #endif +#ifdef CONFIG_ARM_LPAE + dev->dev.coherent_dma_mask = DMA_BIT_MASK(64); +#else dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); +#endif I wouldn't add CONFIG_ARM_LPAE checks in here, you can use CONFIG_ARCH_DMA_ADDR_T_64BIT (types.h uses this for the dma_addr_t definition). I thought about this as well but in arch/arm/mm/mm.h: #ifdef CONFIG_ZONE_DMA extern phys_addr_t arm_dma_limit; #else #define arm_dma_limit ((phys_addr_t)~0) #endif arm_dma_limit is explicitly cast to phys_addr_t, which means that arm_dma_limit will be always be sizeof(phys_addr_t) regardless of sizeof(dma_addr_t). Is it safe to assume that CONFIG_ARCH_DMA_ADDR_T_64BIT will always be selected if sizeof(phys_addr_t) == 8? If not, we've defeated the point of the patch. Alternatively, should the type of arm_dma_limit be dma_addr_t instead of phys_addr_t? Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] of: Set the DMA mask to 64 bits on ARM LPAE systems
By default on ARM systems, the coherent DMA mask (lowest address) is set to ~0 or 0x. Currently, of_platform_device_create_pdata sets the coherent DMA mask to 32 bits. This prevents coherent dma allocations from working by default without clients setting the DMA mask. Rather than make every client on an LPAE system set the mask, set the mask to a 64 bit value on ARM LPAE systems. Signed-off-by: Laura Abbott --- drivers/of/platform.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 0970505..18b69c1 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -214,7 +214,11 @@ struct platform_device *of_platform_device_create_pdata( #if defined(CONFIG_MICROBLAZE) dev->archdata.dma_mask = 0xUL; #endif +#ifdef CONFIG_ARM_LPAE + dev->dev.coherent_dma_mask = DMA_BIT_MASK(64); +#else dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); +#endif dev->dev.bus = &platform_bus_type; dev->dev.platform_data = platform_data; -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC/PATCH v2 2/2] drivers: dma-contiguous: add initialization from device tree
Hi,
On 4/11/2013 4:22 AM, Marek Szyprowski wrote:
...
+
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 01fe743..6a8abab 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,6 +24,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -37,6 +40,7 @@ struct cma {
unsigned long base_pfn;
unsigned long count;
unsigned long *bitmap;
+ charfull_name[32];
};
static DEFINE_MUTEX(cma_mutex);
@@ -133,6 +137,53 @@ static __init int cma_activate_area(struct cma *cma)
return 0;
}
+/*/
+
+#ifdef CONFIG_OF
+int __init cma_fdt_scan(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ static int level;
+ phys_addr_t base, size;
+ unsigned long len;
+ struct cma *cma;
+ __be32 *prop;
+
+ if (depth == 1 && strcmp(uname, "chosen") == 0) {
+ level = depth;
+ return 0;
+ }
+
+ if (depth == 2 && strcmp(uname, "contiguous-memory") == 0) {
+ level = depth;
+ return 0;
+ }
+
+ if (level != 2 || depth != 3 || strncmp(uname, "region@", 7) != 0)
+ return 0;
+
Requiring the region@ label does not work if you want two dynamically
placed regions (i.e. two region@0). The devicetree will take the last
region@0 entry and ignore all the other ones
+ prop = of_get_flat_dt_prop(node, "reg", &len);
+ if (!prop || (len != 2 * sizeof(unsigned long)))
+ return 0;
+
+ base = be32_to_cpu(prop[0]);
+ size = be32_to_cpu(prop[1]);
+
+ pr_info("Found %s, memory base %lx, size %ld MiB\n", uname,
+ (unsigned long)base, (unsigned long)size / SZ_1M);
+
+ dma_contiguous_reserve_area(size, base, 0, &cma);
+
Need to check the return of dma_contiguous_reserve_area, else there is
an abort when trying to access cma->name on an error
+ strcpy(cma->full_name, uname);
+
+ if (of_get_flat_dt_prop(node, "linux,default-contiguous-region", NULL))
{
+
+ dma_contiguous_default_area = cma;
+ }
+ return 0;
+}
+#endif
+
/**
* dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
* @limit: End address of the reserved memory (optional, 0 for any).
if the contiguous region isn't set via devicetree,
default_area->full_name needs to be set in dma_contiguous_reserve, else
we get wrong associations in scan_cma_node.
@@ -149,6 +200,10 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
+#ifdef CONFIG_OF
+ of_scan_flat_dt(cma_fdt_scan, NULL);
+#endif
+
if (size_cmdline != -1) {
sel_size = size_cmdline;
} else {
@@ -265,6 +320,71 @@ int __init dma_contiguous_add_device(struct device *dev,
struct cma *cma)
return 0;
}
+#ifdef CONFIG_OF
+static struct cma_map {
+ struct cma *cma;
+ struct device_node *node;
+} cma_maps[MAX_CMA_AREAS];
+static unsigned cma_map_count;
+
+static void cma_assign_device_from_dt(struct device *dev)
+{
+ int i;
+ for (i=0; iof_node) {
+ dev_set_cma_area(dev, cma_maps[i].cma);
+ pr_info("Assigned CMA %s to %s device\n",
+ cma_maps[i].cma->full_name,
+ dev_name(dev));
+ }
+ }
+}
+
+static int cma_device_init_notifier_call(struct notifier_block *nb,
+unsigned long event, void *data)
+{
+ struct device *dev = data;
+ if (event == BUS_NOTIFY_ADD_DEVICE && dev->of_node)
+ cma_assign_device_from_dt(dev);
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block cma_dev_init_nb = {
+ .notifier_call = cma_device_init_notifier_call,
+};
+
+void scan_cma_nodes(void)
+{
+ struct device_node *parent =
of_find_node_by_path("/chosen/contiguous-memory");
+ struct device_node *child;
+
+ if (!parent)
+ return;
+
+ for_each_child_of_node(parent, child) {
+ struct cma *cma = NULL;
+ int i;
+
+ for (i=0; ifull_name, cma_areas[i].full_name))
+ cma = &cma_areas[i];
break out of the loop once the area is found?
Also, how will the code deal with region names that are substrings of
each other e.g.
region@100
region@1000
+ if (!cma)
+ continue;
+
+ for (i=0;; i++) {
+ struct device_node *node;
+ node = of_parse_phandle(child, "device", i);
+ if (!node)
+ break;
+
+ cma_maps[cm
Re: [Linaro-mm-sig] [PATCH 2/2] drivers: dma-contiguous: add initialization from device tree
On 3/15/2013 8:21 AM, Marek Szyprowski wrote: This scheme of associating devices with CMA regions by base does not work if you want to let CMA figure out where to place the region (base = 0). Can we use the name to associate the device with the region? I had been working on something similar internally and that was the only solution I had come up with to associate arbitrary CMA nodes with devices. Right, support for base = 0 requires different handling, but I thought that if we use the device tree approach, the designer already knows the complete memory configuration, so providing the correct base address is not that hard. Not necessarily. The sizes of and number of regions may change depending on use cases. It's much easier to let Linux figure out where to place the regions vs. having to manually place everything each time. (This also gets into the fact that some of the way we use CMA is a 'grey' area that isn't actually hardware related) Thanks, Laura -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [Linaro-mm-sig] [PATCH 2/2] drivers: dma-contiguous: add initialization from device tree
Hi,
On 2/14/2013 4:45 AM, Marek Szyprowski wrote:
+name: an name given to the defined region.
+base-address: the base address of the defined region.
+size: the size of the memory region.
+linux,contiguous-region: property indicating that the defined memory
+ region is used for contiguous memory allocations,
+ Linux specific (optional)
+linux,default-contiguous-region: property indicating that the region
+ is the default region for all contiguous memory
+ allocations, Linux specific (optional)
+
+
I don't see any code actually implementing the default-contiguous-region
binding. Currently on ARM systems we will still setup the default region
based on the Kconfig. Is this intentional?
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 085389c..5761f73 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -24,6 +24,9 @@
#include
#include
+#include
+#include
+#include
#include
#include
#include
@@ -177,6 +180,35 @@ no_mem:
return ERR_PTR(ret);
}
+/*/
+
+#ifdef CONFIG_OF
+int __init cma_fdt_scan(unsigned long node, const char *uname,
+ int depth, void *data)
+{
+ phys_addr_t base, size;
+ unsigned long len;
+ __be32 *prop;
+
+ if (strncmp(uname, "region@", 7) != 0 || depth != 2 ||
+ !of_get_flat_dt_prop(node, "contiguous-region", NULL))
The documentation says "linux,contiguous-region"
+#ifdef CONFIG_OF
+static void cma_assign_device_from_dt(struct device *dev)
+{
+ struct device_node *node;
+ struct cma *cma;
+ u32 value;
+
+ node = of_parse_phandle(dev->of_node, "linux,contiguous-region", 0);
+ if (!node)
+ return;
+ if (of_property_read_u32(node, "reg", &value) && !value)
+ return;
+ cma = cma_get_area(value);
+ if (!cma)
+ return;
+
+ dev_set_cma_area(dev, cma);
+ pr_info("Assigned CMA region at %lx to %s device\n", (unsigned
long)value, dev_name(dev));
+}
+
This scheme of associating devices with CMA regions by base does not
work if you want to let CMA figure out where to place the region (base =
0). Can we use the name to associate the device with the region? I had
been working on something similar internally and that was the only
solution I had come up with to associate arbitrary CMA nodes with devices.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/2] drivers: dma-contiguous: clean source code and prepare for device tree
Hi,
On 2/14/2013 4:45 AM, Marek Szyprowski wrote:
This patch cleans the initialization of dma contiguous framework. The
all-in-one dma_declare_contiguous() function is now separated into
dma_contiguous_reserve_area() which only steals the the memory from
memblock allocator and dma_contiguous_add_device() function, which
assigns given device to the specified reserved memory area. This improves
the flexibility in defining contiguous memory areas and assigning device
to them, because now it is possible to assign more than one device to
the given contiguous memory area. This split in initialization is also
required for upcoming device tree support.
Signed-off-by: Marek Szyprowski
Acked-by: Kyungmin Park
---
drivers/base/dma-contiguous.c| 210 +-
include/asm-generic/dma-contiguous.h |4 +-
include/linux/dma-contiguous.h | 32 +-
3 files changed, 161 insertions(+), 85 deletions(-)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 0ca5442..085389c 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -39,7 +39,33 @@ struct cma {
unsigned long *bitmap;
};
-struct cma *dma_contiguous_default_area;
+static DEFINE_MUTEX(cma_mutex);
+
+struct cma *dma_contiguous_def_area;
+phys_addr_t dma_contiguous_def_base;
+
+static struct cma_area {
+ phys_addr_t base;
+ unsigned long size;
+ struct cma *cma;
+} cma_areas[MAX_CMA_AREAS] __initdata;
+static unsigned cma_area_count __initdata;
+
cma_areas and cma_area_count are accessed from cma_get_area which gets
called from cma_assign_device_from_dt. You need to drop the __initdata
since the notifier can be called at anytime.
Thanks,
Laura
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] dt/flattree: Add stub defintions for flat device tree functions
Several flattened device tree functions are missing stub functions
when CONFIG_OF_FLATTREE is not selected, creating compilation
errors. Add the stub functions.
Signed-off-by: Laura Abbott
---
include/linux/of_fdt.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
index ed136ad..e3d59cd 100644
--- a/include/linux/of_fdt.h
+++ b/include/linux/of_fdt.h
@@ -119,6 +119,11 @@ extern void unflatten_device_tree(void);
extern void early_init_devtree(void *);
#else /* CONFIG_OF_FLATTREE */
static inline void unflatten_device_tree(void) {}
+static inline void *of_get_flat_dt_prop(unsigned long node, const char *name,
+unsigned long *size) { return NULL; }
+
+static inline int of_flat_dt_is_compatible(unsigned long node,
+ const char *name) { return 0; }
#endif /* CONFIG_OF_FLATTREE */
#endif /* __ASSEMBLY__ */
--
1.7.8.3
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
