* Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output
From: Tomi Valkeinen @ 2014-02-26 12:44 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Laurent Pinchart, Sebastian Reichel, Javier Martinez Canillas,
Florian Vaussard, Benoît Cousson, Tony Lindgren,
devicetree@vger.kernel.org, linux-omap@vger.kernel.org,
Ash Charles, linux-arm-kernel@lists.infradead.org, Arnd Bergmann
In-Reply-To: <20140226120359.GA27282@n2100.arm.linux.org.uk>
[-- Attachment #1: Type: text/plain, Size: 4490 bytes --]
On 26/02/14 14:03, Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote:
>> We have a bunch of panels and encoders used on OMAP boards, and we have
>> separate, omapdss specific, drivers for those. My plan is to continue
>> improving those drivers until they can be platform independent. This
>> would be the Common Display Framework that's been discussed (or a
>> precursor to it).
>
> I believe CDF has been knocked on the head.
I refuse to believe that we can't have common drivers for display
components. Maybe CDF as it's been proposed in its current form is not
good (although I haven't seen any explanation why), we need something
like it. So the "CDF" I speak of is not any particular set of patches
already sent, but a framework that would allow us to have generic
display drivers.
I'd be very glad if someone can point me to the discussions where CDF
has been knocked on the head.
> Also - DRM is not going to ever support hotplugging components - this
> was discussed at kernel summit last year and David Airlie was quite
Ok. Very odd stance. Maybe there's a reason for it that I just don't see.
> adamant about that. So, any "framework" which forces hotplugging of
> components on subsystems isn't going to fly.
CDF doesn't force hotplugging.
Although without hotplugging (hot-unplug not needed), or at least some
minimal form of it, the system is a bit crippled. Leave one kernel
module out, or have one driver probe fail, the whole display subsystem
fails, even if some display pipelines would work fine.
On OMAP4 SDP board, for example, this would mean that if the user
doesn't compile PicoDLP driver, or the driver fails to probe, the two
LCDs and the analog TV out would also fail. Many of the boards don't
even have a PicoDLP module installed, so a fail there somewhere is
guaranteed.
> This is why we now have the component helpers in the driver model -
> to allow devices to be collected together into one logical subsystem
> group, and bound/unbound as a group.
Yep, it's a good start. The component helpers could well be used with CDF.
But if I'm not mistaken, it suffers from the problems above, when there
are multiple independent pipelines (simultaneous or non-simultaneous)
handled by the same IPs.
And, while I may be mistaken, it sounds that the component helpers leave
mostly everything up to the display drivers. Everyone devising their own
way to describe the hardware in DT, and the connections between the
components. Of course, the core component system shouldn't define
anything DT related, as it doesn't. But that part is still needed, which
is where CDF comes in.
In my opinion, the component helpers or similar would be used with CDF
in the beginning, because DRM doesn't support hotplug. Eventually we
should get some kind of basic hotplug support, so that we could add
display pipelines when they are ready.
I need to ask Dave why he is so strongly opposed to hotplugging components.
> Remember that "hotplugging" in this context does not mean that the
> user can physically do something with the hardware. It means that
> they're separate devices which can be probed/removed at will. Every
> device in Linux can be bound and unbound from its driver at any time
> by userspace, and that is something which is expected to be handled
> gracefully.
Hmm, sorry, can you rephrase?
My use of hotplug in this context means roughly "add a new display, and
whatever is related to that, when the drivers required have been probed".
So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
etc, could appear even after the initial probe of the display controller.
But all this is, I think, a bit aside the original point. The original
point was about DT bindings. What kind of framework we have in the
kernel side to handle the bindings is an interesting and very important
topic, but they are not strictly tied together.
Even if CDF is the worst thing ever, and needs to die quickly, I think
the proposed DT bindings are still valid. They describe the hardware as
precisely and as future-proofly as we've been able to come up with.
People can use component helpers with them if they see that's a good
approach. Or if on some beautiful day we get an agreement on CDF or
something similar, and we can support hotplugging components, we already
have proper DT bindings for it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* Re: [PATCH v5 06/11] drivers: of: initialize and assign reserved memory to newly created devices
From: Grant Likely @ 2014-02-26 12:14 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linaro-mm-sig, devicetree,
linux-doc
Cc: Marek Szyprowski, 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, Catalin Marinas,
Will Deacon, Paul Mackerras
In-Reply-To: <1392985527-6260-7-git-send-email-m.szyprowski@samsung.com>
On Fri, 21 Feb 2014 13:25:22 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> Use recently introduced of_reserved_mem_device_init() function to
> automatically assign respective reserved memory region to the newly created
> platform and amba device.
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
I'm wary on this patch. It hides the assignment of regions into the core
code and I worry that it is the wrong level of abstraction. I would
think that drivers should know that they need a reserved memory region
and should be calling the API to obtain the region directly rather than
doing it for them. The reason being is that there may be some situations
where the common code isn't quite right and the driver needs to override
the behaviour. If it is called automatically then the driver cannot do
that.
Is it really a big burden to have the driver call the reserved memory
init function?
g.
> ---
> drivers/of/platform.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> 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;
> }
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH v5 03/11] drivers: of: add initialization code for dynamic reserved memory
From: Grant Likely @ 2014-02-26 12:09 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linaro-mm-sig, devicetree,
linux-doc
Cc: Marek Szyprowski, 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, Catalin Marinas,
Will Deacon, Paul Mackerras
In-Reply-To: <1392985527-6260-4-git-send-email-m.szyprowski@samsung.com>
On Fri, 21 Feb 2014 13:25:19 +0100, Marek Szyprowski <m.szyprowski@samsung.com> wrote:
> This patch adds support for dynamically allocated reserved memory regions
> declared in device tree. Such regions are defined by 'size', 'alignment'
> and 'alloc-ranges' properties.
>
> Based on previous code provided by Josh Cartwright <joshc@codeaurora.org>
>
> Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Acked-by: Grant Likely <grant.likely@linaro.org>
> ---
> drivers/of/Kconfig | 6 ++
> drivers/of/Makefile | 1 +
> drivers/of/fdt.c | 13 ++-
> drivers/of/of_reserved_mem.c | 188 +++++++++++++++++++++++++++++++++++++++
> include/linux/of_reserved_mem.h | 21 +++++
> 5 files changed, 227 insertions(+), 2 deletions(-)
> 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..30a7d87a8077 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 OF_EARLY_FLATTREE
> + bool
> + 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/fdt.c b/drivers/of/fdt.c
> index 12809e20ef71..eafe5805257a 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -15,6 +15,7 @@
> #include <linux/module.h>
> #include <linux/of.h>
> #include <linux/of_fdt.h>
> +#include <linux/of_reserved_mem.h>
> #include <linux/string.h>
> #include <linux/errno.h>
> #include <linux/slab.h>
> @@ -449,7 +450,7 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
> phys_addr_t base, size;
> unsigned long len;
> __be32 *prop;
> - int nomap;
> + int nomap, first = 1;
>
> prop = of_get_flat_dt_prop(node, "reg", &len);
> if (!prop)
> @@ -476,6 +477,10 @@ static int __init __reserved_mem_reserve_reg(unsigned long node,
> uname, &base, (unsigned long)size / SZ_1M);
>
> len -= t_len;
> + if (first) {
> + fdt_reserved_mem_save_node(node, uname, base, size);
> + first = 0;
> + }
> }
> return 0;
> }
> @@ -506,6 +511,7 @@ static int __init __fdt_scan_reserved_mem(unsigned long node, const char *uname,
> {
> static int found;
> const char *status;
> + int err;
>
> if (!found && depth == 1 && strcmp(uname, "reserved-memory") == 0) {
> if (__reserved_mem_check_root(node) != 0) {
> @@ -528,7 +534,9 @@ static int __init __fdt_scan_reserved_mem(unsigned long node, const char *uname,
> if (status && strcmp(status, "okay") != 0 && strcmp(status, "ok") != 0)
> return 0;
>
> - __reserved_mem_reserve_reg(node, uname);
> + err = __reserved_mem_reserve_reg(node, uname);
> + if (err == -ENOENT && of_get_flat_dt_prop(node, "size", NULL))
> + fdt_reserved_mem_save_node(node, uname, 0, 0);
>
> /* scan next node */
> return 0;
> @@ -544,6 +552,7 @@ static int __init __fdt_scan_reserved_mem(unsigned long node, const char *uname,
> void __init early_init_fdt_scan_reserved_mem(void)
> {
> of_scan_flat_dt(__fdt_scan_reserved_mem, NULL);
> + fdt_init_reserved_mem();
> }
>
> /**
> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
> new file mode 100644
> index 000000000000..c7ca6a4a42d1
> --- /dev/null
> +++ b/drivers/of/of_reserved_mem.c
> @@ -0,0 +1,188 @@
> +/*
> + * Device tree based initialization code for reserved memory.
> + *
> + * Copyright (c) 2013, The Linux Foundation. All Rights Reserved.
> + * Copyright (c) 2013,2014 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/of_reserved_mem.h>
> +
> +#define MAX_RESERVED_REGIONS 16
> +static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
> +static int reserved_mem_count;
> +
> +#if defined(CONFIG_HAVE_MEMBLOCK)
> +#include <linux/memblock.h>
> +int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
> + phys_addr_t align, phys_addr_t start, phys_addr_t end, bool nomap,
> + phys_addr_t *res_base)
> +{
> + /*
> + * We use __memblock_alloc_base() because memblock_alloc_base()
> + * panic()s on allocation failure.
> + */
> + phys_addr_t base = __memblock_alloc_base(size, align, end);
> + if (!base)
> + return -ENOMEM;
> +
> + /*
> + * Check if the allocated region fits in to start..end window
> + */
> + if (base < start) {
> + memblock_free(base, size);
> + return -ENOMEM;
> + }
> +
> + *res_base = base;
> + if (nomap)
> + return memblock_remove(base, size);
> + return 0;
> +}
> +#else
> +int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
> + phys_addr_t align, phys_addr_t start, phys_addr_t end, bool nomap,
> + phys_addr_t *res_base)
> +{
> + pr_error("Reserved memory not supported, ignoring region 0x%llx%s\n",
> + size, nomap ? " (nomap)" : "");
> + return -ENOSYS;
> +}
> +#endif
> +
> +/**
> + * res_mem_save_node() - save fdt node for second pass initialization
> + */
> +void __init fdt_reserved_mem_save_node(unsigned long node, const char *uname,
> + phys_addr_t base, phys_addr_t size)
> +{
> + struct reserved_mem *rmem = &reserved_mem[reserved_mem_count];
> +
> + if (reserved_mem_count == ARRAY_SIZE(reserved_mem)) {
> + pr_err("Reserved memory: not enough space all defined regions.\n");
> + return;
> + }
> +
> + rmem->fdt_node = node;
> + rmem->name = uname;
> + rmem->base = base;
> + rmem->size = size;
> +
> + reserved_mem_count++;
> + return;
> +}
> +
> +/**
> + * res_mem_alloc_size() - allocate reserved memory described by 'size', 'align'
> + * and 'alloc-ranges' properties
> + */
> +static int __init __reserved_mem_alloc_size(unsigned long node,
> + const char *uname, phys_addr_t *res_base, phys_addr_t *res_size)
> +{
> + int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
> + phys_addr_t start = 0, end = 0;
> + phys_addr_t base = 0, align = 0, size;
> + unsigned long len;
> + __be32 *prop;
> + int nomap;
> + int ret;
> +
> + 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;
> + }
> + size = dt_mem_next_cell(dt_root_size_cells, &prop);
> +
> + nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
> +
> + prop = of_get_flat_dt_prop(node, "alignment", &len);
> + if (prop) {
> + if (len != dt_root_addr_cells * sizeof(__be32)) {
> + pr_err("Reserved memory: invalid alignment property in '%s' node.\n",
> + uname);
> + return -EINVAL;
> + }
> + align = dt_mem_next_cell(dt_root_addr_cells, &prop);
> + }
> +
> + prop = of_get_flat_dt_prop(node, "alloc-ranges", &len);
> + if (prop) {
> +
> + if (len % t_len != 0) {
> + pr_err("Reserved memory: invalid alloc-ranges property in '%s', skipping node.\n",
> + uname);
> + return -EINVAL;
> + }
> +
> + base = 0;
> +
> + while (len > 0) {
> + start = dt_mem_next_cell(dt_root_addr_cells, &prop);
> + end = start + dt_mem_next_cell(dt_root_size_cells,
> + &prop);
> +
> + ret = early_init_dt_alloc_reserved_memory_arch(size,
> + align, start, end, nomap, &base);
> + if (ret == 0) {
> + pr_debug("Reserved memory: allocated memory for '%s' node: base %pa, size %ld MiB\n",
> + uname, &base,
> + (unsigned long)size / SZ_1M);
> + break;
> + }
> + len -= t_len;
> + }
> +
> + } else {
> + ret = early_init_dt_alloc_reserved_memory_arch(size, align,
> + 0, 0, nomap, &base);
> + if (ret == 0)
> + pr_debug("Reserved memory: allocated memory for '%s' node: base %pa, size %ld MiB\n",
> + uname, &base, (unsigned long)size / SZ_1M);
> + }
> +
> + if (base == 0) {
> + pr_info("Reserved memory: failed to allocate memory for node '%s'\n",
> + uname);
> + return -ENOMEM;
> + }
> +
> + *res_base = base;
> + *res_size = size;
> +
> + return 0;
> +}
> +
> +/**
> + * fdt_init_reserved_mem - allocate and init all saved reserved memory regions
> + */
> +void __init fdt_init_reserved_mem(void)
> +{
> + int i;
> + for (i = 0; i < reserved_mem_count; i++) {
> + struct reserved_mem *rmem = &reserved_mem[i];
> + unsigned long node = rmem->fdt_node;
> + int err = 0;
> +
> + if (rmem->size == 0)
> + err = __reserved_mem_alloc_size(node, rmem->name,
> + &rmem->base, &rmem->size);
> + }
> +}
> diff --git a/include/linux/of_reserved_mem.h b/include/linux/of_reserved_mem.h
> new file mode 100644
> index 000000000000..89226ed7d954
> --- /dev/null
> +++ b/include/linux/of_reserved_mem.h
> @@ -0,0 +1,21 @@
> +#ifndef __OF_RESERVED_MEM_H
> +#define __OF_RESERVED_MEM_H
> +
> +struct reserved_mem {
> + const char *name;
> + unsigned long fdt_node;
> + phys_addr_t base;
> + phys_addr_t size;
> +};
> +
> +#ifdef CONFIG_OF_RESERVED_MEM
> +void fdt_init_reserved_mem(void);
> +void fdt_reserved_mem_save_node(unsigned long node, const char *uname,
> + phys_addr_t base, phys_addr_t size);
> +#else
> +static inline void fdt_init_reserved_mem(void) { }
> +static inline void fdt_reserved_mem_save_node(unsigned long node,
> + const char *uname, phys_addr_t base, phys_addr_t size) { }
> +#endif
> +
> +#endif /* __OF_RESERVED_MEM_H */
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH v5 02/11] drivers: of: add initialization code for static reserved memory
From: Grant Likely @ 2014-02-26 12:05 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linaro-mm-sig-cunTk1MwBs8s++Sfvej+rw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA
Cc: Marek Szyprowski, 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, Catalin Marinas,
Will Deacon, Paul Mackerras
In-Reply-To: <1392985527-6260-3-git-send-email-m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
On Fri, 21 Feb 2014 13:25:18 +0100, Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> wrote:
> This patch adds support for static (defined by 'reg' property) reserved
> memory regions declared in device tree.
>
> 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). Typically, all this happens before device tree
> structures are unflattened, so we need to get reserved memory layout
> directly from fdt.
>
> Based on previous code provided by Josh Cartwright <joshc-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>
> Signed-off-by: Marek Szyprowski <m.szyprowski-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
> ---
> drivers/of/fdt.c | 125 ++++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/of_fdt.h | 3 ++
> 2 files changed, 128 insertions(+)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 758b4f8b30b7..12809e20ef71 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -440,6 +440,113 @@ struct boot_param_header *initial_boot_params;
> #ifdef CONFIG_OF_EARLY_FLATTREE
>
> /**
> + * res_mem_reserve_reg() - reserve all memory described in 'reg' property
> + */
> +static int __init __reserved_mem_reserve_reg(unsigned long node,
> + const char *uname)
> +{
> + int t_len = (dt_root_addr_cells + dt_root_size_cells) * sizeof(__be32);
> + phys_addr_t base, size;
> + unsigned long len;
> + __be32 *prop;
> + int nomap;
> +
> + prop = of_get_flat_dt_prop(node, "reg", &len);
> + if (!prop)
> + return -ENOENT;
> +
> + if (len && len % t_len != 0) {
> + pr_err("Reserved memory: invalid reg property in '%s', skipping node.\n",
> + uname);
> + return -EINVAL;
> + }
> +
> + nomap = of_get_flat_dt_prop(node, "no-map", NULL) != NULL;
> +
> + while (len > 0) {
This is safer: while (len >= t_len) {
> + base = dt_mem_next_cell(dt_root_addr_cells, &prop);
> + size = dt_mem_next_cell(dt_root_size_cells, &prop);
> +
> + if (base && size &&
> + early_init_dt_reserve_memory_arch(base, size, nomap) == 0)
> + pr_debug("Reserved memory: reserved region for node '%s': base %pa, size %ld MiB\n",
> + uname, &base, (unsigned long)size / SZ_1M);
> + else
> + pr_info("Reserved memory: failed to reserve memory for node '%s': base %pa, size %ld MiB\n",
> + uname, &base, (unsigned long)size / SZ_1M);
> +
> + len -= t_len;
> + }
> + return 0;
> +}
> +
> +static int __reserved_mem_check_root(unsigned long node)
Please document the purpose of this function. This function reflects a Linux
implementation limitation because it is easier than parsing a correctly
formed ranges property. Sometime in the future it may be fixed. It is
worth capturing all of that in a comment.
> +{
> + __be32 *prop;
> +
> + prop = of_get_flat_dt_prop(node, "#size-cells", NULL);
> + if (prop && be32_to_cpup(prop) != dt_root_size_cells)
> + return -EINVAL;
> +
> + prop = of_get_flat_dt_prop(node, "#address-cells", NULL);
> + if (prop && be32_to_cpup(prop) != dt_root_addr_cells)
> + return -EINVAL;
> +
> + prop = of_get_flat_dt_prop(node, "ranges", NULL);
> + if (!prop)
> + return -EINVAL;
> + return 0;
> +}
> +
> +/**
> + * fdt_scan_reserved_mem() - scan a single FDT node for reserved memory
> + */
> +static int __init __fdt_scan_reserved_mem(unsigned long node, const char *uname,
> + int depth, void *data)
> +{
> + static int found;
> + const char *status;
> +
> + if (!found && depth == 1 && strcmp(uname, "reserved-memory") == 0) {
> + if (__reserved_mem_check_root(node) != 0) {
> + pr_err("Reserved memory: unsupported node format, ignoring\n");
> + /* break scan */
> + return 1;
> + }
> + found = 1;
> + /* scan next node */
> + return 0;
> + } else if (!found) {
> + /* scan next node */
> + return 0;
> + } else if (found && depth < 2) {
> + /* scanning of /reserved-memory has been finished */
> + return 1;
> + }
> +
> + status = of_get_flat_dt_prop(node, "status", NULL);
> + if (status && strcmp(status, "okay") != 0 && strcmp(status, "ok") != 0)
> + return 0;
> +
> + __reserved_mem_reserve_reg(node, uname);
> +
> + /* scan next node */
> + return 0;
> +}
> +
> +/**
> + * early_init_fdt_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 (i.e. memblock) has been fully activated.
> + */
> +void __init early_init_fdt_scan_reserved_mem(void)
> +{
> + of_scan_flat_dt(__fdt_scan_reserved_mem, NULL);
> +}
Looks good.
> +
> +/**
> * of_scan_flat_dt - scan flattened tree blob and call callback on each.
> * @it: callback function
> * @data: context data pointer
> @@ -856,6 +963,16 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, u64 size)
> memblock_add(base, size);
> }
>
> +int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
> + phys_addr_t size, bool nomap)
> +{
> + if (memblock_is_region_reserved(base, size))
> + return -EBUSY;
> + if (nomap)
> + return memblock_remove(base, size);
> + return memblock_reserve(base, size);
> +}
> +
> /*
> * called from unflatten_device_tree() to bootstrap devicetree itself
> * Architectures can override this definition if memblock isn't used
> @@ -864,6 +981,14 @@ void * __init __weak early_init_dt_alloc_memory_arch(u64 size, u64 align)
> {
> return __va(memblock_alloc(size, align));
> }
> +#else
> +int __init __weak early_init_dt_reserve_memory_arch(phys_addr_t base,
> + phys_addr_t size, bool nomap)
> +{
> + pr_error("Reserved memory not supported, ignoring range 0x%llx - 0x%llx%s\n",
> + base, size, nomap ? " (nomap)" : "");
> + return -ENOSYS;
> +}
> #endif
>
> bool __init early_init_dt_scan(void *params)
> diff --git a/include/linux/of_fdt.h b/include/linux/of_fdt.h
> index 2b77058a7335..8610ad8d77d2 100644
> --- a/include/linux/of_fdt.h
> +++ b/include/linux/of_fdt.h
> @@ -98,7 +98,10 @@ extern int early_init_dt_scan_chosen(unsigned long node, const char *uname,
> int depth, void *data);
> extern int early_init_dt_scan_memory(unsigned long node, const char *uname,
> int depth, void *data);
> +extern void early_init_fdt_scan_reserved_mem(void);
> extern void early_init_dt_add_memory_arch(u64 base, u64 size);
> +extern int early_init_dt_reserve_memory_arch(phys_addr_t base, phys_addr_t size,
> + bool no_map);
> extern void * early_init_dt_alloc_memory_arch(u64 size, u64 align);
> extern u64 dt_mem_next_cell(int s, __be32 **cellp);
I think I'm happy with this one. Address my comments above and add my
Acked-by (so I remember I was okay with this one when you repost it) :-)
Acked-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>
> --
> 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 2/2] ARM: dts: duovero-parlor: Add HDMI output
From: Russell King - ARM Linux @ 2014-02-26 12:03 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, Sebastian Reichel, Javier Martinez Canillas,
Florian Vaussard, Benoît Cousson, Tony Lindgren,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Ash Charles,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Arnd Bergmann
In-Reply-To: <530DCC8A.6060708-l0cyMroinI0@public.gmane.org>
On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote:
> We have a bunch of panels and encoders used on OMAP boards, and we have
> separate, omapdss specific, drivers for those. My plan is to continue
> improving those drivers until they can be platform independent. This
> would be the Common Display Framework that's been discussed (or a
> precursor to it).
I believe CDF has been knocked on the head.
Also - DRM is not going to ever support hotplugging components - this
was discussed at kernel summit last year and David Airlie was quite
adamant about that. So, any "framework" which forces hotplugging of
components on subsystems isn't going to fly.
This is why we now have the component helpers in the driver model -
to allow devices to be collected together into one logical subsystem
group, and bound/unbound as a group.
Remember that "hotplugging" in this context does not mean that the
user can physically do something with the hardware. It means that
they're separate devices which can be probed/removed at will. Every
device in Linux can be bound and unbound from its driver at any time
by userspace, and that is something which is expected to be handled
gracefully.
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
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 v5 2/4] devicetree: bindings: Document Krait CPU/L1 EDAC
From: Lorenzo Pieralisi @ 2014-02-26 12:01 UTC (permalink / raw)
To: Kumar Gala
Cc: Stephen Boyd, Borislav Petkov, linux-kernel@vger.kernel.org,
linux-arm-msm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-edac@vger.kernel.org,
Mark Rutland, devicetree@vger.kernel.org
In-Reply-To: <E34E6789-03BC-452C-9053-82CA1D027861@codeaurora.org>
On Tue, Feb 25, 2014 at 08:48:38PM +0000, Kumar Gala wrote:
>
> On Feb 25, 2014, at 5:16 AM, Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> wrote:
>
> > Hi Stephen,
> >
> > On Wed, Feb 19, 2014 at 12:20:43AM +0000, Stephen Boyd wrote:
> >> (Sorry, this discussion stalled due to merge window + life events)
> >
> > Sorry for the delay in replying on my side too.
> >
> >> On 01/17, Lorenzo Pieralisi wrote:
> >>> On Thu, Jan 16, 2014 at 07:26:17PM +0000, Stephen Boyd wrote:
> >>>> On 01/16, Lorenzo Pieralisi wrote:
> >>>>> On Thu, Jan 16, 2014 at 06:05:05PM +0000, Stephen Boyd wrote:
> >>>>>> On 01/16, Lorenzo Pieralisi wrote:
> >>>>>>> Do we really want to do that ? I am not sure. A cpus node is supposed to
> >>>>>>> be a container node, we should not define this binding just because we
> >>>>>>> know the kernel creates a platform device for it then.
> >>>>>>
> >>>>>> This is just copying more of the ePAPR spec into this document.
> >>>>>> It just so happens that having a compatible field here allows a
> >>>>>> platform device to be created. I don't see why that's a problem.
> >>>>>
> >>>>> I do not see why you cannot define a node like pmu or arch-timer and stick
> >>>>> a compatible property in there. cpus node does not represent a device, and
> >>>>> must not be created as a platform device, that's my opinion.
> >>>>>
> >>>>
> >>>> I had what you're suggesting before in the original revision of
> >>>> this patch. Please take a look at the original patch series[1]. I
> >>>> suppose it could be tweaked slightly to still have a cache node
> >>>> for the L2 interrupt and the next-level-cache pointer from the
> >>>> CPUs.
> >>>
> >>> Ok, sorry, we are running around in circles here, basically you moved
> >>> the node to cpus according to reviews. I still think that treating cpus
> >>> as a device is not a great idea, even though I am in the same
> >>> position with C-states and probably will add C-state tables in the cpus
> >>> node.
> >>>
> >>> http://comments.gmane.org/gmane.linux.power-management.general/41012
> >>>
> >>> I just would like to see under cpus nodes and properties that apply to
> >>> all ARM systems, and avoid defining properties (eg interrupts) that
> >>> have different meanings for different ARM cores.
> >>>
> >>> The question related to why the kernel should create a platform device
> >>> out of cpus is still open. I really do not want to block your series
> >>> for these simple issues but we have to make a decision and stick to that,
> >>> I am fine either way if we have a plan.
> >>>
> >>
> >> Do you just want a backup plan in case we don't make a platform
> >> device out of the cpus node? I believe we can always add code
> >> somewhere to create a platform device at runtime if we detect the
> >> cpus node has a compatible string equal to "qcom,krait". We could
> >> probably change this driver's module_init() to scan the DT for
> >> such a compatible string and create the platform device right
> >> there. If we get more than one interrupt in the cpus node we can
> >> add interrupt-names and then have software look for interrupts by
> >> name instead of number.
> >
> > As I mentioned, I do not like the idea of adding compatible properties
> > just to force the kernel to create platform devices out of device tree
> > nodes. On top of that I would avoid adding a compatible property
> > to the cpus node (after all properties like enable-method are common for all
> > cpus but still duplicated), my only concern being backward compatibility
> > here (ie if we do that for interrupts, we should do that also for other
> > common cpu nodes properties, otherwise we have different rules for
> > different properties).
> >
> > I think you can then add interrupts to cpu nodes ("qcom,krait" specific),
> > and as you mentioned create a platform device for that.
> >
> > Thanks,
> > Lorenzo
>
> So I agree with the statement about adding compatibles just to create platform devices is wrong. However its seems perfectly reasonable for a cpu node to have a compatible property. I don't see why a CPU is any different from any other device described in a DT.
I was referring to the /cpus node, not to individual cpu nodes, where
the compatible property is already present now.
Lorenzo
^ permalink raw reply
* Re: [PATCH v5 01/11] of: document bindings for reserved-memory nodes
From: Grant Likely @ 2014-02-26 11:51 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel, linaro-mm-sig, devicetree,
linux-doc
Cc: Marek Szyprowski, 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, Catalin Marinas,
Will Deacon, Paul Mackerras
In-Reply-To: <1392985527-6260-2-git-send-email-m.szyprowski@samsung.com>
On Fri, 21 Feb 2014 13:25:17 +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.
>
> Signed-off-by: Grant Likely <grant.likely@linaro.org>
> [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]
> 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 still don't like this portion of the binding. I'm not convinced that
it is necessary in the majority of cases and it is going to be very
driver specific. I would rather drop it entirely from the common
binding. If a specific driver needs to do something like the above then
it can have a driver specific binding. Otherwise I think the default
should be a simple phandle with no arguments to a single reserved memory
node.
Ben, can you weigh in on the current state of this document. I'm mostly
happy with it aside from my comment above. Do you think this is ready to
be merged?
> +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>
Add "Use vendor strings to identify regions dedicates for a specific
vendor device. For example: 'acme,framebuffer'. Platform code can use vendor
strings to identify device specific regions"
> +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
* [PATCH] phy: micrel: add of configuration for LED mode
From: Ben Dooks @ 2014-02-26 11:48 UTC (permalink / raw)
To: linux-kernel, devicetree, netdev; +Cc: f.fainelli, Ben Dooks
Add support for the led-mode property for the following PHYs
which have a single LED mode configuration value.
KSZ8001 and KSZ8041 which both use register 0x1e bits 15,14 and
KSZ8021, KSZ8031 and KSZ8051 which use register 0x1f bits 5,4
to control the LED configuration.
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
---
Documentation/devicetree/bindings/net/micrel.txt | 18 +++++++++
drivers/net/phy/micrel.c | 49 ++++++++++++++++++++++--
2 files changed, 63 insertions(+), 4 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/micrel.txt
diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
new file mode 100644
index 0000000..98a3e61
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/micrel.txt
@@ -0,0 +1,18 @@
+Micrel PHY properties.
+
+These properties cover the base properties Micrel PHYs.
+
+Optional properties:
+
+ - micrel,led-mode : LED mode value to set for PHYs with configurable LEDs.
+
+ Configure the LED mode with single value. The list of PHYs and
+ the bits that are currently supported:
+
+ KSZ8001: register 0x1e, bits 15..14
+ KSZ8041: register 0x1e, bits 15..14
+ KSZ8021: register 0x1f, bits 5..4
+ KSZ8031: register 0x1f, bits 5..4
+ KSZ8051: register 0x1f, bits 5..4
+
+ See the respective PHY datasheet for the mode values.
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 5a8993b..0c9e434 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -148,15 +148,52 @@ static int ks8737_config_intr(struct phy_device *phydev)
return rc < 0 ? rc : 0;
}
+static int kszphy_setup_led(struct phy_device *phydev,
+ unsigned int reg, unsigned int shift)
+{
+
+ struct device *dev = &phydev->dev;
+ struct device_node *of_node = dev->of_node;
+ int rc, temp;
+ u32 val;
+
+ if (!of_node && dev->parent->of_node)
+ of_node = dev->parent->of_node;
+
+ if (of_property_read_u32(of_node, "micrel,led-mode", &val))
+ return 0;
+
+ temp = phy_read(phydev, reg);
+ if (temp < 0)
+ return temp;
+
+ temp &= 3 << shift;
+ temp |= val << shift;
+ rc = phy_write(phydev, reg, temp);
+
+ return rc < 0 ? rc : 0;
+}
+
static int kszphy_config_init(struct phy_device *phydev)
{
return 0;
}
+static int kszphy_config_init_led8041(struct phy_device *phydev)
+{
+ /* single led control, register 0x1e bits 15..14 */
+ return kszphy_setup_led(phydev, 0x1e, 14);
+}
+
static int ksz8021_config_init(struct phy_device *phydev)
{
- int rc;
const u16 val = KSZPHY_OMSO_B_CAST_OFF | KSZPHY_OMSO_RMII_OVERRIDE;
+ int rc;
+
+ rc = kszphy_setup_led(phydev, 0x1f, 4);
+ if (rc)
+ dev_err(&phydev->dev, "failed to set led mode\n");
+
phy_write(phydev, MII_KSZPHY_OMSO, val);
rc = ksz_config_flags(phydev);
return rc < 0 ? rc : 0;
@@ -166,6 +203,10 @@ static int ks8051_config_init(struct phy_device *phydev)
{
int rc;
+ rc = kszphy_setup_led(phydev, 0x1f, 4);
+ if (rc)
+ dev_err(&phydev->dev, "failed to set led mode\n");
+
rc = ksz_config_flags(phydev);
return rc < 0 ? rc : 0;
}
@@ -327,7 +368,7 @@ static struct phy_driver ksphy_driver[] = {
.features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
| SUPPORTED_Asym_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
- .config_init = kszphy_config_init,
+ .config_init = kszphy_config_init_led8041,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
@@ -342,7 +383,7 @@ static struct phy_driver ksphy_driver[] = {
.features = PHY_BASIC_FEATURES |
SUPPORTED_Pause | SUPPORTED_Asym_Pause,
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
- .config_init = kszphy_config_init,
+ .config_init = kszphy_config_init_led8041,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
@@ -371,7 +412,7 @@ static struct phy_driver ksphy_driver[] = {
.phy_id_mask = 0x00ffffff,
.features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
- .config_init = kszphy_config_init,
+ .config_init = kszphy_config_init_led8041,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
--
1.8.5.3
^ permalink raw reply related
* Re: [RFCv3 0/7] Convert twl4030-madc to IIO API and add DT support
From: Belisko Marek @ 2014-02-26 11:42 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Sebastian Reichel, Jonathan Cameron, Lee Jones, Samuel Ortiz,
Lars-Peter Clausen, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Grant Likely, LKML,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Dr. H. Nikolaus Schaller
In-Reply-To: <1393374270-20079-1-git-send-email-sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org>
Hi Sebastian,
On Wed, Feb 26, 2014 at 1:24 AM, Sebastian Reichel <sre-8fiUuRrzOP0dnm+yROfE0A@public.gmane.org> wrote:
> Hi,
>
> This is RFCv3 for converting twl4030-madc to the IIO API and
> adding DT support. The patchset compiles and has been tested
> on my Nokia N900.
>
> Changes since RFCv2:
> * Use "--find-renames" for the move from mfd/ to iio/adc/ ;)
> * Added Acked-by from Lee Jones (MFD subsystem maintainer)
> * Fixed issue found by Joe Perches
> - twl4030_madc_request.do_avg should be bool instead of u16
> * Fixed issues found by Peter Meerwald
> - some style issues (e.g. /** instead of /*)
> - typos
> - usage of u16 read/write
> * Tested with converted rx51-battery driver on Nokia N900
>
> TODO:
> * Remove twl4030-madc-hwmon in favour of iio-hwmon
> This driver is currently only used by board-omap3beagle.c
> and board-rx51-peripherals.c. The instanciation in the
> rx51 boardcode is a bug, since actually only twl4030-madc
> is needed. Thus board-omap3beagle.c needs to be updated to
> iio-hwmon and board-rx51-peripherals.c to twl4030-madc.
> Both tasks are pretty trivial and twl4030-madc-hwmon can
> be removed afterwards :)
> * Update twl4030-madc-battery to the IIO API. I guess Marek
> will do this update in the near future, since he is currently
> writing DT bindings for the driver.
Yes I'm working on DT for twl4030-madc-battery. I'll convert it also to IIO
and post for comments. Thanks for doing that it's really nice work!
> * I updated twl4030-madc-battery already and will send it
> in a separate patchset.
> * Once all of the above steps happened the old API can be
> removed from the driver, which allows some more cleanups.
>
> -- Sebastian
>
> Sebastian Reichel (7):
> mfd: twl4030-madc: Use managed resources
> mfd: twl4030-madc: Add DT support and convert to IIO framework
> mfd: twl4030-madc: Cleanup driver
> mfd: twl-core: Add twl_i2c_read/write_u16
> mfd: twl4030-madc: Use twl_i2c_read/write_u16 for 16 bit registers
> Documentation: DT: Document twl4030-madc binding
> mfd: twl4030-madc: Move driver to drivers/iio/adc
>
> .../devicetree/bindings/iio/adc/twl4030-madc.txt | 24 ++
> drivers/iio/adc/Kconfig | 10 +
> drivers/iio/adc/Makefile | 1 +
> drivers/{mfd => iio/adc}/twl4030-madc.c | 278 +++++++++++++--------
> drivers/mfd/Kconfig | 10 -
> drivers/mfd/Makefile | 1 -
> include/linux/i2c/twl.h | 12 +
> include/linux/i2c/twl4030-madc.h | 2 +-
> 8 files changed, 224 insertions(+), 114 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
> rename drivers/{mfd => iio/adc}/twl4030-madc.c (77%)
>
> --
> 1.8.5.3
>
BR,
marek
--
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer
Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
^ permalink raw reply
* Re: [PATCH v4 1/3] [media] of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Grant Likely @ 2014-02-26 11:37 UTC (permalink / raw)
To: Russell King - ARM Linux, Mauro Carvalho Chehab
Cc: Rob Herring, Sylwester Nawrocki, Laurent Pinchart, Tomi Valkeinen,
Kyungmin Park, linux-kernel, linux-media, devicetree,
Guennadi Liakhovetski, Philipp Zabel, Philipp Zabel
In-Reply-To: <1393340304-19005-2-git-send-email-p.zabel@pengutronix.de>
On Tue, 25 Feb 2014 15:58:22 +0100, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> From: Philipp Zabel <philipp.zabel@gmail.com>
>
> This patch moves the parsing helpers used to parse connected graphs
> in the device tree, like the video interface bindings documented in
> Documentation/devicetree/bindings/media/video-interfaces.txt, from
> drivers/media/v4l2-core to drivers/of.
>
> This allows to reuse the same parser code from outside the V4L2
> framework, most importantly from display drivers.
> The functions v4l2_of_get_next_endpoint, v4l2_of_get_remote_port,
> and v4l2_of_get_remote_port_parent are moved. They are renamed to
> of_graph_get_next_endpoint, of_graph_get_remote_port, and
> of_graph_get_remote_port_parent, respectively.
> Since there are not that many current users yet, switch all of
> them to the new functions right away.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> Changes since v3:
> - Moved back to drivers/of
> ---
> drivers/media/i2c/adv7343.c | 4 +-
> drivers/media/i2c/mt9p031.c | 4 +-
> drivers/media/i2c/s5k5baf.c | 3 +-
> drivers/media/i2c/tvp514x.c | 3 +-
> drivers/media/i2c/tvp7002.c | 3 +-
> drivers/media/platform/exynos4-is/fimc-is.c | 6 +-
> drivers/media/platform/exynos4-is/media-dev.c | 3 +-
> drivers/media/platform/exynos4-is/mipi-csis.c | 3 +-
> drivers/media/v4l2-core/v4l2-of.c | 117 ----------------------
> drivers/of/Makefile | 1 +
> drivers/of/of_graph.c | 134 ++++++++++++++++++++++++++
Nah. Just put it into drivers/of/base.c. This isn't a separate subsystem
and the functions are pretty basic.
> include/linux/of_graph.h | 46 +++++++++
> include/media/v4l2-of.h | 25 +----
> 13 files changed, 199 insertions(+), 153 deletions(-)
> create mode 100644 drivers/of/of_graph.c
> create mode 100644 include/linux/of_graph.h
>
[...]
> diff --git a/drivers/of/of_graph.c b/drivers/of/of_graph.c
> new file mode 100644
> index 0000000..267d8f7
> --- /dev/null
> +++ b/drivers/of/of_graph.c
> @@ -0,0 +1,134 @@
> +/*
> + * OF graph binding parsing library
> + *
> + * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
> + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
> + *
> + * Copyright (C) 2012 Renesas Electronics Corp.
> + * Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + */
> +#include <linux/kernel.h>
> +#include <linux/of.h>
> +#include <linux/of_graph.h>
> +#include <linux/types.h>
> +
> +/**
> + * of_graph_get_next_endpoint() - get next endpoint node
> + * @parent: pointer to the parent device node
> + * @prev: previous endpoint node, or NULL to get first
> + *
> + * Return: An 'endpoint' node pointer with refcount incremented. Refcount
> + * of the passed @prev node is not decremented, the caller have to use
> + * of_node_put() on it when done.
> + */
> +struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
> + struct device_node *prev)
> +{
> + struct device_node *endpoint;
> + struct device_node *port = NULL;
> +
> + if (!parent)
> + return NULL;
> +
> + if (!prev) {
> + struct device_node *node;
> + /*
> + * It's the first call, we have to find a port subnode
> + * within this node or within an optional 'ports' node.
> + */
> + node = of_get_child_by_name(parent, "ports");
> + if (node)
> + parent = node;
> +
> + port = of_get_child_by_name(parent, "port");
If you've got a "ports" node, then I would expect every single child to
be a port. Should not need the _by_name variant.
It seems that this function is merely a helper to get all grandchildren
of a node (with some very minor constraints). That could be generalized
and simplified. If the function takes the "ports" node as an argument
instead of the parent, then there is a greater likelyhood that other
code can make use of it...
Thinking further. I think the semantics of this whole feature basically
boil down to this:
#define for_each_grandchild_of_node(parent, child, grandchild) \
for_each_child_of_node(parent, child) \
for_each_child_of_node(child, grandchild)
Correct? Or in this specific case:
parent = of_get_child_by_name(np, "ports")
for_each_grandchild_of_node(parent, child, grandchild) {
...
}
Finally, looking at the actual patch, is any of this actually needed.
All of the users updated by this patch only ever handle a single
endpoint. Have I read it correctly? Are there any users supporting
multiple endpoints?
> +
> + if (port) {
> + /* Found a port, get an endpoint. */
> + endpoint = of_get_next_child(port, NULL);
> + of_node_put(port);
> + } else {
> + endpoint = NULL;
> + }
> +
> + if (!endpoint)
> + pr_err("%s(): no endpoint nodes specified for %s\n",
> + __func__, parent->full_name);
> + of_node_put(node);
If you 'return endpoint' here, then the else block can go down a level.
> + } else {
> + port = of_get_parent(prev);
> + if (!port)
> + /* Hm, has someone given us the root node ?... */
> + return NULL;
WARN_ONCE(). That's a very definite coding failure if that happens.
> +
> + /* Avoid dropping prev node refcount to 0. */
> + of_node_get(prev);
> + endpoint = of_get_next_child(port, prev);
> + if (endpoint) {
> + of_node_put(port);
> + return endpoint;
> + }
> +
> + /* No more endpoints under this port, try the next one. */
> + do {
> + port = of_get_next_child(parent, port);
> + if (!port)
> + return NULL;
> + } while (of_node_cmp(port->name, "port"));
> +
> + /* Pick up the first endpoint in this port. */
> + endpoint = of_get_next_child(port, NULL);
> + of_node_put(port);
> + }
> +
> + return endpoint;
> +}
> +EXPORT_SYMBOL(of_graph_get_next_endpoint);
> +
> +/**
> + * of_graph_get_remote_port_parent() - get remote port's parent node
> + * @node: pointer to a local endpoint device_node
> + *
> + * Return: Remote device node associated with remote endpoint node linked
> + * to @node. Use of_node_put() on it when done.
> + */
> +struct device_node *of_graph_get_remote_port_parent(
> + const struct device_node *node)
> +{
> + struct device_node *np;
> + unsigned int depth;
> +
> + /* Get remote endpoint node. */
> + np = of_parse_phandle(node, "remote-endpoint", 0);
> +
> + /* Walk 3 levels up only if there is 'ports' node. */
This needs a some explaining. My reading of the binding pattern is that
it will always be a fixed number of levels. Why is this test fuzzy?
> + for (depth = 3; depth && np; depth--) {
> + np = of_get_next_parent(np);
> + if (depth == 2 && of_node_cmp(np->name, "ports"))
> + break;
> + }
> + return np;
> +}
> +EXPORT_SYMBOL(of_graph_get_remote_port_parent);
> +
> +/**
> + * of_graph_get_remote_port() - get remote port node
> + * @node: pointer to a local endpoint device_node
> + *
> + * Return: Remote port node associated with remote endpoint node linked
> + * to @node. Use of_node_put() on it when done.
> + */
> +struct device_node *of_graph_get_remote_port(const struct device_node *node)
> +{
> + struct device_node *np;
> +
> + /* Get remote endpoint node. */
> + np = of_parse_phandle(node, "remote-endpoint", 0);
> + if (!np)
> + return NULL;
> + return of_get_next_parent(np);
> +}
> +EXPORT_SYMBOL(of_graph_get_remote_port);
> diff --git a/include/linux/of_graph.h b/include/linux/of_graph.h
> new file mode 100644
> index 0000000..3bbeb60
> --- /dev/null
> +++ b/include/linux/of_graph.h
> @@ -0,0 +1,46 @@
> +/*
> + * OF graph binding parsing helpers
> + *
> + * Copyright (C) 2012 - 2013 Samsung Electronics Co., Ltd.
> + * Author: Sylwester Nawrocki <s.nawrocki@samsung.com>
> + *
> + * Copyright (C) 2012 Renesas Electronics Corp.
> + * Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + */
> +#ifndef __LINUX_OF_GRAPH_H
> +#define __LINUX_OF_GRAPH_H
> +
> +#ifdef CONFIG_OF
> +struct device_node *of_graph_get_next_endpoint(const struct device_node *parent,
> + struct device_node *previous);
> +struct device_node *of_graph_get_remote_port_parent(
> + const struct device_node *node);
> +struct device_node *of_graph_get_remote_port(const struct device_node *node);
> +#else
> +
> +static inline struct device_node *of_graph_get_next_endpoint(
> + const struct device_node *parent,
> + struct device_node *previous)
> +{
> + return NULL;
> +}
> +
> +static inline struct device_node *of_graph_get_remote_port_parent(
> + const struct device_node *node)
> +{
> + return NULL;
> +}
> +
> +static inline struct device_node *of_graph_get_remote_port(
> + const struct device_node *node)
> +{
> + return NULL;
> +}
> +
> +#endif /* CONFIG_OF */
> +
> +#endif /* __LINUX_OF_GRAPH_H */
> diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
> index 541cea4..3a49735 100644
> --- a/include/media/v4l2-of.h
> +++ b/include/media/v4l2-of.h
> @@ -17,6 +17,7 @@
> #include <linux/list.h>
> #include <linux/types.h>
> #include <linux/errno.h>
> +#include <linux/of_graph.h>
>
> #include <media/v4l2-mediabus.h>
>
> @@ -72,11 +73,6 @@ struct v4l2_of_endpoint {
> #ifdef CONFIG_OF
> int v4l2_of_parse_endpoint(const struct device_node *node,
> struct v4l2_of_endpoint *endpoint);
> -struct device_node *v4l2_of_get_next_endpoint(const struct device_node *parent,
> - struct device_node *previous);
> -struct device_node *v4l2_of_get_remote_port_parent(
> - const struct device_node *node);
> -struct device_node *v4l2_of_get_remote_port(const struct device_node *node);
> #else /* CONFIG_OF */
>
> static inline int v4l2_of_parse_endpoint(const struct device_node *node,
> @@ -85,25 +81,6 @@ static inline int v4l2_of_parse_endpoint(const struct device_node *node,
> return -ENOSYS;
> }
>
> -static inline struct device_node *v4l2_of_get_next_endpoint(
> - const struct device_node *parent,
> - struct device_node *previous)
> -{
> - return NULL;
> -}
> -
> -static inline struct device_node *v4l2_of_get_remote_port_parent(
> - const struct device_node *node)
> -{
> - return NULL;
> -}
> -
> -static inline struct device_node *v4l2_of_get_remote_port(
> - const struct device_node *node)
> -{
> - return NULL;
> -}
> -
> #endif /* CONFIG_OF */
>
> #endif /* _V4L2_OF_H */
> --
> 1.8.5.3
>
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output
From: Tomi Valkeinen @ 2014-02-26 11:14 UTC (permalink / raw)
To: Russell King - ARM Linux, Laurent Pinchart, Sebastian Reichel
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
Arnd Bergmann, Tony Lindgren, Ash Charles, Benoît Cousson,
Javier Martinez Canillas, linux-omap@vger.kernel.org,
Florian Vaussard
In-Reply-To: <20140225205634.GZ27282@n2100.arm.linux.org.uk>
[-- Attachment #1.1: Type: text/plain, Size: 8151 bytes --]
Hi,
On 25/02/14 22:56, Russell King - ARM Linux wrote:
> On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote:
First I want to summarize the omapdss DT bindings, even if it was
already more or less covered earlier:
We have a bunch of panels and encoders used on OMAP boards, and we have
separate, omapdss specific, drivers for those. My plan is to continue
improving those drivers until they can be platform independent. This
would be the Common Display Framework that's been discussed (or a
precursor to it).
We need DT bindings for OMAP display, and one option would've been
adding a compatible string of "ti,xxx" for every panel and encoder. That
would obviously be wrong DT representation. So I wanted to do proper DT
bindings, with proper compatible string.
This creates the problem that we don't have generic drivers for those
components yet. For this, I created a hack that, on OMAP, appends
"omapdss," to the display components at boot time. This way we can have
OMAP specific drivers for the time being, but others could still use the
same bindings for their platform and platform specific drivers with
similar trick.
Note that the above is not merged yet, but I'd really want to get it in
for the next merge window, so if that general concept is bad, please
nack it asap. And preferably give ideas for an alternative =).
>> I don't think all physical connectors require a DT binding per-se, but they
>> need to be represented in DT as they're part of the hardware. We could push
>> connector-related information to the nodes of all chips that have interfaces
>> wired directly to connectors, but that would result in more complex DT
>> bindings and core. I believe modeling connectors using separate DT nodes is be
>> best, and would allow easier support for more complex connectors that carry
>> multiple streams/signals in parallel (video, audio, DDC, ...).
There are things we need to represent for the connectors. For example, a
+5V going to the connector is not managed by any IP. In some cases
neither is a hotplug detect GPIO. The i2c lines for the DDC need to be
managed by someone (with DVI. HDMI DDC on OMAP is managed by by the HDMI
IP).
I guess one could argue that those are standard properties of HDMI or
DVI, and thus could well be managed by the HDMI or DVI encoder, even if
the encoder IP itself doesn't have anything to do with those. Maybe they
could, but I think modeling the connector separately is more correct,
and allows more freedom.
Say, the HDMI could as well be directly wired to a panel, without any
connector, although this is perhaps more common with eDP. In that case
the connector related things can be just left out.
Additionally, but perhaps not strictly needed, the connector represents
a "termination" for the display pipeline, so there's a distinct display
element at the end of the chain, sometimes a panel, sometimes a
connector, which marks the end. This makes the pipeline consistent in
the case where you've got an encoder, output of which goes on some
boards to a connector and on some boards to a panel (compared to some
boards having a panel after the encoder, and some having nothing).
> There is some sanity to representing physical connectors in DT, but it's
> not for the reason you mention above. If you consider that it's possible
> on PCs to find out what connectors are on the motherboard and where they
> are located, this is very useful information to be stored and presented.
>
> However, the idea that you combine streams at connectors is not a
> universal truth, and is certainly false for HDMI. HDMI combines video
> and audio at the encoder stage, not at the connector stage, and many
> HDMI encoders will provide everything required for driving the connector.
>
> However, my major objection here is not really that: my major objection
> is using something as generic as "hdmi-connector" as a compatible string.
> The reason is that we have to remember that DT is not just "a Linux thing".
> It's /supposed/ to be an OS independent representation of the hardware.
>
> If we invent something generic called a "hdmi-connector" then we had
> better first do a thorough search to make sure we're not trampling on
> anything which is standardized or becoming a standard - if there is,
> we should work with them - and if that's not possible, then we need to
> distingush ourselves from them.
Yes, I agree that the connectors (DVI, analog-tv, and HDMI) are in a
sense much more generic than bindings for a single IP, and thus more
important to get right.
> What we can't do is go around inventing generic stuff without having our
> eyes wide open.
>
> So, here's a good question to probe how far this has been thought through
> already: what has been done to discuss the creation of this generic
> "hdmi-connector" thing with the various parties who are interested in
> HDMI outputs under DRM using device tree?
They have been discussed, in the context of Common Display Framework
proposals, and in the context of OMAP DSS DT bindings. They've seen
multiple review rounds, but I agree that finding about the connectors
there may be rather difficult if one is not interested in OMAP DSS, or
one see CDF as nonsense.
Those OMAP bindings are used on both OMAP fbdev and DRM drivers, so at
least in that case they've been proven to work on both frameworks.
> If that hasn't happened, that's quite a failing - it means that we're
> on the road to having two _implementation specific_ DT representations
> for the same hardware - one for fbdev and one for DRM. That really
> isn't on.
I hope not. Afais, the bindings are really about the HW. Not fbdev or DRM.
At the moment I do see that usually the existing fbdev and drm bindings
are, in my opinion, quite bad. They don't give proper and detailed
description of the hardware, in a way that should work on other
platforms with very different display pipelines.
The proposed bindings in my patches are the designed to be as generic as
we've (mostly me and Laurent) been able to make them, and very similar
ones have been used by Laurent on shmobile for his CDF patch series.
The HDMI connector in particular doesn't even define much anything at
all. At the moment, it only defines the connection to the previous item
in the display pipeline, usually the HDMI encoder. The +5V I plan to add
at some point, and it should be a clear addition, it's there by the
spec. The same for HPD and i2c, although those should be optional so
that an IP can handle those if the system is so designed.
So while I fully confess that I haven't looked at other platform's HDMI,
I don't see how the above could go badly wrong. The connector would
obviously be extended later to add any missing features.
> Yes, it then opens a pandora's box of problems about how we determine
> whether DRM or fbdev should bind to the DT nodes, but that should be
> an entirely separate issue (and, ideally of course, both should use
> the same sub-drivers for the components.)
Yes, this is what the common display framework tries to accomplish. But
as you say, it's a separate issue. The DT bindings should just model the
hardware so well that we're as confident as we can be that the current
boards can be described with those.
So how to go forward? It's very difficult to get feedback on complex DT
bindings. I recently posted only the DT documentation part for OMAP DSS
[1], in hopes to get some feedback for a smaller series, but nothing so
far. It might be easier to look at the whole series [2] to see how the
board dts files are changed, though.
Maybe the subject "OMAP DSS DT bindings documentation" is not quite
correct, as there's really nothing OMAP specific there except the SoC
bindings itself. Perhaps re-sending with subject of "Generic display
bindings" would catch more eyes.
Tomi
[1]
http://mid.gmane.org/1392294752-18762-1-git-send-email-tomi.valkeinen@ti.com
[2]
http://mid.gmane.org/1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- 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: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Grant Likely @ 2014-02-26 11:01 UTC (permalink / raw)
To: Philipp Zabel
Cc: Sascha Hauer, Rob Herring, Russell King - ARM Linux,
Mauro Carvalho Chehab, Rob Herring, Sylwester Nawrocki,
Laurent Pinchart, Tomi Valkeinen, Kyungmin Park,
linux-kernel@vger.kernel.org, linux-media@vger.kernel.org,
devicetree@vger.kernel.org, Philipp Zabel
In-Reply-To: <1393263389.3091.82.camel@pizza.hi.pengutronix.de>
On Mon, 24 Feb 2014 18:36:29 +0100, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> Am Dienstag, den 18.02.2014, 16:26 +0000 schrieb Grant Likely:
> > >
> > > You can find it under Documentation/devicetree/bindings/media/video-interfaces.txt
> >
> > Okay, I think I'm okay with moving the helpers, but I will make one
> > requirement. I would like to have a short binding document describing
> > the pattern being used. The document above talks a lot about video
> > specific issues, but the helpers appear to be specifically about the
> > tree walking properties of the API.
>
> Reusing the non-video-secific parts of video-interfaces.txt, how about
> the following:
This is good, but I have some comments. This document describes itself
as the common way for doing a device graph within the device tree, but
there is already a well established pattern for device graphs that is
used by the interrupts-extended, clocks and other bindings. Those are
all domain-specific bindings, but the core concept is one device uses
a resource provided by another device. The resource references construct
a graph independent from the natural FDT node graph. (ie. the interrupts
binding forms the interrupt graph. Same for the clock binding).
So, while this binding does describe a pattern for separate device
graphs, it is by no means the only common way of doing so.
I would like the document to acknowledge the difference from the
phandle+args pattern used elsewhere and a description of when it would
be appropriate to use this instead of a simpler binding.
>
> "Common bindings for device graphs"
>
> General concept
> ---------------
>
> The hierarchical organisation of the device tree is well suited to describe
> control flow to devices, but data flow between devices that work together to
> form a logical compound device can follow arbitrarily complex graphs.
I would argue that this pattern isn't necessarily restricted to data
flow descriptions. It wants to describe linkage between devices that are
sufficiently complex that the simple binding doesn't do the job.
> The device tree graph bindings allow to describe data bus connections between
> individual devices, that can't be inferred from device tree parent-child
> relationships. The common bindings do not contain any information about the
> direction or type of data flow, they just map connections. Specific properties
> of the connections can be set depending on the type of connection. To see
> how this binding applies to video pipelines, see for example
> Documentation/device-tree/bindings/media/video-interfaces.txt.
Even if you don't want to declare the direction of data flow, there does
need to be some guidance as to how the binding is constructed. Does
device A point to device B? Or the other way around? Why would someone
choose one over the other? I don't want to see a situation where A & B
point to each other. Things get complex if the graph is allowed to be
cyclical.
> Data interfaces on devices are described by their child 'port' nodes. The port
> node contains an 'endpoint' subnode for each remote device connected to this
> port via a bus. If a port is connected to more than one remote device on the
> same bus, an 'endpoint' child node must be provided for each of them. If more
> than one port is present in a device node or there is more than one endpoint at
> a port, or port node needs to be associated with a selected hardware interface,
> a common scheme using '#address-cells', '#size-cells' and 'reg' properties is
> used.
>
> device {
> ...
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> ...
> endpoint@0 { ... };
> endpoint@1 { ... };
> };
>
> port@1 { ... };
> };
>
> All 'port' nodes can be grouped under optional 'ports' node, which allows to
> specify #address-cells, #size-cells properties independently for the 'port'
> and 'endpoint' nodes and any child device nodes a device might have.
>
> device {
> ...
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> ...
> endpoint@0 { ... };
> endpoint@1 { ... };
> };
>
> port@1 { ... };
> };
> };
>
> Each endpoint can contain a 'remote-endpoint' phandle property that points to
> the corresponding endpoint in the port of the remote device. Two 'endpoint'
> nodes are linked with each other through their 'remote-endpoint' phandles.
I really don't like this aspect. It is far too easy to get wrong. Graphs
should be one direction only.
>
> device_1 {
> port {
> device_1_output: endpoint {
> remote-endpoint = <&device_2_input>;
> };
> };
> };
>
> device_1 {
> port {
> device_2_input: endpoint {
> remote-endpoint = <&device_1_output>;
> };
> };
> };
>
>
> Required properties
> -------------------
>
> If there is more than one 'port' or more than one 'endpoint' node or 'reg'
> property is present in port and/or endpoint nodes the following properties
> are required in a relevant parent node:
>
> - #address-cells : number of cells required to define port/endpoint
> identifier, should be 1.
> - #size-cells : should be zero.
>
> Optional endpoint properties
> ----------------------------
>
> - remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
>
>
^ permalink raw reply
* Re: [PATCH v7 5/9] ARM: Enable erratum 798181 for Broadcom Brahma-B15
From: Will Deacon @ 2014-02-26 10:47 UTC (permalink / raw)
To: Marc Carino
Cc: Christian Daudt, Arnd Bergmann, Olof Johansson, Florian Fainelli,
Matt Porter, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Gregory Fong,
rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org
In-Reply-To: <1393410552-21497-6-git-send-email-marc.ceeeee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Wed, Feb 26, 2014 at 10:29:08AM +0000, Marc Carino wrote:
> From: Gregory Fong <gregory.0xf0-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Broadcom Brahma-B15 (r0p0..r0p2) is also affected by Cortex-A15
> erratum 798181, so enable the workaround for Brahma-B15.
Really... *exactly* the same erratum? That sounds pretty unlikely, so I'd
really like to be sure that the workaround we have indeed solves your
problem (issuing a dummy TLBI to 0x0 + dsb, then followed by a dmb + clrex
on each core). The point is that the workaround doesn't simply perform
non-shareable invalidation on each core using IPIs.
/me counts the days until we need this code in arch/arm64.
Will
--
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
* [PATCH v7 9/9] ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino, Matt Porter
In-Reply-To: <1393410552-21497-1-git-send-email-marc.ceeeee@gmail.com>
Add a sample DTS which will allow bootup of a board populated
with the BCM7445 chip.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Cc: Matt Porter <mporter@linaro.org>
---
arch/arm/boot/dts/bcm7445-bcm97445svmb.dts | 14 ++++
arch/arm/boot/dts/bcm7445.dtsi | 107 ++++++++++++++++++++++++++++
2 files changed, 121 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/bcm7445-bcm97445svmb.dts
create mode 100644 arch/arm/boot/dts/bcm7445.dtsi
diff --git a/arch/arm/boot/dts/bcm7445-bcm97445svmb.dts b/arch/arm/boot/dts/bcm7445-bcm97445svmb.dts
new file mode 100644
index 0000000..9eec2ac
--- /dev/null
+++ b/arch/arm/boot/dts/bcm7445-bcm97445svmb.dts
@@ -0,0 +1,14 @@
+/dts-v1/;
+#include "bcm7445.dtsi"
+
+/ {
+ model = "Broadcom STB (bcm7445), SVMB reference board";
+ compatible = "brcm,bcm7445", "brcm,brcmstb";
+
+ memory {
+ device_type = "memory";
+ reg = <0x00 0x00000000 0x00 0x40000000>,
+ <0x00 0x40000000 0x00 0x40000000>,
+ <0x00 0x80000000 0x00 0x40000000>;
+ };
+};
diff --git a/arch/arm/boot/dts/bcm7445.dtsi b/arch/arm/boot/dts/bcm7445.dtsi
new file mode 100644
index 0000000..f9c9633
--- /dev/null
+++ b/arch/arm/boot/dts/bcm7445.dtsi
@@ -0,0 +1,107 @@
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+#include "skeleton.dtsi"
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Broadcom STB (bcm7445)";
+ compatible = "brcm,bcm7445", "brcm,brcmstb";
+ interrupt-parent = <&gic>;
+
+ chosen {
+ bootargs = "console=ttyS0,115200 earlyprintk";
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "brcm,brahma-b15";
+ device_type = "cpu";
+ reg = <0>;
+ };
+
+ cpu@1 {
+ compatible = "brcm,brahma-b15";
+ device_type = "cpu";
+ reg = <1>;
+ };
+
+ cpu@2 {
+ compatible = "brcm,brahma-b15";
+ device_type = "cpu";
+ reg = <2>;
+ };
+
+ cpu@3 {
+ compatible = "brcm,brahma-b15";
+ device_type = "cpu";
+ reg = <3>;
+ };
+ };
+
+ gic: interrupt-controller@ffd00000 {
+ compatible = "brcm,brahma-b15-gic", "arm,cortex-a15-gic";
+ reg = <0x00 0xffd01000 0x00 0x1000>,
+ <0x00 0xffd02000 0x00 0x2000>,
+ <0x00 0xffd04000 0x00 0x2000>,
+ <0x00 0xffd06000 0x00 0x2000>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <GIC_PPI 13 (GIC_CPU_MASK_RAW(15) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 14 (GIC_CPU_MASK_RAW(15) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 11 (GIC_CPU_MASK_RAW(15) | IRQ_TYPE_LEVEL_LOW)>,
+ <GIC_PPI 10 (GIC_CPU_MASK_RAW(15) | IRQ_TYPE_LEVEL_LOW)>;
+ };
+
+ rdb {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x00 0xf0000000 0x1000000>;
+
+ serial@406b00 {
+ compatible = "ns16550a";
+ reg = <0x406b00 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
+ clock-frequency = <0x4d3f640>;
+ };
+
+ sun_top_ctrl: syscon@404000 {
+ compatible = "brcm,bcm7445-sun-top-ctrl",
+ "syscon";
+ reg = <0x404000 0x51c>;
+ };
+
+ hif_cpubiuctrl: syscon@3e2400 {
+ compatible = "brcm,bcm7445-hif-cpubiuctrl",
+ "syscon";
+ reg = <0x3e2400 0x5b4>;
+ };
+
+ hif_continuation: syscon@452000 {
+ compatible = "brcm,bcm7445-hif-continuation",
+ "syscon";
+ reg = <0x452000 0x100>;
+ };
+ };
+
+ smpboot {
+ compatible = "brcm,brcmstb-smpboot";
+ syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
+ syscon-cont = <&hif_continuation>;
+ };
+
+ reboot {
+ compatible = "brcm,brcmstb-reboot";
+ syscon = <&sun_top_ctrl 0x304 0x308>;
+ };
+};
--
1.7.1
^ permalink raw reply related
* [PATCH v7 8/9] ARM: brcmstb: gic: add compatible string for Broadcom Brahma15
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino
In-Reply-To: <1393410552-21497-1-git-send-email-marc.ceeeee@gmail.com>
Document the Broadcom Brahma B15 GIC implementation as compatible
with the ARM GIC standard.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/arm/gic.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index bae0d87..d1f0b98 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -16,6 +16,7 @@ Main node required properties:
"arm,cortex-a9-gic"
"arm,cortex-a7-gic"
"arm,arm11mp-gic"
+ "brcm,brahma-b15-gic"
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
interrupt source. The type shall be a <u32> and the value shall be 3.
--
1.7.1
^ permalink raw reply related
* [PATCH v7 7/9] ARM: brcmstb: add misc. DT bindings for brcmstb
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino
In-Reply-To: <1393410552-21497-1-git-send-email-marc.ceeeee@gmail.com>
Document the bindings that the Broadcom STB platform needs
for proper bootup.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
.../devicetree/bindings/arm/brcm-brcmstb.txt | 95 ++++++++++++++++++++
1 files changed, 95 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
diff --git a/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
new file mode 100644
index 0000000..3c436cc
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
@@ -0,0 +1,95 @@
+ARM Broadcom STB platforms Device Tree Bindings
+-----------------------------------------------
+Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants)
+SoC shall have the following DT organization:
+
+Required root node properties:
+ - compatible: "brcm,bcm<chip_id>", "brcm,brcmstb"
+
+example:
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ model = "Broadcom STB (bcm7445)";
+ compatible = "brcm,bcm7445", "brcm,brcmstb";
+
+Further, syscon nodes that map platform-specific registers used for general
+system control is required:
+
+ - compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
+ - compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
+ - compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
+
+example:
+ rdb {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ ranges = <0 0x00 0xf0000000 0x1000000>;
+
+ sun_top_ctrl: syscon@404000 {
+ compatible = "brcm,bcm7445-sun-top-ctrl", "syscon";
+ reg = <0x404000 0x51c>;
+ };
+
+ hif_cpubiuctrl: syscon@3e2400 {
+ compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
+ reg = <0x3e2400 0x5b4>;
+ };
+
+ hif_continuation: syscon@452000 {
+ compatible = "brcm,bcm7445-hif-continuation", "syscon";
+ reg = <0x452000 0x100>;
+ };
+ };
+
+Lastly, nodes that allow for support of SMP initialization and reboot are
+required:
+
+smpboot
+-------
+Required properties:
+
+ - compatible
+ The string "brcm,brcmstb-smpboot".
+
+ - syscon-cpu
+ A phandle / integer array property which lets the BSP know the location
+ of certain CPU power-on registers.
+
+ The layout of the property is as follows:
+ o a phandle to the "hif_cpubiuctrl" syscon node
+ o offset to the base CPU power zone register
+ o offset to the base CPU reset register
+
+ - syscon-cont
+ A phandle pointing to the syscon node which describes the CPU boot
+ continuation registers.
+ o a phandle to the "hif_continuation" syscon node
+
+example:
+ smpboot {
+ compatible = "brcm,brcmstb-smpboot";
+ syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
+ syscon-cont = <&hif_continuation>;
+ };
+
+reboot
+-------
+Required properties
+
+ - compatible
+ The string property "brcm,brcmstb-reboot".
+
+ - syscon
+ A phandle / integer array that points to the syscon node which describes
+ the general system reset registers.
+ o a phandle to "sun_top_ctrl"
+ o offset to the "reset source enable" register
+ o offset to the "software master reset" register
+
+example:
+ reboot {
+ compatible = "brcm,brcmstb-reboot";
+ syscon = <&sun_top_ctrl 0x304 0x308>;
+ };
--
1.7.1
^ permalink raw reply related
* [PATCH v7 6/9] ARM: brcmstb: add CPU binding for Broadcom Brahma15
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino
In-Reply-To: <1393410552-21497-1-git-send-email-marc.ceeeee@gmail.com>
Add the Broadcom Brahma B15 CPU to the DT CPU binding list.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 9130435..0cd1e25 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -163,6 +163,7 @@ nodes to be present and contain the properties described below.
"arm,cortex-r4"
"arm,cortex-r5"
"arm,cortex-r7"
+ "brcm,brahma-b15"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
--
1.7.1
^ permalink raw reply related
* [PATCH v7 5/9] ARM: Enable erratum 798181 for Broadcom Brahma-B15
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Gregory Fong, Rob Herring, Will Deacon
In-Reply-To: <1393410552-21497-1-git-send-email-marc.ceeeee@gmail.com>
From: Gregory Fong <gregory.0xf0@gmail.com>
Broadcom Brahma-B15 (r0p0..r0p2) is also affected by Cortex-A15
erratum 798181, so enable the workaround for Brahma-B15.
Signed-off-by: Gregory Fong <gregory.0xf0@gmail.com>
Acked-by: Marc Carino <marc.ceeeee@gmail.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Will Deacon <will.deacon@arm.com>
---
arch/arm/kernel/smp_tlb.c | 20 ++++++++++++--------
1 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kernel/smp_tlb.c b/arch/arm/kernel/smp_tlb.c
index 95d0636..5518e3f 100644
--- a/arch/arm/kernel/smp_tlb.c
+++ b/arch/arm/kernel/smp_tlb.c
@@ -92,15 +92,19 @@ void erratum_a15_798181_init(void)
unsigned int midr = read_cpuid_id();
unsigned int revidr = read_cpuid(CPUID_REVIDR);
- /* Cortex-A15 r0p0..r3p2 w/o ECO fix affected */
- if ((midr & 0xff0ffff0) != 0x410fc0f0 || midr > 0x413fc0f2 ||
- (revidr & 0x210) == 0x210) {
- return;
- }
- if (revidr & 0x10)
- erratum_a15_798181_handler = erratum_a15_798181_partial;
- else
+ /* Brahma-B15 r0p0..(not yet fixed) affected
+ * Cortex-A15 r0p0..r3p2 w/o ECO fix affected */
+ if ((midr & 0xff0ffff0) == 0x420f00f0)
erratum_a15_798181_handler = erratum_a15_798181_broadcast;
+ else if ((midr & 0xff0ffff0) == 0x410fc0f0 && midr <= 0x413fc0f2 &&
+ (revidr & 0x210) != 0x210) {
+ if (revidr & 0x10)
+ erratum_a15_798181_handler =
+ erratum_a15_798181_partial;
+ else
+ erratum_a15_798181_handler =
+ erratum_a15_798181_broadcast;
+ }
}
#endif
--
1.7.1
^ permalink raw reply related
* [PATCH v7 4/9] ARM: do CPU-specific init for Broadcom Brahma15 cores
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino, Russell King
In-Reply-To: <1393410552-21497-1-git-send-email-marc.ceeeee@gmail.com>
Perform any CPU-specific initialization required on the
Broadcom Brahma-15 core.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/mm/proc-v7.S | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index 74f6033..e3da338 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -193,6 +193,7 @@ __v7_cr7mp_setup:
b 1f
__v7_ca7mp_setup:
__v7_ca15mp_setup:
+__v7_b15mp_setup:
mov r10, #0
1:
#ifdef CONFIG_SMP
@@ -494,6 +495,16 @@ __v7_ca15mp_proc_info:
.size __v7_ca15mp_proc_info, . - __v7_ca15mp_proc_info
/*
+ * Broadcom Corporation Brahma-B15 processor.
+ */
+ .type __v7_b15mp_proc_info, #object
+__v7_b15mp_proc_info:
+ .long 0x420f00f0
+ .long 0xff0ffff0
+ __v7_proc __v7_b15mp_setup, hwcaps = HWCAP_IDIV
+ .size __v7_b15mp_proc_info, . - __v7_b15mp_proc_info
+
+ /*
* Qualcomm Inc. Krait processors.
*/
.type __krait_proc_info, #object
--
1.7.1
^ permalink raw reply related
* [PATCH v7 3/9] ARM: brcmstb: add debug UART for earlyprintk support
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: devicetree, Florian Fainelli, Russell King, linux-kernel,
Marc Carino, Matt Porter, linux-arm-kernel
In-Reply-To: <1393410552-21497-1-git-send-email-marc.ceeeee@gmail.com>
Add the UART definitions needed to support earlyprintk on brcmstb machines.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/Kconfig.debug | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 0531da8..5d7f76b 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -125,6 +125,17 @@ choice
Say Y here if you want kernel low-level debugging support
on Marvell Berlin SoC based platforms.
+ config DEBUG_BRCMSTB_UART
+ bool "Use BRCMSTB UART for low-level debug"
+ depends on ARCH_BRCMSTB
+ select DEBUG_UART_8250
+ help
+ Say Y here if you want the debug print routines to direct
+ their output to the first serial port on these devices.
+
+ If you have a Broadcom STB chip and would like early print
+ messages to appear over the UART, select this option.
+
config DEBUG_CLPS711X_UART1
bool "Kernel low-level debugging messages via UART1"
depends on ARCH_CLPS711X
@@ -1049,6 +1060,7 @@ config DEBUG_UART_PHYS
default 0xd4018000 if DEBUG_MMP_UART3
default 0xe0000000 if ARCH_SPEAR13XX
default 0xf0000be0 if ARCH_EBSA110
+ default 0xf0406b00 if DEBUG_BRCMSTB_UART
default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE
default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \
ARCH_ORION5X
@@ -1083,6 +1095,7 @@ config DEBUG_UART_VIRT
default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1
default 0xfb009000 if DEBUG_REALVIEW_STD_PORT
default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT
+ default 0xfc406b00 if DEBUG_BRCMSTB_UART
default 0xfd000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX
default 0xfd000000 if ARCH_SPEAR13XX
default 0xfd012000 if ARCH_MV78XX0
@@ -1136,7 +1149,7 @@ config DEBUG_UART_8250_WORD
ARCH_KEYSTONE || \
DEBUG_DAVINCI_DMx_UART0 || DEBUG_DAVINCI_DA8XX_UART1 || \
DEBUG_DAVINCI_DA8XX_UART2 || DEBUG_DAVINCI_TNETV107X_UART1 || \
- DEBUG_BCM_KONA_UART
+ DEBUG_BCM_KONA_UART || DEBUG_BRCMSTB_UART
config DEBUG_UART_8250_FLOW_CONTROL
bool "Enable flow control for 8250 UART"
--
1.7.1
^ permalink raw reply related
* [PATCH v7 2/9] power: reset: Add reboot driver for brcmstb
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino, Dmitry Eremin-Solenikov,
David Woodhouse
In-Reply-To: <1393410552-21497-1-git-send-email-marc.ceeeee@gmail.com>
Add support for reboot functionality on boards with ARM-based
Broadcom STB chipsets.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: David Woodhouse <dwmw2@infradead.org>
---
arch/arm/mach-bcm/Kconfig | 1 +
drivers/power/reset/Kconfig | 10 +++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/brcmstb-reboot.c | 120 ++++++++++++++++++++++++++++++++++
4 files changed, 132 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/reset/brcmstb-reboot.c
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index f85e7bc..d8f6d7a 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -39,6 +39,7 @@ config ARCH_BRCMSTB
select MIGHT_HAVE_PCI
select HAVE_SMP
select HAVE_ARM_ARCH_TIMER
+ select POWER_RESET_BRCMSTB
help
Say Y if you intend to run the kernel on a Broadcom ARM-based STB
chipset.
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index 6d452a7..c886505 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -12,6 +12,16 @@ config POWER_RESET_AS3722
help
This driver supports turning off board via a ams AS3722 power-off.
+config POWER_RESET_BRCMSTB
+ bool "Broadcom STB reset driver"
+ depends on POWER_RESET && ARCH_BRCMSTB
+ help
+ This driver provides restart support for ARM-based Broadcom STB
+ boards.
+
+ Say Y here if you have an ARM-based Broadcom STB board and you wish
+ to have restart support.
+
config POWER_RESET_GPIO
bool "GPIO power-off driver"
depends on OF_GPIO && POWER_RESET
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a5b4a77..72bb94f 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
obj-$(CONFIG_POWER_RESET_RESTART) += restart-poweroff.o
obj-$(CONFIG_POWER_RESET_VEXPRESS) += vexpress-poweroff.o
obj-$(CONFIG_POWER_RESET_XGENE) += xgene-reboot.o
+obj-$(CONFIG_POWER_RESET_BRCMSTB) += brcmstb-reboot.o
diff --git a/drivers/power/reset/brcmstb-reboot.c b/drivers/power/reset/brcmstb-reboot.c
new file mode 100644
index 0000000..3f23692
--- /dev/null
+++ b/drivers/power/reset/brcmstb-reboot.c
@@ -0,0 +1,120 @@
+/*
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/printk.h>
+#include <linux/reboot.h>
+#include <linux/regmap.h>
+#include <linux/smp.h>
+#include <linux/mfd/syscon.h>
+
+#include <asm/system_misc.h>
+
+#define RESET_SOURCE_ENABLE_REG 1
+#define SW_MASTER_RESET_REG 2
+
+static struct regmap *regmap;
+static u32 rst_src_en;
+static u32 sw_mstr_rst;
+
+static void brcmstb_reboot(enum reboot_mode mode, const char *cmd)
+{
+ int rc;
+ u32 tmp;
+
+ rc = regmap_write(regmap, rst_src_en, 1);
+ if (rc) {
+ pr_err("failed to write rst_src_en (%d)\n", rc);
+ return;
+ }
+
+ rc = regmap_read(regmap, rst_src_en, &tmp);
+ if (rc) {
+ pr_err("failed to read rst_src_en (%d)\n", rc);
+ return;
+ }
+
+ rc = regmap_write(regmap, sw_mstr_rst, 1);
+ if (rc) {
+ pr_err("failed to write sw_mstr_rst (%d)\n", rc);
+ return;
+ }
+
+ rc = regmap_read(regmap, sw_mstr_rst, &tmp);
+ if (rc) {
+ pr_err("failed to read sw_mstr_rst (%d)\n", rc);
+ return;
+ }
+
+ while (1)
+ ;
+}
+
+static int brcmstb_reboot_probe(struct platform_device *pdev)
+{
+ int rc;
+ struct device_node *np = pdev->dev.of_node;
+
+ regmap = syscon_regmap_lookup_by_phandle(np, "syscon");
+ if (IS_ERR(regmap)) {
+ pr_err("failed to get syscon phandle\n");
+ return -EINVAL;
+ }
+
+ rc = of_property_read_u32_index(np, "syscon", RESET_SOURCE_ENABLE_REG,
+ &rst_src_en);
+ if (rc) {
+ pr_err("can't get rst_src_en offset (%d)\n", rc);
+ return -EINVAL;
+ }
+
+ rc = of_property_read_u32_index(np, "syscon", SW_MASTER_RESET_REG,
+ &sw_mstr_rst);
+ if (rc) {
+ pr_err("can't get sw_mstr_rst offset (%d)\n", rc);
+ return -EINVAL;
+ }
+
+ arm_pm_restart = brcmstb_reboot;
+
+ return 0;
+}
+
+static const struct of_device_id of_match[] = {
+ { .compatible = "brcm,brcmstb-reboot", },
+ {},
+};
+
+static struct platform_driver brcmstb_reboot_driver = {
+ .probe = brcmstb_reboot_probe,
+ .driver = {
+ .name = "brcmstb-reboot",
+ .owner = THIS_MODULE,
+ .of_match_table = of_match,
+ },
+};
+
+static int __init brcmstb_reboot_init(void)
+{
+ return platform_driver_probe(&brcmstb_reboot_driver,
+ brcmstb_reboot_probe);
+}
+subsys_initcall(brcmstb_reboot_init);
--
1.7.1
^ permalink raw reply related
* [PATCH v7 1/9] ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King, linux-arm-kernel,
linux-kernel, devicetree, Marc Carino
In-Reply-To: <1393410552-21497-1-git-send-email-marc.ceeeee@gmail.com>
The BCM7xxx series of Broadcom SoCs are used primarily in set-top boxes.
This patch adds machine support for the ARM-based Broadcom SoCs.
Signed-off-by: Marc Carino <marc.ceeeee@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/mach-bcm/Kconfig | 14 ++
arch/arm/mach-bcm/Makefile | 4 +
arch/arm/mach-bcm/brcmstb.c | 104 ++++++++++++
arch/arm/mach-bcm/brcmstb.h | 38 +++++
arch/arm/mach-bcm/headsmp-brcmstb.S | 33 ++++
arch/arm/mach-bcm/hotplug-brcmstb.c | 311 +++++++++++++++++++++++++++++++++++
7 files changed, 505 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-bcm/brcmstb.c
create mode 100644 arch/arm/mach-bcm/brcmstb.h
create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
create mode 100644 arch/arm/mach-bcm/hotplug-brcmstb.c
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index ee69829..650d458 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -12,6 +12,7 @@ CONFIG_MACH_ARMADA_370=y
CONFIG_MACH_ARMADA_XP=y
CONFIG_ARCH_BCM=y
CONFIG_ARCH_BCM_MOBILE=y
+CONFIG_ARCH_BRCMSTB=y
CONFIG_ARCH_BERLIN=y
CONFIG_MACH_BERLIN_BG2=y
CONFIG_MACH_BERLIN_BG2CD=y
diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
index b1aa6a9..f85e7bc 100644
--- a/arch/arm/mach-bcm/Kconfig
+++ b/arch/arm/mach-bcm/Kconfig
@@ -32,6 +32,20 @@ config ARCH_BCM_MOBILE
BCM11130, BCM11140, BCM11351, BCM28145 and
BCM28155 variants.
+config ARCH_BRCMSTB
+ bool "Broadcom BCM7XXX based boards" if ARCH_MULTI_V7
+ depends on MMU
+ select ARM_GIC
+ select MIGHT_HAVE_PCI
+ select HAVE_SMP
+ select HAVE_ARM_ARCH_TIMER
+ help
+ Say Y if you intend to run the kernel on a Broadcom ARM-based STB
+ chipset.
+
+ This enables support for Broadcom ARM-based set-top box chipsets,
+ including the 7445 family of chips.
+
endmenu
endif
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index c2ccd5a..b744a12 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -13,3 +13,7 @@
obj-$(CONFIG_ARCH_BCM_MOBILE) := board_bcm281xx.o bcm_kona_smc.o bcm_kona_smc_asm.o kona.o
plus_sec := $(call as-instr,.arch_extension sec,+sec)
AFLAGS_bcm_kona_smc_asm.o :=-Wa,-march=armv7-a$(plus_sec)
+
+obj-$(CONFIG_ARCH_BRCMSTB) := brcmstb.o
+obj-$(CONFIG_SMP) += headsmp-brcmstb.o
+obj-$(CONFIG_HOTPLUG_CPU) += hotplug-brcmstb.o
diff --git a/arch/arm/mach-bcm/brcmstb.c b/arch/arm/mach-bcm/brcmstb.c
new file mode 100644
index 0000000..71387a8
--- /dev/null
+++ b/arch/arm/mach-bcm/brcmstb.c
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/clk-provider.h>
+#include <linux/console.h>
+#include <linux/clocksource.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/platform_device.h>
+#include <linux/printk.h>
+#include <linux/smp.h>
+
+#include <asm/cacheflush.h>
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/map.h>
+#include <asm/mach/time.h>
+
+#include "brcmstb.h"
+
+/***********************************************************************
+ * STB CPU (main application processor)
+ ***********************************************************************/
+
+static const char *brcmstb_match[] __initconst = {
+ "brcm,bcm7445",
+ "brcm,brcmstb",
+ NULL
+};
+
+/***********************************************************************
+ * SMP boot
+ ***********************************************************************/
+
+#ifdef CONFIG_SMP
+static DEFINE_SPINLOCK(boot_lock);
+
+static void brcmstb_secondary_init(unsigned int cpu)
+{
+ /*
+ * Synchronise with the boot thread.
+ */
+ spin_lock(&boot_lock);
+ spin_unlock(&boot_lock);
+}
+
+static int brcmstb_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ /*
+ * set synchronisation state between this boot processor
+ * and the secondary one
+ */
+ spin_lock(&boot_lock);
+
+ /* Bring up power to the core if necessary */
+ if (brcmstb_cpu_get_power_state(cpu) == 0)
+ brcmstb_cpu_power_on(cpu);
+
+ brcmstb_cpu_boot(cpu);
+
+ /*
+ * now the secondary core is starting up let it run its
+ * calibrations, then wait for it to finish
+ */
+ spin_unlock(&boot_lock);
+
+ return 0;
+}
+
+struct smp_operations brcmstb_smp_ops __initdata = {
+ .smp_prepare_cpus = brcmstb_cpu_ctrl_setup,
+ .smp_secondary_init = brcmstb_secondary_init,
+ .smp_boot_secondary = brcmstb_boot_secondary,
+#ifdef CONFIG_HOTPLUG_CPU
+ .cpu_kill = brcmstb_cpu_kill,
+ .cpu_die = brcmstb_cpu_die,
+#endif
+};
+#endif
+
+DT_MACHINE_START(BRCMSTB, "Broadcom STB (Flattened Device Tree)")
+ .dt_compat = brcmstb_match,
+#ifdef CONFIG_SMP
+ .smp = smp_ops(brcmstb_smp_ops),
+#endif
+MACHINE_END
diff --git a/arch/arm/mach-bcm/brcmstb.h b/arch/arm/mach-bcm/brcmstb.h
new file mode 100644
index 0000000..e49bde6
--- /dev/null
+++ b/arch/arm/mach-bcm/brcmstb.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef __BRCMSTB_H__
+#define __BRCMSTB_H__
+
+#if !defined(__ASSEMBLY__)
+#include <linux/smp.h>
+#endif
+
+#if !defined(__ASSEMBLY__)
+extern void brcmstb_secondary_startup(void);
+extern void brcmstb_cpu_boot(unsigned int cpu);
+extern void brcmstb_cpu_power_on(unsigned int cpu);
+extern int brcmstb_cpu_get_power_state(unsigned int cpu);
+extern struct smp_operations brcmstb_smp_ops;
+#if defined(CONFIG_HOTPLUG_CPU)
+extern void brcmstb_cpu_die(unsigned int cpu);
+extern int brcmstb_cpu_kill(unsigned int cpu);
+void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus);
+#else
+static inline void brcmstb_cpu_die(unsigned int cpu) {}
+static inline int brcmstb_cpu_kill(unsigned int cpu) {}
+static inline void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus) {}
+#endif
+#endif
+
+#endif /* __BRCMSTB_H__ */
diff --git a/arch/arm/mach-bcm/headsmp-brcmstb.S b/arch/arm/mach-bcm/headsmp-brcmstb.S
new file mode 100644
index 0000000..89134c7
--- /dev/null
+++ b/arch/arm/mach-bcm/headsmp-brcmstb.S
@@ -0,0 +1,33 @@
+/*
+ * SMP boot code for secondary CPUs
+ * Based on arch/arm/mach-tegra/headsmp.S
+ *
+ * Copyright (C) 2010 NVIDIA, Inc.
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <asm/assembler.h>
+#include <linux/linkage.h>
+#include <linux/init.h>
+
+ .section ".text.head", "ax"
+
+ENTRY(brcmstb_secondary_startup)
+ /*
+ * Ensure CPU is in a sane state by disabling all IRQs and switching
+ * into SVC mode.
+ */
+ setmode PSR_I_BIT | PSR_F_BIT | SVC_MODE, r0
+
+ bl v7_invalidate_l1
+ b secondary_startup
+ENDPROC(brcmstb_secondary_startup)
diff --git a/arch/arm/mach-bcm/hotplug-brcmstb.c b/arch/arm/mach-bcm/hotplug-brcmstb.c
new file mode 100644
index 0000000..21431a6
--- /dev/null
+++ b/arch/arm/mach-bcm/hotplug-brcmstb.c
@@ -0,0 +1,311 @@
+/*
+ * Broadcom STB CPU hotplug support for ARM
+ *
+ * Copyright (C) 2013 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/errno.h>
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/jiffies.h>
+#include <linux/of_address.h>
+#include <linux/of_irq.h>
+#include <linux/of_platform.h>
+#include <linux/printk.h>
+#include <linux/regmap.h>
+#include <linux/smp.h>
+#include <linux/mfd/syscon.h>
+
+#include <asm/cacheflush.h>
+#include <asm/cp15.h>
+#include <asm/mach-types.h>
+#include <asm/smp_plat.h>
+
+#include "brcmstb.h"
+
+enum {
+ ZONE_MAN_CLKEN_MASK = BIT(0),
+ ZONE_MAN_RESET_CNTL_MASK = BIT(1),
+ ZONE_MAN_MEM_PWR_MASK = BIT(4),
+ ZONE_RESERVED_1_MASK = BIT(5),
+ ZONE_MAN_ISO_CNTL_MASK = BIT(6),
+ ZONE_MANUAL_CONTROL_MASK = BIT(7),
+ ZONE_PWR_DN_REQ_MASK = BIT(9),
+ ZONE_PWR_UP_REQ_MASK = BIT(10),
+ ZONE_BLK_RST_ASSERT_MASK = BIT(12),
+ ZONE_PWR_OFF_STATE_MASK = BIT(25),
+ ZONE_PWR_ON_STATE_MASK = BIT(26),
+ ZONE_DPG_PWR_STATE_MASK = BIT(28),
+ ZONE_MEM_PWR_STATE_MASK = BIT(29),
+ ZONE_RESET_STATE_MASK = BIT(31),
+ CPU0_PWR_ZONE_CTRL_REG = 1,
+ CPU_RESET_CONFIG_REG = 2,
+};
+
+static void __iomem *cpubiuctrl_block;
+static void __iomem *hif_cont_block;
+static u32 cpu0_pwr_zone_ctrl_reg;
+static u32 cpu_rst_cfg_reg;
+static u32 hif_cont_reg;
+DEFINE_PER_CPU_ALIGNED(int, per_cpu_sw_state);
+
+static int per_cpu_sw_state_rd(u32 cpu)
+{
+ sync_cache_r(SHIFT_PERCPU_PTR(&per_cpu_sw_state, per_cpu_offset(cpu)));
+ return per_cpu(per_cpu_sw_state, cpu);
+}
+
+static void per_cpu_sw_state_wr(u32 cpu, int val)
+{
+ per_cpu(per_cpu_sw_state, cpu) = val;
+ dmb();
+ sync_cache_w(SHIFT_PERCPU_PTR(&per_cpu_sw_state, per_cpu_offset(cpu)));
+ dsb_sev();
+}
+
+static void __iomem *pwr_ctrl_get_base(u32 cpu)
+{
+ void __iomem *base = cpubiuctrl_block + cpu0_pwr_zone_ctrl_reg;
+ base += (cpu_logical_map(cpu) * 4);
+ return base;
+}
+
+static u32 pwr_ctrl_rd(u32 cpu)
+{
+ void __iomem *base = pwr_ctrl_get_base(cpu);
+ return readl_relaxed(base);
+}
+
+static void pwr_ctrl_wr(u32 cpu, u32 val)
+{
+ void __iomem *base = pwr_ctrl_get_base(cpu);
+ writel(val, base);
+}
+
+static void cpu_rst_cfg_set(u32 cpu, int set)
+{
+ u32 val;
+ val = readl_relaxed(cpubiuctrl_block + cpu_rst_cfg_reg);
+ if (set)
+ val |= BIT(cpu_logical_map(cpu));
+ else
+ val &= ~BIT(cpu_logical_map(cpu));
+ writel_relaxed(val, cpubiuctrl_block + cpu_rst_cfg_reg);
+}
+
+static void cpu_set_boot_addr(u32 cpu, unsigned long boot_addr)
+{
+ const int reg_ofs = cpu_logical_map(cpu) * 8;
+ writel_relaxed(0, hif_cont_block + hif_cont_reg + reg_ofs);
+ writel_relaxed(boot_addr, hif_cont_block + hif_cont_reg + 4 + reg_ofs);
+}
+
+void brcmstb_cpu_boot(u32 cpu)
+{
+ pr_info("SMP: Booting CPU%d...\n", cpu);
+
+ /*
+ * set the reset vector to point to the secondary_startup
+ * routine
+ */
+ cpu_set_boot_addr(cpu, virt_to_phys(brcmstb_secondary_startup));
+
+ /* unhalt the cpu */
+ cpu_rst_cfg_set(cpu, 0);
+}
+
+void brcmstb_cpu_power_on(u32 cpu)
+{
+ /*
+ * The secondary cores power was cut, so we must go through
+ * power-on initialization.
+ */
+ u32 tmp;
+
+ pr_info("SMP: Powering up CPU%d...\n", cpu);
+
+ /* Request zone power up */
+ pwr_ctrl_wr(cpu, ZONE_PWR_UP_REQ_MASK);
+
+ /* Wait for the power up FSM to complete */
+ do {
+ tmp = pwr_ctrl_rd(cpu);
+ } while (!(tmp & ZONE_PWR_ON_STATE_MASK));
+
+ per_cpu_sw_state_wr(cpu, 1);
+}
+
+int brcmstb_cpu_get_power_state(u32 cpu)
+{
+ int tmp = pwr_ctrl_rd(cpu);
+ return (tmp & ZONE_RESET_STATE_MASK) ? 0 : 1;
+}
+
+void __ref brcmstb_cpu_die(u32 cpu)
+{
+ v7_exit_coherency_flush(all);
+
+ /* Prevent all interrupts from reaching this CPU. */
+ arch_local_irq_disable();
+
+ /*
+ * Final full barrier to ensure everything before this instruction has
+ * quiesced.
+ */
+ isb();
+ dsb();
+
+ per_cpu_sw_state_wr(cpu, 0);
+
+ /* Sit and wait to die */
+ wfi();
+
+ /* We should never get here... */
+ panic("Spurious interrupt on CPU %d received!\n", cpu);
+}
+
+int brcmstb_cpu_kill(u32 cpu)
+{
+ u32 tmp;
+
+ pr_info("SMP: Powering down CPU%d...\n", cpu);
+
+ while (per_cpu_sw_state_rd(cpu))
+ ;
+
+ /* Program zone reset */
+ pwr_ctrl_wr(cpu, ZONE_RESET_STATE_MASK | ZONE_BLK_RST_ASSERT_MASK |
+ ZONE_PWR_DN_REQ_MASK);
+
+ /* Verify zone reset */
+ tmp = pwr_ctrl_rd(cpu);
+ if (!(tmp & ZONE_RESET_STATE_MASK))
+ pr_err("%s: Zone reset bit for CPU %d not asserted!\n",
+ __func__, cpu);
+
+ /* Wait for power down */
+ do {
+ tmp = pwr_ctrl_rd(cpu);
+ } while (!(tmp & ZONE_PWR_OFF_STATE_MASK));
+
+ /* Settle-time from Broadcom-internal DVT reference code */
+ udelay(7);
+
+ /* Assert reset on the CPU */
+ cpu_rst_cfg_set(cpu, 1);
+
+ return 1;
+}
+
+static int __init setup_hifcpubiuctrl_regs(struct device_node *np)
+{
+ int rc = 0;
+ char *name;
+ struct device_node *syscon_np = NULL;
+
+ name = "syscon-cpu";
+
+ syscon_np = of_parse_phandle(np, name, 0);
+ if (!syscon_np) {
+ pr_err("can't find phandle %s\n", name);
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ cpubiuctrl_block = of_iomap(syscon_np, 0);
+ if (!cpubiuctrl_block) {
+ pr_err("iomap failed for cpubiuctrl_block\n");
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ rc = of_property_read_u32_index(np, name, CPU0_PWR_ZONE_CTRL_REG,
+ &cpu0_pwr_zone_ctrl_reg);
+ if (rc) {
+ pr_err("failed to read 1st entry from %s property (%d)\n", name,
+ rc);
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ rc = of_property_read_u32_index(np, name, CPU_RESET_CONFIG_REG,
+ &cpu_rst_cfg_reg);
+ if (rc) {
+ pr_err("failed to read 2nd entry from %s property (%d)\n", name,
+ rc);
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+cleanup:
+ if (syscon_np)
+ of_node_put(syscon_np);
+
+ return rc;
+}
+
+static int __init setup_hifcont_regs(struct device_node *np)
+{
+ int rc = 0;
+ char *name;
+ struct device_node *syscon_np = NULL;
+
+ name = "syscon-cont";
+
+ syscon_np = of_parse_phandle(np, name, 0);
+ if (!syscon_np) {
+ pr_err("can't find phandle %s\n", name);
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ hif_cont_block = of_iomap(syscon_np, 0);
+ if (!hif_cont_block) {
+ pr_err("iomap failed for hif_cont_block\n");
+ rc = -EINVAL;
+ goto cleanup;
+ }
+
+ /* offset is at top of hif_cont_block */
+ hif_cont_reg = 0;
+
+cleanup:
+ if (syscon_np)
+ of_node_put(syscon_np);
+
+ return rc;
+}
+
+void __init brcmstb_cpu_ctrl_setup(unsigned int max_cpus)
+{
+ int rc;
+ struct device_node *np;
+ char *name;
+
+ name = "brcm,brcmstb-smpboot";
+ np = of_find_compatible_node(NULL, NULL, name);
+ if (!np) {
+ pr_err("can't find compatible node %s\n", name);
+ return;
+ }
+
+ rc = setup_hifcpubiuctrl_regs(np);
+ if (rc)
+ return;
+
+ rc = setup_hifcont_regs(np);
+ if (rc)
+ return;
+}
+
--
1.7.1
^ permalink raw reply related
* [PATCH v7 0/9] ARM: brcmstb: Add Broadcom STB SoC support
From: Marc Carino @ 2014-02-26 10:29 UTC (permalink / raw)
To: Christian Daudt, Arnd Bergmann, Olof Johansson
Cc: Florian Fainelli, Matt Porter, Russell King,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Marc Carino
This patchset contains the board support package for the
Broadcom BCM7445 ARM-based SoC [1]. These changes contain a
minimal set of code needed for a BCM7445-based board to boot
the Linux kernel.
These changes heavily leverage the OF/devicetree framework. The
machine is also built into the multi-platform ARMv7 image.
v7:
- rebase to v3.14-rc4
- detect and apply ARM erratum 798181 to Brahma15 CPUs
- split-up bcm7445.dts into a common dtsi and board-specific dts
v6 (https://lkml.org/lkml/2014/2/3/493):
- rebased to v3.14-rc1
- utilize common APIs for handling CPU power-down
- drop deprecated __cpuinit attributes
v5 (https://lkml.org/lkml/2014/1/21/640):
- rebased to v3.13 tag
- make UART DT node a child of 'rdb' node
- fix ordering of debug UART entries
v4 (https://lkml.org/lkml/2014/1/17/455):
- make a reboot driver and put it in the drivers folder
- rework DT bindings to leverage 'syscon'
- rework BSP code to use 'syscon' for all register mappings
- misc. tweaks per suggestions from v3
v3 (https://lkml.org/lkml/2014/1/14/696):
- rebased to v3.13-rc8
- switched to using 'multi_v7_defconfig'
- eliminated dependence on compile-time peripheral register access
- moved DT node iomap out from 'init_early'
- misc. minor cleanups from mailing-list discussion for v2
v2 (https://lkml.org/lkml/2013/11/26/570):
- rebased to v3.13-rc1
- moved implementation to 'mach-bcm' folder
- added CPU init for B16RM
v1:
- initial submission
[1] http://www.broadcom.com/products/Cable/Cable-Set-Top-Box-Solutions/BCM7445
Gregory Fong (1):
ARM: Enable erratum 798181 for Broadcom Brahma-B15
Marc Carino (8):
ARM: brcmstb: add infrastructure for ARM-based Broadcom STB SoCs
power: reset: Add reboot driver for brcmstb
ARM: brcmstb: add debug UART for earlyprintk support
ARM: do CPU-specific init for Broadcom Brahma15 cores
ARM: brcmstb: add CPU binding for Broadcom Brahma15
ARM: brcmstb: add misc. DT bindings for brcmstb
ARM: brcmstb: gic: add compatible string for Broadcom Brahma15
ARM: brcmstb: dts: add a reference DTS for Broadcom 7445
.../devicetree/bindings/arm/brcm-brcmstb.txt | 95 ++++++
Documentation/devicetree/bindings/arm/cpus.txt | 1 +
Documentation/devicetree/bindings/arm/gic.txt | 1 +
arch/arm/Kconfig.debug | 15 +-
arch/arm/boot/dts/bcm7445-bcm97445svmb.dts | 14 +
arch/arm/boot/dts/bcm7445.dtsi | 107 +++++++
arch/arm/configs/multi_v7_defconfig | 1 +
arch/arm/kernel/smp_tlb.c | 20 +-
arch/arm/mach-bcm/Kconfig | 15 +
arch/arm/mach-bcm/Makefile | 4 +
arch/arm/mach-bcm/brcmstb.c | 104 +++++++
arch/arm/mach-bcm/brcmstb.h | 38 +++
arch/arm/mach-bcm/headsmp-brcmstb.S | 33 ++
arch/arm/mach-bcm/hotplug-brcmstb.c | 311 ++++++++++++++++++++
arch/arm/mm/proc-v7.S | 11 +
drivers/power/reset/Kconfig | 10 +
drivers/power/reset/Makefile | 1 +
drivers/power/reset/brcmstb-reboot.c | 120 ++++++++
18 files changed, 892 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
create mode 100644 arch/arm/boot/dts/bcm7445-bcm97445svmb.dts
create mode 100644 arch/arm/boot/dts/bcm7445.dtsi
create mode 100644 arch/arm/mach-bcm/brcmstb.c
create mode 100644 arch/arm/mach-bcm/brcmstb.h
create mode 100644 arch/arm/mach-bcm/headsmp-brcmstb.S
create mode 100644 arch/arm/mach-bcm/hotplug-brcmstb.c
create mode 100644 drivers/power/reset/brcmstb-reboot.c
--
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 v2 0/3] power_supply: modelgauge_battery: Add Maxim ModelGauge ICs gauge
From: Vladimir Barinov @ 2014-02-26 10:21 UTC (permalink / raw)
To: dbaryshkov
Cc: anton@enomsg.org, dwmw2, linux-kernel, devicetree, mk7.kang,
k.kozlowski, mark.rutland
In-Reply-To: <1391293385-27539-1-git-send-email-vladimir.barinov@cogentembedded.com>
Hello Dmitry,
In accordance to this change you've taken the responsibility for power
supply maintainership.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/MAINTAINERS?id=573189354b7c97cd2256b87cf083ee435584594e
It passed almost month and no answer from you.
Does it make sense to apply this patch series?
Regards,
Vladimir
On 02/02/2014 02:23 AM, Vladimir Barinov wrote:
> Hello.
>
> This adds the folowing:
> - Maxim ModelGauge ICs gauge driver for MAX17040/41/43/44/48/49/58/59 chips
> - Document DT bindings
> - Remove superseded Maxim MAX17040 gauge driver
>
> Vladimir Barinov (3):
> [1/3] power_supply: modelgauge_battery: Maxim ModelGauge ICs gauge
> [2/3] dt: Document ModelGauge gauge bindings
> [3/3] power_supply: modelgauge_battery: Remove Maxim MAX17040 gauge
>
> ---
> This patchset is against the 'kernel/git/torvalds/linux.git' repo.
>
> Changes since v1:
> - switched to REGMAP API
> - replaced request_threaded_irq with devm_request_threaded_irq
> - replaced cancel_delayed_work with _sync version
> - moved "empty_alert_threshold, soc_change_alert, hibernate_threshold,
> active_threshold, undervoltage, overvoltage, resetvoltage" parameters
> out from platform_data and DT
> - removed unused parameters "empty_adjustment, empty_adjustment"
> - added return value checks for of_property_read_XX functions
> - removed irrelevant bindings
> - fixed dt properties naming in documentation
> - added binding size description in documentation
> - removed satelite include file include/linux/max17040_battery.h
>
> Documentation/devicetree/bindings/power_supply/modelgauge_battery.txt | 61
> drivers/power/Kconfig | 17
> drivers/power/Makefile | 2
> drivers/power/max17040_battery.c | 297 ---
> drivers/power/modelgauge_battery.c | 838 ++++++++++
> include/linux/max17040_battery.h | 19
> include/linux/platform_data/battery-modelgauge.h | 31
> 7 files changed, 940 insertions(+), 325 deletions(-)
^ permalink raw reply
* Re: [PATCHv3 1/2] net: stmmac: Add SOCFPGA glue driver
From: Giuseppe CAVALLARO @ 2014-02-26 9:44 UTC (permalink / raw)
To: Dinh Nguyen, David Miller, dinguyen
Cc: netdev, devicetree, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, vbridgers2013
In-Reply-To: <52FC4B0A.4010406@gmail.com>
On 2/13/2014 5:33 AM, Dinh Nguyen wrote:
>
> On 2/12/14 6:35 PM, David Miller wrote:
>> From: <dinguyen@altera.com>
>> Date: Mon, 10 Feb 2014 13:48:16 -0600
>>
>>> From: Dinh Nguyen <dinguyen@altera.com>
>>>
>>> Like the STi series SOCs, Altera's SOCFPGA also needs a glue layer on top of the
>>> Synopsys gmac IP.
>>>
>>> This patch adds the platform driver for the glue layer which configures the IP
>>> before the generic STMMAC driver takes over.
>>>
>>> Signed-off-by: Dinh Nguyen <dinguyen@altera.com>
>>> Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Cc: Pawel Moll <pawel.moll@arm.com>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
>>> Cc: Kumar Gala <galak@codeaurora.org>
>>> Cc: Vince Bridgers <vbridgers2013@gmail.com>
>>> ---
>>> v3: Remove stray empty line at end of dwmac-socfpga.c.
>>> v2: Use the dwmac-sti as an example for a glue layer and split patch up
>>> to have dts as a separate patch. Also cc dts maintainers since there is
>>> a new binding.
>> The second patch for the DTS update doesn't apply cleanly at all to
>> mainline.
> Yes, I'm planning to take the DTS bindings patch through arm-soc/next-dt
> tree, so that is where patch 2 is based on.
>>
>> Why don't you push both of these patches through whatever tree that
>> file is maintained under. You can add my ack:
> I'm not sure if Peppe has a tree, but it should go into his tree
> if there is one. If not, can you apply patch 1 to your tree?
Hello
I have not own tree but I am using net.git and net-next to do my patches
and experiments.
I ask you to keep these patches aligned to net-next.
Also I ask you to review the glue-layer that is not in-line with what
have been currently added for dwmac-sti and dwmac-sunxi.c.
BR
Peppe
>>
>> Acked-by: David S. Miller <davem@davemloft.net>
> Thanks,
> Dinh
>
^ 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