Re: [PATCH v3 2/2] drivers: dma-contiguous: add initialization from device tree
Hello Grant,
On 7/11/2013 4:56 PM, Grant Likely wrote:
Hi Marek,
Thanks for working on this. Comments below...
On Wed, Jun 26, 2013 at 2:40 PM, Marek Szyprowski
wrote:
> Add device tree support for contiguous memory regions defined in device
> tree. Initialization is done in 2 steps. First, the contiguous memory is
> reserved, what happens very early when only flattened device tree is
> available. Then on device initialization the corresponding cma regions are
> assigned to each device structure.
>
> Signed-off-by: Marek Szyprowski
> Acked-by: Kyungmin Park
> ---
> .../devicetree/bindings/contiguous-memory.txt | 94 ++
> arch/arm/boot/dts/skeleton.dtsi|7 +-
> drivers/base/dma-contiguous.c | 132
> 3 files changed, 232 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt
>
> diff --git a/Documentation/devicetree/bindings/contiguous-memory.txt
b/Documentation/devicetree/bindings/contiguous-memory.txt
> new file mode 100644
> index 000..a733df2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/contiguous-memory.txt
> @@ -0,0 +1,94 @@
> +*** Contiguous Memory binding ***
> +
> +The /chosen/contiguous-memory node provides runtime configuration of
> +contiguous memory regions for Linux kernel. Such regions can be created
> +for special usage by various device drivers. A good example are
> +contiguous memory allocations or memory sharing with other operating
> +system(s) on the same hardware board. Those special memory regions might
> +depend on the selected board configuration and devices used on the target
> +system.
> +
> +Parameters for each memory region can be encoded into the device tree
> +with the following convention:
> +
> +contiguous-memory {
> +
> + (name): region@(base-address) {
> + reg = <(baseaddr) (size)>;
> + (linux,default-contiguous-region);
> + device = <&device_0 &device_1 ...>
> + };
> +};
Okay, I've gone and read all of the backlog on the 3 versions of the
patch series, and I think I understand the issues. I actually think it
was better off to have the regions specified as children of the memory
node. I understand the argument about how would firmware know what
size the kernel wants and that it would be better to have a kernel
parameter to override the default. However, it is also reasonable for
the kernel to be provided with a default amount of CMA based on the
usage profile of the device. In that regard it is absolutely
appropriate to put the CMA region data into the memory node. I don't
think /chosen is the right place for that.
Thanks for your comments! I will prepare a new version, which will use
/memory node as it was in the first version. I hope that with Your ack
such version can be finally merged.
> +
> +name: an name given to the defined region;
In the above node example, "name:" is a label used for creating
phandles. That information doesn't appear in the resulting .dtb
output. The label is actually optional It should instead be:
[(label):] (name)@(address) { }
> +base-address: the base address of the defined region;
> +size: the size of the memory region (bytes);
The reg property should follow the normal reg rules which are well
defined. That also means that a memory region could have multiple reg
entries if appropriate.
Well, I'm not sure if it really makes sense to support multiple reg
entries.
I also wonder how to provide entries for LPAE systems. They are 32-bit
systems,
but physical addresses can be up to 36bit. How to specify them in device
tree?
> +linux,default-contiguous-region: property indicating that the region
> + is the default region for all contiguous memory
> + allocations, Linux specific (optional);
> +device:array of phandles to the client device nodes, which
> + will use the defined contiguous region.
This is backwards compared to the way device references usually work.
It would be more consistent for each device node to have a
"dma-memory-region" property with phandles to one or more memory
regions that it cares about.
> +Each defined region must use unique name. It is optional to specify the
> +base address, so if one wants to use autoconfiguration of the base
> +address, he must specify the '0' as base address in the 'reg' property
> +and assign ann uniqe name to such regions, following the convention:
> +'region@0', 'region@1', 'region@2', ...
Drop the use of 'region'. "name@0" is more typical. It would be
appropriate to have compatible = &
[PATCH v3 1/2] drivers: dma-contiguous: clean source code and prepare for device tree
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. Such split in initialization procedure
is also required for upcoming device tree support.
Signed-off-by: Marek Szyprowski
Acked-by: Kyungmin Park
---
drivers/base/dma-contiguous.c| 211 --
include/asm-generic/dma-contiguous.h |2 -
include/linux/dma-contiguous.h | 32 +-
3 files changed, 129 insertions(+), 116 deletions(-)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 0ca5442..01fe743 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -39,8 +39,15 @@ struct cma {
unsigned long *bitmap;
};
+static DEFINE_MUTEX(cma_mutex);
+
+static struct cma cma_areas[MAX_CMA_AREAS];
+static unsigned cma_area_count;
+
struct cma *dma_contiguous_default_area;
+/*/
+
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
#else
@@ -95,51 +102,20 @@ static inline __maybe_unused phys_addr_t
cma_early_percent_memory(void)
#endif
-/**
- * dma_contiguous_reserve() - reserve area for contiguous memory handling
- * @limit: End address of the reserved memory (optional, 0 for any).
- *
- * This function reserves memory from early allocator. It should be
- * called by arch specific code once the early allocator (memblock or bootmem)
- * has been activated and all other subsystems have already allocated/reserved
- * memory.
- */
-void __init dma_contiguous_reserve(phys_addr_t limit)
-{
- phys_addr_t selected_size = 0;
-
- pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
-
- if (size_cmdline != -1) {
- selected_size = size_cmdline;
- } else {
-#ifdef CONFIG_CMA_SIZE_SEL_MBYTES
- selected_size = size_bytes;
-#elif defined(CONFIG_CMA_SIZE_SEL_PERCENTAGE)
- selected_size = cma_early_percent_memory();
-#elif defined(CONFIG_CMA_SIZE_SEL_MIN)
- selected_size = min(size_bytes, cma_early_percent_memory());
-#elif defined(CONFIG_CMA_SIZE_SEL_MAX)
- selected_size = max(size_bytes, cma_early_percent_memory());
-#endif
- }
-
- if (selected_size) {
- pr_debug("%s: reserving %ld MiB for global area\n", __func__,
-(unsigned long)selected_size / SZ_1M);
-
- dma_declare_contiguous(NULL, selected_size, 0, limit);
- }
-};
-
-static DEFINE_MUTEX(cma_mutex);
+/*/
-static __init int cma_activate_area(unsigned long base_pfn, unsigned long
count)
+static __init int cma_activate_area(struct cma *cma)
{
- unsigned long pfn = base_pfn;
- unsigned i = count >> pageblock_order;
+ int bitmap_size = BITS_TO_LONGS(cma->count) * sizeof(long);
+ unsigned long base_pfn = cma->base_pfn, pfn = base_pfn;
+ unsigned i = cma->count >> pageblock_order;
struct zone *zone;
+ cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+
+ if (!cma->bitmap)
+ return -ENOMEM;
+
WARN_ON_ONCE(!pfn_valid(pfn));
zone = page_zone(pfn_to_page(pfn));
@@ -153,92 +129,74 @@ static __init int cma_activate_area(unsigned long
base_pfn, unsigned long count)
}
init_cma_reserved_pageblock(pfn_to_page(base_pfn));
} while (--i);
+
return 0;
}
-static __init struct cma *cma_create_area(unsigned long base_pfn,
-unsigned long count)
+/**
+ * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
+ * @limit: End address of the reserved memory (optional, 0 for any).
+ *
+ * This function reserves memory from early allocator. It should be
+ * called by arch specific code once the early allocator (memblock or bootmem)
+ * has been activated and all other subsystems have already allocated/reserved
+ * memory. It reserves contiguous areas for global, device independent
+ * allocations and (optionally) all areas defined in device tree structures.
+ */
+void __init dma_contiguous_reserve(phys_addr_t limit)
{
- int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
- struct cma *cma;
- int ret = -ENOMEM;
-
- pr_debug("%s(base %08lx, count %lx)\n", __func__, base_pfn, count);
-
- cma = kmalloc(sizeof *cma, GFP_KERNEL);
- if (!cma)
-
[PATCH v3 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
Hello,
This is a third version of my proposal for device tree integration for
Contiguous Memory Allocator. Over 2 month has passed from the time I've
posted the second version, but now some things about using /chosen
device tree node has been clarified, so I expect to get this code merged
soon this time.
Just a few words for those who see this code for the first time:
The proposed bindings allows to define contiguous memory regions of
specified base address and size. Then, the defined regions can be
assigned to the given device(s) by adding a property with a phanle to
the defined contiguous memory region. From the device tree perspective
that's all. Once the bindings are added, all the memory allocations from
dma-mapping subsystem will be served from the defined contiguous memory
regions.
Contiguous Memory Allocator is a framework, which lets to provide a
large contiguous memory buffers for (usually a multimedia) devices. The
contiguous memory is reserved during early boot and then shared with
kernel, which is allowed to allocate it for movable pages. Then, when
device driver requests a contigouous buffer, the framework migrates
movable pages out of contiguous region and gives it to the driver. When
device driver frees the buffer, it is added to kernel memory pool again.
For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57
("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895
(CMA merge commit).
Why we need device tree bindings for CMA at all?
Older ARM kernels used so called board-based initialization. Those board
files contained a definition of all hardware blocks available on the
target system and particular kernel and driver software configuration
selected by the board maintainer.
In the new approach the board files will be removed completely and
Device Tree approach is used to describe all hardware blocks available
on the target system. By definition, the bindings should be software
independent, so at least in theory it should be possible to use those
bindings with other operating systems than Linux kernel.
However we also need to pass somehow the information about kernel and
device driver software-only configuration data, which were earlier
encoded in the board file. For such data I decided to use /chosen node,
where kernel command line has been already stored. Future bootloaders
will allow to modify or replace particular nodes and one will be able to
use custom /chosen node to configure his system. The proposed patches
introduce /chosen/contiguous-memory node and related bindings, to avoid
complicated encoding of CMA related configuration to kernel command
line.
Some rationale for using /chosen/ node for kernel configuration entities
has been already suggested by Grant Likely in the following thread:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/155296/focus=34363
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Changelog:
v3:
- fixed issues pointed by Laura and updated documentation
v2: http://thread.gmane.org/gmane.linux.drivers.devicetree/34075
- moved contiguous-memory bindings from /memory to /chosen/contiguous-memory/
node to avoid spreading Linux specific parameters over the whole device
tree definitions
- added support for autoconfigured regions (use zero base)
- fixes minor bugs
v1: http://thread.gmane.org/gmane.linux.drivers.devicetree/30111/
- initial proposal
Patch summary:
Marek Szyprowski (2):
drivers: dma-contiguous: clean source code and prepare for device
tree
drivers: dma-contiguous: add initialization from device tree
.../devicetree/bindings/contiguous-memory.txt | 94 ++
arch/arm/boot/dts/skeleton.dtsi|7 +-
drivers/base/dma-contiguous.c | 325 +---
include/asm-generic/dma-contiguous.h |2 -
include/linux/dma-contiguous.h | 32 +-
5 files changed, 352 insertions(+), 108 deletions(-)
create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v3 2/2] drivers: dma-contiguous: add initialization from device tree
Add device tree support for contiguous memory regions defined in device
tree. Initialization is done in 2 steps. First, the contiguous memory is
reserved, what happens very early when only flattened device tree is
available. Then on device initialization the corresponding cma regions are
assigned to each device structure.
Signed-off-by: Marek Szyprowski
Acked-by: Kyungmin Park
---
.../devicetree/bindings/contiguous-memory.txt | 94 ++
arch/arm/boot/dts/skeleton.dtsi|7 +-
drivers/base/dma-contiguous.c | 132
3 files changed, 232 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt
diff --git a/Documentation/devicetree/bindings/contiguous-memory.txt
b/Documentation/devicetree/bindings/contiguous-memory.txt
new file mode 100644
index 000..a733df2
--- /dev/null
+++ b/Documentation/devicetree/bindings/contiguous-memory.txt
@@ -0,0 +1,94 @@
+*** Contiguous Memory binding ***
+
+The /chosen/contiguous-memory node provides runtime configuration of
+contiguous memory regions for Linux kernel. Such regions can be created
+for special usage by various device drivers. A good example are
+contiguous memory allocations or memory sharing with other operating
+system(s) on the same hardware board. Those special memory regions might
+depend on the selected board configuration and devices used on the target
+system.
+
+Parameters for each memory region can be encoded into the device tree
+with the following convention:
+
+contiguous-memory {
+
+ (name): region@(base-address) {
+ reg = <(baseaddr) (size)>;
+ (linux,default-contiguous-region);
+ device = <&device_0 &device_1 ...>
+ };
+};
+
+name: an name given to the defined region;
+base-address: the base address of the defined region;
+size: the size of the memory region (bytes);
+linux,default-contiguous-region: property indicating that the region
+ is the default region for all contiguous memory
+ allocations, Linux specific (optional);
+device:array of phandles to the client device nodes, which
+ will use the defined contiguous region.
+
+Each defined region must use unique name. It is optional to specify the
+base address, so if one wants to use autoconfiguration of the base
+address, he must specify the '0' as base address in the 'reg' property
+and assign ann uniqe name to such regions, following the convention:
+'region@0', 'region@1', 'region@2', ...
+
+
+*** Example ***
+
+This example defines a memory configuration containing 2 contiguous
+regions for Linux kernel, one default of all device drivers (named
+contig_mem, autoconfigured at boot time, 64MiB) and one dedicated to the
+framebuffer device (named display_mem, placed at 0x7800, 64MiB). The
+display_mem region is then assigned to fb@1230, scaller@1250 and
+codec@1260 devices for contiguous memory allocation with Linux
+kernel drivers.
+
+The reason for creating a separate region for framebuffer device is to
+match the framebuffer base address to the one configured by bootloader,
+so once Linux kernel drivers starts no glitches on the displayed boot
+logo appears. Scaller and codec drivers should share the memory
+allocations with framebuffer driver.
+
+/ {
+ /* ... */
+
+ chosen {
+ bootargs = /* ... */
+
+ contiguous-memory {
+
+ /*
+* global autoconfigured region
+* for contiguous allocations
+*/
+ contig_mem: region@0 {
+ reg = <0x0 0x400>;
+ linux,default-contiguous-region;
+ };
+
+ /*
+* special region for framebuffer and
+* multimedia processing devices
+*/
+ display_mem: region@7800 {
+ reg = <0x7800 0x400>;
+ device = <&fb0 &scaller &codec>;
+ };
+ };
+ };
+
+ /* ... */
+
+ fb0: fb@1230 {
+ status = "okay";
+ };
+ scaller: scaller@1250 {
+ status = "okay";
+ };
+ codec: codec@1260 {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/skeleton.dtsi b/arch/arm/boot/dts/skeleton.dtsi
index b41d241..cadc3b9 100644
--- a/arch/arm/boot/dts/skeleton.dtsi
+++ b/arch/arm/boot/dts/skeleton.dtsi
@@ -7,7 +7,12 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
- chosen {
Re: [PATCH 4/9] ARM: dma-mapping: NULLify dev->archdata.mapping pointer on detach
Hello, On 6/11/2013 11:39 AM, Hiroshi Doyu wrote: On Tue, 11 Jun 2013 10:50:15 +0200 Will Deacon wrote: > On Tue, Jun 11, 2013 at 06:34:55AM +0100, Hiroshi Doyu wrote: > > Hi Will, > > > > Will Deacon wrote @ Mon, 10 Jun 2013 20:34:40 +0200: > > > > > The current code only clobbers a local variable, so the device is left > > > with a stale mapping pointer. > > > > True. This's my bad. Thanks. > > That's alright, it's easy to fix. Mind if I add your ack please? Feel free to add: Acked-by: Hiroshi Doyu Thanks for spotting the bug. I've taked the patch to my dma-mapping tree. Best regards -- Marek Szyprowski Samsung R&D Institute Poland ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/9] ARM: dma-mapping: convert DMA direction into IOMMU protection attributes
Hello, On 6/19/2013 10:52 AM, Will Deacon wrote: On Wed, Jun 19, 2013 at 09:37:03AM +0100, Marek Szyprowski wrote: > Hello, Hi Marek, > On 6/10/2013 8:34 PM, Will Deacon wrote: > > IOMMU mappings take a prot parameter, identifying the protection bits > > to enforce on the newly created mapping (READ or WRITE). The ARM > > dma-mapping framework currently just passes 0 as the prot argument, > > resulting in faulting mappings. > > > > This patch infers the protection attributes based on the direction of > > the DMA transfer. > > > > Cc: Marek Szyprowski > > Signed-off-by: Will Deacon > > Thanks for fixing this issue. Could I take this patch to my dma-mapping tree > with other dma-mapping changes I've collected recently or do you want my ack > and push it via other tree? Please, feel free to take it via the dma-mapping tree! That's probably the best route for it and there's nothing that really depends on it anyway. Ok, thank I will put it on my tree. Thanks for your patches! Best regards -- Marek Szyprowski Samsung R&D Institute Poland ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/9] ARM: dma-mapping: convert DMA direction into IOMMU protection attributes
Hello,
On 6/10/2013 8:34 PM, Will Deacon wrote:
IOMMU mappings take a prot parameter, identifying the protection bits
to enforce on the newly created mapping (READ or WRITE). The ARM
dma-mapping framework currently just passes 0 as the prot argument,
resulting in faulting mappings.
This patch infers the protection attributes based on the direction of
the DMA transfer.
Cc: Marek Szyprowski
Signed-off-by: Will Deacon
Thanks for fixing this issue. Could I take this patch to my dma-mapping tree
with other dma-mapping changes I've collected recently or do you want my ack
and push it via other tree?
---
arch/arm/mm/dma-mapping.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6fb80cf..d119de7 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1636,13 +1636,27 @@ static dma_addr_t arm_coherent_iommu_map_page(struct
device *dev, struct page *p
{
struct dma_iommu_mapping *mapping = dev->archdata.mapping;
dma_addr_t dma_addr;
- int ret, len = PAGE_ALIGN(size + offset);
+ int ret, prot, len = PAGE_ALIGN(size + offset);
dma_addr = __alloc_iova(mapping, len);
if (dma_addr == DMA_ERROR_CODE)
return dma_addr;
- ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len, 0);
+ switch (dir) {
+ case DMA_BIDIRECTIONAL:
+ prot = IOMMU_READ | IOMMU_WRITE;
+ break;
+ case DMA_TO_DEVICE:
+ prot = IOMMU_READ;
+ break;
+ case DMA_FROM_DEVICE:
+ prot = IOMMU_WRITE;
+ break;
+ default:
+ prot = 0;
+ }
+
+ ret = iommu_map(mapping->domain, dma_addr, page_to_phys(page), len,
prot);
if (ret < 0)
goto fail;
Best regards
--
Marek Szyprowski
Samsung R&D Institute Poland
___
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
Hello,
On 4/29/2013 11:21 PM, Marc C wrote:
> /**
> * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
> * @limit: End address of the reserved memory (optional, 0 for any).
> @@ -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
> +
What is your expectation with the contention between default region
setup via the kernel config (CONFIG_CMA_SIZE_SEL_*) and via the DT?
Could the call to 'of_scan_flat_dt()' be done before the setup of the
kernel config early regions, followed by a return code check
'fail-over' scheme, or were you intending for the default region
setups to be mutually-exclusive?
In the proposed patch the default/global cma region setup from device tree
had higher priority than kernel command line parameter and .config saved
values,
but now as I think of this, it looks that it would make more sense to
have the
following priority for setting up the default cma region:
1. kernel cmd line - if not available, then use:
2. device tree - if not available, then use:
3. kernel compiled .config
I will update this in the next version of the CMA DT patches.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
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 Laura,
Thanks for your thorough review! I will fix all the pointed issues once the
main point of this patch set (using /chosen/contiguous-memory for CMA DT
bindings) will be agreed and accepted.
On 4/11/2013 7:56 PM, Laura Abbott wrote:
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 longbase_pfn;
unsigned longcount;
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
Hmm. You are right, I need different solution here to get it working
with autoconfigured base address.
+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
Thanks for pointing this.
+if (!cma)
+continue;
+
+for (i=0;; i++) {
+struct device_node *node;
+
[RFC/PATCH v2 2/2] drivers: dma-contiguous: add initialization from device tree
Add device tree support for contiguous memory regions defined in device
tree. Initialization is done in 2 steps. First, the contiguous memory is
reserved, what happens very early, when only flattened device tree is
available. Then on device initialization the corresponding cma regions are
assigned to device structures.
Signed-off-by: Marek Szyprowski
Acked-by: Kyungmin Park
---
.../devicetree/bindings/contiguous-memory.txt | 69 +++
arch/arm/boot/dts/skeleton.dtsi|8 +-
drivers/base/dma-contiguous.c | 124
3 files changed, 200 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/contiguous-memory.txt
diff --git a/Documentation/devicetree/bindings/contiguous-memory.txt
b/Documentation/devicetree/bindings/contiguous-memory.txt
new file mode 100644
index 000..fa598bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/contiguous-memory.txt
@@ -0,0 +1,69 @@
+* Contiguous memory binding
+
+The /chosen/contiguous-memory node provides runtime configuration of
+contiguous memory regions for Linux kernel. One can create such regions
+for special usage by various device drivers. A good example are
+contiguous memory allocations or memory sharing with other operating
+system on the same hardware board. Those special memory regions might
+depend on the board configuration and devices used on the target system.
+
+Parameters for each memory region can be encoded into the device tree
+wit the following convention:
+
+contiguous-memory {
+
+ (name): region@(base-address) {
+ reg = <(baseaddr) (size)>;
+ (linux,default-contiguous-region);
+ device = <&device_0 &device_1 ...>
+ };
+};
+
+name: an name given to the defined region.
+base-address: the base address of the defined region.
+size: the size of the memory region (bytes).
+linux,default-contiguous-region: property indicating that the region
+ is the default region for all contiguous memory
+ allocations, Linux specific (optional)
+device:array of phandles to the client device nodes, which use
+ the given contiguous region
+
+* Example:
+
+This example defines a memory configuration containing 2 contiguous
+regions for Linux kernel, one default of all device drivers (named
+contig_mem, placed at 0x7200, 64MiB) and one dedicated to the
+framebuffer device (named display_mem, placed at 0x7800, 16MiB). The
+display_mem region is then assigned to fb@1230 device for contiguous
+memory allocation with Linux kernel drivers.
+
+The reason for creating a separate region for framebuffer device is to
+match the framebuffer address of from configuration done by bootloader,
+so once Linux kernel drivers starts, no glitches on the displayed boot
+logo appears.
+
+/ {
+ /* ... */
+
+ chosen {
+ bootargs = /* ... */
+
+ contiguous-memory {
+ contig_mem: region@7200 {
+ reg = <0x7200 0x400>;
+ linux,default-contiguous-region;
+ };
+
+ display_mem: region@7800 {
+ reg = <0x7800 0x100>;
+ device = <&fb0>;
+ };
+ };
+ };
+
+ /* ... */
+
+ fb0: fb@1230 {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/skeleton.dtsi b/arch/arm/boot/dts/skeleton.dtsi
index b41d241..538a868 100644
--- a/arch/arm/boot/dts/skeleton.dtsi
+++ b/arch/arm/boot/dts/skeleton.dtsi
@@ -7,7 +7,13 @@
/ {
#address-cells = <1>;
#size-cells = <1>;
- chosen { };
+ chosen {
+ contiguous-memory {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
aliases { };
memory { device_type = "memory"; reg = <0 0>; };
};
+
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 *
[RFC/PATCH v2 1/2] drivers: dma-contiguous: clean source code and prepare for device tree
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| 211 --
include/asm-generic/dma-contiguous.h |2 -
include/linux/dma-contiguous.h | 32 +-
3 files changed, 129 insertions(+), 116 deletions(-)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index 0ca5442..01fe743 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -39,8 +39,15 @@ struct cma {
unsigned long *bitmap;
};
+static DEFINE_MUTEX(cma_mutex);
+
+static struct cma cma_areas[MAX_CMA_AREAS];
+static unsigned cma_area_count;
+
struct cma *dma_contiguous_default_area;
+/*/
+
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
#else
@@ -95,51 +102,20 @@ static inline __maybe_unused phys_addr_t
cma_early_percent_memory(void)
#endif
-/**
- * dma_contiguous_reserve() - reserve area for contiguous memory handling
- * @limit: End address of the reserved memory (optional, 0 for any).
- *
- * This function reserves memory from early allocator. It should be
- * called by arch specific code once the early allocator (memblock or bootmem)
- * has been activated and all other subsystems have already allocated/reserved
- * memory.
- */
-void __init dma_contiguous_reserve(phys_addr_t limit)
-{
- phys_addr_t selected_size = 0;
-
- pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
-
- if (size_cmdline != -1) {
- selected_size = size_cmdline;
- } else {
-#ifdef CONFIG_CMA_SIZE_SEL_MBYTES
- selected_size = size_bytes;
-#elif defined(CONFIG_CMA_SIZE_SEL_PERCENTAGE)
- selected_size = cma_early_percent_memory();
-#elif defined(CONFIG_CMA_SIZE_SEL_MIN)
- selected_size = min(size_bytes, cma_early_percent_memory());
-#elif defined(CONFIG_CMA_SIZE_SEL_MAX)
- selected_size = max(size_bytes, cma_early_percent_memory());
-#endif
- }
-
- if (selected_size) {
- pr_debug("%s: reserving %ld MiB for global area\n", __func__,
-(unsigned long)selected_size / SZ_1M);
-
- dma_declare_contiguous(NULL, selected_size, 0, limit);
- }
-};
-
-static DEFINE_MUTEX(cma_mutex);
+/*/
-static __init int cma_activate_area(unsigned long base_pfn, unsigned long
count)
+static __init int cma_activate_area(struct cma *cma)
{
- unsigned long pfn = base_pfn;
- unsigned i = count >> pageblock_order;
+ int bitmap_size = BITS_TO_LONGS(cma->count) * sizeof(long);
+ unsigned long base_pfn = cma->base_pfn, pfn = base_pfn;
+ unsigned i = cma->count >> pageblock_order;
struct zone *zone;
+ cma->bitmap = kzalloc(bitmap_size, GFP_KERNEL);
+
+ if (!cma->bitmap)
+ return -ENOMEM;
+
WARN_ON_ONCE(!pfn_valid(pfn));
zone = page_zone(pfn_to_page(pfn));
@@ -153,92 +129,74 @@ static __init int cma_activate_area(unsigned long
base_pfn, unsigned long count)
}
init_cma_reserved_pageblock(pfn_to_page(base_pfn));
} while (--i);
+
return 0;
}
-static __init struct cma *cma_create_area(unsigned long base_pfn,
-unsigned long count)
+/**
+ * dma_contiguous_reserve() - reserve area(s) for contiguous memory handling
+ * @limit: End address of the reserved memory (optional, 0 for any).
+ *
+ * This function reserves memory from early allocator. It should be
+ * called by arch specific code once the early allocator (memblock or bootmem)
+ * has been activated and all other subsystems have already allocated/reserved
+ * memory. It reserves contiguous areas for global, device independent
+ * allocations and (optionally) all areas defined in device tree structures.
+ */
+void __init dma_contiguous_reserve(phys_addr_t limit)
{
- int bitmap_size = BITS_TO_LONGS(count) * sizeof(long);
- struct cma *cma;
- int ret = -ENOMEM;
-
- pr_debug("%s(base %08lx, count %lx)\n", __func__, base_pfn, count);
-
- cma = kmalloc(sizeof *cma, GFP_KERNEL);
- if (!cma)
-
[RFC/PATCH v2 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
Hello,
This is an update for my proposal for device tree integration for
Contiguous Memory Allocator. The code is quite straightforward, but
expect again that the device tree bindings will trigger some discussion.
Just a few words for those who see this code for the first time:
The proposed bindings allows to define contiguous memory regions of
specified base address and size. Then, the defined regions can be
assigned to the given device(s) by adding a property with a phanle to
the defined contiguous memory region. From the device tree perspective
that's all. Once the bindings are added, all the memory allocations from
dma-mapping subsystem will be served from the defined contiguous memory
regions.
Contiguous Memory Allocator is a framework, which lets to provide a
large contiguous memory buffers for (usually a multimedia) devices. The
contiguous memory is reserved during early boot and then shared with
kernel, which is allowed to allocate it for movable pages. Then, when
device driver requests a contigouous buffer, the framework migrates
movable pages out of contiguous region and gives it to the driver. When
device driver frees the buffer, it is added to kernel memory pool again.
For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57
("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895
(CMA merge commit).
Why we need device tree bindings for CMA at all?
Older ARM kernels used so called board-based initialization. Those board
files contained a definition of all hardware blocks available on the
target system and particular kernel and driver software configuration
selected by the board maintainer.
In the new approach the board files will be removed completely and
Device Tree approach is used to describe all hardware blocks available
on the target system. By definition, the bindings should be software
independent, so at least in theory it should be possible to use those
bindings with other operating systems than Linux kernel.
However we also need to pass somehow the information about kernel and
device driver software-only configuration data, which were earlier
encoded in the board file. For such data I propose to use /chosen node,
where kernel command line has been already stored. Future bootloaders
will allow to modify or replace particular nodes and one will be able to
use custom /chosen node to configure his system. The proposed patches
introduce /chosen/contiguous-memory node and related bindings, to avoid
complicated encoding of CMA related configuration to kernel command
line.
Best regards
Marek Szyprowski
Samsung Poland R&D Center
Changelog:
v2:
- moved contiguous-memory bindings from /memory to /chosen/contiguous-memory/
node to avoid spreading Linux specific parameters over the whole device
tree definitions
- added support for autoconfigured regions (use zero base)
- fixes minor bugs
v1: http://thread.gmane.org/gmane.linux.drivers.devicetree/30111/
- initial proposal
Patch summary:
Marek Szyprowski (2):
drivers: dma-contiguous: clean source code and prepare for device
tree
drivers: dma-contiguous: add initialization from device tree
Documentation/devicetree/bindings/memory.txt | 101 ++
arch/arm/boot/dts/skeleton.dtsi |7 +-
drivers/base/dma-contiguous.c| 278 +++---
include/asm-generic/dma-contiguous.h |4 +-
include/linux/dma-contiguous.h | 32 ++-
5 files changed, 338 insertions(+), 84 deletions(-)
create mode 100644 Documentation/devicetree/bindings/memory.txt
--
1.7.9.5
___
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
Hello,
On 2/14/2013 10:34 PM, Laura Abbott wrote:
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?
Nope, this was my fault. I've missed the fixup which added support for
default-contiguous-region (it was just a few lines more to cma_fdt_scan()
function).
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"
Right, lack of another fixup. It looks that I posted an incomplete
version, I'm sorry.
I hurried that time (it was my last day in the office before going for
holidays).
+#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.
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.
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
Hello,
It took me some time to get back to this topic due to my holidays and other
urgent issues. I hope that this I will be able to participate a bit more
actively.
On 2/14/2013 10:30 PM, Sascha Hauer wrote:
Hi Marek,
On Thu, Feb 14, 2013 at 01:45:26PM +0100, Marek Szyprowski wrote:
> Hello,
>
> Here is my initial proposal for device tree integration for Contiguous
> Memory Allocator. The code is quite straightforward, however I expect
> that the memory bindings require some discussion.
>
> The proposed bindings allows to define contiguous memory regions of
> specified base address and size. Then, the defined regions can be
> assigned to the given device(s) by adding a property with a phanle to
> the defined contiguous memory region. From the device tree perspective
> that's all. Once the bindings are added, all the memory allocations from
> dma-mapping subsystem will be served from the defined contiguous memory
> regions.
>
I think CMA regions should not be described in the devicetre at all. The
devicetree is about hardware description and it should be OS agnostic,
but CMA is only a Linux specific implementation detail. It's not even
specific to a particular board, it's specific to a particular usecase of
a board.
Well, I see your point. The main problem is the fact that board files
consisted
of both hw related definitions AND particular kernel configuration for
the device
drivers (like the dma_declare_contiguous() calls for example). Now hw
related
definitions are being moved to device tree, but what should we do with the
kernel configuration data, which was previously in the board files? I
know that
in the ideal scenario there should be no such data at all and all
drivers should
be able to automatically configure all related parameters or give
userspace a
method for changing them in runtime. The real world is not ideal
however. There
is a set of kernel configuration data/parameters which can be set only once,
usually early in the boot process. How should we handle it?
There is kernel command line parameter (surprisingly stored also in
device tree,
which should not have such data...), but it intended mainly for
debug/development
purposes and simple, usually one value parameters.
There have been discussion about CMA configuration via kernel cmd line
long time
ago (in early CMA development days), but such attempt has been rejected,
because
it introduced too complicated kernel parameters, see
http://thread.gmane.org/gmane.linux.kernel.mm/50669/focus=50679
So we need another solution. I'm aware of the idea that DT should be
limited to
hw description. This principle is good and it might let us to find some
better,
more generic approach. However, we already have some of Linux kernel
specific
attributes ("git grep 'linux,' -- Documentation/devicetree | wc -l"
gives 71,
most of them are in keypad and buttons drivers).
Are there any KNOWN use cases for using exiting DTS from Linux kernel
with other
operating systems? I believe that 99% of the DTS files will be both
developed and
used only together with Linux kernel. I'm also seeing the DT as a generic
way of describing different variants of the same hardware (what is quite
common
in the development process) and a method for standardizing the hw
description
to ease the developers (for a good example please just compare some old
OMAP and
Exynos board files - each used completely different way of describing
the same
things).
The CMA DT patches are quite short and lets anyone to put the required
kernel
configuration together with the respective HW definitions in a very
convenient
way. Especially referencing regions and device entries by phandle
pointers allows
us to avoid any text-based config entries and in-kernel parsers for them.
If the presented approach is definitely prohibited then what way should
we go?
As an alternative I'm thinking about extending 'chosen' node for such cases.
Embedding the CMA configuration data into a few sub-nodes and attributes
there
should not be a problem. It would also keep all the config related
entries in
a single place. The another advantage I see is the possibility to update
'chosen' node from the extended dt-aware bootloaders, which might also
let one
to edit them. What's your opinion?
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/2] drivers: dma-contiguous: add initialization from device tree
Add device tree support for contiguous memory regions defined in device
tree. Initialization is done in 2 steps. First, the contiguous memory is
reserved, what happens very early, when only flattened device tree is
available. Then on device initialization the corresponding cma regions are
assigned to device structures.
Signed-off-by: Marek Szyprowski
Acked-by: Kyungmin Park
---
Documentation/devicetree/bindings/memory.txt | 101 ++
arch/arm/boot/dts/skeleton.dtsi |7 +-
drivers/base/dma-contiguous.c| 72 ++
3 files changed, 179 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/memory.txt
diff --git a/Documentation/devicetree/bindings/memory.txt
b/Documentation/devicetree/bindings/memory.txt
new file mode 100644
index 000..74e0476
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory.txt
@@ -0,0 +1,101 @@
+* Memory binding
+
+The /memory node provides basic information about the address and size
+of the physical memory. This node is usually filled or updated by the
+bootloader, depending on the actual memory configuration of the given
+hardware.
+
+The memory layout is described by the folllowing node:
+
+memory {
+ reg = <(baseaddr1) (size1)
+ (baseaddr2) (size2)
+ ...
+ (baseaddrN) (sizeN)>;
+};
+
+baseaddrX: the base address of the defined memory bank
+sizeX: the size of the defined memory bank
+
+More than one memory bank can be defined.
+
+
+* Memory regions
+
+In /memory node one can create additional nodes describing particular
+memory regions, usually for the special usage by various device drivers.
+A good example are contiguous memory allocations or memory sharing with
+other operating system on the same hardware board. Those special memory
+regions might depend on the board configuration and devices used on the
+target system.
+
+Parameters for each memory region can be encoded into the device tree
+wit the following convention:
+
+(name): region@(base-address) {
+ reg = <(baseaddr) (size)>;
+ (linux,contiguous-region);
+ (linux,default-contiguous-region);
+};
+
+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)
+
+
+* Device nodes
+
+Once the regions in the /memory node are defined, they can be assigned
+to device some device nodes for their special use. The following
+properties are defined:
+
+linux,contiguous-region = <&phandle>;
+ This property indicates that the device driver should use the
+ memory region pointed by the given phandle.
+
+
+* Example:
+
+This example defines a memory consisting of 4 memory banks. 2 contiguous
+regions are defined for Linux kernel, one default of all device drivers
+(named contig_mem, placed at 0x7200, 64MiB) and one dedicated to the
+framebuffer device (named display_mem, placed at 0x7800, 16MiB). The
+display_mem region is then assigned to fb@1230 device for contiguous
+memory allocation with Linux kernel drivers.
+
+The reason for creating a separate region for framebuffer device is to
+match the framebuffer address of from configuration done by bootloader,
+so once Linux kernel drivers starts, no glitches on the displayed boot
+logo appears.
+
+/ {
+ /* ... */
+ memory {
+ reg = <0x4000 0x1000
+ 0x5000 0x1000
+ 0x6000 0x1000
+ 0x7000 0x1000>;
+
+ contig_mem: region@7200 {
+ linux,contiguous-region;
+ linux,default-contiguous-region;
+ reg = <0x7200 0x400>;
+ };
+
+ display_mem: region@7800 {
+ linux,contiguous-region;
+ reg = <0x7800 0x100>;
+ };
+ };
+
+ fb@1230 {
+ linux,contiguous-region = <&display_mem>;
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/skeleton.dtsi b/arch/arm/boot/dts/skeleton.dtsi
index b41d241..f9988cd 100644
--- a/arch/arm/boot/dts/skeleton.dtsi
+++ b/arch/arm/boot/dts/skeleton.dtsi
@@ -9,5 +9,10 @@
#size-cells = <1>;
chosen { };
aliases { };
- memory { device_type = "memory"; reg = <0 0>; };
+ memory {
+ #address-cells = <1>;
+
[PATCH 1/2] drivers: dma-contiguous: clean source code and prepare for device tree
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;
+
+
+static struct cma_map {
+ phys_addr_t base;
+ struct device *dev;
+} cma_maps[MAX_CMA_AREAS] __initdata;
+static unsigned cma_map_count __initdata;
+
+static struct cma *cma_get_area(phys_addr_t base)
+{
+ int i;
+ for (i = 0; i < cma_area_count; i++)
+ if (cma_areas[i].base == base)
+ return cma_areas[i].cma;
+ return NULL;
+}
#ifdef CONFIG_CMA_SIZE_MBYTES
#define CMA_SIZE_MBYTES CONFIG_CMA_SIZE_MBYTES
@@ -95,45 +121,6 @@ static inline __maybe_unused phys_addr_t
cma_early_percent_memory(void)
#endif
-/**
- * dma_contiguous_reserve() - reserve area for contiguous memory handling
- * @limit: End address of the reserved memory (optional, 0 for any).
- *
- * This function reserves memory from early allocator. It should be
- * called by arch specific code once the early allocator (memblock or bootmem)
- * has been activated and all other subsystems have already allocated/reserved
- * memory.
- */
-void __init dma_contiguous_reserve(phys_addr_t limit)
-{
- phys_addr_t selected_size = 0;
-
- pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
-
- if (size_cmdline != -1) {
- selected_size = size_cmdline;
- } else {
-#ifdef CONFIG_CMA_SIZE_SEL_MBYTES
- selected_size = size_bytes;
-#elif defined(CONFIG_CMA_SIZE_SEL_PERCENTAGE)
- selected_size = cma_early_percent_memory();
-#elif defined(CONFIG_CMA_SIZE_SEL_MIN)
- selected_size = min(size_bytes, cma_early_percent_memory());
-#elif defined(CONFIG_CMA_SIZE_SEL_MAX)
- selected_size = max(size_bytes, cma_early_percent_memory());
-#endif
- }
-
- if (selected_size) {
- pr_debug("%s: reserving %ld MiB for global area\n", __func__,
-(unsigned long)selected_size / SZ_1M);
-
- dma_declare_contiguous(NULL, selected_size, 0, limit);
- }
-};
-
-static DEFINE_MUTEX(cma_mutex);
-
static __init int cma_activate_area(unsigned long base_pfn, unsigned long
count)
{
unsigned long pfn = base_pfn;
@@ -190,55 +177,73 @@ no_mem:
return ERR_PTR(ret);
}
-static struct cma_reserved {
- phys_addr_t start;
- unsigned long size;
- struct device *dev;
-} cma_reserved[MAX_CMA_AREAS] __initdata;
-static unsigned cma_reserved_count __initdata;
-
-static int __init cma_init_reserved_areas(void)
+/**
+ * dma_contiguous_reserve() - reserve area for contiguous memory handling
+ * @limit: End address of the reserved memory (optional, 0 for any).
+ *
+ * This function reserves memory from early allocator. It should be
+ * called by arch specific code once the early allocator (memblock or bootmem)
+ * has been activated and all other subsystems have already allocated/reserved
+ * memory. It reserves contiguous areas for global, device independent
+ * allocations and (optionally) all areas defined in device tree structures.
+ */
+void __init dma_contiguous_reserve(phys_addr_t limit)
{
- struct cma_reserved *r = cma_reserved;
- unsigned i = cma_reserved_count;
+ phys_addr_t sel_size = 0;
- pr_debug("%s()\n", __func__);
+ pr_debug("%s(limit %08lx)\n", __func__, (unsigned long)limit);
- for (; i; --i, ++r) {
- struct cma *cma;
- cma = cma_create_area(PFN_DOWN(r->start),
- r->siz
[PATCH 0/2] Device Tree support for CMA (Contiguous Memory Allocator)
Hello,
Here is my initial proposal for device tree integration for Contiguous
Memory Allocator. The code is quite straightforward, however I expect
that the memory bindings require some discussion.
The proposed bindings allows to define contiguous memory regions of
specified base address and size. Then, the defined regions can be
assigned to the given device(s) by adding a property with a phanle to
the defined contiguous memory region. From the device tree perspective
that's all. Once the bindings are added, all the memory allocations from
dma-mapping subsystem will be served from the defined contiguous memory
regions.
Contiguous Memory Allocator is a framework, which lets to provide a
large contiguous memory buffers for (usually a multimedia) devices. The
contiguous memory is reserved during early boot and then shared with
kernel, which is allowed to allocate it for movable pages. Then, when
device driver requests a contigouous buffer, the framework migrates
movable pages out of contiguous region and gives it to the driver. When
device driver frees the buffer, it is added to kernel memory pool again.
For more information, please refer to commit c64be2bb1c6eb43c838b2c6d57
("drivers: add Contiguous Memory Allocator") and d484864dd96e1830e76895
(CMA merge commit).
Best regards
Marek Szyprowski
Samsung Poland R&D Center
Patch summary:
Marek Szyprowski (2):
drivers: dma-contiguous: clean source code and prepare for device
tree
drivers: dma-contiguous: add initialization from device tree
Documentation/devicetree/bindings/memory.txt | 101 ++
arch/arm/boot/dts/skeleton.dtsi |7 +-
drivers/base/dma-contiguous.c| 278 +++---
include/asm-generic/dma-contiguous.h |4 +-
include/linux/dma-contiguous.h | 32 ++-
5 files changed, 338 insertions(+), 84 deletions(-)
create mode 100644 Documentation/devicetree/bindings/memory.txt
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH V2 1/7] ARM: SAMSUNG: add additional registers and SFR definitions for writeback
Hello, On Thursday, July 19, 2012 2:44 PM Leela Krishna Amudala > Hello Marek, > > On Wed, Jul 18, 2012 at 12:21 PM, Marek Szyprowski > wrote: > > Hello, > > > > On Wednesday, July 18, 2012 7:57 AM Leela Krishna Amudala wrote: > > > >> This patch updates the register address offsets and adds SFR definitions > >> for writeback for Samsung's V8 display controller. > >> > >> Signed-off-by: Leela Krishna Amudala > >> --- > >> arch/arm/plat-samsung/include/plat/regs-fb-v4.h | 10 > >> arch/arm/plat-samsung/include/plat/regs-fb.h| 51 > >> +++ > >> drivers/video/Kconfig |6 +++ > >> 3 files changed, 67 insertions(+), 0 deletions(-) > >> > >> diff --git a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h > >> b/arch/arm/plat- > >> samsung/include/plat/regs-fb-v4.h > >> index 4c3647f..1639c17 100644 > >> --- a/arch/arm/plat-samsung/include/plat/regs-fb-v4.h > >> +++ b/arch/arm/plat-samsung/include/plat/regs-fb-v4.h > >> @@ -30,9 +30,16 @@ > >> #define VIDCON1_FSTATUS_EVEN (1 << 15) > >> > >> /* Video timing controls */ > >> +#ifdef CONFIG_FB_EXYNOS_FIMD_V8 > >> +#define VIDTCON0(0x20010) > >> +#define VIDTCON1(0x20014) > >> +#define VIDTCON3(0x2001C) > >> +#else > >> #define VIDTCON0 (0x10) > >> #define VIDTCON1 (0x14) > >> #define VIDTCON2 (0x18) > >> +#define VIDTCON3 (0x1C) > >> +#endif > >> > >> /* Window position controls */ > >> > >> @@ -43,9 +50,12 @@ > >> #define VIDOSD_BASE (0x40) > >> > >> #define VIDINTCON0 (0x130) > >> +#define VIDINTCON1 (0x134) > >> > >> /* WINCONx */ > >> > >> +#define WINCONx_CSC_CON_EQ709 (1 << 28) > >> +#define WINCONx_CSC_CON_EQ601 (0 << 28) > >> #define WINCONx_CSCWIDTH_MASK(0x3 << 26) > >> #define WINCONx_CSCWIDTH_SHIFT (26) > >> #define WINCONx_CSCWIDTH_WIDE(0x0 << 26) > >> diff --git a/arch/arm/plat-samsung/include/plat/regs-fb.h b/arch/arm/plat- > >> samsung/include/plat/regs-fb.h > >> index 9a78012..6d2ee16 100644 > >> --- a/arch/arm/plat-samsung/include/plat/regs-fb.h > >> +++ b/arch/arm/plat-samsung/include/plat/regs-fb.h > >> @@ -32,12 +32,28 @@ > >> > >> #define VIDCON0 (0x00) > >> #define VIDCON0_INTERLACE(1 << 29) > >> + > >> +#ifdef CONFIG_FB_EXYNOS_FIMD_V8 > >> +#define VIDOUT_CON (0x2) > >> +#define VIDOUT_CON_VIDOUT_UP_MASK(0x1 << 16) > >> +#define VIDOUT_CON_VIDOUT_UP_SHIFT (16) > >> +#define VIDOUT_CON_VIDOUT_UP_ALWAYS (0x0 << 16) > >> +#define VIDOUT_CON_VIDOUT_UP_START_FRAME (0x1 << 16) > >> +#define VIDOUT_CON_VIDOUT_F_MASK (0x7 << 8) > >> +#define VIDOUT_CON_VIDOUT_F_SHIFT(8) > >> +#define VIDOUT_CON_VIDOUT_F_RGB (0x0 << 8) > >> +#define VIDOUT_CON_VIDOUT_F_I80_LDI0 (0x2 << 8) > >> +#define VIDOUT_CON_VIDOUT_F_I80_LDI1 (0x3 << 8) > >> +#define VIDOUT_CON_VIDOUT_F_WB (0x4 << 8) > >> +#endif > >> + > >> #define VIDCON0_VIDOUT_MASK (0x3 << 26) > >> #define VIDCON0_VIDOUT_SHIFT (26) > >> #define VIDCON0_VIDOUT_RGB (0x0 << 26) > >> #define VIDCON0_VIDOUT_TV(0x1 << 26) > >> #define VIDCON0_VIDOUT_I80_LDI0 (0x2 << 26) > >> #define VIDCON0_VIDOUT_I80_LDI1 (0x3 << 26) > >> +#define VIDCON0_VIDOUT_WB (0x4 << 26) > >> > >> #define VIDCON0_L1_DATA_MASK (0x7 << 23) > >> #define VIDCON0_L1_DATA_SHIFT(23) > >> @@ -81,7 +97,13 @@ > >> #define VIDCON0_ENVID(1 << 1) > >> #define
RE: [PATCH V2 3/7] ARM: EXYNOS5: add machine specific support for LCD
Hello,
On Thursday, July 19, 2012 3:22 PM Leela Krishna Amudala wrote:
> Hello Marek,
>
> On Wed, Jul 18, 2012 at 12:15 PM, Marek Szyprowski
> wrote:
> > Hello,
> >
> > On Wednesday, July 18, 2012 7:57 AM Leela Krishna Amudala wrote:
> >
> >> This patch adds machine specific support for LCD controller like setting
> >> power to LCD
> >> and adding LCD platform device.
> >>
> >> Signed-off-by: Prathyush K
> >> Signed-off-by: Leela Krishna Amudala
> >> ---
> >> arch/arm/mach-exynos/mach-exynos5-dt.c | 56
> >>
> >> 1 files changed, 56 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
> >> b/arch/arm/mach-exynos/mach-exynos5-
> dt.c
> >> index e7113cc..02a0e68 100644
> >> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> >> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> >> @@ -13,6 +13,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >>
> >> #include
> >> #include
> >> @@ -24,6 +25,7 @@
> >> #include
> >>
> >> #include "common.h"
> >> +#include
> >>
> >> static int smdk5250_bl_notify(struct device *unused, int brightness)
> >> {
> >> @@ -47,6 +49,55 @@ static struct platform_pwm_backlight_data
> >> smdk5250_bl_data = {
> >> .notify = smdk5250_bl_notify,
> >> };
> >>
> >> +static void lcd_set_power(struct plat_lcd_data *pd,
> >> + unsigned int power)
> >> +{
> >> +
> >> + /* reset */
> >> + gpio_request_one(EXYNOS5_GPX1(5), GPIOF_OUT_INIT_HIGH, "GPX1");
> >> +
> >> + mdelay(20);
> >> + if (power) {
> >> + /* fire nRESET on power up */
> >> + gpio_set_value(EXYNOS5_GPX1(5), 0);
> >> + mdelay(20);
> >> + gpio_set_value(EXYNOS5_GPX1(5), 1);
> >> + mdelay(20);
> >> + gpio_free(EXYNOS5_GPX1(5));
> >> + } else {
> >> + /* fire nRESET on power off */
> >> + gpio_set_value(EXYNOS5_GPX1(5), 0);
> >> + mdelay(20);
> >> + gpio_set_value(EXYNOS5_GPX1(5), 1);
> >> + mdelay(20);
> >> + gpio_free(EXYNOS5_GPX1(5));
> >> + }
> >> + mdelay(20);
> >> +
> >> + /*
> >> + * Request lcd_bl_en GPIO for smdk5250_bl_notify().
> >> + * TODO: Fix this so we are not at risk of requesting the GPIO
> >> + * multiple times, this should be done with device tree, and
> >> + * likely integrated into the plat-samsung/dev-backlight.c init.
> >> + */
> >> + gpio_request_one(EXYNOS5_GPX3(0), GPIOF_OUT_INIT_LOW, "GPX3");
> >> +}
> >> +
> >> +static int smdk5250_match_fb(struct plat_lcd_data *pd, struct fb_info
> >> *info)
> >> +{
> >> + /* Don't call .set_power callback while unblanking */
> >> + return 0;
> >> +}
> >> +
> >> +static struct plat_lcd_data smdk5250_lcd_data = {
> >> + .set_power = lcd_set_power,
> >> + .match_fb = smdk5250_match_fb,
> >> +};
> >> +
> >> +static struct platform_device smdk5250_lcd = {
> >> + .name = "platform-lcd",
> >> + .dev.platform_data = &smdk5250_lcd_data,
> >> +};
> >> /*
> >> * The following lookup table is used to override device names when
> >> devices
> >> * are registered from device tree. This is temporarily added to enable
> >> @@ -85,6 +136,10 @@ static const struct of_dev_auxdata
> >> exynos5250_auxdata_lookup[]
> __initconst
> >> = {
> >> {},
> >> };
> >>
> >> +static struct platform_device *smdk5250_devices[] __initdata = {
> >> + &smdk5250_lcd, /* for platform_lcd device */
> >> +};
> >> +
> >> static void __init exynos5250_dt_map_io(void)
> >> {
> >> exynos_init_io(NULL, 0);
> >> @@ -96,6 +151,7 @@ static void __init exynos5250_dt_machine_init(void)
> >> samsung_bl_set(&smdk5250_bl_gpio_info, &smdk5250_bl_data);
> >> of_platform_populate(NULL, of_default_bus_match_table,
> >>
RE: [PATCH V2 3/7] ARM: EXYNOS5: add machine specific support for LCD
Hello,
On Wednesday, July 18, 2012 7:57 AM Leela Krishna Amudala wrote:
> This patch adds machine specific support for LCD controller like setting
> power to LCD
> and adding LCD platform device.
>
> Signed-off-by: Prathyush K
> Signed-off-by: Leela Krishna Amudala
> ---
> arch/arm/mach-exynos/mach-exynos5-dt.c | 56
>
> 1 files changed, 56 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos/mach-exynos5-dt.c
> b/arch/arm/mach-exynos/mach-exynos5-dt.c
> index e7113cc..02a0e68 100644
> --- a/arch/arm/mach-exynos/mach-exynos5-dt.c
> +++ b/arch/arm/mach-exynos/mach-exynos5-dt.c
> @@ -13,6 +13,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -24,6 +25,7 @@
> #include
>
> #include "common.h"
> +#include
>
> static int smdk5250_bl_notify(struct device *unused, int brightness)
> {
> @@ -47,6 +49,55 @@ static struct platform_pwm_backlight_data smdk5250_bl_data
> = {
> .notify = smdk5250_bl_notify,
> };
>
> +static void lcd_set_power(struct plat_lcd_data *pd,
> + unsigned int power)
> +{
> +
> + /* reset */
> + gpio_request_one(EXYNOS5_GPX1(5), GPIOF_OUT_INIT_HIGH, "GPX1");
> +
> + mdelay(20);
> + if (power) {
> + /* fire nRESET on power up */
> + gpio_set_value(EXYNOS5_GPX1(5), 0);
> + mdelay(20);
> + gpio_set_value(EXYNOS5_GPX1(5), 1);
> + mdelay(20);
> + gpio_free(EXYNOS5_GPX1(5));
> + } else {
> + /* fire nRESET on power off */
> + gpio_set_value(EXYNOS5_GPX1(5), 0);
> + mdelay(20);
> + gpio_set_value(EXYNOS5_GPX1(5), 1);
> + mdelay(20);
> + gpio_free(EXYNOS5_GPX1(5));
> + }
> + mdelay(20);
> +
> + /*
> + * Request lcd_bl_en GPIO for smdk5250_bl_notify().
> + * TODO: Fix this so we are not at risk of requesting the GPIO
> + * multiple times, this should be done with device tree, and
> + * likely integrated into the plat-samsung/dev-backlight.c init.
> + */
> + gpio_request_one(EXYNOS5_GPX3(0), GPIOF_OUT_INIT_LOW, "GPX3");
> +}
> +
> +static int smdk5250_match_fb(struct plat_lcd_data *pd, struct fb_info *info)
> +{
> + /* Don't call .set_power callback while unblanking */
> + return 0;
> +}
> +
> +static struct plat_lcd_data smdk5250_lcd_data = {
> + .set_power = lcd_set_power,
> + .match_fb = smdk5250_match_fb,
> +};
> +
> +static struct platform_device smdk5250_lcd = {
> + .name = "platform-lcd",
> + .dev.platform_data = &smdk5250_lcd_data,
> +};
> /*
> * The following lookup table is used to override device names when devices
> * are registered from device tree. This is temporarily added to enable
> @@ -85,6 +136,10 @@ static const struct of_dev_auxdata
> exynos5250_auxdata_lookup[] __initconst
> = {
> {},
> };
>
> +static struct platform_device *smdk5250_devices[] __initdata = {
> + &smdk5250_lcd, /* for platform_lcd device */
> +};
> +
> static void __init exynos5250_dt_map_io(void)
> {
> exynos_init_io(NULL, 0);
> @@ -96,6 +151,7 @@ static void __init exynos5250_dt_machine_init(void)
> samsung_bl_set(&smdk5250_bl_gpio_info, &smdk5250_bl_data);
> of_platform_populate(NULL, of_default_bus_match_table,
> exynos5250_auxdata_lookup, NULL);
> + platform_add_devices(smdk5250_devices, ARRAY_SIZE(smdk5250_devices));
> }
>
> static char const *exynos5250_dt_compat[] __initdata = {
Sorry, but this patch looks completely weird to me. exynos5-dt machine is aimed
to
operate on ANY Exynos5 based board with proper device tree bindings, not only
SMDK5250.
Please add DT support to platform lcd driver and create required bindings for it
instead of hardcoding the platform data and gpio numbers in mach-exynos5-dt.c
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH V2 1/7] ARM: SAMSUNG: add additional registers and SFR definitions for writeback
define VIDCON2_TVFORMATSEL_YUV444 (0x2 << 12) > + > +#define VIDCON2_TVFMTSEL1_MASK (0x3 << 12) > +#define VIDCON2_TVFMTSEL1_RGB(0x0 << 12) > +#define VIDCON2_TVFMTSEL1_YUV422 (0x1 << 12) > +#define VIDCON2_TVFMTSEL1_YUV444 (0x2 << 12) > > #define VIDCON2_ORGYCbCr (1 << 8) > #define VIDCON2_YUVORDCrCb (1 << 7) > @@ -165,8 +195,15 @@ > #define VIDTCON1_HSPW_SHIFT (0) > #define VIDTCON1_HSPW_LIMIT (0xff) > #define VIDTCON1_HSPW(_x)((_x) << 0) > +#define VIDCON1_VCLK_MASK (0x3 << 9) > +#define VIDCON1_VCLK_HOLD (0x0 << 9) > +#define VIDCON1_VCLK_RUN(0x1 << 9) > > +#ifdef CONFIG_FB_EXYNOS_FIMD_V8 > +#define VIDTCON2 (0x20018) > +#else > #define VIDTCON2 (0x18) > +#endif > #define VIDTCON2_LINEVAL_E(_x) _x) & 0x800) >> 11) > << 23) > #define VIDTCON2_LINEVAL_MASK(0x7ff << 11) > #define VIDTCON2_LINEVAL_SHIFT (11) > @@ -186,6 +223,9 @@ > #define WINCONx_BYTSWP (1 << 17) > #define WINCONx_HAWSWP (1 << 16) > #define WINCONx_WSWP (1 << 15) > +#define WINCONx_ENLOCAL_MASK (0xf << 15) > +#define WINCONx_INRGB_RGB(0 << 13) > +#define WINCONx_INRGB_YCBCR (1 << 13) > #define WINCONx_BURSTLEN_MASK(0x3 << 9) > #define WINCONx_BURSTLEN_SHIFT (9) > #define WINCONx_BURSTLEN_16WORD (0x0 << 9) > @@ -205,6 +245,7 @@ > #define WINCON0_BPPMODE_24BPP_888(0xb << 2) > > #define WINCON1_BLD_PIX (1 << 6) > +#define WINCON1_BLD_PLANE(0 << 6) > > #define WINCON1_ALPHA_SEL(1 << 1) > #define WINCON1_BPPMODE_MASK (0xf << 2) > @@ -395,9 +436,19 @@ > #define WPALCON_W0PAL_16BPP_A555 (0x5 << 0) > #define WPALCON_W0PAL_16BPP_565 (0x6 << 0) > > +/* Clock gate mode control */ > +#define REG_CLKGATE_MODE (0x1b0) > +#define REG_CLKGATE_MODE_AUTO_CLOCK_GATE (0 << 0) > +#define REG_CLKGATE_MODE_NON_CLOCK_GATE (1 << 0) > + > /* Blending equation control */ > #define BLENDCON (0x260) > #define BLENDCON_NEW_MASK(1 << 0) > #define BLENDCON_NEW_8BIT_ALPHA_VALUE(1 << 0) > #define BLENDCON_NEW_4BIT_ALPHA_VALUE(0 << 0) > > +/* Window alpha control */ > +#define VIDW0ALPHA0 (0x200) > +#define VIDW0ALPHA1 (0x204) > +#define DPCLKCON (0x27c) > +#define DPCLKCON_ENABLE (1 << 1) > diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig > index 0217f74..f81bf55 100644 > --- a/drivers/video/Kconfig > +++ b/drivers/video/Kconfig > @@ -2053,6 +2053,12 @@ config FB_S3C > > Currently the support is only for the S3C6400 and S3C6410 SoCs. > > +config FB_EXYNOS_FIMD_V8 > + bool "register extensions for FIMD version 8" > + depends on ARCH_EXYNOS5 > + ---help--- > + This uses register extensions for FIMD version 8 > + > config FB_S3C_DEBUG_REGWRITE > bool "Debug register writes" > depends on FB_S3C Do we really need these defines in arch/arm/plat-samsung/include/plat/regs-fb* ? IMHO they should be moved from arch/arm to drivers/video to live together with the driver. They are not a part of core platform code. I thought that there have been some patches cleaning up regs-fb mess a long time ago, but it looks they didn't get their way to mainline. Best regards -- Marek Szyprowski Samsung Poland R&D Center ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 3/3] i2c-s3c2410: Add HDMIPHY quirk for S3C2440
Hi Wolfram, On Tuesday, April 17, 2012 7:40 PM Wolfram Sang wrote: > On Wed, Mar 21, 2012 at 08:11:53PM +0100, Karol Lewandowski wrote: > > This patch adds support for s3c2440 I2C bus controller dedicated HDMIPHY > > device on > > Exynos4 platform. Some quirks are introduced due to differences between > > HDMIPHY > > and other I2C controllers on Exynos4. These differences are: > > - no GPIOs, HDMIPHY is inside the SoC and the controller is connected > > internally > > - due to unknown reason (probably HW bug in HDMIPHY and/or the controller) a > > transfer fails to finish. The controller hangs after sending the last > > byte, > > the workaround for this bug is resetting the controller after each > > transfer > > > > Signed-off-by: Tomasz Stanislawski > > Signed-off-by: Karol Lewandowski > > Tested-by: Tomasz Stanislawski > > Signed-off-by: Kyungmin Park > > --- > > .../devicetree/bindings/i2c/samsung-i2c.txt| 11 +- > > drivers/i2c/busses/i2c-s3c2410.c | 35 > > > > 2 files changed, 44 insertions(+), 2 deletions(-) > > > > diff --git a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt > b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt > > index 38832c7..c6670f9 100644 > > --- a/Documentation/devicetree/bindings/i2c/samsung-i2c.txt > > +++ b/Documentation/devicetree/bindings/i2c/samsung-i2c.txt > > @@ -10,14 +10,21 @@ Required properties: > > region. > >- interrupts: interrupt number to the cpu. > >- samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges. > > - - gpios: The order of the gpios should be the following: . > > -The gpio specifier depends on the gpio controller. > > > > Optional properties: > > + - gpios: The order of the gpios should be the following: . > > +The gpio specifier depends on the gpio controller. Required in all > > cases > > +except when "samsung,i2c-no-gpio" is also specified. > > + - samsung,i2c-no-gpio: input/output lines of the controller are > > +permanently wired to the respective client, there are no gpio > > +lines that need to be configured to enable this controller > > Can't we just skip this property... All standard s3c-24x0 i2c controllers require gpio lines for proper operation, so lack of the gpios property should be considered as an error. However there is a special case of internal, embedded i2c controller which has no such gpio lines at all. > >- samsung,i2c-slave-addr: Slave address in multi-master enviroment. If > > not > > specified, default value is 0. > >- samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not > > specified, the default value in Hz is 10. > > + - samsung,i2c-quirk-hdmiphy: Quirk for HDMI PHY block found on > > +Exynos4 platform - reduce timeout and reset controller after each > > +transfer > > ... and this one, if we declare a new compatible-entry for exynos4? It is not strictly related to Exynos4 SoCs. Exynos4 SoC has 8 standard s3c2440 style i2c controllers and one additional, internal controller for HDMIPHY, which needs some workarounds in the driver. Maybe the quirk should be named 'broken timeout detection' (snipped) Best regards -- Marek Szyprowski Samsung Poland R&D Center ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [RFC 4/4] drm: Add NVIDIA Tegra support
Hi Thierry, On Thursday, April 12, 2012 3:42 PM Thierry Reding wrote: > > > Also this doesn't yet solve the vmap() problem that is needed for the > > > kernel > > > virtual mapping. I did try using dma_alloc_writecombine(), but that only > > > works for chunks of 2 MB or smaller, unless I use > > > init_consistent_dma_size() > > > during board setup, which isn't provided for in a DT setup. I couldn't > > > find > > > a better alternative, but I admit I'm not very familiar with all the VM > > > APIs. > > > Do you have any suggestions on how to solve this? Otherwise I'll try and > > > dig > > > in some more. > > > > Yes, I'm aware of this issue I'm currently working on solving it. I hope to > > use > > standard vmalloc range for all coherent/writecombine allocations and get > > rid of > > the custom 'consistent_dma' region at all. > > Does your work aim at removing the 2 MB limitation or at remapping non- > contiguous memory to a virtually linear buffer? I have some trouble > understanding how removing the 2 MB limit would help, because if all buffers > can be allocated contiguously then there wouldn't be any need for the IOMMU, > right? I would like to remove 2MiB limitation by moving these mapping to generic vmalloc area. Please notice that this 2MiB limit is only applied to CPU virtual address space and no physical memory is preallocated for consistent dma. ARM linear dma mapping implementation allocates coherent buffers by calling alloc_pages() and then creating a coherent mapping for the allocated buffer. With IOMMU you can allocate chunks of memory and create a contiguous DMA mapping. To fulfill dma mapping request you also need to create a cpu coherent mapping for them and right now my core uses the same remapping function as linear version. The only limitation here will be vmalloc space and its fragmentation. Best regards -- Marek Szyprowski Samsung Poland R&D Center ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [RFC 4/4] drm: Add NVIDIA Tegra support
Hi Arnd, On Thursday, April 12, 2012 1:18 PM Arnd Bergmann wrote: > On Thursday 12 April 2012, Marek Szyprowski wrote: > > Scatter lists were initially designed for the disk based block io > > operations, > > hence the presence of the in-page offsets and lengths for each chunk. For > > multimedia use cases providing an array of struct pages and asking > > dma-mapping > > to map them into contiguous memory is probably all we need. I wonder if > > introducing such new calls is a good idea. Anrd, what do think? It will > > definitely simplify the drivers and improve the code understanding. On the > > other hand it requires a significant amount of work in the dma-mapping > > framework for all architectures, but that's not a big issue for me. > > My feeling is that it's too much like the existing _sg version, so I wouldn't > add yet another variant. While having a simple page array is definitely > simpler and potentially faster, I think the API is already too complex > and we need to be very careful with new additions. You are right, the API is already complex. The idea of adding page array came after explaining once again how the _sg functions work and how to use them for this specific use case. There is one more point for page array. Scatter-lists are also very inefficient in terms of the used memory. In the worst case we create a single scatterlist entry for every single page of the large buffer. For each entry we really use only a page pointer, leaving offset at zero and size set to 4KiB, dma_address and dma_length entries are usually used only for the first element in the list. On the other hand scatter lists are the only way to describe a complex block IO requests which is spread across multiple io buffers, which are smaller than a single page. Having a specialized set of functions in the API is not bad in general. Maybe the obscurity of the current _sg functions was the reason that almost every developer involved in gfx/multimedia and memory management tried to provide his own solution instead of using the dma-mapping api. We already have dma_map_page() and dma_map_single() which are very similar. Maybe adding dma_map_pages() won't be such a bad idea? If not maybe we should provide some kind of helper functions which converts page array to scatterlist and then maps them. Best regards -- Marek Szyprowski Samsung Poland R&D Center ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [RFC 4/4] drm: Add NVIDIA Tegra support
Hi Thierry, On Thursday, April 12, 2012 9:18 AM Thierry Reding wrote: > * Arnd Bergmann wrote: > > On Wednesday 11 April 2012, Thierry Reding wrote: > > > Daniel Vetter wrote: > > > > Well, you use the iommu api to map/unmap memory into the iommu for > > > > tegra, > > > > whereas usually device drivers just use the dma api to do that. The > > > > usual > > > > interface is dma_map_sg/dma_unmap_sg, but there are quite a few variants > > > > around. I'm just wondering why this you've choosen this. > > > > > > I don't think this works on ARM. Maybe I'm not seeing the whole picture > > > but > > > judging by a quick look through the kernel tree there aren't any users > > > that > > > map DMA memory through an IOMMU. > > > > dma_map_sg is certainly the right interface to use, and Marek Szyprowski has > > patches to make that work on ARM, hopefully going into v3.5, so you could > > use those. > > I've looked at Marek's patches but I don't think they'll work for Tegra 2 or > Tegra 3. The corresponding iommu_map() functions only set one PTE, regardless > of the number of bytes passed to them. However, the Tegra TRM indicates that > mapping needs to be done on a per-page basis so contiguous regions cannot be > combined. I suppose the IOMMU driver would have to be fixed to program more > than a single page in that case. I assume you want to map a set of pages into contiguous chunk in io address space. This can be done with dma_map_sg() call once IOMMU aware implementation has been assigned to the given device. DMA-mapping implementation is able to merge consecutive chunks of the scatter list in the dma/io address space if possible (i.e. there are no in-page offsets between the chunks). With my implementation of IOMMU aware dma-mapping you usually you get a single DMA chunk from the provided scatter-list. I know that this approach causes a lot of confusion at the first look, but that how dma mapping api has been designed. The scatter list based approach has some drawbacks - it is a bit oversized for most of the typical use cases for the gfx/multimedia buffers, but that's all we have now. Scatter lists were initially designed for the disk based block io operations, hence the presence of the in-page offsets and lengths for each chunk. For multimedia use cases providing an array of struct pages and asking dma-mapping to map them into contiguous memory is probably all we need. I wonder if introducing such new calls is a good idea. Anrd, what do think? It will definitely simplify the drivers and improve the code understanding. On the other hand it requires a significant amount of work in the dma-mapping framework for all architectures, but that's not a big issue for me. > Also this doesn't yet solve the vmap() problem that is needed for the kernel > virtual mapping. I did try using dma_alloc_writecombine(), but that only > works for chunks of 2 MB or smaller, unless I use init_consistent_dma_size() > during board setup, which isn't provided for in a DT setup. I couldn't find > a better alternative, but I admit I'm not very familiar with all the VM APIs. > Do you have any suggestions on how to solve this? Otherwise I'll try and dig > in some more. Yes, I'm aware of this issue I'm currently working on solving it. I hope to use standard vmalloc range for all coherent/writecombine allocations and get rid of the custom 'consistent_dma' region at all. Best regards -- Marek Szyprowski Samsung Poland R&D Center ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v2 2/3] ARM: Exynos4: Add ioremap interceptor for statically remapped regions
Hello,
On Tuesday, November 01, 2011 2:01 AM Thomas Abraham wrote:
> ioremap() request for statically remapped regions are intercepted and the
> statically assigned virtual address is returned. For requests for which
> there are no statically remapped regions, the requests are let through.
>
> Cc: Kukjin Kim
> Signed-off-by: Thomas Abraham
> ---
> arch/arm/mach-exynos4/cpu.c | 16
> arch/arm/mach-exynos4/include/mach/io.h |5 +
> 2 files changed, 21 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
> index 5b1765b..358624d 100644
> --- a/arch/arm/mach-exynos4/cpu.c
> +++ b/arch/arm/mach-exynos4/cpu.c
> @@ -137,6 +137,22 @@ static struct map_desc exynos4_iodesc1[] __initdata = {
> },
> };
>
> +/*
> + * For all ioremap requests of statically mapped regions, intercept ioremap
> and
> + * return virtual address from the iodesc table.
> + */
> +void __iomem *exynos4_ioremap(unsigned long phy, size_t size, unsigned int
> type)
> +{
> + struct map_desc *desc = exynos4_iodesc;
> + unsigned int idx;
> +
> + for (idx = 0; idx < ARRAY_SIZE(exynos4_iodesc); idx++, desc++)
> + if (desc->pfn == __phys_to_pfn(phy) && desc->type == type)
> + return (void __iomem *)desc->virtual;
I've just noticed that this function make access to exynos4_iodesc array which
is
placed in initdata section. This might cause a lot of strange unpredictable
issues,
so this patch should probably remove __initdata annotations in iodesc arrays.
> +
> + return __arm_ioremap(phy, size, type);
> +}
> +
> static void exynos4_idle(void)
> {
> if (!need_resched())
> diff --git a/arch/arm/mach-exynos4/include/mach/io.h
> b/arch/arm/mach-exynos4/include/mach/io.h
> index d5478d2..c1b21d5 100644
> --- a/arch/arm/mach-exynos4/include/mach/io.h
> +++ b/arch/arm/mach-exynos4/include/mach/io.h
> @@ -22,5 +22,10 @@
> #define __mem_pci(a) (a)
>
> #define IO_SPACE_LIMIT (0x)
> +#define __arch_ioremap exynos4_ioremap
> +#define __arch_iounmap __iounmap
> +
> +void __iomem *exynos4_ioremap(unsigned long phy, size_t size,
> + unsigned int type);
>
> #endif /* __ASM_ARM_ARCH_IO_H */
> --
> 1.7.4.4
>
Best regards
--
Marek Szyprowski
Samsung Poland R&D Center
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
