* Re: [PATCH v2 4/4] pci: Add support for creating a generic host_bridge from device tree
From: Benjamin Herrenschmidt @ 2014-02-27 23:32 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree@vger.kernel.org, linaro-kernel, linux-pci, Liviu Dudau,
LKML, Will Deacon, Catalin Marinas, Bjorn Helgaas, LAKML
In-Reply-To: <18746655.qWHLpMg2Yy@wuerfel>
On Thu, 2014-02-27 at 14:38 +0100, Arnd Bergmann wrote:
> On Thursday 27 February 2014 13:06:42 Liviu Dudau wrote:
> > Several platforms use a rather generic version of parsing
> > the device tree to find the host bridge ranges. Move the common code
> > into the generic PCI code and use it to create a pci_host_bridge
> > structure that can be used by arch code.
> >
> > Based on early attempts by Andrew Murray to unify the code.
> > Used powerpc and microblaze PCI code as starting point.
So that is only going to work for archs that don't have any special
twist. For example it won't work for powerpc which is why Andrew
original approach didn't fly.
The range walk helpers do help though, I need to review in more details
and test Andrew powerpc patch here and will merge it.
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
>
> Please add Benjamin Herrenschmidt to Cc here, I think it would be helpful
> to get his input so we can make this work on powerpc as well.
Tricky... We would need hooks which would turn the whole thing into a
pile of spaghetti. I think we should stick to using the range helpers
(Andrew latest patch), which makes the powerpc code a lot smaller,
and leave it at that.
> > diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
> > index 06ace62..feb8436 100644
> > --- a/drivers/pci/host-bridge.c
> > +++ b/drivers/pci/host-bridge.c
> > @@ -6,9 +6,13 @@
> > #include <linux/init.h>
> > #include <linux/pci.h>
> > #include <linux/module.h>
> > +#include <linux/of_address.h>
> > +#include <linux/of_pci.h>
> >
> > #include "pci.h"
> >
> > +static int domain_nr;
> > +
>
> For correctness, I think you want an 'atomic_t' here and use
> atomic_inc_return() to get a new value.
>
> > static struct pci_bus *find_pci_root_bus(struct pci_bus *bus)
> > {
> > while (bus->parent)
> > @@ -91,3 +95,133 @@ void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
> > res->end = region->end + offset;
> > }
> > EXPORT_SYMBOL(pcibios_bus_to_resource);
> > +
> > +/**
> > + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
> > + * @dev: device node of the host bridge having the range property
> > + * @resources: list where the range of resources will be added after DT parsing
> > + * @io_base: pointer to a variable that will contain the physical address for
> > + * the start of the I/O range.
> > + *
> > + * If this function returns an error then the @resources list will be freed.
> > + *
> > + * This function will parse the "ranges" property of a PCI host bridge device
> > + * node and setup the resource mapping based on its content. It is expected
> > + * that the property conforms with the Power ePAPR document.
> > + *
> > + * Each architecture is then offered the chance of applying their own
> > + * filtering of pci_host_bridge_windows based on their own restrictions by
> > + * calling pcibios_fixup_bridge_ranges(). The filtered list of windows
> > + * can then be used when creating a pci_host_bridge structure.
> > + */
> > +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
> > + struct list_head *resources, resource_size_t *io_base)
> > +{
> > + struct resource *res;
> > + struct of_pci_range range;
> > + struct of_pci_range_parser parser;
> > + int err;
> > +
> > + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> > +
> > + /* Check for ranges property */
> > + err = of_pci_range_parser_init(&parser, dev);
> > + if (err)
> > + return err;
> > +
> > + pr_debug("Parsing ranges property...\n");
> > + for_each_of_pci_range(&parser, &range) {
> > + /* Read next ranges element */
> > + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> > + range.pci_space, range.pci_addr);
> > + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> > + range.cpu_addr, range.size);
> > +
> > + /*
> > + * If we failed translation or got a zero-sized region
> > + * then skip this range
> > + */
> > + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> > + continue;
Shouldn't that test move into the parsing helper ?
> > + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> > + if (!res) {
> > + err = -ENOMEM;
> > + goto bridge_ranges_nomem;
> > + }
> > +
> > + of_pci_range_to_resource(&range, dev, res);
> > +
> > + if (resource_type(res) == IORESOURCE_IO)
> > + *io_base = range.cpu_addr;
You don't care about the size of the IO space ?
> > + pci_add_resource_offset(resources, res,
> > + res->start - range.pci_addr);
> > + }
>
> This is not the correct resource for I/O space at all. Please talk
> to Will, I've been over this with him in detail and he probably
> understands it now. I assume you are both working in the same
> building.
Yes, the IO offsets work differently on powerpc as well
> Since this is common PCI code, you could also decide to open-code
> the pci_add_resource_offset() function. If you don't do that, I
> think you have a memory leak for the resources that you can avoid
> by allocating the resource and pci_host_bridge_window structures
> together with a single kzalloc.
>
> > + /* Apply architecture specific fixups for the ranges */
> > + pcibios_fixup_bridge_ranges(resources);
> > +
> > + return 0;
> > +
> > +bridge_ranges_nomem:
> > + pci_free_resource_list(resources);
> > + return err;
> > +}
> > +
> > +/**
> > + * of_create_pci_host_bridge - Create a PCI host bridge structure using
> > + * information passed in the DT.
> > + * @parent: device owning this host bridge
> > + * @ops: pci_ops associated with the host controller
> > + * @host_data: opaque data structure used by the host controller.
> > + *
> > + * returns a pointer to the newly created pci_host_bridge structure, or
> > + * NULL if the call failed.
> > + *
> > + * This function will try to obtain the host bridge domain number by
> > + * using of_alias_get_id() call with "pci-domain" as a stem. If that
> > + * fails, a local allocator will be used that will put each host bridge
> > + * in a new domain.
> > + */
> > +struct pci_host_bridge *
> > +of_create_pci_host_bridge(struct device *parent, struct pci_ops *ops, void *host_data)
> > +{
> > + int err, domain, busno;
> > + struct resource bus_range;
> > + struct pci_bus *root_bus;
> > + struct pci_host_bridge *bridge;
> > + resource_size_t io_base;
> > + LIST_HEAD(res);
> > +
> > + domain = of_alias_get_id(parent->of_node, "pci-domain");
> > + if (domain == -ENODEV)
> > + domain = domain_nr++;
> >
We probably want some uniqueness testing here.
> > + err = of_pci_parse_bus_range(parent->of_node, &bus_range);
> > + if (err) {
> > + dev_info(parent, "No bus range for %s, using default [0-255]\n",
> > + parent->of_node->full_name);
> > + bus_range.start = 0;
> > + bus_range.end = 255;
> > + bus_range.flags = IORESOURCE_BUS;
> > + }
> > + busno = bus_range.start;
> > + pci_add_resource(&res, &bus_range);
> > +
> > + /* now parse the rest of host bridge bus ranges */
> > + if (pci_host_bridge_of_get_ranges(parent->of_node, &res, &io_base))
> > + return NULL;
> > +
> > + /* then create the root bus */
> > + root_bus = pci_create_root_bus_in_domain(parent, domain, busno,
> > + ops, host_data, &res);
> > + if (!root_bus)
> > + return NULL;
>
> Do we have any code that checks for conflicting domain/bus numbers here?
> I guess pci_create_root_bus_in_domain() will fail if you have that.
>
> Since pci_create_root_bus_in_domain() is a new function that you just
> introduced, it would be helpful to change the calling conventions
> so it returns an error pointer instead of NULL upon failing.
> of_create_pci_host_bridge() can do the same, but pci_create_root_bus()
> should keep returning NULL so we don't have to change all the
> callers.
>
> > + bridge = to_pci_host_bridge(root_bus->bridge);
> > + bridge->io_base = io_base;
> > +
> > + return bridge;
> > +}
> > +EXPORT_SYMBOL_GPL(of_create_pci_host_bridge);
> > diff --git a/include/linux/pci.h b/include/linux/pci.h
> > index 1eed009..0c5e269 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -395,6 +395,7 @@ struct pci_host_bridge {
> > struct device dev;
> > struct pci_bus *bus; /* root bus */
> > int domain_nr;
> > + resource_size_t io_base; /* physical address for the start of I/O area */
> > struct list_head windows; /* pci_host_bridge_windows */
> > void (*release_fn)(struct pci_host_bridge *);
> > void *release_data;
>
> What is the io_base used for here?
>
> > @@ -1786,11 +1787,23 @@ static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
> > return bus ? bus->dev.of_node : NULL;
> > }
> >
> > +struct pci_host_bridge *
> > +of_create_pci_host_bridge(struct device *parent, struct pci_ops *ops,
> > + void *host_data);
> > +
> > +void pcibios_fixup_bridge_ranges(struct list_head *resources);
> > #else /* CONFIG_OF */
> > static inline void pci_set_of_node(struct pci_dev *dev) { }
> > static inline void pci_release_of_node(struct pci_dev *dev) { }
> > static inline void pci_set_bus_of_node(struct pci_bus *bus) { }
> > static inline void pci_release_bus_of_node(struct pci_bus *bus) { }
> > +
> > +static inline struct pci_host_bridge *
> > +pci_host_bridge_of_init(struct device *parent, struct pci_ops *ops,
> > + void *host_data)
> > +{
> > + return NULL;
> > +}
> > #endif /* CONFIG_OF */
> >
> > #ifdef CONFIG_EEH
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/6] spi: sh-msiof: Add support for R-Car H2 and M2
From: Laurent Pinchart @ 2014-02-27 23:02 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Bastian Hecht, Mark Brown, Takashi Yoshii, Magnus Damm, linux-spi,
Linux-sh list,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Geert Uytterhoeven,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <CAMuHMdU6R_Wubsx2KCAXVBynzqquJekDNDZ-Sq1sKYEOM1RtTw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Geert,
On Thursday 27 February 2014 12:09:52 Geert Uytterhoeven wrote:
> On Thu, Feb 27, 2014 at 11:41 AM, Laurent Pinchart wrote:
> >> >> -- compatible : "renesas,sh-msiof" for SuperH, or
> >> >> +- compatible : "renesas,msiof-<soctype>" for SoCs,
> >> >> + "renesas,sh-msiof" for SuperH, or
> >> >> "renesas,sh-mobile-msiof" for SH Mobile series.
> >> >> + Examples with soctypes are:
> >> >> + "renesas,msiof-sh7724" (SH)
> >> >
> >> > Given that the driver doesn't handle the "renesas,msiof-sh7724"
> >> > compatible string this might not be a good example. Furthermore SuperH
> >> > doesn't have DT support. I would thus drop the "renesas,sh-msiof"
> >> > compatible string from patch 1/6 and wouldn't mention sh7724 here. I
> >> > very much doubt that someone would have developed DT support for SuperH
> >> > on the side and shipped products that would be broken by this change
> >> > :-)
> >>
> >> Upon reading your comment again: do you suggest to also remove the plain
> >> "renesas,sh-msiof"? That one was present before, since DT support was
> >> added to the driver in
> >>
> >> commit cf9c86efecf9510e62388fd174cf607671c59fa3
> >> Author: Bastian Hecht <hechtb-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Date: Wed Dec 12 12:54:48 2012 +0100
> >>
> >> spi/sh-msiof: Add device tree parsing to driver
> >>
> >> This adds the capability to retrieve setup data from the device tree
> >> node. The usage of platform data is still available.
> >>
> >> Signed-off-by: Bastian Hecht <hechtb+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> Signed-off-by: Grant Likely <grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
> >>
> >> So I prefer not to remove any pre-existing compatible values.
> >> Do you agree?
> >
> > I'd like to remove it (in a separate patch) if we can. The reason is that
> > keeping the DT ABI both forward- and backward-compatible is pretty painful
> > enough without having to care about compatibility strings that have no
> > user. I'd rather work on adding DT support for SuperH MSIOF later when
> > we'll have a platform we can test it on, instead of trying to guess now
> > what the needs will be, get users later and realize even later on that we
> > made a mistake that we can't fix because those users will have DT
> > binaries in the wild. Every unneeded bit of DT bindings that we keep in
> > the kernel is one potential problem for future binary compatibility.
>
> I agree about the complexity of keeping the DT ABI forward- and
> backward-compatible.
>
> However, in this case I don't think it hurts that much to just keep it:
> - DT compatible values and platform device names are kept in sync
> through a pointer to the same struct sh_msiof_chipdata, so there's
> not much maintenance needed.
> - DT compatible "renesas,sh-msiof" means exactly the same as
> the "spi_sh_msiof" platform device name, which is currently in use.
>
> So even if SuperH never moves to DT, we have to keep support for that
> specific MSIOF implementation, unless we drop the platform device version,
> too (Hmm, maybe that's what you're alluding to ;-)
Of course, I'm not trying to get support for SuperH dropped, I'm sure someone
would realize and complain before the end of the century ;-)
> And if we remove "renesas,sh-msiof", we should probably remove
> "renesas,sh-mobile-msiof", too, as there are no current users, and it also
> assumes the same MSIOF implementation?
I'm not too familiar with the MSIOF hardware, can "renesas,sh-mobile-msiof" be
used as a fallback for the currently support ARM SoCs ?
> Bastian: What was your real plan with "renesas,sh-msiof" and
> "renesas,sh-mobile-msiof"?
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 06/15] dt: binding: add binding for ImgTec IR block
From: James Hogan @ 2014-02-27 22:52 UTC (permalink / raw)
To: Rob Herring, Mark Rutland
Cc: Mauro Carvalho Chehab, linux-media, Pawel Moll, Ian Campbell,
Kumar Gala, devicetree, Rob Landley, linux-doc, Tomasz Figa
In-Reply-To: <1391788155-29191-1-git-send-email-james.hogan@imgtec.com>
[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]
Hi Rob, Mark + DT maintainers,
On Friday 07 February 2014 15:49:15 James Hogan wrote:
> Add device tree binding for ImgTec Consumer Infrared block, specifically
> major revision 1 of the hardware.
>
> Signed-off-by: James Hogan <james.hogan@imgtec.com>
> Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
> Cc: linux-media@vger.kernel.org
> 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: devicetree@vger.kernel.org
> Cc: Rob Landley <rob@landley.net>
> Cc: linux-doc@vger.kernel.org
> Cc: Tomasz Figa <tomasz.figa@gmail.com>
> ---
> v3:
> - Rename compatible string to "img,ir-rev1" (Rob Herring).
> - Specify ordering of clocks explicitly (Rob Herring).
I'd appreciate if somebody could give this another glance after the two
changes listed above and Ack it (I'll probably be posting a v4 patchset
tomorrow).
Thanks
James
>
> v2:
> - Future proof compatible string from "img,ir" to "img,ir1", where the 1
> corresponds to the major revision number of the hardware (Tomasz
> Figa).
> - Added clock-names property and three specific clock names described in
> the manual, only one of which is used by the current driver (Tomasz
> Figa).
> ---
> .../devicetree/bindings/media/img-ir-rev1.txt | 34
> ++++++++++++++++++++++ 1 file changed, 34 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/img-ir-rev1.txt
>
> diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt
> b/Documentation/devicetree/bindings/media/img-ir-rev1.txt new file mode
> 100644
> index 000000000000..5434ce61b925
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/img-ir-rev1.txt
> @@ -0,0 +1,34 @@
> +* ImgTec Infrared (IR) decoder version 1
> +
> +This binding is for Imagination Technologies' Infrared decoder block,
> +specifically major revision 1.
> +
> +Required properties:
> +- compatible: Should be "img,ir-rev1"
> +- reg: Physical base address of the controller and length of
> + memory mapped region.
> +- interrupts: The interrupt specifier to the cpu.
> +
> +Optional properties:
> +- clocks: List of clock specifiers as described in standard
> + clock bindings.
> + Up to 3 clocks may be specified in the following order:
> + 1st: Core clock (defaults to 32.768KHz if omitted).
> + 2nd: System side (fast) clock.
> + 3rd: Power modulation clock.
> +- clock-names: List of clock names corresponding to the clocks
> + specified in the clocks property.
> + Accepted clock names are:
> + "core": Core clock.
> + "sys": System clock.
> + "mod": Power modulation clock.
> +
> +Example:
> +
> + ir@02006200 {
> + compatible = "img,ir-rev1";
> + reg = <0x02006200 0x100>;
> + interrupts = <29 4>;
> + clocks = <&clk_32khz>;
> + clock-names = "core";
> + };
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] spi: sh-msiof: Remove "renesas,msiof-sh7724" from bindings
From: Laurent Pinchart @ 2014-02-27 22:50 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-sh-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven
In-Reply-To: <1393505238-11954-1-git-send-email-geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Hi Geert,
Thank you for the patch.
On Thursday 27 February 2014 13:47:17 Geert Uytterhoeven wrote:
> From: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
>
> It's not implemented in the driver, so it's a bad example.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org>
Acked-by: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>
> ---
> Documentation/devicetree/bindings/spi/sh-msiof.txt | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt
> b/Documentation/devicetree/bindings/spi/sh-msiof.txt index
> 1f0cb33763a1..f24baf3b6cc1 100644
> --- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
> +++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
> @@ -5,7 +5,6 @@ Required properties:
> "renesas,sh-msiof" for SuperH, or
> "renesas,sh-mobile-msiof" for SH Mobile series.
> Examples with soctypes are:
> - "renesas,msiof-sh7724" (SH)
> "renesas,msiof-r8a7790" (R-Car H2)
> "renesas,msiof-r8a7791" (R-Car M2)
> - reg : Offset and length of the register set for the
> device
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-spi" 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 v2 3/4] ARM: mvebu: move DT Dove to MVEBU
From: Sebastian Hesselbarth @ 2014-02-27 22:03 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Jason Cooper, Andrew Lunn, Gregory Clement,
Kishon Vijay Abraham I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1393536486-3827-4-git-send-email-sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
With all the DT support preparation done, we are able to move Dove
to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
for a while before removal. Also, convert SATA PHY Kconfig entry,
which is DT-only.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
Changelog:
v1->v2:
- just rename CONFIG_ARCH_DOVE to CONFIG_MACH_DOVE in dts/Makefile
(Suggested by Jason Cooper)
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
Cc: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
---
arch/arm/boot/dts/Makefile | 2 +-
arch/arm/mach-dove/Kconfig | 12 ------------
arch/arm/mach-dove/Makefile | 1 -
arch/arm/mach-mvebu/Kconfig | 12 ++++++++++++
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20 ++++++++------------
drivers/phy/Kconfig | 2 +-
7 files changed, 23 insertions(+), 27 deletions(-)
rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 032030361bef..21317af7fe48 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -55,7 +55,7 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
berlin2cd-google-chromecast.dtb
dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
-dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
+dtb-$(CONFIG_MACH_DOVE) += dove-cm-a510.dtb \
dove-cubox.dtb \
dove-d2plug.dtb \
dove-d3plug.dtb \
diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index 0bc7cdf8cf46..d8c439c89ea9 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -20,18 +20,6 @@ config MACH_CM_A510
Say 'Y' here if you want your kernel to support the
CompuLab CM-A510 Board.
-config MACH_DOVE_DT
- bool "Marvell Dove Flattened Device Tree"
- select DOVE_CLK
- select ORION_IRQCHIP
- select ORION_TIMER
- select REGULATOR
- select REGULATOR_FIXED_VOLTAGE
- select USE_OF
- help
- Say 'Y' here if you want your kernel to support the
- Marvell Dove using flattened device tree.
-
endmenu
endif
diff --git a/arch/arm/mach-dove/Makefile b/arch/arm/mach-dove/Makefile
index cbc5c0618788..b608a21919fb 100644
--- a/arch/arm/mach-dove/Makefile
+++ b/arch/arm/mach-dove/Makefile
@@ -2,5 +2,4 @@ obj-y += common.o
obj-$(CONFIG_DOVE_LEGACY) += irq.o mpp.o
obj-$(CONFIG_PCI) += pcie.o
obj-$(CONFIG_MACH_DOVE_DB) += dove-db-setup.o
-obj-$(CONFIG_MACH_DOVE_DT) += board-dt.o
obj-$(CONFIG_MACH_CM_A510) += cm-a510.o
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5e269d7263ce..966e5c6b9944 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -46,6 +46,18 @@ config MACH_ARMADA_XP
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada XP SoC with device tree.
+config MACH_DOVE
+ bool "Marvell Dove boards" if ARCH_MULTI_V7
+ select CACHE_L2X0
+ select CPU_PJ4
+ select DOVE_CLK
+ select ORION_IRQCHIP
+ select ORION_TIMER
+ select PINCTRL_DOVE
+ help
+ Say 'Y' here if you want your kernel to support the
+ Marvell Dove using flattened device tree.
+
endmenu
endif
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 878aebe98dcc..dd3e7188f75d 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -5,6 +5,7 @@ AFLAGS_coherency_ll.o := -Wa,-march=armv7-a
obj-y += system-controller.o mvebu-soc-id.o
obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
+obj-$(CONFIG_MACH_DOVE) += dove.o
obj-$(CONFIG_ARCH_MVEBU) += coherency.o coherency_ll.o pmsu.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-mvebu/dove.c
similarity index 61%
rename from arch/arm/mach-dove/board-dt.c
rename to arch/arm/mach-mvebu/dove.c
index 49fa9abd09da..5e5a43624237 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-mvebu/dove.c
@@ -1,5 +1,5 @@
/*
- * arch/arm/mach-dove/board-dt.c
+ * arch/arm/mach-mvebu/dove.c
*
* Marvell Dove 88AP510 System On Chip FDT Board
*
@@ -9,17 +9,14 @@
*/
#include <linux/init.h>
-#include <linux/clk-provider.h>
+#include <linux/mbus.h>
#include <linux/of.h>
#include <linux/of_platform.h>
#include <asm/hardware/cache-tauros2.h>
#include <asm/mach/arch.h>
-#include <mach/dove.h>
-#include <mach/pm.h>
-#include <plat/common.h>
#include "common.h"
-static void __init dove_dt_init(void)
+static void __init dove_init(void)
{
pr_info("Dove 88AP510 SoC\n");
@@ -30,14 +27,13 @@ static void __init dove_dt_init(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
-static const char * const dove_dt_board_compat[] = {
+static const char * const dove_dt_compat[] = {
"marvell,dove",
NULL
};
-DT_MACHINE_START(DOVE_DT, "Marvell Dove (Flattened Device Tree)")
- .map_io = dove_map_io,
- .init_machine = dove_dt_init,
- .restart = dove_restart,
- .dt_compat = dove_dt_board_compat,
+DT_MACHINE_START(DOVE_DT, "Marvell Dove")
+ .init_machine = dove_init,
+ .restart = mvebu_restart,
+ .dt_compat = dove_dt_compat,
MACHINE_END
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c7a551c2d5f1..ffd7f07adca3 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -24,7 +24,7 @@ config PHY_EXYNOS_MIPI_VIDEO
config PHY_MVEBU_SATA
def_bool y
- depends on ARCH_KIRKWOOD || ARCH_DOVE
+ depends on ARCH_KIRKWOOD || MACH_DOVE
depends on OF
select GENERIC_PHY
--
1.8.5.3
--
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 related
* Re: [PATCH v12 1/4] PHY: Add function set_speed to generic PHY framework
From: Loc Ho @ 2014-02-27 22:03 UTC (permalink / raw)
To: balbi-l0cyMroinI0
Cc: Kishon Vijay Abraham I, Tejun Heo, Olof Johansson, Arnd Bergmann,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linux SCSI List,
linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Don Dutile, Jon Masters, patches-qTEPVZfXA3Y@public.gmane.org
In-Reply-To: <20140227213427.GG5375-HgARHv6XitL9zxVx7UNMDg@public.gmane.org>
HI,
>> >> >> This patch adds function set_speed to the generic PHY framework operation
>> >> >> structure. This function can be called to instruct the PHY underlying layer
>> >> >> at specified lane to configure for specified speed in hertz.
>> >> >
>> >> > why ? looks like clk_set_rate() is your friend here. Can you be more
>> >> > descriptive of the use case ? When will this be used ?
>> >> >
>> >>
>> >> The phy_set_speed is used to configure the operation speed of the PHY
>> >> at run-time. The clock interface in general is used to configure the
>> >> clock input to the IP. I don't believe they are the same thing. Maybe
>> >> it will be clear in my response to your second email
>> >
>> > The problem with this is that you end up adding SATA-specific details to
>> > something which is supposed to be generic.
>>
>> Setting the operation speed is pretty generic from an interface point
>> of view. An generic multi-purpose PHY can support multiple speed. If
>
> no it's not. Specially when you consider that your "speed" argument can
> be just about anything and depending on the underlying bus, it *will* be
> treated differently. Note that e.g. in OMAP devices the exact *same* PHY
> IP is used for PCIe, SATA and USB... now, let's assume for the sake of
> argument that we were to implement ->set_speed() in that environment,
> how do you plan to do that ? a 6MHz arguments isn't valid from USB stand
> point and could mean different things in PCIe or SATA.
>
Correct me if I am wrong here. If the same PHY is used for PCIe, SATA,
and USB, would you not need to indicate what speed the PHY should be
operated at - unless the underlying IP magically negotiate and
configured automatically? If so, what about PHY isn't so intelligent?
How should you suggest that we handle these?
>> the upper layer wish to operate at an specified speed (say for testing
>> purpose and etc), it can be allowed.
>
> anything for testing purposes, should be limited to test scenarios.
Testing purpose is only one use case. Another use case is to limit the
speed so that I can confirm the driver actually works with various
speed of the device and handle correctly.
>
>> > After negoatiation, don't you
>> > get any interrupt from your PHY indicating that link speed negotiation
>> > is done ? Or is that IRQ only on AHCI IP ?
>>
>> There is NO interrupt from the PHY. The IRQ is assoicated with the
>> AHCI IP. With SATA host flow, it starts off with an COMRESET to start
>> the link negotiation. At that point, it will poll for completion.
>>
>> Any other concerns?
>
> hey, calm down... just trying to prevent us from applying something
> which isn't truly generic and I don't think "->set_speed" is generic
> enough. The semantics of the "speed" argument won't be valid for all use
> cases.
>
> I can already see people using that to pass
> USB_SPEED_{LOW,FULL,HIGH,SUPER}, instead of actual speed numbers. We wil
> end up with a mess to handle from a PHY driver, specially in cases such
> as OMAP where, as mentioned above, the same IP is used for SATA, PCIe
> and USB3.
>
This PHY isn't as "intelligent" as other PHY's. What would you suggest
as I need an method to indicate to the underlying PHY that I want to
operate at an specified speed?
-Loc
--
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 3/3] ARM: dts: bcm21664: Add device tree files.
From: Markus Mayer @ 2014-02-27 21:56 UTC (permalink / raw)
To: Christian Daudt, Matt Porter
Cc: Device Tree List, ARM Kernel List, Linux Kernel Mailing List,
Broadcom Kernel Feedback
In-Reply-To: <1393538166-22868-1-git-send-email-markus.mayer@linaro.org>
Add device tree files for the Broadcom BCM21664 SoC.
Signed-off-by: Markus Mayer <markus.mayer@linaro.org>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/bcm21664-garnet.dts | 56 +++++++
arch/arm/boot/dts/bcm21664.dtsi | 292 +++++++++++++++++++++++++++++++++
3 files changed, 350 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/bcm21664-garnet.dts
create mode 100644 arch/arm/boot/dts/bcm21664.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..0c1853a 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -48,7 +48,8 @@ dtb-$(CONFIG_ARCH_AT91) += sama5d36ek.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm11351-brt.dtb \
- bcm28155-ap.dtb
+ bcm28155-ap.dtb \
+ bcm21664-garnet.dtb
dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
dtb-$(CONFIG_ARCH_BERLIN) += \
berlin2-sony-nsz-gs7.dtb \
diff --git a/arch/arm/boot/dts/bcm21664-garnet.dts b/arch/arm/boot/dts/bcm21664-garnet.dts
new file mode 100644
index 0000000..e87cb26
--- /dev/null
+++ b/arch/arm/boot/dts/bcm21664-garnet.dts
@@ -0,0 +1,56 @@
+/*
+ * Copyright (C) 2014 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.
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+
+#include "bcm21664.dtsi"
+
+/ {
+ model = "BCM21664 Garnet board";
+ compatible = "brcm,bcm21664-garnet", "brcm,bcm21664";
+
+ memory {
+ reg = <0x80000000 0x40000000>; /* 1 GB */
+ };
+
+ uart@3e000000 {
+ status = "okay";
+ };
+
+ sdio1: sdio@3f180000 {
+ max-frequency = <48000000>;
+ status = "okay";
+ };
+
+ sdio2: sdio@3f190000 {
+ non-removable;
+ max-frequency = <48000000>;
+ status = "okay";
+ };
+
+ sdio4: sdio@3f1b0000 {
+ max-frequency = <48000000>;
+ cd-gpios = <&gpio 91 GPIO_ACTIVE_LOW>;
+ status = "okay";
+ };
+
+ usbotg: usb@3f120000 {
+ status = "okay";
+ };
+
+ usbphy: usb-phy@3f130000 {
+ status = "okay";
+ };
+};
diff --git a/arch/arm/boot/dts/bcm21664.dtsi b/arch/arm/boot/dts/bcm21664.dtsi
new file mode 100644
index 0000000..08a44d4
--- /dev/null
+++ b/arch/arm/boot/dts/bcm21664.dtsi
@@ -0,0 +1,292 @@
+/*
+ * Copyright (C) 2014 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 <dt-bindings/interrupt-controller/arm-gic.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+
+#include "skeleton.dtsi"
+
+/ {
+ model = "BCM21664 SoC";
+ compatible = "brcm,bcm21664";
+ interrupt-parent = <&gic>;
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ gic: interrupt-controller@3ff00100 {
+ compatible = "arm,cortex-a9-gic";
+ #interrupt-cells = <3>;
+ #address-cells = <0>;
+ interrupt-controller;
+ reg = <0x3ff01000 0x1000>,
+ <0x3ff00100 0x100>;
+ };
+
+ smc@0x3404e000 {
+ compatible = "brcm,bcm21664-smc", "brcm,kona-smc";
+ reg = <0x3404e000 0x400>; /* 1 KiB in SRAM */
+ };
+
+ uart@3e000000 {
+ compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
+ status = "disabled";
+ reg = <0x3e000000 0x118>;
+ clocks = <&uartb_clk>;
+ interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
+
+ uart@3e001000 {
+ compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
+ status = "disabled";
+ reg = <0x3e001000 0x118>;
+ clocks = <&uartb2_clk>;
+ interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
+
+ uart@3e002000 {
+ compatible = "brcm,bcm21664-dw-apb-uart", "snps,dw-apb-uart";
+ status = "disabled";
+ reg = <0x3e002000 0x118>;
+ clocks = <&uartb3_clk>;
+ interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ };
+
+ L2: l2-cache {
+ compatible = "arm,pl310-cache";
+ reg = <0x3ff20000 0x1000>;
+ cache-unified;
+ cache-level = <2>;
+ };
+
+ brcm,resetmgr@35001f00 {
+ compatible = "brcm,bcm21664-resetmgr";
+ reg = <0x35001f00 0x24>;
+ };
+
+ timer@35006000 {
+ compatible = "brcm,kona-timer";
+ reg = <0x35006000 0x1c>;
+ interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&hub_timer_clk>;
+ };
+
+ gpio: gpio@35003000 {
+ compatible = "brcm,bcm21664-gpio", "brcm,kona-gpio";
+ reg = <0x35003000 0x524>;
+ interrupts =
+ <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH
+ GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH>;
+ #gpio-cells = <2>;
+ #interrupt-cells = <2>;
+ gpio-controller;
+ interrupt-controller;
+ };
+
+ sdio1: sdio@3f180000 {
+ compatible = "brcm,kona-sdhci";
+ reg = <0x3f180000 0x801c>;
+ interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sdio1_clk>;
+ status = "disabled";
+ };
+
+ sdio2: sdio@3f190000 {
+ compatible = "brcm,kona-sdhci";
+ reg = <0x3f190000 0x801c>;
+ interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sdio2_clk>;
+ status = "disabled";
+ };
+
+ sdio3: sdio@3f1a0000 {
+ compatible = "brcm,kona-sdhci";
+ reg = <0x3f1a0000 0x801c>;
+ interrupts = <GIC_SPI 74 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sdio3_clk>;
+ status = "disabled";
+ };
+
+ sdio4: sdio@3f1b0000 {
+ compatible = "brcm,kona-sdhci";
+ reg = <0x3f1b0000 0x801c>;
+ interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&sdio4_clk>;
+ status = "disabled";
+ };
+
+ i2c@3e016000 {
+ compatible = "brcm,bcm21664-i2c", "brcm,kona-i2c";
+ reg = <0x3e016000 0x70>;
+ interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc1_clk>;
+ status = "disabled";
+ };
+
+ i2c@3e017000 {
+ compatible = "brcm,bcm21664-i2c", "brcm,kona-i2c";
+ reg = <0x3e017000 0x70>;
+ interrupts = <GIC_SPI 102 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc2_clk>;
+ status = "disabled";
+ };
+
+ i2c@3e018000 {
+ compatible = "brcm,bcm21664-i2c", "brcm,kona-i2c";
+ reg = <0x3e018000 0x70>;
+ interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc3_clk>;
+ status = "disabled";
+ };
+
+ i2c@3e01c000 {
+ compatible = "brcm,bcm21664-i2c", "brcm,kona-i2c";
+ reg = <0x3e01c000 0x70>;
+ interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&bsc4_clk>;
+ status = "disabled";
+ };
+
+ clocks {
+ bsc1_clk: bsc1 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ bsc2_clk: bsc2 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ bsc3_clk: bsc3 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ bsc4_clk: bsc4 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ pmu_bsc_clk: pmu_bsc {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ hub_timer_clk: hub_timer {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+
+ pwm_clk: pwm {
+ compatible = "fixed-clock";
+ clock-frequency = <26000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio1_clk: sdio1 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio2_clk: sdio2 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio3_clk: sdio3 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ sdio4_clk: sdio4 {
+ compatible = "fixed-clock";
+ clock-frequency = <48000000>;
+ #clock-cells = <0>;
+ };
+
+ tmon_1m_clk: tmon_1m {
+ compatible = "fixed-clock";
+ clock-frequency = <1000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb_clk: uartb {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb2_clk: uartb2 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ uartb3_clk: uartb3 {
+ compatible = "fixed-clock";
+ clock-frequency = <13000000>;
+ #clock-cells = <0>;
+ };
+
+ usb_otg_ahb_clk: usb_otg_ahb {
+ compatible = "fixed-clock";
+ clock-frequency = <52000000>;
+ #clock-cells = <0>;
+ };
+ };
+
+ usbotg: usb@3f120000 {
+ compatible = "snps,dwc2";
+ reg = <0x3f120000 0x10000>;
+ interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&usb_otg_ahb_clk>;
+ clock-names = "otg";
+ phys = <&usbphy>;
+ phy-names = "usb2-phy";
+ status = "disabled";
+ };
+
+ usbphy: usb-phy@3f130000 {
+ compatible = "brcm,kona-usb2-phy";
+ reg = <0x3f130000 0x28>;
+ #phy-cells = <0>;
+ status = "disabled";
+ };
+};
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/3] ARM: bcm21664: Add board support.
From: Markus Mayer @ 2014-02-27 21:56 UTC (permalink / raw)
To: Christian Daudt, Matt Porter
Cc: Device Tree List, ARM Kernel List, Linux Kernel Mailing List,
Broadcom Kernel Feedback
In-Reply-To: <1393538166-22868-1-git-send-email-markus.mayer@linaro.org>
Add support for the Broadcom BCM21664 mobile SoC. It has two Cortex-A9
cores like the BCM281xx family of chips. BCM21664 and BCM281xx share
many IP blocks in addition to the ARM cores.
Signed-off-by: Markus Mayer <markus.mayer@linaro.org>
---
arch/arm/mach-bcm/Makefile | 6 ++-
arch/arm/mach-bcm/board_bcm21664.c | 78 ++++++++++++++++++++++++++++++++++++
2 files changed, 82 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/mach-bcm/board_bcm21664.c
diff --git a/arch/arm/mach-bcm/Makefile b/arch/arm/mach-bcm/Makefile
index c2ccd5a..0e2e52e 100644
--- a/arch/arm/mach-bcm/Makefile
+++ b/arch/arm/mach-bcm/Makefile
@@ -1,5 +1,5 @@
#
-# Copyright (C) 2012-2013 Broadcom Corporation
+# Copyright (C) 2012-2014 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
@@ -10,6 +10,8 @@
# of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
-obj-$(CONFIG_ARCH_BCM_MOBILE) := board_bcm281xx.o bcm_kona_smc.o bcm_kona_smc_asm.o kona.o
+obj-$(CONFIG_ARCH_BCM_MOBILE) := board_bcm281xx.o board_bcm21664.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)
diff --git a/arch/arm/mach-bcm/board_bcm21664.c b/arch/arm/mach-bcm/board_bcm21664.c
new file mode 100644
index 0000000..d3ef7e5
--- /dev/null
+++ b/arch/arm/mach-bcm/board_bcm21664.c
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2014 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/clocksource.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+
+#include <asm/mach/arch.h>
+
+#include "bcm_kona_smc.h"
+#include "kona.h"
+
+#define RSTMGR_DT_STRING "brcm,bcm21664-resetmgr"
+
+#define RSTMGR_REG_WR_ACCESS_OFFSET 0
+#define RSTMGR_REG_CHIP_SOFT_RST_OFFSET 4
+
+#define RSTMGR_WR_PASSWORD 0xa5a5
+#define RSTMGR_WR_PASSWORD_SHIFT 8
+#define RSTMGR_WR_ACCESS_ENABLE 1
+
+static void bcm21644_restart(enum reboot_mode mode, const char *cmd)
+{
+ void __iomem *base;
+ struct device_node *resetmgr;
+
+ resetmgr = of_find_compatible_node(NULL, NULL, RSTMGR_DT_STRING);
+ if (!resetmgr) {
+ pr_emerg("Couldn't find " RSTMGR_DT_STRING "\n");
+ return;
+ }
+ base = of_iomap(resetmgr, 0);
+ if (!base) {
+ pr_emerg("Couldn't map " RSTMGR_DT_STRING "\n");
+ return;
+ }
+
+ /*
+ * A soft reset is triggered by writing a 0 to bit 0 of the soft reset
+ * register. To write to that register we must first write the password
+ * and the enable bit in the write access enable register.
+ */
+ writel((RSTMGR_WR_PASSWORD << RSTMGR_WR_PASSWORD_SHIFT) |
+ RSTMGR_WR_ACCESS_ENABLE,
+ base + RSTMGR_REG_WR_ACCESS_OFFSET);
+ writel(0, base + RSTMGR_REG_CHIP_SOFT_RST_OFFSET);
+
+ /* Wait for reset */
+ while (1);
+}
+
+static void __init bcm21644_init(void)
+{
+ of_platform_populate(NULL, of_default_bus_match_table, NULL,
+ &platform_bus);
+ kona_l2_cache_init();
+}
+
+static const char * const bcm21664_dt_compat[] = {
+ "brcm,bcm21664",
+ NULL,
+};
+
+DT_MACHINE_START(BCM21664_DT, "BCM21664 Broadcom Application Processor")
+ .init_machine = bcm21644_init,
+ .restart = bcm21644_restart,
+ .dt_compat = bcm21664_dt_compat,
+MACHINE_END
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/3] ARM: DT: bcm21664: Device tree bindings
From: Markus Mayer @ 2014-02-27 21:56 UTC (permalink / raw)
To: Christian Daudt, Matt Porter
Cc: Device Tree List, ARM Kernel List, Linux Kernel Mailing List,
Broadcom Kernel Feedback
In-Reply-To: <1393538166-22868-1-git-send-email-markus.mayer@linaro.org>
Add binding documents for the Broadcom BCM21664 SoC.
Signed-off-by: Markus Mayer <markus.mayer@linaro.org>
---
.../devicetree/bindings/arm/bcm/bcm21664.txt | 15 +++++++++++++++
.../devicetree/bindings/arm/bcm/kona-resetmgr.txt | 14 ++++++++++++++
2 files changed, 29 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
create mode 100644 Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
new file mode 100644
index 0000000..e077425
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
@@ -0,0 +1,15 @@
+Broadcom BCM21664 device tree bindings
+--------------------------------------
+
+This document describes the device tree bindings for boards with the BCM21664
+SoC.
+
+Required root node property:
+ - compatible: brcm,bcm21664
+
+Example:
+ / {
+ model = "BCM21664 SoC";
+ compatible = "brcm,bcm21664";
+ [...]
+ }
diff --git a/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
new file mode 100644
index 0000000..93f31ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
@@ -0,0 +1,14 @@
+Broadcom Kona Family Reset Manager
+----------------------------------
+
+The reset manager is used on the Broadcom BCM21664 SoC.
+
+Required properties:
+ - compatible: brcm,bcm21664-resetmgr
+ - reg: memory address & range
+
+Example:
+ brcm,resetmgr@35001f00 {
+ compatible = "brcm,bcm21664-resetmgr";
+ reg = <0x35001f00 0x24>;
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/3] ARM: bcm21664: Add initial support.
From: Markus Mayer @ 2014-02-27 21:56 UTC (permalink / raw)
To: Christian Daudt, Matt Porter
Cc: Device Tree List, ARM Kernel List, Linux Kernel Mailing List,
Broadcom Kernel Feedback
This series adds initial support for the Broadcom BCM21664 mobile SoC.
The series depends on the series "ARM: bcm281xx: Consolidate code":
https://lkml.org/lkml/2014/2/25/548
Markus Mayer (3):
ARM: DT: bcm21664: Device tree bindings
ARM: bcm21664: Add board support.
ARM: dts: bcm21664: Add device tree files.
.../devicetree/bindings/arm/bcm/bcm21664.txt | 15 +
.../devicetree/bindings/arm/bcm/kona-resetmgr.txt | 14 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/bcm21664-garnet.dts | 56 ++++
arch/arm/boot/dts/bcm21664.dtsi | 292 ++++++++++++++++++++
arch/arm/mach-bcm/Makefile | 6 +-
arch/arm/mach-bcm/board_bcm21664.c | 78 ++++++
7 files changed, 461 insertions(+), 3 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
create mode 100644 Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
create mode 100644 arch/arm/boot/dts/bcm21664-garnet.dts
create mode 100644 arch/arm/boot/dts/bcm21664.dtsi
create mode 100644 arch/arm/mach-bcm/board_bcm21664.c
--
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 3/4] ARM: mvebu: move DT Dove to MVEBU
From: Jason Cooper @ 2014-02-27 21:47 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement,
Kishon Vijay Abraham I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <530FB19F.3050209-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Thu, Feb 27, 2014 at 10:43:59PM +0100, Sebastian Hesselbarth wrote:
> On 02/27/2014 10:40 PM, Jason Cooper wrote:
> >On Thu, Feb 27, 2014 at 10:28:04PM +0100, Sebastian Hesselbarth wrote:
> >>With all the DT support preparation done, we are able to move Dove
> >>to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
> >>for a while before removal. Also, convert SATA PHY Kconfig entry,
> >>which is DT-only.
> >>
> >>Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >>---
> >>Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >>Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
> >>Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
> >>Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
> >>Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> >>Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
> >>Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
> >>Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
> >>Cc: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> >>Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
> >>Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >>Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> >>Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> >>---
> >> arch/arm/boot/dts/Makefile | 12 ++++++------
> >> arch/arm/mach-dove/Kconfig | 12 ------------
> >> arch/arm/mach-dove/Makefile | 1 -
> >> arch/arm/mach-mvebu/Kconfig | 12 ++++++++++++
> >> arch/arm/mach-mvebu/Makefile | 1 +
> >> arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20 ++++++++------------
> >> drivers/phy/Kconfig | 2 +-
> >> 7 files changed, 28 insertions(+), 32 deletions(-)
> >> rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
> >>
> >>diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >>index 032030361bef..376a2573e500 100644
> >>--- a/arch/arm/boot/dts/Makefile
> >>+++ b/arch/arm/boot/dts/Makefile
> >>@@ -55,11 +55,6 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
> >> berlin2cd-google-chromecast.dtb
> >> dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
> >> da850-evm.dtb
> >>-dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> >>- dove-cubox.dtb \
> >>- dove-d2plug.dtb \
> >>- dove-d3plug.dtb \
> >>- dove-dove-db.dtb
> >> dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
> >> dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
> >> exynos4210-smdkv310.dtb \
> >>@@ -132,7 +127,12 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> >> armada-xp-gp.dtb \
> >> armada-xp-netgear-rn2120.dtb \
> >> armada-xp-matrix.dtb \
> >>- armada-xp-openblocks-ax3-4.dtb
> >>+ armada-xp-openblocks-ax3-4.dtb \
> >>+ dove-cm-a510.dtb \
> >>+ dove-cubox.dtb \
> >>+ dove-d2plug.dtb \
> >>+ dove-d3plug.dtb \
> >>+ dove-dove-db.dtb
> >
> >This is going to conflict badly with
> >
> > a02dd0271d01 ARM: mvebu: select dtbs from MACH_ARMADA_*
> >
> >Perhaps you could mimic what Andrew did in his series:
> >
> >dove := dove-cm-a510.dtb \
> > dove-cubox.dtb \
> > dove-d2plug.dtb \
> > dove-d3plug.dtb \
> > dove-dove-db.dtb
> >dtb-$(CONFIG_ARCH_DOVE) += $(dove)
> >dtb-$(CONFIG_MACH_DOVE) += $(dove)
>
> Ok, will do - except dtb-$(CONFIG_ARCH_DOVE) above.. there is no
> DT in ARCH_DOVE after this patch.
Ok, then there's no need for 'dove :=', just s/ARCH_DOVE/MACH_DOVE/ on
the original without movement.
thx,
Jason.
--
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 3/4] ARM: mvebu: move DT Dove to MVEBU
From: Sebastian Hesselbarth @ 2014-02-27 21:43 UTC (permalink / raw)
To: Jason Cooper
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement,
Kishon Vijay Abraham I, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140227214039.GJ1872-u4khhh1J0LxI1Ri9qeTfzeTW4wlIGRCZ@public.gmane.org>
On 02/27/2014 10:40 PM, Jason Cooper wrote:
> On Thu, Feb 27, 2014 at 10:28:04PM +0100, Sebastian Hesselbarth wrote:
>> With all the DT support preparation done, we are able to move Dove
>> to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
>> for a while before removal. Also, convert SATA PHY Kconfig entry,
>> which is DT-only.
>>
>> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>> ---
>> Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
>> Cc: Pawel Moll <pawel.moll-5wv7dgnIgG8@public.gmane.org>
>> Cc: Mark Rutland <mark.rutland-5wv7dgnIgG8@public.gmane.org>
>> Cc: Ian Campbell <ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>
>> Cc: Kumar Gala <galak-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>> Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
>> Cc: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
>> Cc: Andrew Lunn <andrew-g2DYL2Zd6BY@public.gmane.org>
>> Cc: Gregory Clement <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>> Cc: Kishon Vijay Abraham I <kishon-l0cyMroinI0@public.gmane.org>
>> Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>> Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> ---
>> arch/arm/boot/dts/Makefile | 12 ++++++------
>> arch/arm/mach-dove/Kconfig | 12 ------------
>> arch/arm/mach-dove/Makefile | 1 -
>> arch/arm/mach-mvebu/Kconfig | 12 ++++++++++++
>> arch/arm/mach-mvebu/Makefile | 1 +
>> arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20 ++++++++------------
>> drivers/phy/Kconfig | 2 +-
>> 7 files changed, 28 insertions(+), 32 deletions(-)
>> rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 032030361bef..376a2573e500 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -55,11 +55,6 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
>> berlin2cd-google-chromecast.dtb
>> dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
>> da850-evm.dtb
>> -dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
>> - dove-cubox.dtb \
>> - dove-d2plug.dtb \
>> - dove-d3plug.dtb \
>> - dove-dove-db.dtb
>> dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
>> dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
>> exynos4210-smdkv310.dtb \
>> @@ -132,7 +127,12 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
>> armada-xp-gp.dtb \
>> armada-xp-netgear-rn2120.dtb \
>> armada-xp-matrix.dtb \
>> - armada-xp-openblocks-ax3-4.dtb
>> + armada-xp-openblocks-ax3-4.dtb \
>> + dove-cm-a510.dtb \
>> + dove-cubox.dtb \
>> + dove-d2plug.dtb \
>> + dove-d3plug.dtb \
>> + dove-dove-db.dtb
>
> This is going to conflict badly with
>
> a02dd0271d01 ARM: mvebu: select dtbs from MACH_ARMADA_*
>
> Perhaps you could mimic what Andrew did in his series:
>
> dove := dove-cm-a510.dtb \
> dove-cubox.dtb \
> dove-d2plug.dtb \
> dove-d3plug.dtb \
> dove-dove-db.dtb
> dtb-$(CONFIG_ARCH_DOVE) += $(dove)
> dtb-$(CONFIG_MACH_DOVE) += $(dove)
Ok, will do - except dtb-$(CONFIG_ARCH_DOVE) above.. there is no
DT in ARCH_DOVE after this patch.
> We plan on re-alphabetizing next window to prevent bad conflicts in this
> window.
Good!
Sebastian
--
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 3/4] ARM: mvebu: move DT Dove to MVEBU
From: Jason Cooper @ 2014-02-27 21:40 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Andrew Lunn, Gregory Clement,
Kishon Vijay Abraham I, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1393536486-3827-4-git-send-email-sebastian.hesselbarth@gmail.com>
On Thu, Feb 27, 2014 at 10:28:04PM +0100, Sebastian Hesselbarth wrote:
> With all the DT support preparation done, we are able to move Dove
> to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
> for a while before removal. Also, convert SATA PHY Kconfig entry,
> which is DT-only.
>
> Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.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: Russell King <linux@arm.linux.org.uk>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Kishon Vijay Abraham I <kishon@ti.com>
> Cc: devicetree@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/Makefile | 12 ++++++------
> arch/arm/mach-dove/Kconfig | 12 ------------
> arch/arm/mach-dove/Makefile | 1 -
> arch/arm/mach-mvebu/Kconfig | 12 ++++++++++++
> arch/arm/mach-mvebu/Makefile | 1 +
> arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20 ++++++++------------
> drivers/phy/Kconfig | 2 +-
> 7 files changed, 28 insertions(+), 32 deletions(-)
> rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 032030361bef..376a2573e500 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -55,11 +55,6 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
> berlin2cd-google-chromecast.dtb
> dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
> da850-evm.dtb
> -dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
> - dove-cubox.dtb \
> - dove-d2plug.dtb \
> - dove-d3plug.dtb \
> - dove-dove-db.dtb
> dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
> dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
> exynos4210-smdkv310.dtb \
> @@ -132,7 +127,12 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> armada-xp-gp.dtb \
> armada-xp-netgear-rn2120.dtb \
> armada-xp-matrix.dtb \
> - armada-xp-openblocks-ax3-4.dtb
> + armada-xp-openblocks-ax3-4.dtb \
> + dove-cm-a510.dtb \
> + dove-cubox.dtb \
> + dove-d2plug.dtb \
> + dove-d3plug.dtb \
> + dove-dove-db.dtb
This is going to conflict badly with
a02dd0271d01 ARM: mvebu: select dtbs from MACH_ARMADA_*
Perhaps you could mimic what Andrew did in his series:
dove := dove-cm-a510.dtb \
dove-cubox.dtb \
dove-d2plug.dtb \
dove-d3plug.dtb \
dove-dove-db.dtb
dtb-$(CONFIG_ARCH_DOVE) += $(dove)
dtb-$(CONFIG_MACH_DOVE) += $(dove)
We plan on re-alphabetizing next window to prevent bad conflicts in this
window.
thx,
Jason.
^ permalink raw reply
* Re: [PATCH V2 1/3] dt: palmas: support IRQ inversion at the board level
From: Stephen Warren @ 2014-02-27 21:35 UTC (permalink / raw)
To: Graeme Gregory
Cc: Samuel Ortiz, Lee Jones, Mark Rutland,
devicetree-u79uwXL29TY76Z2rM5mHXA, Stephen Warren, Pawel Moll,
Ian Campbell, J Keerthy, Ian Lartey, Rob Herring, Kumar Gala,
linux-tegra-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20140227210227.GE2931@xora-haswell>
On 02/27/2014 02:02 PM, Graeme Gregory wrote:
> On Thu, Feb 27, 2014 at 01:51:19PM -0700, Stephen Warren wrote:
>> Some boards or SoCs have an inverter between the PMIC IRQ output pin and
>> the IRQ controller input signal.
>>
>> The IRQ specifier in DT is meant to represent the IRQ flags at the input
>> to the IRQ controller.
>>
>> The Palmas HW's IRQ output has configurable polarity. Software needs to
>> know which polarity to choose for the IRQ output. Software may be tempted
>> to extract the IRQ polarity from the IRQ specifier in order to make this
>> choice.
>>
>> That approach works fine if the IRQ signal is routed directly from the
>> PMIC to the IRQ controller with no intervening logic. However, if the
>> signal is inverted between the two, this approach gets the wrong answer.
>>
>> Add an additional optional DT property which indicates that such an
>> inversion occurs. This allows DT to give complete information about the
>> desired IRQ output polarity to software.
>>
>> An alternative would have been to add a new non-optional DT parameter to
>> indicate the exact desired output polarity. However, this would have been
>> an incompatible change to the DT binding.
>> diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt
>> +- ti,irq-externally-inverted : If missing, the polarity of the Palmas IRQ
>> + output should be set to the opposite of the polarity indicated by the IRQ
>> + specifier in the interrupts property. If absent, the polarity should be
>> + configured to match. This allows the representation of an inverter between
>> + the Palmas IRQ output and the interrupt parent's IRQ input.
>
> This has got to be the wrong way to do things, all this leads to is every
> device doing this property in its own way and having totally inconsistent
> properties all meaning the same thing.
>
> If there is some other hardware inverting lines then there should be
> a generic binding for this in DT. This is not describing the palmas hardware
> but some external object to the palmas.
I'd be fine with removing the "ti," vendor prefix from the property
name, and promoting it to be a cross-device standard.
I'm not sure that many devices will need this though; most don't have
configurable output polarity. Still, I guess that shouldn't stop us from
creating standards for the cases where it is needed.
If the DT reviewers can ack the concept, I'm happy to respin the patch
with the more generic property name.
^ permalink raw reply
* Re: [PATCHv1 1/2] rx51_battery: convert to iio consumer
From: Belisko Marek @ 2014-02-27 21:34 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Dmitry Eremin-Solenikov, David Woodhouse, Jonathan Cameron,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Grant Likely, LKML, devicetree@vger.kernel.org, linux-iio,
Pali Rohár
In-Reply-To: <20140226215452.GA11468@earth.universe>
Hi Sebastian,
On Wed, Feb 26, 2014 at 10:54 PM, Sebastian Reichel <sre@debian.org> wrote:
> Hi,
>
> On Wed, Feb 26, 2014 at 10:43:40PM +0100, Belisko Marek wrote:
>> [...]
>> > + int val, err;
>> > + err = iio_read_channel_average_raw(channel, &val);
>> Where this function comes from? I cannot find it in current linux-next
>> (only iio_read_channel_raw()). Am I missing some patches? Thx.
>
> Ah right. I planned to send a patch adding this function together
> with the rx51-battery patchset, but it seems I forgot to include it.
>
> Sorry for the inconvenience. I will send it out as a separate patch
> now.
>
>> BTW when I convert to iio consumer and use DT some of values work
>> but some of them just report 0 :( (I don't have latest twl4030-madc
>> iio patches).
>
> Can you retry with the twl4030-madc iio patch from today? The
> older patchsets, which do not contain the "tested on real hw"
> note are slightly broken.
Well I've tried and it's worse :). I got during booting:
[ 2.218383] ERROR: could not get IIO channel /battery:temp(0)
[ 2.224639] platform battery.4: Driver twl4030_madc_battery
requests probe deferral
Not sure if it's just error or warning but temp is always reported as
0 (and also other values in sysfs).
My patches ca be found here:
https://patchwork.kernel.org/patch/3735981/
https://patchwork.kernel.org/patch/3735961/
https://patchwork.kernel.org/patch/3735941/
>
> -- Sebastian
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 v12 1/4] PHY: Add function set_speed to generic PHY framework
From: Felipe Balbi @ 2014-02-27 21:34 UTC (permalink / raw)
To: Loc Ho
Cc: balbi-l0cyMroinI0, Kishon Vijay Abraham I, Tejun Heo,
Olof Johansson, Arnd Bergmann,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Linux SCSI List,
linux-ide-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Don Dutile, Jon Masters, patches-qTEPVZfXA3Y@public.gmane.org
In-Reply-To: <CAPw-ZT=7cu1NoxrBL48RUJV04ofrnNkF=p=23VFfu8ZZWmkQWQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2630 bytes --]
Hi,
On Thu, Feb 27, 2014 at 01:09:57PM -0800, Loc Ho wrote:
> >> >> This patch adds function set_speed to the generic PHY framework operation
> >> >> structure. This function can be called to instruct the PHY underlying layer
> >> >> at specified lane to configure for specified speed in hertz.
> >> >
> >> > why ? looks like clk_set_rate() is your friend here. Can you be more
> >> > descriptive of the use case ? When will this be used ?
> >> >
> >>
> >> The phy_set_speed is used to configure the operation speed of the PHY
> >> at run-time. The clock interface in general is used to configure the
> >> clock input to the IP. I don't believe they are the same thing. Maybe
> >> it will be clear in my response to your second email
> >
> > The problem with this is that you end up adding SATA-specific details to
> > something which is supposed to be generic.
>
> Setting the operation speed is pretty generic from an interface point
> of view. An generic multi-purpose PHY can support multiple speed. If
no it's not. Specially when you consider that your "speed" argument can
be just about anything and depending on the underlying bus, it *will* be
treated differently. Note that e.g. in OMAP devices the exact *same* PHY
IP is used for PCIe, SATA and USB... now, let's assume for the sake of
argument that we were to implement ->set_speed() in that environment,
how do you plan to do that ? a 6MHz arguments isn't valid from USB stand
point and could mean different things in PCIe or SATA.
> the upper layer wish to operate at an specified speed (say for testing
> purpose and etc), it can be allowed.
anything for testing purposes, should be limited to test scenarios.
> > After negoatiation, don't you
> > get any interrupt from your PHY indicating that link speed negotiation
> > is done ? Or is that IRQ only on AHCI IP ?
>
> There is NO interrupt from the PHY. The IRQ is assoicated with the
> AHCI IP. With SATA host flow, it starts off with an COMRESET to start
> the link negotiation. At that point, it will poll for completion.
>
> Any other concerns?
hey, calm down... just trying to prevent us from applying something
which isn't truly generic and I don't think "->set_speed" is generic
enough. The semantics of the "speed" argument won't be valid for all use
cases.
I can already see people using that to pass
USB_SPEED_{LOW,FULL,HIGH,SUPER}, instead of actual speed numbers. We wil
end up with a mess to handle from a PHY driver, specially in cases such
as OMAP where, as mentioned above, the same IP is used for SATA, PCIe
and USB3.
--
balbi
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH 3/3] Documentation: DT: Document twl4030-madc-battery bindings.
From: Marek Belisko @ 2014-02-27 21:29 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
dbaryshkov, dwmw2, grant.likely
Cc: devicetree, linux-doc, linux-kernel, hns, sre, Marek Belisko
In-Reply-To: <1393536570-29969-1-git-send-email-marek@goldelico.com>
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
.../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
diff --git a/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
new file mode 100644
index 0000000..fd0b6d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
@@ -0,0 +1,43 @@
+twl4030_madc_battery
+
+Required properties:
+ - compatible : "ti,twl4030-madc-battery"
+ - capacity : battery capacity in uAh
+ - charging-calibration-data : list of voltage(mV):level(%) values
+ for charging calibration (see example)
+ - discharging-calibration-data : list of voltage(mV):level(%) values
+ for discharging calibration (see example)
+ - io-channels: Should contain IIO channel specifiers
+ for each element in io-channel-names.
+- io-channel-names: Should contain the following values:
+ * "temp" - The ADC channel for temperature reading
+ * "ichg" - The ADC channel for battery charging status
+ * "vbat" - The ADC channel to measure the battery voltage
+
+Example:
+ madc-battery {
+ compatible = "ti,twl4030-madc-battery";
+ capacity = <1200000>;
+ charging-calibration-data = <4200 100
+ 4100 75
+ 4000 55
+ 3900 25
+ 3800 5
+ 3700 2
+ 3600 1
+ 3300 0>;
+
+ discharging-calibration-data = <4200 100
+ 4100 95
+ 4000 70
+ 3800 50
+ 3700 10
+ 3600 5
+ 3300 0>;
+ io-channels = <&twl_madc 1>,
+ <&twl_madc 10>,
+ <&twl_madc 12>;
+ io-channel-names = "temp",
+ "ichg",
+ "vbat";
+ };
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/3] power: twl4030_madc_battery: Add device tree support.
From: Marek Belisko @ 2014-02-27 21:29 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
dbaryshkov, dwmw2, grant.likely
Cc: devicetree, linux-doc, linux-kernel, hns, sre, Marek Belisko
In-Reply-To: <1393536570-29969-1-git-send-email-marek@goldelico.com>
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
drivers/power/twl4030_madc_battery.c | 83 +++++++++++++++++++++++++++++++++++-
1 file changed, 82 insertions(+), 1 deletion(-)
diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index 42685df..24c69f7 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -20,6 +20,7 @@
#include <linux/i2c/twl4030-madc.h>
#include <linux/power/twl4030_madc_battery.h>
#include <linux/iio/consumer.h>
+#include <linux/of.h>
struct twl4030_madc_battery {
struct power_supply psy;
@@ -184,6 +185,82 @@ static int twl4030_cmp(const void *a, const void *b)
((struct twl4030_madc_bat_calibration *)a)->voltage;
}
+#ifdef CONFIG_OF
+static struct twl4030_madc_bat_platform_data *
+ twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+ struct twl4030_madc_bat_platform_data *pdata;
+ struct device_node *np = pdev->dev.of_node;
+ int ret;
+ int i, proplen;
+
+ pdata = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_bat_platform_data),
+ GFP_KERNEL);
+ if (!pdata)
+ return ERR_PTR(-ENOMEM);
+
+ ret = of_property_read_u32(np, "capacity", &pdata->capacity);
+ if (ret != 0)
+ return ERR_PTR(-EINVAL);
+
+ /* parse and prepare charging data */
+ proplen = of_property_count_u32_elems(np, "charging-calibration-data");
+ if (proplen < 0) {
+ dev_warn(&pdev->dev, "No 'charging-calibration-data' property found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ pdata->charging = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+ GFP_KERNEL);
+
+ for (i = 0; i < proplen / 2; i++) {
+ of_property_read_u32_index(np, "charging-calibration-data",
+ i * 2,
+ (u32 *)&pdata->charging[i].voltage);
+ of_property_read_u32_index(np, "charging-calibration-data",
+ i * 2 + 1,
+ (u32 *)&pdata->charging[i].level);
+ }
+
+ /* parse and prepare discharging data */
+ proplen = of_property_count_u32_elems(np,
+ "discharging-calibration-data");
+ if (proplen < 0) {
+ dev_warn(&pdev->dev, "No 'discharging-calibration-data' property found\n");
+ return ERR_PTR(-EINVAL);
+ }
+
+ pdata->discharging = devm_kzalloc(&pdev->dev,
+ sizeof(struct twl4030_madc_bat_calibration) * (proplen / 2),
+ GFP_KERNEL);
+
+ for (i = 0; i < proplen / 2; i++) {
+ of_property_read_u32_index(np, "discharging-calibration-data",
+ i * 2,
+ (u32 *)&pdata->discharging[i].voltage);
+ of_property_read_u32_index(np, "discharging-calibration-data",
+ i * 2 + 1,
+ (u32 *)&pdata->discharging[i].level);
+ }
+
+ return pdata;
+}
+
+static const struct of_device_id of_twl4030_madc_match[] = {
+ { .compatible = "ti,twl4030-madc-battery", },
+ {},
+};
+
+#else
+static struct twl4030_madc_bat_platform_data *
+ twl4030_madc_dt_probe(struct platform_device *pdev)
+{
+ return ERR_PTR(-ENODEV);
+}
+#endif
+
static int twl4030_madc_battery_probe(struct platform_device *pdev)
{
struct twl4030_madc_battery *twl4030_madc_bat;
@@ -193,6 +270,9 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
if (!twl4030_madc_bat)
return -ENOMEM;
+ if (!pdata)
+ pdata = twl4030_madc_dt_probe(pdev);
+
twl4030_madc_bat->psy.name = "twl4030_battery";
twl4030_madc_bat->psy.type = POWER_SUPPLY_TYPE_BATTERY;
twl4030_madc_bat->psy.properties = twl4030_madc_bat_props;
@@ -201,7 +281,7 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
twl4030_madc_bat->psy.get_property = twl4030_madc_bat_get_property;
twl4030_madc_bat->psy.external_power_changed =
twl4030_madc_bat_ext_changed;
-
+
twl4030_madc_bat->channel_temp = iio_channel_get(&pdev->dev, "temp");
if (IS_ERR(twl4030_madc_bat->channel_temp))
return PTR_ERR(twl4030_madc_bat->channel_temp);
@@ -242,6 +322,7 @@ static int twl4030_madc_battery_remove(struct platform_device *pdev)
static struct platform_driver twl4030_madc_battery_driver = {
.driver = {
.name = "twl4030_madc_battery",
+ .of_match_table = of_match_ptr(of_twl4030_madc_match),
},
.probe = twl4030_madc_battery_probe,
.remove = twl4030_madc_battery_remove,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/3] power: twl4030-madc-battery: Convert to iio consumer.
From: Marek Belisko @ 2014-02-27 21:29 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
dbaryshkov, dwmw2, grant.likely
Cc: devicetree, linux-doc, linux-kernel, hns, sre, Marek Belisko
In-Reply-To: <1393536570-29969-1-git-send-email-marek@goldelico.com>
Signed-off-by: Marek Belisko <marek@goldelico.com>
---
drivers/power/twl4030_madc_battery.c | 74 ++++++++++++++++++++----------------
1 file changed, 41 insertions(+), 33 deletions(-)
diff --git a/drivers/power/twl4030_madc_battery.c b/drivers/power/twl4030_madc_battery.c
index 7ef445a..42685df 100644
--- a/drivers/power/twl4030_madc_battery.c
+++ b/drivers/power/twl4030_madc_battery.c
@@ -19,10 +19,14 @@
#include <linux/sort.h>
#include <linux/i2c/twl4030-madc.h>
#include <linux/power/twl4030_madc_battery.h>
+#include <linux/iio/consumer.h>
struct twl4030_madc_battery {
struct power_supply psy;
struct twl4030_madc_bat_platform_data *pdata;
+ struct iio_channel *channel_temp;
+ struct iio_channel *channel_ichg;
+ struct iio_channel *channel_vbat;
};
static enum power_supply_property twl4030_madc_bat_props[] = {
@@ -38,43 +42,35 @@ static enum power_supply_property twl4030_madc_bat_props[] = {
POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
};
-static int madc_read(int index)
+static int madc_read(struct iio_channel *channel)
{
- struct twl4030_madc_request req;
- int val;
-
- req.channels = index;
- req.method = TWL4030_MADC_SW2;
- req.type = TWL4030_MADC_WAIT;
- req.do_avg = 0;
- req.raw = false;
- req.func_cb = NULL;
-
- val = twl4030_madc_conversion(&req);
- if (val < 0)
- return val;
-
- return req.rbuf[ffs(index) - 1];
+ int val, err;
+ err = iio_read_channel_raw(channel, &val);
+ if (err < 0) {
+ pr_info("Error:%d\n", err);
+ return err;
+ }
+ return val;
}
-static int twl4030_madc_bat_get_charging_status(void)
+static int twl4030_madc_bat_get_charging_status(struct twl4030_madc_battery *bt)
{
- return (madc_read(TWL4030_MADC_ICHG) > 0) ? 1 : 0;
+ return (madc_read(bt->channel_ichg) > 0) ? 1 : 0;
}
-static int twl4030_madc_bat_get_voltage(void)
+static int twl4030_madc_bat_get_voltage(struct twl4030_madc_battery *bt)
{
- return madc_read(TWL4030_MADC_VBAT);
+ return madc_read(bt->channel_vbat);
}
-static int twl4030_madc_bat_get_current(void)
+static int twl4030_madc_bat_get_current(struct twl4030_madc_battery *bt)
{
- return madc_read(TWL4030_MADC_ICHG) * 1000;
+ return madc_read(bt->channel_ichg) * 1000;
}
-static int twl4030_madc_bat_get_temp(void)
+static int twl4030_madc_bat_get_temp(struct twl4030_madc_battery *bt)
{
- return madc_read(TWL4030_MADC_BTEMP) * 10;
+ return madc_read(bt->channel_temp) * 10;
}
static int twl4030_madc_bat_voltscale(struct twl4030_madc_battery *bat,
@@ -84,7 +80,7 @@ static int twl4030_madc_bat_voltscale(struct twl4030_madc_battery *bat,
int i, res = 0;
/* choose charging curve */
- if (twl4030_madc_bat_get_charging_status())
+ if (twl4030_madc_bat_get_charging_status(bat))
calibration = bat->pdata->charging;
else
calibration = bat->pdata->discharging;
@@ -119,23 +115,23 @@ static int twl4030_madc_bat_get_property(struct power_supply *psy,
switch (psp) {
case POWER_SUPPLY_PROP_STATUS:
if (twl4030_madc_bat_voltscale(bat,
- twl4030_madc_bat_get_voltage()) > 95)
+ twl4030_madc_bat_get_voltage(bat)) > 95)
val->intval = POWER_SUPPLY_STATUS_FULL;
else {
- if (twl4030_madc_bat_get_charging_status())
+ if (twl4030_madc_bat_get_charging_status(bat))
val->intval = POWER_SUPPLY_STATUS_CHARGING;
else
val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
}
break;
case POWER_SUPPLY_PROP_VOLTAGE_NOW:
- val->intval = twl4030_madc_bat_get_voltage() * 1000;
+ val->intval = twl4030_madc_bat_get_voltage(bat) * 1000;
break;
case POWER_SUPPLY_PROP_TECHNOLOGY:
val->intval = POWER_SUPPLY_TECHNOLOGY_LION;
break;
case POWER_SUPPLY_PROP_CURRENT_NOW:
- val->intval = twl4030_madc_bat_get_current();
+ val->intval = twl4030_madc_bat_get_current(bat);
break;
case POWER_SUPPLY_PROP_PRESENT:
/* assume battery is always present */
@@ -143,23 +139,23 @@ static int twl4030_madc_bat_get_property(struct power_supply *psy,
break;
case POWER_SUPPLY_PROP_CHARGE_NOW: {
int percent = twl4030_madc_bat_voltscale(bat,
- twl4030_madc_bat_get_voltage());
+ twl4030_madc_bat_get_voltage(bat));
val->intval = (percent * bat->pdata->capacity) / 100;
break;
}
case POWER_SUPPLY_PROP_CAPACITY:
val->intval = twl4030_madc_bat_voltscale(bat,
- twl4030_madc_bat_get_voltage());
+ twl4030_madc_bat_get_voltage(bat));
break;
case POWER_SUPPLY_PROP_CHARGE_FULL:
val->intval = bat->pdata->capacity;
break;
case POWER_SUPPLY_PROP_TEMP:
- val->intval = twl4030_madc_bat_get_temp();
+ val->intval = twl4030_madc_bat_get_temp(bat);
break;
case POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW: {
int percent = twl4030_madc_bat_voltscale(bat,
- twl4030_madc_bat_get_voltage());
+ twl4030_madc_bat_get_voltage(bat));
/* in mAh */
int chg = (percent * (bat->pdata->capacity/1000))/100;
@@ -205,6 +201,18 @@ static int twl4030_madc_battery_probe(struct platform_device *pdev)
twl4030_madc_bat->psy.get_property = twl4030_madc_bat_get_property;
twl4030_madc_bat->psy.external_power_changed =
twl4030_madc_bat_ext_changed;
+
+ twl4030_madc_bat->channel_temp = iio_channel_get(&pdev->dev, "temp");
+ if (IS_ERR(twl4030_madc_bat->channel_temp))
+ return PTR_ERR(twl4030_madc_bat->channel_temp);
+
+ twl4030_madc_bat->channel_ichg = iio_channel_get(&pdev->dev, "ichg");
+ if (IS_ERR(twl4030_madc_bat->channel_ichg))
+ return PTR_ERR(twl4030_madc_bat->channel_ichg);
+
+ twl4030_madc_bat->channel_vbat = iio_channel_get(&pdev->dev, "vbat");
+ if (IS_ERR(twl4030_madc_bat->channel_vbat))
+ return PTR_ERR(twl4030_madc_bat->channel_vbat);
/* sort charging and discharging calibration data */
sort(pdata->charging, pdata->charging_size,
--
1.8.3.2
^ permalink raw reply related
* [PATCH 0/3] Convert twl4030_madc_battery to IIO and add DT aupport
From: Marek Belisko @ 2014-02-27 21:29 UTC (permalink / raw)
To: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, galak, rob,
dbaryshkov, dwmw2, grant.likely
Cc: devicetree, linux-doc, linux-kernel, hns, sre, Marek Belisko
This patches are based on Sebastian Reichel work [1] which convert twl4030_madc mfd to iio
framework. Patches was tested on gta04 board. twl4030_madc_battery driver is converted in
first patch to iio consumer and in next patches is added support for devicetree.
[1] - https://lkml.org/lkml/2014/2/26/482
Marek Belisko (3):
power: twl4030-madc-battery: Convert to iio consumer.
power: twl4030_madc_battery: Add device tree support.
Documentation: DT: Document twl4030-madc-battery bindings.
.../bindings/power_supply/twl4030_madc_battery.txt | 43 ++++++
drivers/power/twl4030_madc_battery.c | 155 ++++++++++++++++-----
2 files changed, 165 insertions(+), 33 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power_supply/twl4030_madc_battery.txt
--
1.8.3.2
^ permalink raw reply
* [PATCH 3/4] ARM: mvebu: move DT Dove to MVEBU
From: Sebastian Hesselbarth @ 2014-02-27 21:28 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Jason Cooper, Andrew Lunn, Gregory Clement,
Kishon Vijay Abraham I, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1393536486-3827-1-git-send-email-sebastian.hesselbarth@gmail.com>
With all the DT support preparation done, we are able to move Dove
to MVEBU easily. Legacy non-DT mach-dove is left untouched to rot
for a while before removal. Also, convert SATA PHY Kconfig entry,
which is DT-only.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.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: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: Kishon Vijay Abraham I <kishon@ti.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/Makefile | 12 ++++++------
arch/arm/mach-dove/Kconfig | 12 ------------
arch/arm/mach-dove/Makefile | 1 -
arch/arm/mach-mvebu/Kconfig | 12 ++++++++++++
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} | 20 ++++++++------------
drivers/phy/Kconfig | 2 +-
7 files changed, 28 insertions(+), 32 deletions(-)
rename arch/arm/{mach-dove/board-dt.c => mach-mvebu/dove.c} (61%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 032030361bef..376a2573e500 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -55,11 +55,6 @@ dtb-$(CONFIG_ARCH_BERLIN) += \
berlin2cd-google-chromecast.dtb
dtb-$(CONFIG_ARCH_DAVINCI) += da850-enbw-cmc.dtb \
da850-evm.dtb
-dtb-$(CONFIG_ARCH_DOVE) += dove-cm-a510.dtb \
- dove-cubox.dtb \
- dove-d2plug.dtb \
- dove-d3plug.dtb \
- dove-dove-db.dtb
dtb-$(CONFIG_ARCH_EFM32) += efm32gg-dk3750.dtb
dtb-$(CONFIG_ARCH_EXYNOS) += exynos4210-origen.dtb \
exynos4210-smdkv310.dtb \
@@ -132,7 +127,12 @@ dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
armada-xp-gp.dtb \
armada-xp-netgear-rn2120.dtb \
armada-xp-matrix.dtb \
- armada-xp-openblocks-ax3-4.dtb
+ armada-xp-openblocks-ax3-4.dtb \
+ dove-cm-a510.dtb \
+ dove-cubox.dtb \
+ dove-d2plug.dtb \
+ dove-d3plug.dtb \
+ dove-dove-db.dtb
dtb-$(CONFIG_ARCH_MXC) += \
imx25-karo-tx25.dtb \
imx25-pdk.dtb \
diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index 0bc7cdf8cf46..d8c439c89ea9 100644
--- a/arch/arm/mach-dove/Kconfig
+++ b/arch/arm/mach-dove/Kconfig
@@ -20,18 +20,6 @@ config MACH_CM_A510
Say 'Y' here if you want your kernel to support the
CompuLab CM-A510 Board.
-config MACH_DOVE_DT
- bool "Marvell Dove Flattened Device Tree"
- select DOVE_CLK
- select ORION_IRQCHIP
- select ORION_TIMER
- select REGULATOR
- select REGULATOR_FIXED_VOLTAGE
- select USE_OF
- help
- Say 'Y' here if you want your kernel to support the
- Marvell Dove using flattened device tree.
-
endmenu
endif
diff --git a/arch/arm/mach-dove/Makefile b/arch/arm/mach-dove/Makefile
index cbc5c0618788..b608a21919fb 100644
--- a/arch/arm/mach-dove/Makefile
+++ b/arch/arm/mach-dove/Makefile
@@ -2,5 +2,4 @@ obj-y += common.o
obj-$(CONFIG_DOVE_LEGACY) += irq.o mpp.o
obj-$(CONFIG_PCI) += pcie.o
obj-$(CONFIG_MACH_DOVE_DB) += dove-db-setup.o
-obj-$(CONFIG_MACH_DOVE_DT) += board-dt.o
obj-$(CONFIG_MACH_CM_A510) += cm-a510.o
diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 5e269d7263ce..966e5c6b9944 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -46,6 +46,18 @@ config MACH_ARMADA_XP
Say 'Y' here if you want your kernel to support boards based
on the Marvell Armada XP SoC with device tree.
+config MACH_DOVE
+ bool "Marvell Dove boards" if ARCH_MULTI_V7
+ select CACHE_L2X0
+ select CPU_PJ4
+ select DOVE_CLK
+ select ORION_IRQCHIP
+ select ORION_TIMER
+ select PINCTRL_DOVE
+ help
+ Say 'Y' here if you want your kernel to support the
+ Marvell Dove using flattened device tree.
+
endmenu
endif
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 878aebe98dcc..dd3e7188f75d 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -5,6 +5,7 @@ AFLAGS_coherency_ll.o := -Wa,-march=armv7-a
obj-y += system-controller.o mvebu-soc-id.o
obj-$(CONFIG_MACH_ARMADA_370_XP) += armada-370-xp.o
+obj-$(CONFIG_MACH_DOVE) += dove.o
obj-$(CONFIG_ARCH_MVEBU) += coherency.o coherency_ll.o pmsu.o
obj-$(CONFIG_SMP) += platsmp.o headsmp.o
obj-$(CONFIG_HOTPLUG_CPU) += hotplug.o
diff --git a/arch/arm/mach-dove/board-dt.c b/arch/arm/mach-mvebu/dove.c
similarity index 61%
rename from arch/arm/mach-dove/board-dt.c
rename to arch/arm/mach-mvebu/dove.c
index 49fa9abd09da..5e5a43624237 100644
--- a/arch/arm/mach-dove/board-dt.c
+++ b/arch/arm/mach-mvebu/dove.c
@@ -1,5 +1,5 @@
/*
- * arch/arm/mach-dove/board-dt.c
+ * arch/arm/mach-mvebu/dove.c
*
* Marvell Dove 88AP510 System On Chip FDT Board
*
@@ -9,17 +9,14 @@
*/
#include <linux/init.h>
-#include <linux/clk-provider.h>
+#include <linux/mbus.h>
#include <linux/of.h>
#include <linux/of_platform.h>
#include <asm/hardware/cache-tauros2.h>
#include <asm/mach/arch.h>
-#include <mach/dove.h>
-#include <mach/pm.h>
-#include <plat/common.h>
#include "common.h"
-static void __init dove_dt_init(void)
+static void __init dove_init(void)
{
pr_info("Dove 88AP510 SoC\n");
@@ -30,14 +27,13 @@ static void __init dove_dt_init(void)
of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
-static const char * const dove_dt_board_compat[] = {
+static const char * const dove_dt_compat[] = {
"marvell,dove",
NULL
};
-DT_MACHINE_START(DOVE_DT, "Marvell Dove (Flattened Device Tree)")
- .map_io = dove_map_io,
- .init_machine = dove_dt_init,
- .restart = dove_restart,
- .dt_compat = dove_dt_board_compat,
+DT_MACHINE_START(DOVE_DT, "Marvell Dove")
+ .init_machine = dove_init,
+ .restart = mvebu_restart,
+ .dt_compat = dove_dt_compat,
MACHINE_END
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index c7a551c2d5f1..ffd7f07adca3 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -24,7 +24,7 @@ config PHY_EXYNOS_MIPI_VIDEO
config PHY_MVEBU_SATA
def_bool y
- depends on ARCH_KIRKWOOD || ARCH_DOVE
+ depends on ARCH_KIRKWOOD || MACH_DOVE
depends on OF
select GENERIC_PHY
--
1.8.5.3
^ permalink raw reply related
* [PATCH 1/4] ARM: dove: add system controller node
From: Sebastian Hesselbarth @ 2014-02-27 21:28 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Russell King, Jason Cooper, Andrew Lunn, Gregory Clement,
devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <1393536486-3827-1-git-send-email-sebastian.hesselbarth@gmail.com>
This adds a DT node for the system-controller found on Marvell Dove
SoCs.
Signed-off-by: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.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: Russell King <linux@arm.linux.org.uk>
Cc: Jason Cooper <jason@lakedaemon.net>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Gregory Clement <gregory.clement@free-electrons.com>
Cc: devicetree@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
---
arch/arm/boot/dts/dove.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/dove.dtsi b/arch/arm/boot/dts/dove.dtsi
index 187fd46b7b5e..bd63452b18c0 100644
--- a/arch/arm/boot/dts/dove.dtsi
+++ b/arch/arm/boot/dts/dove.dtsi
@@ -186,6 +186,11 @@
reg = <0x20000 0x80>, <0x800100 0x8>;
};
+ sysc: system-ctrl@20000 {
+ compatible = "marvell,orion-system-controller";
+ reg = <0x20000 0x110>;
+ };
+
bridge_intc: bridge-interrupt-ctrl@20110 {
compatible = "marvell,orion-bridge-intc";
interrupt-controller;
--
1.8.5.3
^ permalink raw reply related
* [PATCH v2 7/7] ARM: dts: keystone: Udate USB node for dma properties
From: Santosh Shilimkar @ 2014-02-27 21:17 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Santosh Shilimkar, Russell King,
Olof Johansson
In-Reply-To: <1393535872-20915-1-git-send-email-santosh.shilimkar-l0cyMroinI0@public.gmane.org>
Keystone supports dma-coherent on USB master and also needs
dma-ranges to specify the hardware alias memory range in which DMA
can be operational.
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/keystone.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index 171579d..de155c0 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -200,6 +200,8 @@
clock-names = "usb";
interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>;
ranges;
+ dma-coherent;
+ dma-ranges;
status = "disabled";
dwc3@2690000 {
--
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 related
* [PATCH v2 6/7] ARM: dts: keystone: Use dma-ranges property
From: Santosh Shilimkar @ 2014-02-27 21:17 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Grygorii Strashko, Russell King,
Olof Johansson, Santosh Shilimkar
In-Reply-To: <1393535872-20915-1-git-send-email-santosh.shilimkar-l0cyMroinI0@public.gmane.org>
From: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
The dma-ranges property has to be specified per bus and has format:
< DMA addr > - Base DMA address for Bus (Bus format 32-bits)
< CPU addr > - Corresponding base CPU address (CPU format 64-bits)
< DMA range size > - Size of supported DMA range
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/keystone.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi
index b420290..171579d 100644
--- a/arch/arm/boot/dts/keystone.dtsi
+++ b/arch/arm/boot/dts/keystone.dtsi
@@ -96,6 +96,7 @@
compatible = "ti,keystone","simple-bus";
interrupt-parent = <&gic>;
ranges = <0x0 0x0 0x0 0xc0000000>;
+ dma-ranges = <0x80000000 0x8 0x00000000 0x80000000>;
rstctrl: reset-controller {
compatible = "ti,keystone-reset";
--
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 related
* [PATCH v2 5/7] ARM: of: introduce common routine for DMA configuration
From: Santosh Shilimkar @ 2014-02-27 21:17 UTC (permalink / raw)
To: arnd-r2nGTMty4D4
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA,
magnus.damm-Re5JQEeQqe8AvxtiuMwx3w,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
grant.likely-QSEj5FYQhm4dnm+yROfE0A,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, Grygorii Strashko, Russell King,
Olof Johansson, Santosh Shilimkar
In-Reply-To: <1393535872-20915-1-git-send-email-santosh.shilimkar-l0cyMroinI0@public.gmane.org>
From: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
This patch introduces ARM specific function arm_dt_dma_configure()
which intended to retrieve DMA configuration from DT and setup Platform
device's DMA parameters.
The DMA configuration in DT has to be specified using "dma-ranges"
and "dam-coherent" properties if supported. The DMA configuration applied
by arm_dt_dma_configure() as following:
- call of_get_dma_range() and get supported DMA range info
(dma_addr, cpu_addr, dma_size);
- if "not found" then fill dma_mask as DMA_BIT_MASK(32)
(this is default behaviour);
- if "failed" then clean up dma_mask (DMA not supported)
- if ok then update devices DMA configuration:
set dma_mask to (dma_addr + dma_size - 1)
set dma_pfn_offset to PFN_DOWN(cpu_addr - dma_addr)
Cc: Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>
Cc: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Cc: Olof Johansson <olof-nZhT3qVonbNeoWH0uzbU5w@public.gmane.org>
Cc: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
---
arch/arm/include/asm/prom.h | 3 +++
arch/arm/kernel/devtree.c | 61 +++++++++++++++++++++++++++++++++++++++++++
drivers/of/platform.c | 5 +++-
include/linux/of.h | 2 +-
4 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h
index b681575..1acb732 100644
--- a/arch/arm/include/asm/prom.h
+++ b/arch/arm/include/asm/prom.h
@@ -11,11 +11,13 @@
#ifndef __ASMARM_PROM_H
#define __ASMARM_PROM_H
+struct device;
#ifdef CONFIG_OF
extern const struct machine_desc *setup_machine_fdt(unsigned int dt_phys);
extern void arm_dt_memblock_reserve(void);
extern void __init arm_dt_init_cpu_maps(void);
+extern void arm_dt_dma_configure(struct device *dev);
#else /* CONFIG_OF */
@@ -26,6 +28,7 @@ static inline const struct machine_desc *setup_machine_fdt(unsigned int dt_phys)
static inline void arm_dt_memblock_reserve(void) { }
static inline void arm_dt_init_cpu_maps(void) { }
+static inline void arm_dt_dma_configure(struct device *dev) { }
#endif /* CONFIG_OF */
#endif /* ASMARM_PROM_H */
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f751714..926b5dd 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -18,6 +18,9 @@
#include <linux/of_fdt.h>
#include <linux/of_irq.h>
#include <linux/of_platform.h>
+#include <linux/of_dma.h>
+#include <linux/dma-mapping.h>
+#include <linux/slab.h>
#include <asm/cputype.h>
#include <asm/setup.h>
@@ -235,3 +238,61 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
return mdesc;
}
+
+void arm_dt_dma_configure(struct device *dev)
+{
+ dma_addr_t dma_addr;
+ phys_addr_t paddr, size;
+ dma_addr_t dma_mask;
+ int ret;
+
+ /*
+ * if dma-ranges property doesn't exist - use 32 bits DMA mask
+ * by default and don't set skip archdata.dma_pfn_offset
+ */
+ ret = of_dma_get_range(dev->of_node, &dma_addr, &paddr, &size);
+ if (ret == -ENODEV) {
+ dev->coherent_dma_mask = DMA_BIT_MASK(32);
+ if (!dev->dma_mask)
+ dev->dma_mask = &dev->coherent_dma_mask;
+ return;
+ }
+
+ /* if failed - disable DMA for device */
+ if (ret < 0) {
+ dev_err(dev, "failed to configure DMA\n");
+ return;
+ }
+
+ /* DMA ranges found. Calculate and set dma_pfn_offset */
+ dev->archdata.dma_pfn_offset = PFN_DOWN(paddr - dma_addr);
+
+ /* Configure DMA mask */
+ dev->dma_mask = kmalloc(sizeof(*dev->dma_mask), GFP_KERNEL);
+ if (!dev->dma_mask)
+ return;
+
+ dma_mask = dma_addr + size - 1;
+
+ ret = arm_dma_set_mask(dev, dma_mask);
+ if (ret < 0) {
+ dev_err(dev, "failed to set DMA mask %#08x\n", dma_mask);
+ kfree(dev->dma_mask);
+ dev->dma_mask = NULL;
+ return;
+ }
+
+ dev_dbg(dev, "dma_pfn_offset(%#08lx) dma_mask(%#016llx)\n",
+ dev->archdata.dma_pfn_offset, *dev->dma_mask);
+
+ if (of_dma_is_coherent(dev->of_node)) {
+ set_dma_ops(dev, &arm_coherent_dma_ops);
+ dev_dbg(dev, "device is dma coherent\n");
+ }
+
+ ret = dma_set_coherent_mask(dev, dma_mask);
+ if (ret < 0) {
+ dev_err(dev, "failed to set coherent DMA mask %#08x\n",
+ dma_mask);
+ }
+}
diff --git a/drivers/of/platform.c b/drivers/of/platform.c
index 404d1da..97d5533 100644
--- a/drivers/of/platform.c
+++ b/drivers/of/platform.c
@@ -213,10 +213,13 @@ static struct platform_device *of_platform_device_create_pdata(
#if defined(CONFIG_MICROBLAZE)
dev->archdata.dma_mask = 0xffffffffUL;
-#endif
+#elif defined(CONFIG_ARM_LPAE)
+ arm_dt_dma_configure(&dev->dev);
+#else
dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
if (!dev->dev.dma_mask)
dev->dev.dma_mask = &dev->dev.coherent_dma_mask;
+#endif
dev->dev.bus = &platform_bus_type;
dev->dev.platform_data = platform_data;
diff --git a/include/linux/of.h b/include/linux/of.h
index 70c64ba..a321058 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -136,7 +136,7 @@ static inline unsigned long of_read_ulong(const __be32 *cell, int size)
return of_read_number(cell, size);
}
-#if defined(CONFIG_SPARC)
+#if defined(CONFIG_SPARC) || defined(CONFIG_ARM_LPAE)
#include <asm/prom.h>
#endif
--
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 related
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