* Re: [PATCH 1/4] ARM: STi: add stid127 soc support
From: srinivas kandagatla @ 2014-02-05 11:48 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, devicetree, Russell King, kernel, Linus Walleij,
Patrice CHOTARD, linux-kernel, Stuart Menefy, Rob Herring,
Grant Likely, Giuseppe Cavallaro, maxime.coquelin,
alexandre.torgue
In-Reply-To: <201401312115.33731.arnd@arndb.de>
Hi Arnd,
On 31/01/14 20:15, Arnd Bergmann wrote:
> On Friday 31 January 2014, srinivas kandagatla wrote:
>
>>> Sorry if I missed the initial review, but can you explain
>>> why this is needed to start with?
>>
>> On ST SoCs the default value for L2 AUX_CTRL register is 0x0, so we set
>> the way-size explicit here.
>
> Unfortunately, we keep going back and forth on the L2 cache controller
> setup between "it should work automatically" and "we don't want to
> have configuration data in DT", where my personal opinion is that
> the first one is more important here.
>
> Now, there are a couple of properties that are defined in
> Documentation/devicetree/bindings/arm/l2cc.txt to let some of the
> things get set up automatically already. Can you check which bits
> are missing there, if any? Are they better described as "configuration"
> or "hardware" settings?
Currently l2cc bindings has few optional properties like.
- arm,data-latency
- arm,tag-latency
- arm,dirty-latency
- arm,filter-ranges
- interrupts :
- cache-id-part:
- wt-override:
These does not include properties to set "way-size", "associativity",
"enabling prefetching", "Prefetch drop enable", "prefetch offset",
"Double linefill" and few more in prefect control register and
aux-control register.
This is not just a issue with STi SOCs, having a quick look, I can see
that few more SOCs have similar requirements to set these properties.
We could do two things to get l2 setup automatically on STi SOCS.
1> Either define these properties case-by-case basic, which might be
useful for other SOCs too.
2> Or Add new compatible string for STi SoCs so that they can
automatically setup these values in cache-l2x0.c
Am Ok with either approaches.
Thanks,
srini
>
> Arnd
>
>
^ permalink raw reply
* Re: [RFC PATCH v2 03/14] of: mtd: add documentation for nand-ecc-level property
From: Grant Likely @ 2014-02-05 11:15 UTC (permalink / raw)
To: Ezequiel Garcia, Boris BREZILLON
Cc: Maxime Ripard, Rob Landley, Russell King, David Woodhouse,
Brian Norris, Jason Gunthorpe, Arnd Bergmann, devicetree,
linux-doc, dev, linux-kernel, linux-mtd, linux-arm-kernel,
Pekon Gupta
In-Reply-To: <20140129175331.GA27143@localhost>
On Wed, 29 Jan 2014 14:53:32 -0300, Ezequiel Garcia <ezequiel.garcia@free-electrons.com> wrote:
> On Wed, Jan 29, 2014 at 03:34:13PM +0100, Boris BREZILLON wrote:
> > nand-ecc-level property statically defines NAND chip's ECC requirements.
> >
> > Signed-off-by: Boris BREZILLON <b.brezillon.dev@gmail.com>
> > ---
> > Documentation/devicetree/bindings/mtd/nand.txt | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
> > index 03855c8..0c962296 100644
> > --- a/Documentation/devicetree/bindings/mtd/nand.txt
> > +++ b/Documentation/devicetree/bindings/mtd/nand.txt
> > @@ -3,5 +3,8 @@
> > - nand-ecc-mode : String, operation mode of the NAND ecc mode.
> > Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
> > "soft_bch".
> > +- nand-ecc-level : Two cells property defining the ECC level requirements.
> > + The first cell represent the strength and the second cell the ECC block size.
> > + E.g. : nand-ecc-level = <4 512>; /* 4 bits / 512 bytes */
> > - nand-bus-width : 8 or 16 bus width if not present 8
> > - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
>
> Hm.. when was this proposal agreed? It seems I've missed the
> discussion...
>
> FWIW, we've already proposed an equivalent one, but it received no
> feedback from the devicetree maintainers:
Sorry, binding review has become a huge undertaking.
>
> http://comments.gmane.org/gmane.linux.drivers.devicetree/58764
>
> Maybe we can discuss about it now?
>
> nand-ecc-strength : integer ECC required strength.
> nand-ecc-size : integer step size associated to the ECC strength.
I'm okay with either, but the above binding is indeed more readable.
g.
^ permalink raw reply
* Re: [PATCH v7 2/7] dt-bindings: sram: describe option to reserve parts of the memory
From: Grant Likely @ 2014-02-05 11:12 UTC (permalink / raw)
To: linux-arm-kernel@lists.infradead.org
Cc: Mark Rutland, devicetree, Pawel Moll, Stephen Warren,
Greg Kroah-Hartman, Ian Campbell, linux-kernel, arm,
Philipp Zabel
In-Reply-To: <1782709.QdZpsrsctf@phil>
[-- Attachment #1: Type: text/plain, Size: 1555 bytes --]
On Mon, 20 Jan 2014 16:42:58 +0100, Heiko Stübner <heiko@sntech.de> wrote:
> Some SoCs need parts of their sram for special purposes. So while being part
> of the peripheral, it should not be part of the genpool controlling the sram.
>
> Therefore add an option mmio-sram-reserved to keep arbitrary portions of the
> sram from general usage.
>
> Suggested-by: Rob Herring <robherring2@gmail.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> Tested-by: Ulrich Prinz <ulrich.prinz@googlemail.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> Documentation/devicetree/bindings/misc/sram.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
> index 4d0a00e..09ee7a3 100644
> --- a/Documentation/devicetree/bindings/misc/sram.txt
> +++ b/Documentation/devicetree/bindings/misc/sram.txt
> @@ -8,9 +8,17 @@ Required properties:
>
> - reg : SRAM iomem address range
>
> +Optional properties:
> +
> +- mmio-sram-reserved: ordered list of reserved chunks inside the sram that
> + should not be used by the operating system.
> + Format is <base size>, <base size>, ...; with base being relative to the
> + reg property base.
> +
We've now got a draft binding for reserved memory. Can you use the format
here? Basically each reserved region is a sub node with either a reg
property or a size property.
This is specifically for sram, so I won't make a big deal about it, but
it would be good to have some commonality.
g.
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 3/5] drivers: of: implement reserved-memory handling for cma
From: Grant Likely @ 2014-02-05 11:09 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linaro-mm-sig, devicetree,
linux-doc
Cc: Marek Szyprowski, Kyungmin Park, Benjamin Herrenschmidt,
Arnd Bergmann, Michal Nazarewicz, Tomasz Figa, Sascha Hauer,
Laura Abbott, Rob Herring, Olof Johansson, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Tomasz Figa,
Kumar Gala, Nishanth Peethambaran, Marc, Josh Cartwright
In-Reply-To: <1391515773-6112-4-git-send-email-m.szyprowski@samsung.com>
On Tue, 04 Feb 2014 13:09:31 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> From: Josh Cartwright <joshc@codeaurora.org>
>
> Add support for handling 'shared-dma-pool' reserved-memory nodes using
> Contiguous Memory Allocator driver.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Laura Abbott <lauraa@codeaurora.org>
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/of/Kconfig | 7 ++++
> drivers/of/Makefile | 1 +
> drivers/of/of_reserved_mem_cma.c | 75 ++++++++++++++++++++++++++++++++++++++
> 3 files changed, 83 insertions(+)
> create mode 100644 drivers/of/of_reserved_mem_cma.c
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index 7ac330473ec9..5dd3a80910d2 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -81,6 +81,13 @@ config OF_RESERVED_MEM
> help
> Helpers to allow for reservation of memory regions
>
> +config OF_RESERVED_MEM_CMA
> + depends on OF_RESERVED_MEM
> + depends on DMA_CMA
> + def_bool y
> + help
> + Helpers for reserving memory regions for DMA use
> +
> config OF_RESERVED_MEM_DMA
> depends on OF_RESERVED_MEM
> depends on HAVE_GENERIC_DMA_COHERENT
> diff --git a/drivers/of/Makefile b/drivers/of/Makefile
> index 6142227ca854..49b9078637b8 100644
> --- a/drivers/of/Makefile
> +++ b/drivers/of/Makefile
> @@ -10,4 +10,5 @@ obj-$(CONFIG_OF_PCI) += of_pci.o
> obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
> obj-$(CONFIG_OF_MTD) += of_mtd.o
> obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
> +obj-$(CONFIG_OF_RESERVED_MEM_CMA) += of_reserved_mem_cma.o
> obj-$(CONFIG_OF_RESERVED_MEM_DMA) += of_reserved_mem_dma.o
> diff --git a/drivers/of/of_reserved_mem_cma.c b/drivers/of/of_reserved_mem_cma.c
> new file mode 100644
> index 000000000000..601d80655102
> --- /dev/null
> +++ b/drivers/of/of_reserved_mem_cma.c
> @@ -0,0 +1,75 @@
> +/*
> + * Device tree based initialization code for DMA reserved regions.
> + *
> + * Copyright (c) 2013, The Linux Foundation. All Rights Reserved.
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + * Author: Marek Szyprowski <m.szyprowski@samsung.com>
> + * Author: Josh Cartwright <joshc@codeaurora.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License or (at your optional) any later version of the license.
> + */
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/of_platform.h>
> +#include <linux/mm.h>
> +#include <linux/sizes.h>
> +#include <linux/mm_types.h>
> +#include <linux/dma-contiguous.h>
> +#include <linux/of_reserved_mem.h>
> +
> +static void rmem_cma_device_init(struct reserved_mem *rmem,
> + struct device *dev,
> + struct of_phandle_args *args)
> +{
> + struct cma *cma = rmem->priv;
> + dev_set_cma_area(dev, cma);
> +}
> +
> +static const struct reserved_mem_ops rmem_cma_ops = {
> + .device_init = rmem_cma_device_init,
> +};
> +
> +static int __init rmem_cma_setup(struct reserved_mem *rmem,
> + unsigned long node,
> + const char *uname)
> +{
> + struct cma *cma;
> + int err;
> +
> + if (!of_get_flat_dt_prop(node, "reusable", NULL))
> + return -EINVAL;
> +
> + err = of_parse_flat_dt_reg(node, uname, &rmem->base, &rmem->size);
> + if (!err)
> + goto out_done;
> +
> + rmem->base = 0;
> + err = of_parse_flat_dt_size(node, uname, &rmem->size);
> + if (err)
> + goto out_err;
> +
> +out_done:
Please restrict gotos for error handling. Why not the following:
err = of_parse_flat_dt_reg(node, uname, &rmem->base, &rmem->size);
if (err) {
rmem->base = 0;
err = of_parse_flat_dt_size(node, uname, &rmem->size);
if (err)
goto out_err;
}
> + err = dma_contiguous_reserve_area(rmem->size, rmem->base, 0,
> + &cma);
> + if (err) {
> + pr_err("Reserved memory: unable to setup CMA region\n");
> + return err;
> + }
> +
> + if (of_get_flat_dt_prop(node, "linux,cma-default", NULL))
> + dma_contiguous_set_default(cma);
> +
> + rmem->ops = &rmem_cma_ops;
> + rmem->priv = cma;
> +
> + return 0;
> +out_err:
> + pr_err("Reseved memory: malformed node '%s'.\n", uname);
> + return err;
> +}
> +RESERVEDMEM_OF_DECLARE(cma, "shared-dma-pool", rmem_cma_setup);
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH v2 1/5] drivers: of: add initialization code for reserved memory
From: Grant Likely @ 2014-02-05 11:05 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linaro-mm-sig, devicetree,
linux-doc
Cc: Marek Szyprowski, Kyungmin Park, Benjamin Herrenschmidt,
Arnd Bergmann, Michal Nazarewicz, Tomasz Figa, Sascha Hauer,
Laura Abbott, Rob Herring, Olof Johansson, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Tomasz Figa,
Kumar Gala, Nishanth Peethambaran, Marc, Josh Cartwright
In-Reply-To: <1391515773-6112-2-git-send-email-m.szyprowski@samsung.com>
On Tue, 04 Feb 2014 13:09:29 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> This patch adds device tree support for contiguous and reserved memory
> regions defined in device tree.
>
> Large memory blocks can be reliably reserved only during early boot.
> This must happen before the whole memory management subsystem is
> initialized, because we need to ensure that the given contiguous blocks
> are not yet allocated by kernel. Also it must happen before kernel
> mappings for the whole low memory are created, to ensure that there will
> be no mappings (for reserved blocks) or mapping with special properties
> can be created (for CMA blocks). This all happens before device tree
> structures are unflattened, so we need to get reserved memory layout
> directly from fdt.
>
> Later, those reserved memory regions are assigned to devices on each
> device structure initialization.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Laura Abbott <lauraa@codeaurora.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> [joshc: rework to implement new DT binding, provide mechanism for
> plugging in new reserved-memory node handlers via
> RESERVEDMEM_OF_DECLARE]
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> [mszyprow: little code cleanup]
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> drivers/of/Kconfig | 6 +
> drivers/of/Makefile | 1 +
> drivers/of/of_reserved_mem.c | 219 +++++++++++++++++++++++++++++++++++++
> drivers/of/platform.c | 7 ++
> include/asm-generic/vmlinux.lds.h | 11 ++
> include/linux/of_reserved_mem.h | 62 +++++++++++
> 6 files changed, 306 insertions(+)
> create mode 100644 drivers/of/of_reserved_mem.c
> create mode 100644 include/linux/of_reserved_mem.h
>
> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> index c6973f101a3e..aba13df56f3a 100644
> --- a/drivers/of/Kconfig
> +++ b/drivers/of/Kconfig
> @@ -75,4 +75,10 @@ config OF_MTD
> depends on MTD
> def_bool y
>
> +config OF_RESERVED_MEM
> + depends on HAVE_MEMBLOCK
> + def_bool y
> + help
> + Helpers to allow for reservation of memory regions
> +
> endmenu # OF
> 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
> obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
> obj-$(CONFIG_OF_MTD) += of_mtd.o
> +obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> new file mode 100644
> index 000000000000..f17cd56e68d9
> --- /dev/null
> +++ b/drivers/of/of_reserved_mem.c
> @@ -0,0 +1,219 @@
> +/*
> + * Device tree based initialization code for reserved memory.
> + *
> + * Copyright (c) 2013, The Linux Foundation. All Rights Reserved.
> + * Copyright (c) 2013 Samsung Electronics Co., Ltd.
> + * http://www.samsung.com
> + * Author: Marek Szyprowski <m.szyprowski@samsung.com>
> + * Author: Josh Cartwright <joshc@codeaurora.org>
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License or (at your optional) any later version of the license.
> + */
> +#include <linux/memblock.h>
> +#include <linux/err.h>
> +#include <linux/of.h>
> +#include <linux/of_fdt.h>
> +#include <linux/of_platform.h>
> +#include <linux/mm.h>
> +#include <linux/sizes.h>
> +#include <linux/of_reserved_mem.h>
> +
> +#define MAX_RESERVED_REGIONS 16
> +static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
> +static int reserved_mem_count;
> +
> +int __init of_parse_flat_dt_reg(unsigned long node, const char *uname,
> + phys_addr_t *base, phys_addr_t *size)
Useful utility function; move to drivers/of/fdt.c
> +{
> + unsigned long len;
> + __be32 *prop;
> +
> + prop = of_get_flat_dt_prop(node, "reg", &len);
> + if (!prop)
> + return -EINVAL;
> +
> + if (len < (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32)) {
> + pr_err("Reserved memory: invalid reg property in '%s' node.\n",
> + uname);
> + return -EINVAL;
> + }
This is /okay/ for an initial implementation, but it is naive. While I
suggested making #address-cells and #size-cells equal the root node
values for the purpose of simplicity, it should still be perfectly valid
to have different values if the ranges property is correctly formed.
> +
> + *base = dt_mem_next_cell(dt_root_addr_cells, &prop);
> + *size = dt_mem_next_cell(dt_root_size_cells, &prop);
Future enhancement; allow for parsing more than just the first reg
tuple.
> + return 0;
> +}
> +
> +int __init of_parse_flat_dt_size(unsigned long node, const char *uname,
> + phys_addr_t *size)
> +{
> + unsigned long len;
> + __be32 *prop;
> +
> + prop = of_get_flat_dt_prop(node, "size", &len);
> + if (!prop)
> + return -EINVAL;
> +
> + if (len < dt_root_size_cells * sizeof(__be32)) {
> + pr_err("Reserved memory: invalid size property in '%s' node.\n",
> + uname);
> + return -EINVAL;
> + }
More than that, the size should be dead on. '==' would be the correct
test I think.
> +
> + *size = dt_mem_next_cell(dt_root_size_cells, &prop);
> + return 0;
> +}
> +
> +static int __init rmem_default_early_setup(struct reserved_mem *rmem,
> + unsigned long node,
> + const char *uname)
> +{
> + int err;
> +
> + if (of_get_flat_dt_prop(node, "compatible", NULL))
> + return -EINVAL;
> +
> + err = of_parse_flat_dt_reg(node, uname, &rmem->base, &rmem->size);
> + if (err)
> + return err;
> +
> + if (of_get_flat_dt_prop(node, "no-map", NULL))
> + err = memblock_remove(rmem->base, rmem->size);
> + else
> + err = memblock_reserve(rmem->base, rmem->size);
This is the only dependency on memblock. Make it an arch hook, and
create a default __weak implementation:
#if defined(CONFIG_HAVE_MEMBLOCK)
int __init __weak early_init_dt_reserve_memory_arch(u64 base, u64 size, bool nomap)
{
if (nomap)
return memblock_remove(base, size);
return memblock_reserve(base, size);
}
#else
int __init __weak early_init_dt_reserve_memory_arch(u64 base, u64 size, bool nomap)
{
pr_error("Reserved memory not supported, ignoring range 0x%llx - 0x%llx%s\n",
base, size, nomap ? " (nomap)" : "");
}
#endif
> +
> + if (err == 0)
> + pr_info("Reserved memory: found '%s', memory base %pa, size %ld MiB\n",
> + uname, &rmem->base, (unsigned long)rmem->size / SZ_1M);
pr_info will be too chatty I think. pr_debug please.
> +
> + return err;
> +}
> +
> +static const struct of_device_id rmem_default_id
> + __used __section(__reservedmem_of_table_end) = {
> + .data = rmem_default_early_setup,
> +};
I was going to say this isn't very type safe and that the only reason to
use of_device_id is when using of_match_node() which will iterate a
table for you. But reading further I see you're handling type checking
in the macro so this is okay.
> +
> +static int __init fdt_scan_reserved_mem(unsigned long node, const char *uname,
> + int depth, void *data)
Move this function to fdt.c. It should be treated as a fundamental part
of memory node parsing. It should also always be enabled, regardless of
the CONFIG_OF_RESERVED_MEMORY state because the region should always be
set aside even when the kernel doesn't know how to use it.
> +{
> + struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
> + extern const struct of_device_id __reservedmem_of_table[];
> + const struct of_device_id *id;
> + const char *status;
> +
> + if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
> + pr_err("Reserved memory: not enough space all defined regions.\n");
> + return -ENOSPC;
> + }
It is not okay to bail here. If a region is reserved, then the kernel
*MUST* honor it, even if drivers cannot make use of it. As a bare
minimum it should be removed from the memblock pool.
> +
> + status = of_get_flat_dt_prop(node, "status", NULL);
> + if (status && strcmp(status, "okay") != 0)
> + return 0;
> +
> + /*
> + * The default handler above ensures this section is terminated with a
> + * id whose compatible string is empty
> + */
> + for (id = __reservedmem_of_table; id <= &rmem_default_id; id++) {
> + reservedmem_of_init_fn initfn = id->data;
> + const char *compat = id->compatible;
> +
> + if (compat[0] && !of_flat_dt_is_compatible(node, compat))
> + continue;
> +
> + if (initfn(rmem, node, uname) == 0) {
> + pr_info("Reserved memory: created %s node, compatible id %s\n",
> + uname, compat);
> + rmem->name = uname;
> + reserved_mem_count++;
> + break;
> + }
> + }
What would be the condition that a special setup hook is called, but the
memory is not removed from the memblock pool? I seems wrong to me that
memory blocks wouldn't always get removed from main memory; even if
special setup code is executed on them.
By calling out to extra setup functions it means that each one of them
needs to implement its own memory removal code and get it correct. There
is a strong possibility for bugs there.
> +
> + return 0;
> +}
> +
> +static struct reserved_mem *find_rmem(struct device_node *np)
> +{
> + const char *name;
> + unsigned int i;
> +
> + name = kbasename(np->full_name);
> +
> + for (i = 0; i < reserved_mem_count; i++)
> + if (strcmp(name, reserved_mem[i].name) == 0)
> + return &reserved_mem[i];
This looks fragile. It needs to match on the full path, not just
kbasename(), but that is expensive. However, all reserved regions should
have a phandle. You can use that for matching.
> +
> + return NULL;
> +}
> +
> +/**
> + * of_reserved_mem_device_init() - assign reserved memory region to given device
> + *
> + * This function assign memory region pointed by "memory-region" device tree
> + * property to the given device.
> + */
> +void of_reserved_mem_device_init(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct reserved_mem *rmem;
> + struct of_phandle_args s;
> + unsigned int i;
> +
> + for (i = 0; of_parse_phandle_with_args(np, "memory-region",
> + "#memory-region-cells", i, &s) == 0; i++) {
> +
> + rmem = find_rmem(s.np);
> + if (!rmem || !rmem->ops || !rmem->ops->device_init) {
> + of_node_put(s.np);
> + continue;
> + }
> +
> + rmem->ops->device_init(rmem, dev, &s);
> + dev_info(dev, "assigned reserved memory node %s\n",
> + rmem->name);
> + of_node_put(s.np);
> + break;
> + }
> +}
> +
> +/**
> + * of_reserved_mem_device_release() - release reserved memory device structures
> + *
> + * This function releases structures allocated for memory region handling for
> + * the given device.
> + */
> +void of_reserved_mem_device_release(struct device *dev)
> +{
> + struct device_node *np = dev->of_node;
> + struct reserved_mem *rmem;
> + struct of_phandle_args s;
> + unsigned int i;
> +
> + for (i = 0; of_parse_phandle_with_args(np, "memory-region",
> + "#memory-region-cells", i, &s) == 0; i++) {
> +
> + rmem = find_rmem(s.np);
> + if (rmem && rmem->ops && rmem->ops->device_release)
> + rmem->ops->device_release(rmem, dev);
> +
> + of_node_put(s.np);
> + }
> +}
> +
> +/**
> + * early_init_dt_scan_reserved_mem() - create reserved memory regions
> + *
> + * This function grabs memory from early allocator for device exclusive use
> + * defined in device tree structures. It should be called by arch specific code
> + * once the early allocator (memblock) has been activated and all other
> + * subsystems have already allocated/reserved memory.
As commented on patch 4, this should be called by common parsing code,
not arch code.
Why do you require other subsystems to allocate/reserve memory before
the reserved regions? I would think that the reserved regions declared
in the device tree would take precedence.
> + */
> +void __init early_init_dt_scan_reserved_mem(void)
> +{
> + of_scan_flat_dt_by_path("/reserved-memory", fdt_scan_reserved_mem,
> + NULL);
> +}
> diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> index 404d1daebefa..3df0b1826e8b 100644
> --- a/drivers/of/platform.c
> +++ b/drivers/of/platform.c
> @@ -21,6 +21,7 @@
> #include <linux/of_device.h>
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> +#include <linux/of_reserved_mem.h>
> #include <linux/platform_device.h>
>
> const struct of_device_id of_default_bus_match_table[] = {
> @@ -220,6 +221,8 @@ static struct platform_device *of_platform_device_create_pdata(
> dev->dev.bus = &platform_bus_type;
> dev->dev.platform_data = platform_data;
>
> + of_reserved_mem_device_init(&dev->dev);
> +
> /* We do not fill the DMA ops for platform devices by default.
> * This is currently the responsibility of the platform code
> * to do such, possibly using a device notifier
> @@ -227,6 +230,7 @@ static struct platform_device *of_platform_device_create_pdata(
>
> if (of_device_add(dev) != 0) {
> platform_device_put(dev);
> + of_reserved_mem_device_release(&dev->dev);
> return NULL;
> }
>
> @@ -282,6 +286,8 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
> else
> of_device_make_bus_id(&dev->dev);
>
> + of_reserved_mem_device_init(&dev->dev);
> +
> /* Allow the HW Peripheral ID to be overridden */
> prop = of_get_property(node, "arm,primecell-periphid", NULL);
> if (prop)
> @@ -308,6 +314,7 @@ static struct amba_device *of_amba_device_create(struct device_node *node,
> return dev;
>
> err_free:
> + of_reserved_mem_device_release(&dev->dev);
> amba_device_put(dev);
> return NULL;
> }
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index bc2121fa9132..f10f64fcc815 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -167,6 +167,16 @@
> #define CLK_OF_TABLES()
> #endif
>
> +#ifdef CONFIG_OF_RESERVED_MEM
> +#define RESERVEDMEM_OF_TABLES() \
> + . = ALIGN(8); \
> + VMLINUX_SYMBOL(__reservedmem_of_table) = .; \
> + *(__reservedmem_of_table) \
> + *(__reservedmem_of_table_end)
> +#else
> +#define RESERVEDMEM_OF_TABLES()
> +#endif
> +
> #define KERNEL_DTB() \
> STRUCT_ALIGN(); \
> VMLINUX_SYMBOL(__dtb_start) = .; \
> @@ -490,6 +500,7 @@
> TRACE_SYSCALLS() \
> MEM_DISCARD(init.rodata) \
> CLK_OF_TABLES() \
> + RESERVEDMEM_OF_TABLES() \
> CLKSRC_OF_TABLES() \
> KERNEL_DTB() \
> IRQCHIP_OF_MATCH_TABLE()
> diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
> new file mode 100644
> index 000000000000..41f43828e1db
> --- /dev/null
> +++ b/include/linux/of_reserved_mem.h
> @@ -0,0 +1,62 @@
> +#ifndef __OF_RESERVED_MEM_H
> +#define __OF_RESERVED_MEM_H
> +
> +struct cma;
> +struct platform_device;
> +struct of_phandle_args;
> +struct reserved_mem_ops;
> +
> +struct reserved_mem {
> + const char *name;
> + const struct reserved_mem_ops *ops;
> + phys_addr_t base;
> + phys_addr_t size;
> + void *priv;
> +};
> +
> +struct reserved_mem_ops {
> + void (*device_init)(struct reserved_mem *rmem,
> + struct device *dev,
> + struct of_phandle_args *args);
> + void (*device_release)(struct reserved_mem *rmem,
> + struct device *dev);
> +};
> +
> +typedef int (*reservedmem_of_init_fn)(struct reserved_mem *rmem,
> + unsigned long node, const char *uname);
> +
> +#ifdef CONFIG_OF_RESERVED_MEM
> +void of_reserved_mem_device_init(struct device *dev);
> +void of_reserved_mem_device_release(struct device *dev);
> +void early_init_dt_scan_reserved_mem(void);
> +
> +int of_parse_flat_dt_reg(unsigned long node, const char *uname,
> + phys_addr_t *base, phys_addr_t *size);
> +int of_parse_flat_dt_size(unsigned long node, const char *uname,
> + phys_addr_t *size);
> +
> +#define RESERVEDMEM_OF_DECLARE(name, compat, init) \
> + static const struct of_device_id __reservedmem_of_table_##name \
> + __used __section(__reservedmem_of_table) \
> + = { .compatible = compat, \
> + .data = (init == (reservedmem_of_init_fn)NULL) ? \
> + init : init }
Clever type checking! I haven't known about doing it that way.
> +
> +#else
> +static inline void of_reserved_mem_device_init(struct device *dev) { }
> +
> +static inline
> +void of_reserved_mem_device_release(struct device *dev) { }
> +
> +static inline void early_init_dt_scan_reserved_mem(void) { }
> +
> +#define RESERVEDMEM_OF_DECLARE(name, compat, init) \
> + static const struct of_device_id __reservedmem_of_table_##name \
> + __attribute__((unused)) \
> + = { .compatible = compat, \
> + .data = (init == (reservedmem_of_init_fn)NULL) ? \
> + init : init }
> +
> +#endif
> +
> +#endif /* __OF_RESERVED_MEM_H */
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH v4 1/2] iio:as3935: Add DT binding docs for AS3935 driver
From: Jonathan Cameron @ 2014-02-05 10:58 UTC (permalink / raw)
To: Matt Ranostay
Cc: Matt Porter, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou
In-Reply-To: <CAKzfze8d7uzwmTByJD-jmZszeD7fr=1k0y0jdCLU92wNOD=NMg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On February 5, 2014 10:22:24 AM GMT+00:00, Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>On Tue, Feb 4, 2014 at 11:24 PM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>wrote:
>>
>>
>> On February 5, 2014 4:43:35 AM GMT+00:00, Matt Porter
><mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>>On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay
>>>wrote:
>>>> Document compatible string, required and optional DT properties for
>>>> AS3935 chipset driver.
>>>>
>>>> Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>>> ---
>>>> .../devicetree/bindings/iio/proximity/as3935.txt | 25
>>>++++++++++++++++++++++
>>>> 1 file changed, 25 insertions(+)
>>>> create mode 100644
>>>Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>>>
>>>> diff --git
>>>a/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>>b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>>> new file mode 100644
>>>> index 0000000..7e117cd
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>>> @@ -0,0 +1,25 @@
>>>> +Austrian Microsystems AS3935 Franklin lightning sensor device
>driver
>>>> +
>>>> +Required properties:
>>>> + - compatible: must be "ams,as3935"
>>>
>>>Change this to "amstaos,as3935"
>>>
>>>amstaos (AMS bought Taos) is already a registered vendor prefix in
>>>vendor-prefixes.txt
>>
>> It is but has a rather separate presence and is not where people
>expect to find non light
>> sensor stuff from ams. I personally would go for a new vendor prefix
>and stick with ams.
>>
>
>So should I add to vendor-prefixes.txt as well? or not?
Yes. All vendor prefixes should be in there
>
>>>
>>>> + - reg: SPI chip select number for the device
>>>> + - spi-cpha: SPI Mode 1
>>>
>>>When using generic binding properties, please reference the binding
>>>being used. Like:
>>>
>>> - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic
>SPI
>>> slave node bindings.
>>>
>>>> + - interrupt-parent : should be the phandle for the interrupt
>>>controller
>>>> + - interrupts : interrupt mapping for GPIO IRQ
>>>
>>> Refer to interrupt-controller/interrupts.txt for generic
>>> interrupt client node bindings.
>>>
>>>> +
>>>> +Optional properties:
>>>> + - ams,tune-cap: Calibration tuning capacitor stepping value 0
>- 15.
>>>> + Range of 0 to 120 pF, 8pF steps. This will require using the
>>>> + calibration data from the manufacturer.
>>>> +
>>>> +
>>>> +Example:
>>>> +
>>>> +as3935@0 {
>>>> + compatible = "ams,as3935";
>>>> + reg = <0>;
>>>> + spi-cpha;
>>>> + interrupt-parent = <&gpio1>;
>>>> + interrupts = <16 1>;
>>>> + ams,tune-cap = /bits/ 8 <10>;
>>>
>>>What is this? Why not just ams,tune-cap = <10>; ?
>>>
>>>It's a value between 0-15, right?
>>>
>>>-Matt
>>>--
>>>To unsubscribe from this list: send the line "unsubscribe linux-iio"
>in
>>>the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>> --
>> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH v2 0/6] ARM: sunxi: Add driver for SD/MMC hosts found on allwinner sunxi SOCs
From: Maxime Ripard @ 2014-02-05 10:39 UTC (permalink / raw)
To: David Lanzendörfer
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Ulf Hansson, Laurent Pinchart,
Simon Baatz, Hans de Goede, linux-mmc-u79uwXL29TY76Z2rM5mHXA,
Chris Ball, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
H Hartley Sweeten, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Tejun Heo,
Guennadi Liakhovetski,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20140204191648.29809.14611.stgit-GPtPHOohwllnsqa/0SyWJQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1439 bytes --]
Hi David,
On Tue, Feb 04, 2014 at 08:24:13PM +0100, David Lanzendörfer wrote:
> Hello
> The following patchset adds support for the SD/MMC host found in the Allwinner SoCs.
> It contains all the necessary modifications for clock environment and also the device
> tree script modification which add it to all the boards using it.
> The clock environment function needed for phase offset configuration has
> been proposed and implemented by Emilio.
> This patchset is the second attempt to send this driver upstream.
> I'm looking forward to the acceptance of this patchset into mainline.
I have four comments here:
- Read Documentation/SubmittingPatches, especially Section 5 and 12
(hints, you forgot the clock maintainers for your clock patches
and you didn't put any signed-off-by tags)
- You ignored pretty much all the comments that were made during the
review of the first version. Go through
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-December/219339.html
and address the comments that were made.
- Each of your patches should compile. Fix the order of your
patches.
- Submit a v3, with the changes you made. Otherwise we have no way
of knowing what have been fixed and what didn't
Looking forward for the next iteration!
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 8/8] ARM: dts: sun7i: Add ethernet alias for GMAC
From: Maxime Ripard @ 2014-02-05 10:32 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Emilio Lopez, Mike Turquette, linux-arm-kernel, linux-sunxi,
devicetree, linux-kernel
In-Reply-To: <CAGb2v659T_QTLChB0NRS0seQvwDBCmTAH6UBEghZng9Ac6uL4g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2266 bytes --]
On Wed, Feb 05, 2014 at 12:43:18PM +0800, Chen-Yu Tsai wrote:
> On Tue, Feb 4, 2014 at 3:38 AM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > On Mon, Feb 03, 2014 at 11:32:26AM +0800, Chen-Yu Tsai wrote:
> >> U-Boot will insert MAC address into the device tree image.
> >> It looks up ethernet[0-5] aliases to find the ethernet nodes.
> >> Alias GMAC as ethernet0, as it is the only ethernet controller used.
> >>
> >> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> >> ---
> >> arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> >> index 65fb8d0..c48fb11 100644
> >> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> >> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> >> @@ -17,7 +17,7 @@
> >> interrupt-parent = <&gic>;
> >>
> >> aliases {
> >> - ethernet0 = &emac;
> >> + ethernet0 = &gmac;
> >> };
> >
> > I'm not very fond of this patch.
> >
> > People might rely on the fact that ethernet0 is actually the emac, and
> > are expecting u-boot to fill the ethaddr variable to the emac, and not
> > the gmac.
> >
> > Since u-boot is totally able to deal with several ethernet addresses,
> > please add it as ethernet1.
>
> Actually I think we should override this in the board dts.
> The boards we currently support can only use emac or gmac,
> and in our u-boot tree, they have been converted to using
> gmac. If any future boards support both emac and gmac, we
> can address the ordering then. And the ordering should
> match u-boot.
>
> What do you think?
That what u-boot does is not a good argument (especially when it's not
even mainline u-boot we're talking about). Otherwise, I can just cook
up a bootloader of my own, do crazy stuff in it, and use that as an
argument to get crazy things in the kernel.
And you can set eth1addr just fine in u-boot.
But thinking a bit more about your patch, I guess that this patch
makes some kind of sense anyway..
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] ARM: dts: Add support of STid127 Soc.
From: Patrice Chotard @ 2014-02-05 10:27 UTC (permalink / raw)
To: srinivas kandagatla, Stuart Menefy, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kernel-F5mvAk5X5gdBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linus Walleij, Grant Likely,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: maxime.coquelin-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
Giuseppe Cavallaro
In-Reply-To: <52EB9C03.70009-qxv4g6HH51o@public.gmane.org>
Hi Srinivas
Thanks for reviewing, a V2 serie will be pushed with all required fixes.
Patrice
On 01/31/2014 01:50 PM, srinivas kandagatla wrote:
> Hi Patrice,
>
> On 30/01/14 14:55, Patrice CHOTARD wrote:
>> From: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>>
>> The STid127 integrates all harware components to function as a cable modem
> s/harware/hardware/
>
> s/STid127/STiD127
>
> Please fix other instances too.
>
>> or, in combination with a back end device, as a Gateway set top boxe.
> s/boxe/box/
>> Supported devices:
>> -UART0
>> -UART2
>>
>> Signed-off-by: alexandre torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>> ---
>> arch/arm/boot/dts/stid127-clock.dtsi | 31 ++++
>> arch/arm/boot/dts/stid127-pinctrl.dtsi | 245 ++++++++++++++++++++++++++++++++
>> arch/arm/boot/dts/stid127.dtsi | 130 +++++++++++++++++
>> 3 files changed, 406 insertions(+)
>> create mode 100644 arch/arm/boot/dts/stid127-clock.dtsi
>> create mode 100644 arch/arm/boot/dts/stid127-pinctrl.dtsi
>> create mode 100644 arch/arm/boot/dts/stid127.dtsi
>>
>> diff --git a/arch/arm/boot/dts/stid127-clock.dtsi b/arch/arm/boot/dts/stid127-clock.dtsi
>> new file mode 100644
>> index 0000000..c6cafa9
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/stid127-clock.dtsi
>> @@ -0,0 +1,31 @@
>> +/*
>> + * Copyright (C) 2013 STMicroelectronics (R&D) Limited
> 2014
>
>> + * Author(s): Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
>> + * Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +/ {Acked-by: Srinivas Kandagatla <srinivas.kandagatla-qxv4g6HH51o@public.gmane.org>
>> + clocks {
>> + /*
>> + * ARM Peripheral clock for timers
>> + */
>> + arm_periph_clk: arm_periph_clk {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <100000000>;
>> + };
>> + /*
>> + * Bootloader initialized system infrastructure clock for
>> + * serial devices.
>> + */
>> + CLK_IC_LP_HD: clockgenA0@29 {
>> + #clock-cells = <0>;
>> + compatible = "fixed-clock";
>> + clock-frequency = <100000000>;
>> + clock-output-names = "CLK_IC_LP_HD";
>> + };
>> + };
>> +};
>> diff --git a/arch/arm/boot/dts/stid127-pinctrl.dtsi b/arch/arm/boot/dts/stid127-pinctrl.dtsi
>> new file mode 100644
>> index 0000000..3fa66f3
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/stid127-pinctrl.dtsi
>> @@ -0,0 +1,245 @@
>> +/*
>> + * Copyright (C) 2012 STMicroelectronics Limited.
> 2014
>
>> + * Author(s): Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
>> + * Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * publishhed by the Free Software Foundation.
> s/publishhed/published/
>
>> + */
>> +#include "st-pincfg.h"
>> +/ {
>> + aliases {
>> + gpio0 = &PIO0;
>> + gpio1 = &PIO1;
>> + gpio2 = &PIO2;
>> + gpio3 = &PIO3;
>> + gpio4 = &PIO4;
>> + gpio5 = &PIO5;
>> + gpio6 = &PIO6;
>> + gpio7 = &PIO7;
>> + gpio8 = &PIO8;
>> + gpio9 = &PIO9;
>> + gpio10 = &PIO10;
>> + gpio11 = &PIO11;
>> + gpio12 = &PIO12;
>> + gpio13 = &PIO13;
>> + gpio14 = &PIO14;
>> + gpio15 = &PIO15;
>> + gpio16 = &PIO16;
>> + gpio17 = &PIO17;
>> + gpio18 = &PIO18;
>> + gpio19 = &PIO19;
>> + gpio20 = &PIO20;
>> + gpio21 = &PIO21;
>> + gpio22 = &PIO22;
>> +
>> + };
>> +
>> + soc {
>> + pin-controller-pwest {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + compatible = "st,stid127-pwest-pinctrl";
>> + st,syscfg = <&syscfg_pwest>;
>> + ranges = <0 0xfebe0000 0x8000>;
> Can you add interrupt controller support to the pin controller.
>
> Patches are in : https://lkml.org/lkml/2014/1/16/342
> All these patches are due to be in v3.15.
>
>> +
>> + PIO0: gpio@febe0000 {
>> + gpio-controller;
>> + #gpio-cells = <1>;
>> + reg = <0 0x100>;
>> + interrupts = <0 149 0>;
>> + st,bank-name = "PIO0";
>> + };
>> + rx = <&PIO3 0 ALT2 IN>;
>> + };
>> + };
>> + };
>> +
>> + };
> unnecessary empty line here.
>
>> diff --git a/arch/arm/boot/dts/stid127.dtsi b/arch/arm/boot/dts/stid127.dtsi
>> new file mode 100644
>> index 0000000..a6f0b8fe
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/stid127.dtsi
>> @@ -0,0 +1,130 @@
>> +/*
>> + * Copyright (C) 2013 STMicroelectronics Limited.
> 2014
>> + * Author(s): Giuseppe Cavallaro <peppe.cavallaro-qxv4g6HH51o@public.gmane.org>
>> + * Alexandre Torgue <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * publishhed by the Free Software Foundation.
> s/publishhed/published/
>
>> + */
>> +#include "stid127-pinctrl.dtsi"
>> +#include "stid127-clock.dtsi"
>> +/ {
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> +
>> + cpus {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + reg = <0>;
>> + };
>> + cpu@1 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a9";
>> + reg = <1>;
>> + };
>> + };
>> +
>> + intc: interrupt-controller@fffe1000 {
>> + compatible = "arm,cortex-a9-gic";
>> + #interrupt-cells = <3>;
>> + interrupt-controller;
>> + reg = <0xfffe1000 0x1000>,
>> + <0xfffe0100 0x100>;
>> + };
>> +
>> + scu@fffe0000 {
>> + compatible = "arm,cortex-a9-scu";
>> + reg = <0xfffe0000 0x1000>;
>> + };
>> +
>> + timer@fffe0200 {
>> + interrupt-parent = <&intc>;
>> + compatible = "arm,cortex-a9-global-timer";
>> + reg = <0xfffe0200 0x100>;
>> + interrupts = <1 11 0x04>;
>> + clocks = <&arm_periph_clk>;
> Fix the tab spacing here.
>
> Thanks,
> srini
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [PATCH v3 3/6] misc: fuse: Add efuse driver for Tegra
From: Jim Lin @ 2014-02-05 10:26 UTC (permalink / raw)
To: Peter De Schrijver
Cc: linux-arm-kernel@lists.infradead.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, Rob Landley, Stephen Warren,
Thierry Reding, Grant Likely, Rob Herring, Danny Huang,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20140203141529.GF19389@tbergstrom-lnx.Nvidia.com>
Please ignore my comment.
I will try to use exported tegra_fuse_readl().
-----Original Message-----
From: Peter De Schrijver [mailto:pdeschrijver@nvidia.com]
Sent: Monday, February 03, 2014 10:15 PM
To: Jim Lin
Cc: linux-arm-kernel@lists.infradead.org; linux-tegra@vger.kernel.org; linux-kernel@vger.kernel.org; Rob Landley; Stephen Warren; Thierry Reding; Grant Likely; Rob Herring; Danny Huang; linux-doc@vger.kernel.org; devicetree@vger.kernel.org
Subject: Re: [PATCH v3 3/6] misc: fuse: Add efuse driver for Tegra
On Wed, Jan 29, 2014 at 03:26:18AM +0100, Jim Lin wrote:
> On Wed, 2014-01-29 at 07:36 +0800, Peter De Schrijver wrote:
> > Implement fuse driver for Tegra20, Tegra30, Tegra114 and Tegra124.
> >
> > Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> > ---
> > Documentation/ABI/testing/sysfs-driver-tegra-fuse | 8 +
> > drivers/misc/fuse/Makefile | 1 +
> > drivers/misc/fuse/tegra/Makefile | 7 +
> > drivers/misc/fuse/tegra/fuse-tegra.c | 228 ++++++++++++++++
> > drivers/misc/fuse/tegra/fuse-tegra20.c | 136 ++++++++++
> > drivers/misc/fuse/tegra/fuse-tegra30.c | 178 +++++++++++++
> > drivers/misc/fuse/tegra/fuse.h | 82 ++++++
> Could we move this fuse.h to other folder under /include/linux (like
> /include/linux/platform_data) for other driver to include?
I don't think we should expose everything in fuse.h to the world.
> So other driver can invoke function to read fuse data if needed.
Which functionality do you want? Just reading the fuse data exposed in the sysfs file from a driver? exporting tegra_fuse_readl() should do that I think?
Cheers,
Peter.
--nvpublic
^ permalink raw reply
* Re: [PATCH v4 1/2] iio:as3935: Add DT binding docs for AS3935 driver
From: Matt Ranostay @ 2014-02-05 10:22 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Matt Porter, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou
In-Reply-To: <634e62ea-d33f-42f3-8500-6331d4de495d-2ueSQiBKiTY7tOexoI0I+QC/G2K4zDHf@public.gmane.org>
On Tue, Feb 4, 2014 at 11:24 PM, Jonathan Cameron <jic23-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
>
>
> On February 5, 2014 4:43:35 AM GMT+00:00, Matt Porter <mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>>On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay
>>wrote:
>>> Document compatible string, required and optional DT properties for
>>> AS3935 chipset driver.
>>>
>>> Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> ---
>>> .../devicetree/bindings/iio/proximity/as3935.txt | 25
>>++++++++++++++++++++++
>>> 1 file changed, 25 insertions(+)
>>> create mode 100644
>>Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>>
>>> diff --git
>>a/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>> new file mode 100644
>>> index 0000000..7e117cd
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>> @@ -0,0 +1,25 @@
>>> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
>>> +
>>> +Required properties:
>>> + - compatible: must be "ams,as3935"
>>
>>Change this to "amstaos,as3935"
>>
>>amstaos (AMS bought Taos) is already a registered vendor prefix in
>>vendor-prefixes.txt
>
> It is but has a rather separate presence and is not where people expect to find non light
> sensor stuff from ams. I personally would go for a new vendor prefix and stick with ams.
>
So should I add to vendor-prefixes.txt as well? or not?
>>
>>> + - reg: SPI chip select number for the device
>>> + - spi-cpha: SPI Mode 1
>>
>>When using generic binding properties, please reference the binding
>>being used. Like:
>>
>> - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
>> slave node bindings.
>>
>>> + - interrupt-parent : should be the phandle for the interrupt
>>controller
>>> + - interrupts : interrupt mapping for GPIO IRQ
>>
>> Refer to interrupt-controller/interrupts.txt for generic
>> interrupt client node bindings.
>>
>>> +
>>> +Optional properties:
>>> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
>>> + Range of 0 to 120 pF, 8pF steps. This will require using the
>>> + calibration data from the manufacturer.
>>> +
>>> +
>>> +Example:
>>> +
>>> +as3935@0 {
>>> + compatible = "ams,as3935";
>>> + reg = <0>;
>>> + spi-cpha;
>>> + interrupt-parent = <&gpio1>;
>>> + interrupts = <16 1>;
>>> + ams,tune-cap = /bits/ 8 <10>;
>>
>>What is this? Why not just ams,tune-cap = <10>; ?
>>
>>It's a value between 0-15, right?
>>
>>-Matt
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>>the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH v2 4/5] ARM: init: add support for reserved memory defined by device tree
From: Grant Likely @ 2014-02-05 10:15 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linaro-mm-sig, devicetree,
linux-doc
Cc: Marek Szyprowski, Kyungmin Park, Benjamin Herrenschmidt,
Arnd Bergmann, Michal Nazarewicz, Tomasz Figa, Sascha Hauer,
Laura Abbott, Rob Herring, Olof Johansson, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Tomasz Figa,
Kumar Gala, Nishanth Peethambaran, Marc, Josh Cartwright
In-Reply-To: <1391515773-6112-5-git-send-email-m.szyprowski@samsung.com>
On Tue, 04 Feb 2014 13:09:32 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> Enable reserved memory initialization from device tree.
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Laura Abbott <lauraa@codeaurora.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> arch/arm/mm/init.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 804d61566a53..ebafdb479410 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -17,6 +17,7 @@
> #include <linux/nodemask.h>
> #include <linux/initrd.h>
> #include <linux/of_fdt.h>
> +#include <linux/of_reserved_mem.h>
> #include <linux/highmem.h>
> #include <linux/gfp.h>
> #include <linux/memblock.h>
> @@ -323,6 +324,8 @@ void __init arm_memblock_init(struct meminfo *mi,
> if (mdesc->reserve)
> mdesc->reserve();
>
> + early_init_dt_scan_reserved_mem();
> +
The new binding is being made fundamental. If the reserved-memory node
is present, then it needs to be honored, even if the kernel doesn't know
how to use the regions. Therefore, This needs to be unconditional for
all architectures. The hook should be called in early_init_dt_scan()
(drivers/of/fdt.c) immediately after the early_init_dt_scan_memory()
hook.
> /*
> * reserve memory for DMA contigouos allocations,
> * must come from DMA area inside low memory
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH v2 5/5] of: document bindings for reserved-memory nodes
From: Grant Likely @ 2014-02-05 10:07 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linaro-mm-sig, devicetree,
linux-doc
Cc: Marek Szyprowski, Kyungmin Park, Benjamin Herrenschmidt,
Arnd Bergmann, Michal Nazarewicz, Tomasz Figa, Sascha Hauer,
Laura Abbott, Rob Herring, Olof Johansson, Pawel Moll,
Mark Rutland, Stephen Warren, Ian Campbell, Tomasz Figa,
Kumar Gala, Nishanth Peethambaran, Marc, Josh Cartwright
In-Reply-To: <1391515773-6112-6-git-send-email-m.szyprowski@samsung.com>
On Tue, 04 Feb 2014 13:09:33 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> From: Grant Likely <grant.likely@linaro.org>
>
> Reserved memory nodes allow for the reservation of static (fixed
> address) regions, or dynamically allocated regions for a specific
> purpose.
>
> [joshc: Based on binding document proposed (in non-patch form) here:
> http://lkml.kernel.org/g/20131030134702.19B57C402A0@trevor.secretlab.ca
> adapted to support #memory-region-cells]
>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Laura Abbott <lauraa@codeaurora.org>
> Signed-off-by: Josh Cartwright <joshc@codeaurora.org>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
> ---
> .../bindings/reserved-memory/reserved-memory.txt | 138 ++++++++++++++++++++
> 1 file changed, 138 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
>
> diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> new file mode 100644
> index 000000000000..a606ce90c9c4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
> @@ -0,0 +1,138 @@
> +*** Reserved memory regions ***
> +
> +Reserved memory is specified as a node under the /reserved-memory node.
> +The operating system shall exclude reserved memory from normal usage
> +one can create child nodes describing particular reserved (excluded from
> +normal use) memory regions. Such memory regions are usually designed for
> +the special usage by various device drivers.
> +
> +Parameters for each memory region can be encoded into the device tree
> +with the following nodes:
> +
> +/reserved-memory node
> +---------------------
> +#address-cells, #size-cells (required) - standard definition
> + - Should use the same values as the root node
> +#memory-region-cells (required) - dictates number of cells used in the child
> + nodes memory-region specifier
I don't think this isn't defined well enough. These reserved regions may
not have a driver attached to them, so there is no central agent to
decide what the specifier means. That leaves the interpretation of
the memory region in the hands of the client drivers. How do you see the
specifier getting parsed and used?
Otherwise the binding looks good to me. Also, please add my s-o-b line
to the patch (instead of a-b because I authored part of the text)
Signed-off-by: Grant Likely <grant.likely@linaro.org>
g.
> +ranges (required) - standard definition
> + - Should be empty
> +
> +/reserved-memory/ child nodes
> +-----------------------------
> +Each child of the reserved-memory node specifies one or more regions of
> +reserved memory. Each child node may either use a 'reg' property to
> +specify a specific range of reserved memory, or a 'size' property with
> +optional constraints to request a dynamically allocated block of memory.
> +
> +Following the generic-names recommended practice, node names should
> +reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
> +address (@<address>) should be appended to the name if the node is a
> +static allocation.
> +
> +Properties:
> +Requires either a) or b) below.
> +a) static allocation
> + reg (required) - standard definition
> +b) dynamic allocation
> + size (required) - length based on parent's #size-cells
> + - Size in bytes of memory to reserve.
> + alignment (optional) - length based on parent's #size-cells
> + - Address boundary for alignment of allocation.
> + alloc-ranges (optional) - prop-encoded-array (address, length pairs).
> + - Specifies regions of memory that are
> + acceptable to allocate from.
> +
> +If both reg and size are present, then the reg property takes precedence
> +and size is ignored.
> +
> +Additional properties:
> +compatible (optional) - standard definition
> + - may contain the following strings:
> + - shared-dma-pool: This indicates a region of memory meant to be
> + used as a shared pool of DMA buffers for a set of devices. It can
> + be used by an operating system to instanciate the necessary pool
> + management subsystem if necessary.
> + - vendor specific string in the form <vendor>,[<device>-]<usage>
> +no-map (optional) - empty property
> + - Indicates the operating system must not create a virtual mapping
> + of the region as part of its standard mapping of system memory,
> + nor permit speculative access to it under any circumstances other
> + than under the control of the device driver using the region.
> +reusable (optional) - empty property
> + - The operating system can use the memory in this region with the
> + limitation that the device driver(s) owning the region need to be
> + able to reclaim it back. Typically that means that the operating
> + system can use that region to store volatile or cached data that
> + can be otherwise regenerated or migrated elsewhere.
> +
> +Linux implementation note:
> +- If a "linux,cma-default" property is present, then Linux will use the
> + region for the default pool of the contiguous memory allocator.
> +
> +Device node references to reserved memory
> +-----------------------------------------
> +Regions in the /reserved-memory node may be referenced by other device
> +nodes by adding a memory-region property to the device node.
> +
> +memory-region (optional) - phandle, specifier pairs to children of /reserved-memory
> +
> +Example
> +-------
> +This example defines 3 contiguous regions are defined for Linux kernel:
> +one default of all device drivers (named linux,cma@72000000 and 64MiB in size),
> +one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), and
> +one for multimedia processing (named multimedia-memory@77000000, 64MiB).
> +
> +/ {
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + memory {
> + reg = <0x40000000 0x40000000>;
> + };
> +
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + /* global autoconfigured region for contiguous allocations */
> + linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + #memory-region-cells = <0>;
> + size = <0x4000000>;
> + alignment = <0x2000>;
> + linux,cma-default;
> + };
> +
> + display_reserved: framebuffer@78000000 {
> + #memory-region-cells = <0>;
> + reg = <0x78000000 0x800000>;
> + };
> +
> + multimedia_reserved: multimedia@77000000 {
> + compatible = "acme,multimedia-memory";
> + #memory-region-cells = <1>;
> + reg = <0x77000000 0x4000000>;
> + };
> + };
> +
> + /* ... */
> +
> + fb0: video@12300000 {
> + memory-region = <&display_reserved>;
> + /* ... */
> + };
> +
> + scaler: scaler@12500000 {
> + memory-region = <&multimedia_reserved 0xdeadbeef>;
> + /* ... */
> + };
> +
> + codec: codec@12600000 {
> + memory-region = <&multimedia_reserved 0xfeebdaed>;
> + /* ... */
> + };
> +};
> --
> 1.7.9.5
>
^ permalink raw reply
* RE: [PATCH V3] net/dt: Add support for overriding phy configuration from device tree
From: David Laight @ 2014-02-05 9:51 UTC (permalink / raw)
To: 'Florian Fainelli', Matthew Garrett
Cc: netdev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Kishon Vijay Abraham I
In-Reply-To: <CAGVrzcZ4TFd=9KP+aoG47QbmqDJ1i23WBcEWDbzNRUfGmPvZHQ@mail.gmail.com>
From: Florian Fainelli
> It would be good to explain exactly how your hardware is broken
> exactly. I really do not think that such a fine-grained setting where
> you could disable, e.g: 100BaseT_Full, but allow 100BaseT_Half to
> remain usable makes that much sense. In general, Gigabit might be
> badly broken, but 100 and 10Mbits/sec should work fine. How about the
> MASTER-SLAVE bit, is overriding it really required?
There are plenty of systems out there where you'd want to disable
either HDX or FDX modes.
The MAC unit has to know whether the PHY is in HDX or FDX in order
to work properly. Many do not need to know the speed - since the
PHY is responsible for the tx/rx fifo clock.
Getting the negotiated speed out of the PHY can be difficult, while
the ANAR can easily be set.
Unfortunately it is usually impossible to disable the 'fall-back'
10M HDX.
David
^ permalink raw reply
* Re: [PATCH V3] net/dt: Add support for overriding phy configuration from device tree
From: Grant Likely @ 2014-02-05 9:47 UTC (permalink / raw)
To: Florian Fainelli, Matthew Garrett
Cc: netdev, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Kishon Vijay Abraham I
In-Reply-To: <CAGVrzcZ4TFd=9KP+aoG47QbmqDJ1i23WBcEWDbzNRUfGmPvZHQ@mail.gmail.com>
On Tue, 4 Feb 2014 12:39:41 -0800, Florian Fainelli <f.fainelli@gmail.com> wrote:
> 2014-01-17 Matthew Garrett <matthew.garrett@nebula.com>:
> > Some hardware may be broken in interesting and board-specific ways, such
> > that various bits of functionality don't work. This patch provides a
> > mechanism for overriding mii registers during init based on the contents of
> > the device tree data, allowing board-specific fixups without having to
> > pollute generic code.
>
> It would be good to explain exactly how your hardware is broken
> exactly. I really do not think that such a fine-grained setting where
> you could disable, e.g: 100BaseT_Full, but allow 100BaseT_Half to
> remain usable makes that much sense. In general, Gigabit might be
> badly broken, but 100 and 10Mbits/sec should work fine. How about the
> MASTER-SLAVE bit, is overriding it really required?
>
> Is not a PHY fixup registered for a specific OUI the solution you are
> looking for? I am also concerned that this creates PHY troubleshooting
> issues much harder to debug than before as we may have no idea about
> how much information has been put in Device Tree to override that.
>
> Finally, how about making this more general just like the BCM87xx PHY
> driver, which is supplied value/reg pairs directly? There are 16
> common MII registers, and 16 others for vendor specific registers,
> this is just covering for about 2% of the possible changes.
I would be fine with that too.
g.
^ permalink raw reply
* Re: [PATCH 09/10] watchdog: xilinx: Add missing binding
From: Michal Simek @ 2014-02-05 9:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel, monstr, Mark Rutland, devicetree, Pawel Moll,
Ian Campbell, linux-doc, Michal Simek, linux-kernel, Rob Herring,
Rob Landley, Kumar Gala
In-Reply-To: <201402051036.19428.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1269 bytes --]
On 02/05/2014 10:36 AM, Arnd Bergmann wrote:
> On Wednesday 05 February 2014, Michal Simek wrote:
>> I am not quite sure what you mean by reports to user space.
>> If you mean to get timeout through ioctl for example - then yes it is working
>> through standard watchdog ioctl interface and timeout is calculated
>> from hardware setup.
>
> Yes, that is what I meant. I believe most other watchdogs let
> you program the timeout, but I don't see anything wrong with
> having that fixed in the FPGA in your case.
>
> Still, the choice of putting the timeout into DT in terms of
> cycles rather than miliseconds wasn't ideal from an interface
> perspective and we should change that if/when we do a generic
> binding. I can definitely see where it's coming from for your
> case, as the cycle count totally makes sense from an FPGA
> tool perspective...
Thanks. I take this like ACK for this current binding description.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 09/10] watchdog: xilinx: Add missing binding
From: Arnd Bergmann @ 2014-02-05 9:36 UTC (permalink / raw)
To: linux-arm-kernel, monstr
Cc: Mark Rutland, devicetree, Pawel Moll, linux-doc, Ian Campbell,
Michal Simek, linux-kernel, Rob Herring, Rob Landley, Kumar Gala
In-Reply-To: <52F20387.3090709@monstr.eu>
On Wednesday 05 February 2014, Michal Simek wrote:
> I am not quite sure what you mean by reports to user space.
> If you mean to get timeout through ioctl for example - then yes it is working
> through standard watchdog ioctl interface and timeout is calculated
> from hardware setup.
Yes, that is what I meant. I believe most other watchdogs let
you program the timeout, but I don't see anything wrong with
having that fixed in the FPGA in your case.
Still, the choice of putting the timeout into DT in terms of
cycles rather than miliseconds wasn't ideal from an interface
perspective and we should change that if/when we do a generic
binding. I can definitely see where it's coming from for your
case, as the cycle count totally makes sense from an FPGA
tool perspective...
Arnd
^ permalink raw reply
* Re: [PATCH v2 0/6] ARM: STi reset controller support
From: Philipp Zabel @ 2014-02-05 9:28 UTC (permalink / raw)
To: srinivas.kandagatla
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc, linux-kernel,
stephen.gallimore, Stuart Menefy, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
In-Reply-To: <1391437665-11913-1-git-send-email-srinivas.kandagatla@st.com>
Hi Srinivas,
Am Montag, den 03.02.2014, 14:27 +0000 schrieb
srinivas.kandagatla@st.com:
> From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
>
> Hi All,
>
> This patch series adds reset controller support for STi SOC series STiH415 and
> STiH416. It adds support for both power down reset and soft reset controllers.
> On STi series SOCs reset lines are wired up to system configuration registers.
> Most of the IPs on STi SOCs are left in reset state, so this driver is very
> important for other drivers to use the IPs.
>
> Patch 01: Adds reset controller based on system configuration registers via
> regmap.
>
> Patch 02, 03: adds STiH415 and STiH416 reset controller drivers.
>
> Patch 04, 05: adds STiH415 and STiH416 soft reset controllers.
>
> The final patch 06 selects reset controller in mach-sti Kconfig.
>
> I would like get this driver in to 3.15, so that its possible to add dt
> support for other IPs with reset lines. Without this patchset its impossible
> to add DT support to IPs with reset lines as reset line definition is in
> common header file in include/dt-bindings/.
>
> This reset controller will be used by gmac, i2c and st-ir drivers.
>
>
> Comments?
the patchset looks good to me for the soft resets. But for the powerdown
bits I am wondering whether the reset controller API is the right
abstraction. Depending on whether those bits really just put the IPs
into reset or there is some power gating / sequencing involved,
shouldn't this rather be handled as a set of pm domains?
I see that for example on STiH415 there are both soft resets and
powerdown bits for USB[012].
regards
Philipp
^ permalink raw reply
* Re: [PATCH 09/10] watchdog: xilinx: Add missing binding
From: Michal Simek @ 2014-02-05 9:25 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Michal Simek, linux-arm-kernel, linux-kernel, monstr,
Mark Rutland, devicetree, Pawel Moll, Ian Campbell, linux-doc,
Rob Herring, Rob Landley, Kumar Gala
In-Reply-To: <201402042027.15898.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 2898 bytes --]
On 02/04/2014 08:27 PM, Arnd Bergmann wrote:
> On Monday 03 February 2014, Michal Simek wrote:
>> On 02/03/2014 04:32 PM, Arnd Bergmann wrote:
>>> On Monday 03 February 2014 16:13:47 Michal Simek wrote:
>>>> Intention wasn't to fix binding but document current one
>>>> which is in mainline for a long time.
>>>
>>> Ok, I see.
>>>
>>>> Apart of this - yes, wdt-enable-once is nowayout and wdt-interval should be timeout
>>>> is seconds, and clock-frequency should go out and use CCF for getting clock.
>>>
>>> Could we make a common binding then, and document that the xilinx
>>> watchdog can optionally provide either one?
>>
>> Do you mean to have 2 DT bindings?
>>
>> This binding is used from 2011-07.
>> It means it was generated for all hw designs at least from this time.
>> I would say from DT usage on Microblaze because it is not special case
>> in our dt generator.
>
> I certainly wasn't suggesting to break the binding, quite the contrary.
> What I tried to say is that the properties look like they should be
> useful for different kinds of watchdogs, not just xilinx, so it would
> be good to have a common definition using generic strings.
>
> The xilinx driver would definitely have to keep supporting the traditional
> property names, but it could also support the generic names in the
> future.
No problem with to do in future.
>> xlnx,XXX are XXX parameters which you have to setup in tools
>> and get synthesized. This is valid for all xilinx IPs. We have full
>> IP description by generating xlnx,XXX parameters directly from tools
>> because we know all variants which can happen.
>>
>> Just back to your previous post:
>> "I'm not sure about the enable-once flag, which seems to just map to the
>> "nowayout" watchdog option that is not a hardware feature at all"
>> this is hw feature which you can select in tools because this is fpga. :-)
>
> Ah, so you mean the properties are not settings that the driver
> programs into the hardware, but they are hardware properties that the
> driver reports to user space?
yes, they are hardware properties which you can choose based on your
configuration. Every user just decides if this watchdog can be started just
once and how long it takes in synthesis time. There is no option to program
this by software.
I am not quite sure what you mean by reports to user space.
If you mean to get timeout through ioctl for example - then yes it is working
through standard watchdog ioctl interface and timeout is calculated
from hardware setup.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 1/6] i2c: bcm-kona: register with subsys_initcall
From: Wolfram Sang @ 2014-02-05 9:08 UTC (permalink / raw)
To: Matt Porter
Cc: Tim Kryger, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Samuel Ortiz, Lee Jones, Liam Girdwood, Mark Brown,
Christian Daudt, Devicetree List, Linux I2C List,
Linux ARM Kernel List, Linux Kernel Mailing List
In-Reply-To: <1391516352-32359-2-git-send-email-mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 224 bytes --]
On Tue, Feb 04, 2014 at 07:19:07AM -0500, Matt Porter wrote:
> Voltage regulators are needed very early due to deferred probe
> being incompatible with built-in USB gadget drivers.
What does it need to fix those instead?
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v4 1/2] iio:as3935: Add DT binding docs for AS3935 driver
From: Jonathan Cameron @ 2014-02-05 7:24 UTC (permalink / raw)
To: Matt Porter, Matt Ranostay
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
pantelis.antoniou-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20140205044335.GA2172@beef>
On February 5, 2014 4:43:35 AM GMT+00:00, Matt Porter <mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay
>wrote:
>> Document compatible string, required and optional DT properties for
>> AS3935 chipset driver.
>>
>> Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> .../devicetree/bindings/iio/proximity/as3935.txt | 25
>++++++++++++++++++++++
>> 1 file changed, 25 insertions(+)
>> create mode 100644
>Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>
>> diff --git
>a/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> new file mode 100644
>> index 0000000..7e117cd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> @@ -0,0 +1,25 @@
>> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
>> +
>> +Required properties:
>> + - compatible: must be "ams,as3935"
>
>Change this to "amstaos,as3935"
>
>amstaos (AMS bought Taos) is already a registered vendor prefix in
>vendor-prefixes.txt
It is but has a rather separate presence and is not where people expect to find non light
sensor stuff from ams. I personally would go for a new vendor prefix and stick with ams.
>
>> + - reg: SPI chip select number for the device
>> + - spi-cpha: SPI Mode 1
>
>When using generic binding properties, please reference the binding
>being used. Like:
>
> - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
> slave node bindings.
>
>> + - interrupt-parent : should be the phandle for the interrupt
>controller
>> + - interrupts : interrupt mapping for GPIO IRQ
>
> Refer to interrupt-controller/interrupts.txt for generic
> interrupt client node bindings.
>
>> +
>> +Optional properties:
>> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
>> + Range of 0 to 120 pF, 8pF steps. This will require using the
>> + calibration data from the manufacturer.
>> +
>> +
>> +Example:
>> +
>> +as3935@0 {
>> + compatible = "ams,as3935";
>> + reg = <0>;
>> + spi-cpha;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <16 1>;
>> + ams,tune-cap = /bits/ 8 <10>;
>
>What is this? Why not just ams,tune-cap = <10>; ?
>
>It's a value between 0-15, right?
>
>-Matt
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Re: [PATCH v4 1/2] iio:as3935: Add DT binding docs for AS3935 driver
From: Matt Ranostay @ 2014-02-05 5:30 UTC (permalink / raw)
To: Matt Porter
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou
In-Reply-To: <20140205051730.GA3911@beef>
On Tue, Feb 4, 2014 at 9:17 PM, Matt Porter <mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Feb 04, 2014 at 08:52:26PM -0800, Matt Ranostay Matt Ranostay wrote:
>> On Tue, Feb 4, 2014 at 8:43 PM, Matt Porter <mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>> > On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay wrote:
>> >> Document compatible string, required and optional DT properties for
>> >> AS3935 chipset driver.
>> >>
>> >> Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> >> ---
>> >> .../devicetree/bindings/iio/proximity/as3935.txt | 25 ++++++++++++++++++++++
>> >> 1 file changed, 25 insertions(+)
>> >> create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> >>
>> >> diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> >> new file mode 100644
>> >> index 0000000..7e117cd
>> >> --- /dev/null
>> >> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> >> @@ -0,0 +1,25 @@
>> >> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
>> >> +
>> >> +Required properties:
>> >> + - compatible: must be "ams,as3935"
>> >
>> > Change this to "amstaos,as3935"
>> >
>> > amstaos (AMS bought Taos) is already a registered vendor prefix in
>> > vendor-prefixes.txt
>> >
>> >> + - reg: SPI chip select number for the device
>> >> + - spi-cpha: SPI Mode 1
>> >
>> > When using generic binding properties, please reference the binding
>> > being used. Like:
>> >
>> > - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
>> > slave node bindings.
>> >
>> Noted.
>>
>> >> + - interrupt-parent : should be the phandle for the interrupt controller
>> >> + - interrupts : interrupt mapping for GPIO IRQ
>> >
>> > Refer to interrupt-controller/interrupts.txt for generic
>> > interrupt client node bindings.
>> >
>> Noted.
>>
>> >> +
>> >> +Optional properties:
>> >> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
>> >> + Range of 0 to 120 pF, 8pF steps. This will require using the
>> >> + calibration data from the manufacturer.
>> >> +
>> >> +
>> >> +Example:
>> >> +
>> >> +as3935@0 {
>> >> + compatible = "ams,as3935";
>> >> + reg = <0>;
>> >> + spi-cpha;
>> >> + interrupt-parent = <&gpio1>;
>> >> + interrupts = <16 1>;
>> >> + ams,tune-cap = /bits/ 8 <10>;
>> >
>> > What is this? Why not just ams,tune-cap = <10>; ?
>> >
>> > It's a value between 0-15, right?
>>
>> Correct but it is using of_property_read_u8() so that requires the
>> /bits/ statement.
>> Should this just be a u32 value?
>
> Do you really need a u8? If not just read_u32() into an int and keep
> this syntax simple.
Just me different it seems :P. Will fix in next version waiting for
Peter's and Jonathan's input on the rest of the code first.
>
> -Matt
^ permalink raw reply
* Re: [PATCH v4 1/2] iio:as3935: Add DT binding docs for AS3935 driver
From: Matt Porter @ 2014-02-05 5:17 UTC (permalink / raw)
To: Matt Ranostay
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou
In-Reply-To: <CAKzfze-mHkxmnb06jDuD=-Zg3SmhRoZo6-P0D9dReA-gDwbTnw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Feb 04, 2014 at 08:52:26PM -0800, Matt Ranostay Matt Ranostay wrote:
> On Tue, Feb 4, 2014 at 8:43 PM, Matt Porter <mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> > On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay wrote:
> >> Document compatible string, required and optional DT properties for
> >> AS3935 chipset driver.
> >>
> >> Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> ---
> >> .../devicetree/bindings/iio/proximity/as3935.txt | 25 ++++++++++++++++++++++
> >> 1 file changed, 25 insertions(+)
> >> create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
> >> new file mode 100644
> >> index 0000000..7e117cd
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
> >> @@ -0,0 +1,25 @@
> >> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
> >> +
> >> +Required properties:
> >> + - compatible: must be "ams,as3935"
> >
> > Change this to "amstaos,as3935"
> >
> > amstaos (AMS bought Taos) is already a registered vendor prefix in
> > vendor-prefixes.txt
> >
> >> + - reg: SPI chip select number for the device
> >> + - spi-cpha: SPI Mode 1
> >
> > When using generic binding properties, please reference the binding
> > being used. Like:
> >
> > - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
> > slave node bindings.
> >
> Noted.
>
> >> + - interrupt-parent : should be the phandle for the interrupt controller
> >> + - interrupts : interrupt mapping for GPIO IRQ
> >
> > Refer to interrupt-controller/interrupts.txt for generic
> > interrupt client node bindings.
> >
> Noted.
>
> >> +
> >> +Optional properties:
> >> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
> >> + Range of 0 to 120 pF, 8pF steps. This will require using the
> >> + calibration data from the manufacturer.
> >> +
> >> +
> >> +Example:
> >> +
> >> +as3935@0 {
> >> + compatible = "ams,as3935";
> >> + reg = <0>;
> >> + spi-cpha;
> >> + interrupt-parent = <&gpio1>;
> >> + interrupts = <16 1>;
> >> + ams,tune-cap = /bits/ 8 <10>;
> >
> > What is this? Why not just ams,tune-cap = <10>; ?
> >
> > It's a value between 0-15, right?
>
> Correct but it is using of_property_read_u8() so that requires the
> /bits/ statement.
> Should this just be a u32 value?
Do you really need a u8? If not just read_u32() into an int and keep
this syntax simple.
-Matt
^ permalink raw reply
* Re: [PATCHv10] video: backlight: gpio-backlight: Add DT support.
From: Jingoo Han @ 2014-02-05 5:12 UTC (permalink / raw)
To: 'Denis Carikli'
Cc: 'Alexander Shiyan', 'Eric Bénard',
'Grant Likely', 'Ian Campbell',
'Jean-Christophe Plagniol-Villard', 'Kumar Gala',
'Laurent Pinchart', 'Lothar Waßmann',
'Mark Rutland', 'Pawel Moll',
'Rob Herring', 'Thierry Reding',
devicetree-u79uwXL29TY76Z2rM5mHXA, 'Jingoo Han'
In-Reply-To: <1389878369-2046-1-git-send-email-denis-fO0SIAKYzcbQT0dZR+AlfA@public.gmane.org>
On Thursday, January 16, 2014 10:19 PM, Denis Carikli wrote:
>
> Cc: Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>
> Cc: Eric Bénard <eric-fO0SIAKYzcbQT0dZR+AlfA@public.gmane.org>
> Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
> Cc: Jingoo Han <jg1.han-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> Cc: Laurent Pinchart <Laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> Cc: Lothar Waßmann <LW-bxm8fMRDkQLDiMYJYoSAnRvVK+yQ3ZXh@public.gmane.org>
> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Cc: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> CC: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> Signed-off-by: Denis Carikli <denis-fO0SIAKYzcbQT0dZR+AlfA@public.gmane.org>
> ---
> ChangeLog v9->v10:
> - Only the respective maintainers, or people who responded to the patch
> were kept in the Cc.
> - The unnecessary of_match_ptr in of_match_table was removed.
>
> ChangeLog v8->v9:
> - Added Shawn Guo in the Cc list.
> - The default-brightness-level is now a boolean default-on property,
> the gpio is only touched if the gpio-backlight driver instance probes.
> - The code and documentation was updated accordingly.
>
> ChangeLog v7->v8:
> - The default-state was renamed to default-brightness-level.
> - default-brightness-level is now mandatory, like for backlight-pwm,
> That way we avoid having to handle the case where it's not set,
> which means that we would need not to set the gpio, but still
> report a brightness value for sysfs, when not all gpio controllers are
> able to read the gpio value.
> - switched the default-brightness-level to boolean values (0 or 1) instead
> of using strings ("on", "off", "keep").
> - The documentation was updated accordingly.
> - The example in the documentation now uses the dts gpio defines.
> - The "backlight: gpio_backlight: Use a default state enum." patch was then
> dropped, becuase it is not necessary anymore.
>
> ChangeLog v6->v7:
> - removed a compilation warning with the removal of the useless ret declaration.
>
> ChangeLog v5->v6:
> - The default state handling was reworked:
> - it's now called default-state, and looks like the gpio-leds default-state.
> - it now has a "keep" option, like for the gpio-leds.
> - that "keep" option is the default when the default-state property is not set.
> - The documentation was updated accordingly.
>
> ChangeLog v4->v5:
> - The default-brightness property now defaults to 0 in the driver.
> - def_value int becomes a bool.
> - The check for the gpio validity has been reworked.
> ---
> .../bindings/video/backlight/gpio-backlight.txt | 19 +++++++
> drivers/video/backlight/gpio_backlight.c | 60 +++++++++++++++++---
> 2 files changed, 72 insertions(+), 7 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt
>
[.....]
> diff --git a/drivers/video/backlight/gpio_backlight.c b/drivers/video/backlight/gpio_backlight.c
> index 81fb127..ec4cf5d 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
[.....]
> +static struct of_device_id gpio_backlight_of_match[] = {
> + { .compatible = "gpio-backlight" },
> + { /* sentinel */ }
> +};
> +
> static struct platform_driver gpio_backlight_driver = {
> .driver = {
> .name = "gpio-backlight",
> .owner = THIS_MODULE,
> + .of_match_table = &gpio_backlight_of_match,
The following build warning happens.
Would you fix the following build error?
CC drivers/video/backlight/gpio_backlight.o
drivers/video/backlight/gpio_backlight.c:162:3: warning: initialization from incompatible pointer type [enabled by default]
drivers/video/backlight/gpio_backlight.c:162:3: warning: (near initialization for ?쁤pio_backlight_driver.driver.of_match_table?? [enabled by default]
Best regards,
Jingoo Han
> },
> .probe = gpio_backlight_probe,
> };
> --
> 1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 1/2] iio:as3935: Add DT binding docs for AS3935 driver
From: Matt Ranostay @ 2014-02-05 4:52 UTC (permalink / raw)
To: Matt Porter
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Pantelis Antoniou
In-Reply-To: <20140205044335.GA2172@beef>
On Tue, Feb 4, 2014 at 8:43 PM, Matt Porter <mporter-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Tue, Feb 04, 2014 at 07:14:55PM -0800, Matt Ranostay Matt Ranostay wrote:
>> Document compatible string, required and optional DT properties for
>> AS3935 chipset driver.
>>
>> Signed-off-by: Matt Ranostay <mranostay-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> .../devicetree/bindings/iio/proximity/as3935.txt | 25 ++++++++++++++++++++++
>> 1 file changed, 25 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/proximity/as3935.txt
>>
>> diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> new file mode 100644
>> index 0000000..7e117cd
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
>> @@ -0,0 +1,25 @@
>> +Austrian Microsystems AS3935 Franklin lightning sensor device driver
>> +
>> +Required properties:
>> + - compatible: must be "ams,as3935"
>
> Change this to "amstaos,as3935"
>
> amstaos (AMS bought Taos) is already a registered vendor prefix in
> vendor-prefixes.txt
>
>> + - reg: SPI chip select number for the device
>> + - spi-cpha: SPI Mode 1
>
> When using generic binding properties, please reference the binding
> being used. Like:
>
> - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
> slave node bindings.
>
Noted.
>> + - interrupt-parent : should be the phandle for the interrupt controller
>> + - interrupts : interrupt mapping for GPIO IRQ
>
> Refer to interrupt-controller/interrupts.txt for generic
> interrupt client node bindings.
>
Noted.
>> +
>> +Optional properties:
>> + - ams,tune-cap: Calibration tuning capacitor stepping value 0 - 15.
>> + Range of 0 to 120 pF, 8pF steps. This will require using the
>> + calibration data from the manufacturer.
>> +
>> +
>> +Example:
>> +
>> +as3935@0 {
>> + compatible = "ams,as3935";
>> + reg = <0>;
>> + spi-cpha;
>> + interrupt-parent = <&gpio1>;
>> + interrupts = <16 1>;
>> + ams,tune-cap = /bits/ 8 <10>;
>
> What is this? Why not just ams,tune-cap = <10>; ?
>
> It's a value between 0-15, right?
Correct but it is using of_property_read_u8() so that requires the
/bits/ statement.
Should this just be a u32 value?
>
> -Matt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox