On 11/17/15 7:15 AM, Arnd Bergmann wrote:
On Monday 16 November 2015 16:57:32 Laura Abbott wrote:
Hi,
This is another attempt at devicetree bindings for Ion. The big complaint from
v1 was that too much unnecessary data was being pushed into devicetree.
v2 takes a different approach of using
might look like. As always, your comments and reviews are appreciated.
Thanks,
Laura
Laura Abbott (3):
ion: Devicetree bindings for Ion
staging: ion: Add files for parsing the devicetree (WIP)
NOMERGE: Sample driver
drivers/staging/android/ion/Kconfig | 16 +++
drivers/staging
Small sample driver to show what setup would look like with the dt
bindings
Signed-off-by: Laura Abbott <la...@labbott.name>
---
drivers/staging/android/ion/Kconfig | 6 ++
drivers/staging/android/ion/Makefile| 1 +
drivers/staging/android/ion/ion_of_sample.
Devicetree is the preferred mechanism for platform definition
these days. Add a set of files for supporting Ion with devicetree.
This is a set of functions for drivers to call to parse the Ion
devicetree along with definitons for defining heaps.
Signed-off-by: Laura Abbott <la...@labbott.n
This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.
Signed-off-by: Laura Abbott <la...@labbott.name>
---
drivers/staging/android/ion/devicetree.txt | 50 ++
1 file chang
:35:41 PM, Rob Herring <robherri...@gmail.com>
wrote:
On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labb...@fedoraproject.org>
wrote:
[...]
+Example:
+
+ ion {
+ compatbile = "linux,ion";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ion-system-heap {
+ li
From: Laura Abbott <la...@labbott.name>
Devicetree is the preferred mechanism for platform definition
these days. Add a set of files for supporting Ion with devicetree.
This includes a set of bindings for heaps common across all
devices and parsing methods. Clients may use the standard
bi
From: Laura Abbott <la...@labbott.name>
This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic set of heaps and
their properties.
Signed-off-by: Laura Abbott <la...@labbott.name>
Signed-off-by: Andrew Andrianov <an
From: Laura Abbott <la...@labbott.name>
Hi,
At the last Plumbers and Linaro Connect, there was some discussion
related to Ion. One of the items that came up towards eventually
getting Ion out of staging was some concept of stable devicetree
bindings. This is a proof of concept for bi
On 10/6/15 3:35 PM, Rob Herring wrote:
On Tue, Oct 6, 2015 at 3:47 PM, Laura Abbott <labb...@fedoraproject.org> wrote:
From: Laura Abbott <la...@labbott.name>
This adds a base set of devicetree bindings for the Ion memory
manager. This supports setting up the generic
(adding devicetree mailing list since I didn't see it cc-ed)
Please also remember to cc the staging list since Ion is
still a staging framework.
On 06/30/2015 08:34 AM, Andrew Andrianov wrote:
Signed-off-by: Andrew Andrianov and...@ncrmnt.org
---
On 2/7/2015 2:41 PM, a...@arndb.de wrote:
Laura Abbott lau...@codeaurora.org hat am 6. Februar 2015 um 01:31
geschrieben:
The requirement for this is based on a previous patch to add clock
support to the ARM SMMU driver[2]. Once we have clock support, it's
possible that the driver itself may
of_dma_configure is currently a void function. IOMMU configuration may
need to defer probing so return appropriate values.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
drivers/iommu/of_iommu.c | 14 +++---
drivers/of/device.c | 9 +++--
include/linux/of_device.h | 4
...@codeaurora.org
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
This is a rework of the patch to add clocks and it attempted to address
previous comments. I sent it with this series to give the rest of the
RFC some series but I'll probably resend later versions of this one separately
from
With the addition of clocks in the SMMU driver, the driver
now may need to be deferred if the clocks are not ready. Apart from
just the probe function though, we may need to defer attachment as
well. Support both of these.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
I went
://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/319390.html
Laura Abbott (3):
dma-mapping: Make arch_setup_dma_ops return an error code
of: Return error codes from of_dma_configure
iommu/arm-smmu: Support deferred probing
Mitchel Humpherys (1):
iommu/arm-smmu: add support
Setting up the DMA operations may trigger a probe deferral.
Return a proper error code to let probe deferral do its thing.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
arch/arm/include/asm/dma-mapping.h | 2 +-
arch/arm/mm/dma-mapping.c| 4 +++-
arch/arm64/include/asm
On 8/12/2014 9:48 AM, Grant Likely wrote:
On Wed, 6 Aug 2014 17:02:44 -0500, Rob Herring robherri...@gmail.com wrote:
On Wed, Aug 6, 2014 at 3:30 PM, Al Cooper alcoop...@gmail.com wrote:
__reserved_mem_reserve_reg() won't reserve memory if the base address
is zero. This change removes the
On 7/14/2014 12:12 AM, Marek Szyprowski wrote:
Add a function to create CMA region from previously reserved memory
and add support for handling 'shared-dma-pool' reserved-memory device
tree nodes.
Based on previous code provided by Josh Cartwright jo...@codeaurora.org
Signed-off-by: Marek
the default
240MB vmalloc space, 64M is ~25% of the vmalloc space. At least on arm you can
make this up by remapping the memory as coherent.
I haven't seen this picked up anywhere yet so you are welcome to add
Tested-by: Laura Abbott lau...@codeaurora.org
Thanks,
Laura
--
Qualcomm Innovation Center
On 7/26/2014 2:20 PM, Rob Herring wrote:
On Tue, Jul 15, 2014 at 12:03 PM, Laura Abbott lau...@codeaurora.org wrote:
Hi,
This is a resend of the series to fix the uboot bug exposed by the removal
of meminfo. I haven't gotten any acks though.
Is the bug with ATAGs that get converted to DT
Hi,
This is a resend of the series to fix the uboot bug exposed by the removal
of meminfo. I haven't gotten any acks though.
Please help with review/acks. Grant/Rob, I'd still like this to go through
the devicetree tree if possible.
Thanks,
Laura
--
The Qualcomm Innovation Center, Inc. is a
the memory.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
drivers/of/fdt.c | 18 +-
include/linux/of_fdt.h | 2 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c4cddf0..55bfca9 100644
--- a/drivers/of/fdt.c
+++ b
. In this fixup function for exynos, limit the maximum
number of memory regions in the devicetree.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
arch/arm/include/asm/mach/arch.h | 1 +
arch/arm/kernel/devtree.c| 7 ++-
arch/arm/mach-exynos/exynos.c| 10 ++
3 files changed, 17
Buggy bootloaders may pass bogus memory entries in the devicetree.
Add of_fdt_limit_memory to add an upper bound on the number of
entries that can be present in the devicetree.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
drivers/of/fdt.c | 48
(phys_addr_t).
Check against phys_addr_t instead.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
drivers/of/fdt.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index b777d8f..b88a68e 100644
--- a/drivers/of/fdt.c
+++ b
On 7/1/2014 7:03 PM, Laura Abbott wrote:
Currently, early_init_dt_scan validates the header, sets the
boot params, and scans for chosen/memory all in one function.
Split this up into two separate functions (validation/setting
boot params in one, scanning in another) to allow for
additional
the memory.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
drivers/of/fdt.c | 18 +-
include/linux/of_fdt.h | 2 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c4cddf0..55bfca9 100644
--- a/drivers/of/fdt.c
+++ b
. In this fixup function for exynos, limit the maximum
number of memory regions in the devicetree.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
arch/arm/include/asm/mach/arch.h | 1 +
arch/arm/kernel/devtree.c| 7 ++-
arch/arm/mach-exynos/exynos.c| 10 ++
3 files changed, 17
Buggy bootloaders may pass bogus memory entries in the devicetree.
Add of_fdt_limit_memory to add an upper bound on the number of
entries that can be present in the devicetree.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
drivers/of/fdt.c | 48
On 6/30/2014 3:43 AM, Grant Likely wrote:
Instead of splitting early_init_dt_scan(), the call to
early_init_dt_scan() could probably be moved after the
of_flat_dt_match_machine() call. It's at least worth a try. Looking at
the code I don't see anything obvious that requires the
-by: Laura Abbott lau...@codeaurora.org
---
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/265615.html
For those who did not see the discussion before
---
arch/arm/include/asm/mach/arch.h | 10 --
arch/arm/kernel/atags_parse.c| 1 +
arch/arm/kernel/devtree.c
the memory.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
drivers/of/fdt.c | 18 +-
include/linux/of_fdt.h | 2 ++
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c4cddf0..55bfca9 100644
--- a/drivers/of/fdt.c
+++ b
outside the
range of phys_addr_t. Add range checks for the base and size if
phys_addr_t is smaller than u64.
Reported-by: Geert Uytterhoeven ge...@linux-m68k.org
Tested-by: Geert Uytterhoeven ge...@linux-m68k.org
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
v2: Switched to sizeof
On 6/3/2014 6:28 AM, Will Deacon wrote:
Hi Laura,
On Mon, Jun 02, 2014 at 09:03:52PM +0100, Laura Abbott wrote:
Neither CMA nor noncoherent allocations support atomic allocations.
Add a dedicated atomic pool to support this.
Change-Id: I46c8fdffe5e0687403d42b37643137c8cf344259
Signed-off
Neither CMA nor noncoherent allocations support atomic allocations.
Add a dedicated atomic pool to support this.
Change-Id: I46c8fdffe5e0687403d42b37643137c8cf344259
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
v2: Various bug fixes pointed out by David and Ritesh (CMA dependency
On 2/12/2014 3:51 AM, Arnd Bergmann wrote:
On Wednesday 12 February 2014, Laura Abbott wrote:
This is an RFC to seed the random number pool earlier when using devicetree.
The big issue this is trying to solve is the fact that the stack canary for
ARM tends to be the same across bootups
On 2/12/2014 8:49 AM, Grant Likely wrote:
On Tue, 11 Feb 2014 17:33:24 -0800, Laura Abbott lau...@codeaurora.org wrote:
The stack canary for ARM is currently the same across reboots
due to lack of randomness early enough. Add ARCH_WANT_OF_RANDOMNESS
to allow devices to add whatever randomness
The stack canary for ARM is currently the same across reboots
due to lack of randomness early enough. Add ARCH_WANT_OF_RANDOMNESS
to allow devices to add whatever randomness they need.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
arch/arm/Kconfig |3 +++
arch/arm/kernel
have would be reasonable if only seeded earlier.
Thanks,
Laura
Laura Abbott (3):
of: Add early randomness hooks
arm: Add ARCH_WANT_OF_RANDOMNESS
init: Move stack canary initialization after setup_arch
arch/arm/Kconfig |3 ++
arch/arm/kernel/vmlinux.lds.S |1
-by: Laura Abbott lau...@codeaurora.org
---
init/main.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/init/main.c b/init/main.c
index eb03090..63d0596 100644
--- a/init/main.c
+++ b/init/main.c
@@ -489,11 +489,6 @@ asmlinkage void __init start_kernel(void
is present the
function is called. Note that this must happen on the flattened
devicetree to ensure the randomness gets added to the pool
early enough to make a difference.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
drivers/of/Kconfig|7 ++
drivers/of/Makefile
Hi,
On 2/4/2014 4:09 AM, Marek Szyprowski wrote:
...
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index efd05102c405..ed9660adad77 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
43 matches
Mail list logo
