* [PATCH v1 0/3] net: stmmac: Add STi GMAC ethernet
From: srinivas.kandagatla @ 2014-02-03 11:59 UTC (permalink / raw)
To: netdev
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, Srinivas Kandagatla, linux-doc, linux-kernel,
Stuart Menefy, Rob Herring, Rob Landley, Kumar Gala,
Giuseppe Cavallaro, davem, linux-arm-kernel
From: Srinivas Kandagatla <srinivas.kandagatla@st.com>
Hi All,
This patch series adds Ethernet support to STi series SOCs STiH415 and STiH416.
STi SOC series integrates dwmac IP from synopsis, however there is a hardware
glue on top of this standard IP, this glue needs to configured before the
actual dwmac can be used. Also the glue logic needs re-configuring when the
link speed changes, This is because the clk source can change as the link
speed.
This patch just adds STi specific callbacks into of_data for configuring the
glue layer.
I have rebased my original patches (http://lkml.org/lkml/2013/11/12/243)
to latest stmmac which updates callbacks to suit glue drivers like this.
These patches are tested on b2000 and B2020 with STiH415 and STiH416.
Thanks,
srini
Srinivas Kandagatla (3):
net: stmmac:sti: Add STi SOC glue driver.
ARM: STi: Add STiH415 ethernet support.
ARM: STi: Add STiH416 ethernet support.
.../devicetree/bindings/net/sti-dwmac.txt | 58 ++++
arch/arm/boot/dts/stih415-clock.dtsi | 14 +
arch/arm/boot/dts/stih415-pinctrl.dtsi | 121 +++++++
arch/arm/boot/dts/stih415.dtsi | 48 +++
arch/arm/boot/dts/stih416-clock.dtsi | 14 +
arch/arm/boot/dts/stih416-pinctrl.dtsi | 109 +++++++
arch/arm/boot/dts/stih416.dtsi | 44 +++
arch/arm/boot/dts/stih41x-b2000.dtsi | 22 ++
arch/arm/boot/dts/stih41x-b2020.dtsi | 26 ++
drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 +
drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 331 ++++++++++++++++++++
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 3 +
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 5 +
14 files changed, 807 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/sti-dwmac.txt
create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c
--
1.7.9.5
^ permalink raw reply
* Re: [PATCH V5 2/4] DRIVERS: IRQCHIP: CROSSBAR: Add support for Crossbar IP
From: Sricharan R @ 2014-02-03 11:29 UTC (permalink / raw)
Cc: linux-kernel, devicetree, linux-doc, linux-arm-kernel, linux-omap,
linus.walleij, linux, tony, rnayak, marc.zyngier, grant.likely,
mark.rutland, robherring2, tglx, galak, rob.herring,
santosh.shilimkar, nm, bcousson, Kevin Hilman, Sricharan R
In-Reply-To: <52D7B2CA.8080902@ti.com>
Hi Thomas,
On Thursday 16 January 2014 03:52 PM, Sricharan R wrote:
> Hi Thomas,
>
> On Tuesday 03 December 2013 03:57 PM, Sricharan R wrote:
>> Some socs have a large number of interrupts requests to service
>> the needs of its many peripherals and subsystems. All of the
>> interrupt lines from the subsystems are not needed at the same
>> time, so they have to be muxed to the irq-controller appropriately.
>> In such places a interrupt controllers are preceded by an CROSSBAR
>> that provides flexibility in muxing the device requests to the controller
>> inputs.
>>
>> This driver takes care a allocating a free irq and then configuring the
>> crossbar IP as a part of the mpu's irqchip callbacks. crossbar_init should
>> be called right before the irqchip_init, so that it is setup to handle the
>> irqchip callbacks.
>>
>> Cc: Thomas Gleixner <tglx@linutronix.de>
>> Cc: Linus Walleij <linus.walleij@linaro.org>
>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Cc: Russell King <linux@arm.linux.org.uk>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Rajendra Nayak <rnayak@ti.com>
>> Cc: Marc Zyngier <marc.zyngier@arm.com>
>> Cc: Grant Likely <grant.likely@linaro.org>
>> Cc: Rob Herring <rob.herring@calxeda.com>
>> Signed-off-by: Sricharan R <r.sricharan@ti.com>
>> Acked-by: Kumar Gala <galak@codeaurora.org> (for DT binding portion)
>> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
>> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> [v5] Used the function of_property_read_u32_index instead of raw reading
>> from DT as per comments from Mark Rutland <mark.rutland@arm.com>
>>
>> .../devicetree/bindings/arm/omap/crossbar.txt | 27 +++
>> drivers/irqchip/Kconfig | 8 +
>> drivers/irqchip/Makefile | 1 +
>> drivers/irqchip/irq-crossbar.c | 208 ++++++++++++++++++++
>> include/linux/irqchip/irq-crossbar.h | 11 ++
>> 5 files changed, 255 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> create mode 100644 drivers/irqchip/irq-crossbar.c
>> create mode 100644 include/linux/irqchip/irq-crossbar.h
>>
>> diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> new file mode 100644
>> index 0000000..fb88585
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
>> @@ -0,0 +1,27 @@
>> +Some socs have a large number of interrupts requests to service
>> +the needs of its many peripherals and subsystems. All of the
>> +interrupt lines from the subsystems are not needed at the same
>> +time, so they have to be muxed to the irq-controller appropriately.
>> +In such places a interrupt controllers are preceded by an CROSSBAR
>> +that provides flexibility in muxing the device requests to the controller
>> +inputs.
>> +
>> +Required properties:
>> +- compatible : Should be "ti,irq-crossbar"
>> +- reg: Base address and the size of the crossbar registers.
>> +- ti,max-irqs: Total number of irqs available at the interrupt controller.
>> +- ti,reg-size: Size of a individual register in bytes. Every individual
>> + register is assumed to be of same size. Valid sizes are 1, 2, 4.
>> +- ti,irqs-reserved: List of the reserved irq lines that are not muxed using
>> + crossbar. These interrupt lines are reserved in the soc,
>> + so crossbar bar driver should not consider them as free
>> + lines.
>> +
>> +Examples:
>> + crossbar_mpu: @4a020000 {
>> + compatible = "ti,irq-crossbar";
>> + reg = <0x4a002a48 0x130>;
>> + ti,max-irqs = <160>;
>> + ti,reg-size = <2>;
>> + ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
>> + };
>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>> index 3792a1a..2efcde6 100644
>> --- a/drivers/irqchip/Kconfig
>> +++ b/drivers/irqchip/Kconfig
>> @@ -61,3 +61,11 @@ config VERSATILE_FPGA_IRQ_NR
>> int
>> default 4
>> depends on VERSATILE_FPGA_IRQ
>> +
>> +config IRQ_CROSSBAR
>> + bool
>> + help
>> + Support for a CROSSBAR ip that preceeds the main interrupt controller.
>> + The primary irqchip invokes the crossbar's callback which inturn allocates
>> + a free irq and configures the IP. Thus the peripheral interrupts are
>> + routed to one of the free irqchip interrupt lines.
>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>> index c60b901..2edead9 100644
>> --- a/drivers/irqchip/Makefile
>> +++ b/drivers/irqchip/Makefile
>> @@ -22,3 +22,4 @@ obj-$(CONFIG_RENESAS_IRQC) += irq-renesas-irqc.o
>> obj-$(CONFIG_VERSATILE_FPGA_IRQ) += irq-versatile-fpga.o
>> obj-$(CONFIG_ARCH_VT8500) += irq-vt8500.o
>> obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
>> +obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
>> diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
>> new file mode 100644
>> index 0000000..ae605a3
>> --- /dev/null
>> +++ b/drivers/irqchip/irq-crossbar.c
>> @@ -0,0 +1,208 @@
>> +/*
>> + * drivers/irqchip/irq-crossbar.c
>> + *
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
>> + * Author: Sricharan R <r.sricharan@ti.com>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +#include <linux/err.h>
>> +#include <linux/io.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/slab.h>
>> +#include <linux/irqchip/arm-gic.h>
>> +
>> +#define IRQ_FREE -1
>> +#define GIC_IRQ_START 32
>> +
>> +/*
>> + * @int_max: maximum number of supported interrupts
>> + * @irq_map: array of interrupts to crossbar number mapping
>> + * @crossbar_base: crossbar base address
>> + * @register_offsets: offsets for each irq number
>> + */
>> +struct crossbar_device {
>> + uint int_max;
>> + uint *irq_map;
>> + void __iomem *crossbar_base;
>> + int *register_offsets;
>> + void (*write) (int, int);
>> +};
>> +
>> +static struct crossbar_device *cb;
>> +
>> +static inline void crossbar_writel(int irq_no, int cb_no)
>> +{
>> + writel(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
>> +}
>> +
>> +static inline void crossbar_writew(int irq_no, int cb_no)
>> +{
>> + writew(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
>> +}
>> +
>> +static inline void crossbar_writeb(int irq_no, int cb_no)
>> +{
>> + writeb(cb_no, cb->crossbar_base + cb->register_offsets[irq_no]);
>> +}
>> +
>> +static inline int allocate_free_irq(int cb_no)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < cb->int_max; i++) {
>> + if (cb->irq_map[i] == IRQ_FREE) {
>> + cb->irq_map[i] = cb_no;
>> + return i;
>> + }
>> + }
>> +
>> + return -ENODEV;
>> +}
>> +
>> +static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
>> + irq_hw_number_t hw)
>> +{
>> + cb->write(hw - GIC_IRQ_START, cb->irq_map[hw - GIC_IRQ_START]);
>> + return 0;
>> +}
>> +
>> +static void crossbar_domain_unmap(struct irq_domain *d, unsigned int irq)
>> +{
>> + irq_hw_number_t hw = irq_get_irq_data(irq)->hwirq;
>> +
>> + if (hw > GIC_IRQ_START)
>> + cb->irq_map[hw - GIC_IRQ_START] = IRQ_FREE;
>> +}
>> +
>> +static int crossbar_domain_xlate(struct irq_domain *d,
>> + struct device_node *controller,
>> + const u32 *intspec, unsigned int intsize,
>> + unsigned long *out_hwirq,
>> + unsigned int *out_type)
>> +{
>> + unsigned long ret;
>> +
>> + ret = allocate_free_irq(intspec[1]);
>> +
>> + if (IS_ERR_VALUE(ret))
>> + return ret;
>> +
>> + *out_hwirq = ret + GIC_IRQ_START;
>> + return 0;
>> +}
>> +
>> +const struct irq_domain_ops routable_irq_domain_ops = {
>> + .map = crossbar_domain_map,
>> + .unmap = crossbar_domain_unmap,
>> + .xlate = crossbar_domain_xlate
>> +};
>> +
>> +static int __init crossbar_of_init(struct device_node *node)
>> +{
>> + int i, size, max, reserved = 0, entry;
>> + const __be32 *irqsr;
>> +
>> + cb = kzalloc(sizeof(struct cb_device *), GFP_KERNEL);
>> +
>> + if (!cb)
>> + return -ENOMEM;
>> +
>> + cb->crossbar_base = of_iomap(node, 0);
>> + if (!cb->crossbar_base)
>> + goto err1;
>> +
>> + of_property_read_u32(node, "ti,max-irqs", &max);
>> + cb->irq_map = kzalloc(max * sizeof(int), GFP_KERNEL);
>> + if (!cb->irq_map)
>> + goto err2;
>> +
>> + cb->int_max = max;
>> +
>> + for (i = 0; i < max; i++)
>> + cb->irq_map[i] = IRQ_FREE;
>> +
>> + /* Get and mark reserved irqs */
>> + irqsr = of_get_property(node, "ti,irqs-reserved", &size);
>> + if (irqsr) {
>> + size /= sizeof(__be32);
>> +
>> + for (i = 0; i < size; i++) {
>> + of_property_read_u32_index(node,
>> + "ti,irqs-reserved",
>> + i, &entry);
>> + if (entry > max) {
>> + pr_err("Invalid reserved entry\n");
>> + goto err3;
>> + }
>> + cb->irq_map[entry] = 0;
>> + }
>> + }
>> +
>> + cb->register_offsets = kzalloc(max * sizeof(int), GFP_KERNEL);
>> + if (!cb->register_offsets)
>> + goto err3;
>> +
>> + of_property_read_u32(node, "ti,reg-size", &size);
>> +
>> + switch (size) {
>> + case 1:
>> + cb->write = crossbar_writeb;
>> + break;
>> + case 2:
>> + cb->write = crossbar_writew;
>> + break;
>> + case 4:
>> + cb->write = crossbar_writel;
>> + break;
>> + default:
>> + pr_err("Invalid reg-size property\n");
>> + goto err4;
>> + break;
>> + }
>> +
>> + /*
>> + * Register offsets are not linear because of the
>> + * reserved irqs. so find and store the offsets once.
>> + */
>> + for (i = 0; i < max; i++) {
>> + if (!cb->irq_map[i])
>> + continue;
>> +
>> + cb->register_offsets[i] = reserved;
>> + reserved += size;
>> + }
>> +
>> + register_routable_domain_ops(&routable_irq_domain_ops);
>> + return 0;
>> +
>> +err4:
>> + kfree(cb->register_offsets);
>> +err3:
>> + kfree(cb->irq_map);
>> +err2:
>> + iounmap(cb->crossbar_base);
>> +err1:
>> + kfree(cb);
>> + return -ENOMEM;
>> +}
>> +
>> +static const struct of_device_id crossbar_match[] __initconst = {
>> + { .compatible = "ti,irq-crossbar" },
>> + {}
>> +};
>> +
>> +int irqcrossbar_init(void)
>> +{
>> + struct device_node *np;
>> + np = of_find_matching_node(NULL, crossbar_match);
>> + if (!np)
>> + return -ENODEV;
>> +
>> + crossbar_of_init(np);
>> + return 0;
>> +}
>> diff --git a/include/linux/irqchip/irq-crossbar.h b/include/linux/irqchip/irq-crossbar.h
>> new file mode 100644
>> index 0000000..e5537b8
>> --- /dev/null
>> +++ b/include/linux/irqchip/irq-crossbar.h
>> @@ -0,0 +1,11 @@
>> +/*
>> + * drivers/irqchip/irq-crossbar.h
>> + *
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +int irqcrossbar_init(void);
>
> I already have your reviewed-by tag for the first patch in this series.
>
> Kevin was pointing out that irqchip maintainer tag is needed for this patch as well
> to be merged. We are planning to take this series through arm-soc tree.
>
> Can i please have your tag for this patch as well ?
>
Ping..
Regards,
Sricharan
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Ian Campbell @ 2014-02-03 11:14 UTC (permalink / raw)
To: Christoffer Dall
Cc: Christopher Covington, Mark Rutland, devicetree, Arnd Bergmann,
Pawel Moll, Stefano Stabellini, Marc Zyngier, Will Deacon,
linux-kernel, Rob Herring, Kumar Gala, Olof Johansson,
linux-arm-kernel
In-Reply-To: <20140203045638.GB4167@cbox>
On Sun, 2014-02-02 at 20:56 -0800, Christoffer Dall wrote:
> On Thu, Jan 30, 2014 at 11:54:46AM -0500, Christopher Covington wrote:
> > Hi Ian,
> >
> > On 01/30/2014 11:11 AM, Ian Campbell wrote:
> > > mach-virt has existed for a while but it is not written down what it actually
> > > consists of. Although it seems a bit unusual to document a binding for an
> > > entire platform since mach-virt is entirely virtual it is helpful to have
> > > something to refer to in the absence of a single concrete implementation.
> > >
> > > I've done my best to capture the requirements based on the git log and my
> > > memory/understanding.
> > >
> > > While here remove the xenvm dts example, the Xen tools will now build a
> > > suitable mach-virt compatible dts when launching the guest.
> >
>
> [...]
>
> > > +The platform may also provide hypervisor specific functionality
> > > +(e.g. PV I/O), if it does so then this functionality must be
> > > +discoverable (directly or indirectly) via device tree.
> >
> > I think it would be informative to provide pointers here to commonly used
> > paravirtualized devices, especially VirtIO PCI/MMIO.
> >
>
> I disagree: that would only encourage limited testing or assumptions
> about these specific devices when really this platform is just a
> bare-bones platform driven by device tree which should make no
> preference, whatsoever, about which devices are used with the platform.
Thanks, I think this is exactly what I was failing to express coherently
last week ;-)
Ian.
^ permalink raw reply
* Re: [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
From: Lee Jones @ 2014-02-03 11:02 UTC (permalink / raw)
To: Linus Walleij
Cc: devicetree@vger.kernel.org, Dmitry Torokhov, Linux Input,
Samuel Ortiz, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Mark Rutland
In-Reply-To: <CACRpkdaX7AO3C-N+OMCqtQvFUmHmVRfMhPqGY2LciZQHT7iq+g@mail.gmail.com>
> >> > Patch looks good to me. Is there any reason why we should rush this in
> >> > for v3.14, or is it okay to go to -next?
> >>
> >> No rush, but it's been on review like forever so unless there is
> >> some noise from the DT people at -rc1 I'd be very happy if you
> >> could apply patches 1 & 2 by then.
> >
> > I'm just waiting for their Ack. If I don't have it soon I'll review it
> > myself and any changes will have to come in via subsequent patch
> > submissions.
> >
> > I think it's sensible to head for v3.15 for this set.
>
> So now that v3.14-rc1 is out can we queue this stuff?
Queued.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-input" 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 2/3 RESEND] mfd: tc3589x: Reform device tree probing
From: Lee Jones @ 2014-02-03 11:01 UTC (permalink / raw)
To: Linus Walleij
Cc: devicetree, Dmitry Torokhov, linux-input, Samuel Ortiz,
linux-kernel, linux-arm-kernel, Mark Rutland
In-Reply-To: <1390481008-23900-1-git-send-email-linus.walleij@linaro.org>
> This changes the following mechanisms in the TC3589x device tree
> probing path:
>
> - Use the .of_match_table in struct device_driver to match the
> device in the device tree.
> - Add matches for the proper compatible strings "toshiba,..."
> and all sub-variants, just as is done for the .id matches.
> - Move over all the allocation of platform data etc to the
> tc3589x_of_probe() function and follow the pattern of passing
> a platform data pointer back, or an error pointer on error,
> as found in the STMPE driver.
> - Match the new (proper) compatible strings for the GPIO and
> keypad MFD cells.
> - Use of_device_is_compatible() rather than just !strcmp()
> to discover which cells to instantiate.
>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
> ---
> drivers/mfd/tc3589x.c | 84 ++++++++++++++++++++++++++++++++++++---------------
> 1 file changed, 59 insertions(+), 25 deletions(-)
Looks good, applied.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-input" 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 v5 13/14] ARM: sun4i: dts: Add ahci / sata support
From: Hans de Goede @ 2014-02-03 10:35 UTC (permalink / raw)
To: Maxime Ripard
Cc: Tejun Heo, Oliver Schinagl, Richard Zhu, Roger Quadros,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20140131134505.GG2950@lukather>
Hi,
On 01/31/2014 02:45 PM, Maxime Ripard wrote:
> Hi Hans,
>
> On Wed, Jan 22, 2014 at 08:04:48PM +0100, Hans de Goede wrote:
>> From: Oliver Schinagl <oliver-dxLnbx3+1qmEVqv0pETR8A@public.gmane.org>
>>
>> This patch adds sunxi sata support to A10 boards that have such a connector.
>> Some boards also feature a regulator via a GPIO and support for this is also
>> added.
>>
>> Signed-off-by: Olliver Schinagl <oliver-dxLnbx3+1qmEVqv0pETR8A@public.gmane.org>
>> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> ---
>> arch/arm/boot/dts/sun4i-a10-a1000.dts | 4 ++++
>> arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 6 +++++
>> arch/arm/boot/dts/sun4i-a10.dtsi | 8 +++++++
>> arch/arm/boot/dts/sunxi-ahci-reg.dtsi | 38 ++++++++++++++++++++++++++++++
>
> I'm still half convinced about this at the moment, given the number of
> platforms we support, we can always change it back if things become too messy.
I assume that this == sunxi-ahci-reg.dtsi ? To be sure I understand you correctly,
you're ok with going this route for now, right ?
How about the same for the usb ohci/ehci controller dts patches ? Currently they
are still using the put a regulator node in each dts file model, which leads to
a lot of boilerplate code. So I would like to move to the same model as I'm
using here for the sata supply.
>
>> 4 files changed, 56 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sunxi-ahci-reg.dtsi
>>
>> diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> index aef8207..3fb7305 100644
>> --- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> +++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> @@ -48,6 +48,10 @@
>> status = "okay";
>> };
>>
>> + ahci: sata@01c18000 {
>> + status = "okay";
>> + };
>> +
>> pinctrl@01c20800 {
>> mmc0_cd_pin_a1000: mmc0_cd_pin@0 {
>> allwinner,pins = "PH1";
>> diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> index f50fb2b..6ae1110 100644
>> --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> @@ -12,6 +12,7 @@
>>
>> /dts-v1/;
>> /include/ "sun4i-a10.dtsi"
>> +/include/ "sunxi-ahci-reg.dtsi"
>>
>> / {
>> model = "Cubietech Cubieboard";
>> @@ -51,6 +52,11 @@
>> status = "okay";
>> };
>>
>> + ahci: sata@01c18000 {
>> + target-supply = <®_ahci_5v>;
>> + status = "okay";
>> + };
>> +
>> pinctrl@01c20800 {
>> mmc0_cd_pin_cubieboard: mmc0_cd_pin@0 {
>> allwinner,pins = "PH1";
>> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
>> index 4736dd2..198dcda 100644
>> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
>> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
>> @@ -331,6 +331,14 @@
>> status = "disabled";
>> };
>>
>> + ahci: sata@01c18000 {
>> + compatible = "allwinner,sun4i-a10-ahci";
>
> To be consistent with the rest of the sun4i devices compatible, It
> should be sun4i-ahci.
>
> However, since these devices don't use the same compatible pattern as
> their own machine compatible, and are consisent with the rest of the
> compatibles for the other SoCs, we can probably make this a go to
> transition progressively to this pattern.
Ack, I think it would be good to be consistent and try to use
sun?i-aXX-foo everywhere. I noticed that we already use that in various
places, so I thought it would be good to do that for all new dts bindings.
> I'll cook up some patches for the other devices.
Thanks.
>
>> + reg = <0x01c18000 0x1000>;
>> + interrupts = <56>;
>> + clocks = <&pll6 0>, <&ahb_gates 25>;
>> + status = "disabled";
>> + };
>> +
>> intc: interrupt-controller@01c20400 {
>> compatible = "allwinner,sun4i-ic";
>> reg = <0x01c20400 0x400>;
>> diff --git a/arch/arm/boot/dts/sunxi-ahci-reg.dtsi b/arch/arm/boot/dts/sunxi-ahci-reg.dtsi
>> new file mode 100644
>> index 0000000..955b197
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sunxi-ahci-reg.dtsi
>> @@ -0,0 +1,38 @@
>> +/*
>> + * sunxi boards sata target power supply common code
>> + *
>> + * Copyright 2014 - Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> + *
>> + * The code contained herein is licensed under the GNU General Public
>> + * License. You may obtain a copy of the GNU General Public License
>> + * Version 2 or later at the following locations:
>> + *
>> + * http://www.opensource.org/licenses/gpl-license.html
>> + * http://www.gnu.org/copyleft/gpl.html
>> + */
>> +
>> +/ {
>> + soc@01c00000 {
>> + ahci_pwr_pin_a: ahci_pwr_pin@0 {
>> + allwinner,pins = "PB8";
>> + allwinner,function = "gpio_out";
>> + allwinner,drive = <0>;
>> + allwinner,pull = <0>;
>> + };
>
> This should be under the pinctrl node.
Fixed already locally.
Regards,
Hans
^ permalink raw reply
* Re: [PATCH 2/3 RESEND] mfd: tc3589x: Reform device tree probing
From: Linus Walleij @ 2014-02-03 10:32 UTC (permalink / raw)
To: Lee Jones
Cc: devicetree@vger.kernel.org, Dmitry Torokhov, Linux Input,
Samuel Ortiz, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Mark Rutland
In-Reply-To: <20140123151123.GE8586@lee--X1>
On Thu, Jan 23, 2014 at 4:11 PM, Lee Jones <lee.jones@linaro.org> wrote:
>> > Patch looks good to me. Is there any reason why we should rush this in
>> > for v3.14, or is it okay to go to -next?
>>
>> No rush, but it's been on review like forever so unless there is
>> some noise from the DT people at -rc1 I'd be very happy if you
>> could apply patches 1 & 2 by then.
>
> I'm just waiting for their Ack. If I don't have it soon I'll review it
> myself and any changes will have to come in via subsequent patch
> submissions.
>
> I think it's sensible to head for v3.15 for this set.
So now that v3.14-rc1 is out can we queue this stuff?
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v10 1/2] [media] exynos5-is: Adds DT binding documentation
From: Arun Kumar K @ 2014-02-03 10:13 UTC (permalink / raw)
To: LMML, linux-samsung-soc, devicetree@vger.kernel.org
Cc: Sylwester Nawrocki, Mark Rutland, Shaik Ameer Basha, Arun Kumar
In-Reply-To: <1386911563-26236-2-git-send-email-arun.kk@samsung.com>
Hi Mark,
This patch and hence a full series of 13 patches is waiting for a long time now
due to your missing ack on this DT binding patch.
I have addressed your review comments given on earlier version -
http://www.spinics.net/lists/devicetree/msg11550.html
Please check this and give an ack if it is fine to be merged.
Regards
Arun
On Fri, Dec 13, 2013 at 10:42 AM, Arun Kumar K <arun.kk@samsung.com> wrote:
> From: Shaik Ameer Basha <shaik.ameer@samsung.com>
>
> The patch adds the DT binding doc for exynos5 SoC camera
> subsystem.
>
> Signed-off-by: Shaik Ameer Basha <shaik.ameer@samsung.com>
> Signed-off-by: Arun Kumar K <arun.kk@samsung.com>
> ---
> .../bindings/media/exynos5250-camera.txt | 136 ++++++++++++++++++++
> 1 file changed, 136 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/exynos5250-camera.txt
>
> diff --git a/Documentation/devicetree/bindings/media/exynos5250-camera.txt b/Documentation/devicetree/bindings/media/exynos5250-camera.txt
> new file mode 100644
> index 0000000..0c36bc4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/exynos5250-camera.txt
> @@ -0,0 +1,136 @@
> +Samsung EXYNOS5 SoC Camera Subsystem
> +------------------------------------
> +
> +The Exynos5 SoC Camera subsystem comprises of multiple sub-devices
> +represented by separate device tree nodes. Currently this includes: FIMC-LITE,
> +MIPI CSIS and FIMC-IS.
> +
> +The sub-device nodes are referenced using phandles in the common 'camera' node
> +which also includes common properties of the whole subsystem not really
> +specific to any single sub-device, like common camera port pins or the common
> +camera bus clocks.
> +
> +Common 'camera' node
> +--------------------
> +
> +Required properties:
> +
> +- compatible : must be "samsung,exynos5250-fimc"
> +- clocks : list of phandles and clock specifiers, corresponding
> + to entries in the clock-names property
> +- clock-names : must contain "sclk_bayer" entry
> +- samsung,csis : list of phandles to the mipi-csis device nodes
> +- samsung,fimc-lite : list of phandles to the fimc-lite device nodes
> +- samsung,fimc-is : phandle to the fimc-is device node
> +
> +The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
> +to define a required pinctrl state named "default".
> +
> +'parallel-ports' node
> +---------------------
> +
> +This node should contain child 'port' nodes specifying active parallel video
> +input ports. It includes camera A, camera B and RGB bay inputs.
> +'reg' property in the port nodes specifies the input type:
> + 1 - parallel camport A
> + 2 - parallel camport B
> + 5 - RGB camera bay
> +
> +3, 4 are for MIPI CSI-2 bus and are already described in samsung-mipi-csis.txt
> +
> +Required properties:
> +
> +For describing the input type in the child nodes, the following properties
> +have to be present in the parallel-ports node:
> +- #address-cells: Must be 1
> +- #size-cells: Must be 0
> +
> +Image sensor nodes
> +------------------
> +
> +The sensor device nodes should be added to their control bus controller (e.g.
> +I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
> +using the common video interfaces bindings, defined in video-interfaces.txt.
> +
> +Example:
> +
> + aliases {
> + fimc-lite0 = &fimc_lite_0
> + };
> +
> + /* Parallel bus IF sensor */
> + i2c_0: i2c@13860000 {
> + s5k6aa: sensor@3c {
> + compatible = "samsung,s5k6aafx";
> + reg = <0x3c>;
> + vddio-supply = <...>;
> +
> + clock-frequency = <24000000>;
> + clocks = <...>;
> + clock-names = "mclk";
> +
> + port {
> + s5k6aa_ep: endpoint {
> + remote-endpoint = <&fimc0_ep>;
> + bus-width = <8>;
> + hsync-active = <0>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + };
> + };
> + };
> + };
> +
> + /* MIPI CSI-2 bus IF sensor */
> + s5c73m3: sensor@1a {
> + compatible = "samsung,s5c73m3";
> + reg = <0x1a>;
> + vddio-supply = <...>;
> +
> + clock-frequency = <24000000>;
> + clocks = <...>;
> + clock-names = "mclk";
> +
> + port {
> + s5c73m3_1: endpoint {
> + data-lanes = <1 2 3 4>;
> + remote-endpoint = <&csis0_ep>;
> + };
> + };
> + };
> +
> + camera {
> + compatible = "samsung,exynos5250-fimc";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&cam_port_a_clk_active>;
> +
> + samsung,csis = <&csis_0>, <&csis_1>;
> + samsung,fimc-lite = <&fimc_lite_0>, <&fimc_lite_1>, <&fimc_lite_2>;
> + samsung,fimc-is = <&fimc_is>;
> +
> + /* parallel camera ports */
> + parallel-ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* camera A input */
> + port@1 {
> + reg = <1>;
> + camport_a_ep: endpoint {
> + remote-endpoint = <&s5k6aa_ep>;
> + bus-width = <8>;
> + hsync-active = <0>;
> + vsync-active = <1>;
> + pclk-sample = <1>;
> + };
> + };
> + };
> + };
> +
> +MIPI-CSIS device binding is defined in samsung-mipi-csis.txt, FIMC-LITE
> +device binding is defined in exynos-fimc-lite.txt and FIMC-IS binding
> +is defined in exynos5-fimc-is.txt.
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH] spi: rspi: fix build error when CONFIG_OF is not set
From: Geert Uytterhoeven @ 2014-02-03 8:47 UTC (permalink / raw)
To: Shimoda, Yoshihiro, Grant Likely, Rob Herring
Cc: Mark Brown, linux-spi, SH-Linux, devicetree,
Linux Kernel Development
In-Reply-To: <52EEF452.4060205@renesas.com>
Hi Shimoda-san,
On Mon, 3 Feb 2014, Shimoda, Yoshihiro wrote:
> This patch fixes an issue that the following build error happens when
> the CONFIG_OF is not set:
>
> drivers/spi/spi-rspi.c: In function 'rspi_probe':
> drivers/spi/spi-rspi.c:1203:26: error: 'rspi_of_match' undeclared (first use in this function)
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> ---
> This patch is based on the latest origin/topic/rspi branch in the spi.git.
>
> drivers/spi/spi-rspi.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c
> index 34ad4bc..e5cfc3d 100644
> --- a/drivers/spi/spi-rspi.c
> +++ b/drivers/spi/spi-rspi.c
> @@ -1164,6 +1164,7 @@ static int rspi_parse_dt(struct device *dev, struct spi_master *master)
> return 0;
> }
> #else
> +#define rspi_of_match NULL
> static inline int rspi_parse_dt(struct device *dev, struct spi_master *master)
> {
> return -EINVAL;
> --
> 1.7.1
Thanks, obviously I missed that of_match_device() still uses the ID table
parameter if CONFIG_OF=n :-(
Below I have two alternative solutions:
1. Uses rspi_of_match() to nullify the ID table pointer, like is done in
the platform_driver structure,
2. Fixes it at the OF subsystem level, by nullifying the ID table pointer
inside of_match_device().
If 2 is accepted, drivers don't have to care about this anymore.
What do you think?
>From 060b8577e95441ee3b29e966a9fdd19b2a870bdf Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Date: Mon, 3 Feb 2014 09:22:06 +0100
Subject: [PATCH 1/2] spi: rspi: fix build error when CONFIG_OF is not set
If CONFIG_OF=n:
drivers/spi/spi-rspi.c: In function 'rspi_probe':
drivers/spi/spi-rspi.c:1203:26: error: 'rspi_of_match' undeclared (first use in this function)
drivers/spi/spi-rspi.c:1203:26: note: each undeclared identifier is reported only once for each function it appears in
Use of_match_ptr() to fix this.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
drivers/spi/spi-rspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-rspi.c b/drivers/spi/spi-rspi.c
index 1c3aed63a2e0..df637184f6f0 100644
--- a/drivers/spi/spi-rspi.c
+++ b/drivers/spi/spi-rspi.c
@@ -1200,7 +1200,7 @@ static int rspi_probe(struct platform_device *pdev)
return -ENOMEM;
}
- of_id = of_match_device(rspi_of_match, &pdev->dev);
+ of_id = of_match_device(of_match_ptr(rspi_of_match), &pdev->dev);
if (of_id) {
ops = of_id->data;
ret = rspi_parse_dt(&pdev->dev, master);
--
1.7.9.5
>From 477ab825d43524959d68c3974e6e9536bd83bcde Mon Sep 17 00:00:00 2001
From: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
Date: Mon, 3 Feb 2014 09:27:40 +0100
Subject: [PATCH 2/2] [RFC] of/device: Nullify match table in
of_match_device() for CONFIG_OF=n
If the of_device_id table inside a device driver is protected by #ifdef
CONFIG_OF, the driver still has to provide a dummy declaration of the
table, or wrap it inside of_match_ptr(), when calling of_match_device()
in the CONFIG_OF=n case, else the driver fails to compile with e.g.
drivers/spi/spi-rspi.c: In function 'rspi_probe':
drivers/spi/spi-rspi.c:1203:26: error: 'rspi_of_match' undeclared (first use in this function)
drivers/spi/spi-rspi.c:1203:26: note: each undeclared identifier is reported only once for each function it appears in
Make of_match_device() nullify the table pointer if CONFIG_OF=n to fix
this.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@linux-m68k.org>
---
include/linux/of_device.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/of_device.h b/include/linux/of_device.h
index 82ce324fdce7..dac8bd2890ca 100644
--- a/include/linux/of_device.h
+++ b/include/linux/of_device.h
@@ -72,11 +72,13 @@ static inline int of_device_uevent_modalias(struct device *dev,
static inline void of_device_node_put(struct device *dev) { }
-static inline const struct of_device_id *of_match_device(
+static inline const struct of_device_id *__of_match_device(
const struct of_device_id *matches, const struct device *dev)
{
return NULL;
}
+#define of_match_device(matches, dev) \
+ __of_match_device(of_match_ptr(matches), (dev))
static inline struct device_node *of_cpu_device_node_get(int cpu)
{
--
1.7.9.5
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply related
* Re: [PATCH 1/4] ARM: STi: add stid127 soc support
From: Alexandre Torgue @ 2014-02-03 8:33 UTC (permalink / raw)
To: Arnd Bergmann, srinivas kandagatla
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King,
kernel-F5mvAk5X5gdBDgjK7y7TUQ, Linus Walleij, Patrice CHOTARD,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Stuart Menefy, Rob Herring,
Grant Likely, Giuseppe Cavallaro, maxime.coquelin-qxv4g6HH51o
In-Reply-To: <201401312115.33731.arnd-r2nGTMty4D4@public.gmane.org>
On 01/31/2014 09:15 PM, Arnd Bergmann wrote:
> On Friday 31 January 2014, srinivas kandagatla wrote:
>
>>> Sorry if I missed the initial review, but can you explain
>>> why this is needed to start with?
>> On ST SoCs the default value for L2 AUX_CTRL register is 0x0, so we set
>> the way-size explicit here.
> Unfortunately, we keep going back and forth on the L2 cache controller
> setup between "it should work automatically" and "we don't want to
> have configuration data in DT", where my personal opinion is that
> the first one is more important here.
>
> Now, there are a couple of properties that are defined in
> Documentation/devicetree/bindings/arm/l2cc.txt to let some of the
> things get set up automatically already. Can you check which bits
> are missing there, if any? Are they better described as "configuration"
> or "hardware" settings?
Hi Arnd,
Thanks for remarks. I will a have a look on it, but unfortunately not
before 2 weeks.
Alex.
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/6] Documentation: devicetree: sja1000: add reg-io-width binding
From: Florian Vaussard @ 2014-02-03 8:11 UTC (permalink / raw)
To: Marc Kleine-Budde, Wolfgang Grandegger
Cc: linux-can, netdev, linux-kernel, Grant Likely, Rob Herring,
Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, devicetree
In-Reply-To: <52EB9723.3080008@pengutronix.de>
On 01/31/2014 01:29 PM, Marc Kleine-Budde wrote:
> On 01/31/2014 11:35 AM, Florian Vaussard wrote:
>> Add the reg-io-width property to describe the width of the memory
>> accesses.
>>
>> Cc: Grant Likely <grant.likely@linaro.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
>> Acked-by: Rob Herring <robh@kernel.org>
>> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
>
> I think it makes sense to squash into patch 6.
>
According to recent guidelines from the DT maintainers [1], the
documentation part should be a separate patch. I guess it makes sense to
ease the review process for new bindings.
Regards
Florian
[1]
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/submitting-patches.txt
^ permalink raw reply
* Re: [PATCH 07/10] watchdog: xilinx: Fix OF binding
From: Michal Simek @ 2014-02-03 8:01 UTC (permalink / raw)
To: monstr-pSz03upnqPeHXe+LvDLADg
Cc: Rob Herring, Michal Simek,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Wim Van Sebroeck, Grant Likely, Rob Herring,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <52EF4C6F.8040701-pSz03upnqPeHXe+LvDLADg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4391 bytes --]
On 02/03/2014 08:59 AM, Michal Simek wrote:
> On 01/31/2014 06:33 PM, Rob Herring wrote:
>> On Fri, Jan 31, 2014 at 8:18 AM, Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org> wrote:
>>> Use of_property_read_u32 functions to clean OF probing.
>>
>> The subject is a bit misleading as this doesn't really fix anything.
>
> fair enough. Will change it.
>
>>
>>>
>>> Signed-off-by: Michal Simek <michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
>>> ---
>>>
>>> drivers/watchdog/of_xilinx_wdt.c | 25 ++++++++++---------------
>>> 1 file changed, 10 insertions(+), 15 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/of_xilinx_wdt.c b/drivers/watchdog/of_xilinx_wdt.c
>>> index c229cc4..475440a6 100644
>>> --- a/drivers/watchdog/of_xilinx_wdt.c
>>> +++ b/drivers/watchdog/of_xilinx_wdt.c
>>> @@ -147,8 +147,7 @@ static u32 xwdt_selftest(struct xwdt_device *xdev)
>>> static int xwdt_probe(struct platform_device *pdev)
>>> {
>>> int rc;
>>> - u32 *tmptr;
>>> - u32 *pfreq;
>>> + u32 pfreq, enable_once;
>>> struct resource *res;
>>> struct xwdt_device *xdev;
>>> bool no_timeout = false;
>>> @@ -168,28 +167,24 @@ static int xwdt_probe(struct platform_device *pdev)
>>> if (IS_ERR(xdev->base))
>>> return PTR_ERR(xdev->base);
>>>
>>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>>> - "clock-frequency", NULL);
>>> -
>>> - if (pfreq == NULL) {
>>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency", &pfreq);
>>> + if (rc) {
>>> dev_warn(&pdev->dev,
>>> "The watchdog clock frequency cannot be obtained\n");
>>> no_timeout = true;
>>
>> You can kill this...
>>
>>> }
>>>
>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>> - "xlnx,wdt-interval", NULL);
>>> - if (tmptr == NULL) {
>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
>>> + &xdev->wdt_interval);
>>> + if (rc) {
>>> dev_warn(&pdev->dev,
>>> "Parameter \"xlnx,wdt-interval\" not found\n");
>>> no_timeout = true;
>>
>> and this...
>>
>>> - } else {
>>> - xdev->wdt_interval = *tmptr;
>>> }
>>>
>>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>>> - "xlnx,wdt-enable-once", NULL);
>>> - if (tmptr == NULL) {
>>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
>>> + &enable_once);
>>> + if (!rc && enable_once) {
>>> dev_warn(&pdev->dev,
>>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>>> watchdog_set_nowayout(xilinx_wdt_wdd, true);
>>> @@ -201,7 +196,7 @@ static int xwdt_probe(struct platform_device *pdev)
>>> */
>>> if (!no_timeout)
>>
>> and use "if (pfreq && xdev->wdt_interval)" if you initialize pfreq to 0.
>
>
> I just wanted to to change functions not logic in the driver.
> But it can be changed too.
>
>>> xilinx_wdt_wdd->timeout = 2 * ((1 << xdev->wdt_interval) /
>>> - *pfreq);
>>> + pfreq);
>>
>> Is the wdog really usable if the timeout properties are missing? Seems
>> like you should fail to probe rather than warn.
>
> There are 2 things.
> 1. timeout - you don't need pfreq and wdt_interval to use this driver
> but for that there should be module parameter timeout there.
> It should be added.
>
> 2. about warn - based on 1 I don't think driver should failed
> but I am looking at logic above which I have added there but should be different.
>
> u32 enable_once = 0;
> if (!rc)
> dev_warn
>
if (rc) here sorry.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH 07/10] watchdog: xilinx: Fix OF binding
From: Michal Simek @ 2014-02-03 7:59 UTC (permalink / raw)
To: Rob Herring
Cc: Michal Simek, linux-kernel@vger.kernel.org, Wim Van Sebroeck,
Grant Likely, Rob Herring, linux-watchdog,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <CAL_JsqJ+Dc9PFVYcxHvLiG9unKQX-kEc1fsYsieyTjf-AN3j=A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4214 bytes --]
On 01/31/2014 06:33 PM, Rob Herring wrote:
> On Fri, Jan 31, 2014 at 8:18 AM, Michal Simek <michal.simek@xilinx.com> wrote:
>> Use of_property_read_u32 functions to clean OF probing.
>
> The subject is a bit misleading as this doesn't really fix anything.
fair enough. Will change it.
>
>>
>> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
>> ---
>>
>> drivers/watchdog/of_xilinx_wdt.c | 25 ++++++++++---------------
>> 1 file changed, 10 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/watchdog/of_xilinx_wdt.c b/drivers/watchdog/of_xilinx_wdt.c
>> index c229cc4..475440a6 100644
>> --- a/drivers/watchdog/of_xilinx_wdt.c
>> +++ b/drivers/watchdog/of_xilinx_wdt.c
>> @@ -147,8 +147,7 @@ static u32 xwdt_selftest(struct xwdt_device *xdev)
>> static int xwdt_probe(struct platform_device *pdev)
>> {
>> int rc;
>> - u32 *tmptr;
>> - u32 *pfreq;
>> + u32 pfreq, enable_once;
>> struct resource *res;
>> struct xwdt_device *xdev;
>> bool no_timeout = false;
>> @@ -168,28 +167,24 @@ static int xwdt_probe(struct platform_device *pdev)
>> if (IS_ERR(xdev->base))
>> return PTR_ERR(xdev->base);
>>
>> - pfreq = (u32 *)of_get_property(pdev->dev.of_node,
>> - "clock-frequency", NULL);
>> -
>> - if (pfreq == NULL) {
>> + rc = of_property_read_u32(pdev->dev.of_node, "clock-frequency", &pfreq);
>> + if (rc) {
>> dev_warn(&pdev->dev,
>> "The watchdog clock frequency cannot be obtained\n");
>> no_timeout = true;
>
> You can kill this...
>
>> }
>>
>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>> - "xlnx,wdt-interval", NULL);
>> - if (tmptr == NULL) {
>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-interval",
>> + &xdev->wdt_interval);
>> + if (rc) {
>> dev_warn(&pdev->dev,
>> "Parameter \"xlnx,wdt-interval\" not found\n");
>> no_timeout = true;
>
> and this...
>
>> - } else {
>> - xdev->wdt_interval = *tmptr;
>> }
>>
>> - tmptr = (u32 *)of_get_property(pdev->dev.of_node,
>> - "xlnx,wdt-enable-once", NULL);
>> - if (tmptr == NULL) {
>> + rc = of_property_read_u32(pdev->dev.of_node, "xlnx,wdt-enable-once",
>> + &enable_once);
>> + if (!rc && enable_once) {
>> dev_warn(&pdev->dev,
>> "Parameter \"xlnx,wdt-enable-once\" not found\n");
>> watchdog_set_nowayout(xilinx_wdt_wdd, true);
>> @@ -201,7 +196,7 @@ static int xwdt_probe(struct platform_device *pdev)
>> */
>> if (!no_timeout)
>
> and use "if (pfreq && xdev->wdt_interval)" if you initialize pfreq to 0.
I just wanted to to change functions not logic in the driver.
But it can be changed too.
>> xilinx_wdt_wdd->timeout = 2 * ((1 << xdev->wdt_interval) /
>> - *pfreq);
>> + pfreq);
>
> Is the wdog really usable if the timeout properties are missing? Seems
> like you should fail to probe rather than warn.
There are 2 things.
1. timeout - you don't need pfreq and wdt_interval to use this driver
but for that there should be module parameter timeout there.
It should be added.
2. about warn - based on 1 I don't think driver should failed
but I am looking at logic above which I have added there but should be different.
u32 enable_once = 0;
if (!rc)
dev_warn
if (enable_once)
watchdog_set_nowayout(xilinx_wdt_wdd, true);
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* Re: [PATCH] arm: document "mach-virt" platform.
From: Christoffer Dall @ 2014-02-03 4:56 UTC (permalink / raw)
To: Christopher Covington
Cc: Ian Campbell, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
Arnd Bergmann, Pawel Moll, Stefano Stabellini, Marc Zyngier,
Will Deacon, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
Kumar Gala, Olof Johansson,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <52EA83D6.9050506-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Thu, Jan 30, 2014 at 11:54:46AM -0500, Christopher Covington wrote:
> Hi Ian,
>
> On 01/30/2014 11:11 AM, Ian Campbell wrote:
> > mach-virt has existed for a while but it is not written down what it actually
> > consists of. Although it seems a bit unusual to document a binding for an
> > entire platform since mach-virt is entirely virtual it is helpful to have
> > something to refer to in the absence of a single concrete implementation.
> >
> > I've done my best to capture the requirements based on the git log and my
> > memory/understanding.
> >
> > While here remove the xenvm dts example, the Xen tools will now build a
> > suitable mach-virt compatible dts when launching the guest.
>
[...]
> > +The platform may also provide hypervisor specific functionality
> > +(e.g. PV I/O), if it does so then this functionality must be
> > +discoverable (directly or indirectly) via device tree.
>
> I think it would be informative to provide pointers here to commonly used
> paravirtualized devices, especially VirtIO PCI/MMIO.
>
I disagree: that would only encourage limited testing or assumptions
about these specific devices when really this platform is just a
bare-bones platform driven by device tree which should make no
preference, whatsoever, about which devices are used with the platform.
-Christoffer
--
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] arm: document "mach-virt" platform.
From: Christoffer Dall @ 2014-02-03 4:54 UTC (permalink / raw)
To: Ian Campbell
Cc: linux-kernel, Mark Rutland, devicetree, Pawel Moll,
Stefano Stabellini, Marc Zyngier, Will Deacon, Rob Herring,
Arnd Bergmann, Kumar Gala, Olof Johansson, linux-arm-kernel
In-Reply-To: <1391098262-15944-1-git-send-email-ian.campbell@citrix.com>
On Thu, Jan 30, 2014 at 04:11:02PM +0000, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
[...]
>
> +
> +The platform may also provide hypervisor specific functionality
> +(e.g. PV I/O), if it does so then this functionality must be
> +discoverable (directly or indirectly) via device tree.
While this is obviously true, I'm not sure I see the value of this text.
Isn't it more essential to just say that *any* functionality provided to
the platform must be discoverable via device tree?
-Christoffer
^ permalink raw reply
* [PATCH v3 8/8] ARM: dts: sun7i: Add ethernet alias for GMAC
From: Chen-Yu Tsai @ 2014-02-03 3:32 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
U-Boot will insert MAC address into the device tree image.
It looks up ethernet[0-5] aliases to find the ethernet nodes.
Alias GMAC as ethernet0, as it is the only ethernet controller used.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 65fb8d0..c48fb11 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -17,7 +17,7 @@
interrupt-parent = <&gic>;
aliases {
- ethernet0 = &emac;
+ ethernet0 = &gmac;
};
cpus {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v3 7/8] ARM: dts: sun7i: olinuxino-micro: Enable GMAC instead of EMAC
From: Chen-Yu Tsai @ 2014-02-03 3:32 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
GMAC has better performance and fewer hardware issues.
Use the GMAC in MII mode for ethernet instead of the EMAC.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 27 +++++++++++--------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index ead3013..b02a796 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -19,21 +19,6 @@
compatible = "olimex,a20-olinuxino-micro", "allwinner,sun7i-a20";
soc@01c00000 {
- emac: ethernet@01c0b000 {
- pinctrl-names = "default";
- pinctrl-0 = <&emac_pins_a>;
- phy = <&phy1>;
- status = "okay";
- };
-
- mdio@01c0b080 {
- status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
- };
-
pinctrl@01c20800 {
led_pins_olinuxino: led_pins@0 {
allwinner,pins = "PH2";
@@ -78,6 +63,18 @@
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c50000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_mii_a>;
+ phy = <&phy1>;
+ phy-mode = "mii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
leds {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v3 6/8] ARM: dts: sun7i: cubieboard2: Enable GMAC instead of EMAC
From: Chen-Yu Tsai @ 2014-02-03 3:32 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
GMAC has better performance and fewer hardware issues.
Use the GMAC in MII mode for ethernet instead of the EMAC.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
index 5c51cb8..7bf4935 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
@@ -19,21 +19,6 @@
compatible = "cubietech,cubieboard2", "allwinner,sun7i-a20";
soc@01c00000 {
- emac: ethernet@01c0b000 {
- pinctrl-names = "default";
- pinctrl-0 = <&emac_pins_a>;
- phy = <&phy1>;
- status = "okay";
- };
-
- mdio@01c0b080 {
- status = "okay";
-
- phy1: ethernet-phy@1 {
- reg = <1>;
- };
- };
-
pinctrl@01c20800 {
led_pins_cubieboard2: led_pins@0 {
allwinner,pins = "PH20", "PH21";
@@ -60,6 +45,18 @@
pinctrl-0 = <&i2c1_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c50000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_mii_a>;
+ phy = <&phy1>;
+ phy-mode = "mii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
leds {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v3 5/8] ARM: dts: sun7i: cubietruck: Enable the GMAC
From: Chen-Yu Tsai @ 2014-02-03 3:32 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
The CubieTruck uses the GMAC with an RGMII phy.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index f9dcb61..025ce52 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -51,6 +51,18 @@
pinctrl-0 = <&i2c2_pins_a>;
status = "okay";
};
+
+ gmac: ethernet@01c50000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac_pins_rgmii_a>;
+ phy = <&phy1>;
+ phy-mode = "rgmii";
+ status = "okay";
+
+ phy1: ethernet-phy@1 {
+ reg = <1>;
+ };
+ };
};
leds {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v3 4/8] ARM: dts: sun7i: Add pin muxing options for the GMAC
From: Chen-Yu Tsai @ 2014-02-03 3:32 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
The A20 has EMAC and GMAC muxed on the same pins.
Add pin sets with gmac function for MII and RGMII mode to the DTSI.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 26 ++++++++++++++++++++++++++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 5fbac23..65fb8d0 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -469,6 +469,32 @@
allwinner,drive = <0>;
allwinner,pull = <0>;
};
+
+ gmac_pins_mii_a: gmac_mii@0 {
+ allwinner,pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA9", "PA10",
+ "PA11", "PA12", "PA13", "PA14",
+ "PA15", "PA16";
+ allwinner,function = "gmac";
+ allwinner,drive = <0>;
+ allwinner,pull = <0>;
+ };
+
+ gmac_pins_rgmii_a: gmac_rgmii@0 {
+ allwinner,pins = "PA0", "PA1", "PA2",
+ "PA3", "PA4", "PA5", "PA6",
+ "PA7", "PA8", "PA10",
+ "PA11", "PA12", "PA13",
+ "PA15", "PA16";
+ allwinner,function = "gmac";
+ /*
+ * data lines in RGMII mode use DDR mode
+ * and need a higher signal drive strength
+ */
+ allwinner,drive = <3>;
+ allwinner,pull = <0>;
+ };
};
timer@01c20c00 {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v3 3/8] ARM: dts: sun7i: Add GMAC controller node to sun7i DTSI
From: Chen-Yu Tsai @ 2014-02-03 3:32 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index fc7f470..5fbac23 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -630,6 +630,21 @@
status = "disabled";
};
+ gmac: ethernet@01c50000 {
+ compatible = "allwinner,sun7i-a20-gmac";
+ reg = <0x01c50000 0x10000>;
+ interrupts = <0 85 4>;
+ interrupt-names = "macirq";
+ clocks = <&ahb_gates 49>, <&gmac_tx_clk>;
+ clock-names = "stmmaceth", "allwinner_gmac_tx";
+ snps,pbl = <2>;
+ snps,fixed-burst;
+ snps,force_sf_dma_mode;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
hstimer@01c60000 {
compatible = "allwinner,sun7i-a20-hstimer";
reg = <0x01c60000 0x1000>;
--
1.9.rc1
^ permalink raw reply related
* [PATCH v3 2/8] ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
From: Chen-Yu Tsai @ 2014-02-03 3:32 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
The GMAC uses 1 of 2 sources for its transmit clock, depending on the
PHY interface mode. Add both sources as dummy clocks, and as parents
to the GMAC clock node.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 1595e9a..fc7f470 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -314,6 +314,34 @@
};
/*
+ * The following two are dummy clocks, placeholders used
+ * on gmac_tx clock. The actual frequency and availability
+ * depends on the external PHY, operation mode and link
+ * speed.
+ */
+ mii_phy_tx_clk: clk@2 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "mii_phy_tx";
+ };
+
+ gmac_int_tx_clk: clk@3 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "gmac_int_tx";
+ };
+
+ gmac_tx_clk: clk@01c20164 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun7i-a20-gmac-clk";
+ reg = <0x01c20164 0x4>;
+ clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
+ clock-output-names = "gmac_tx";
+ };
+
+ /*
* Dummy clock used by output clocks
*/
osc24M_32k: clk@1 {
--
1.9.rc1
^ permalink raw reply related
* [PATCH v3 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Chen-Yu Tsai @ 2014-02-03 3:32 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1391398346-5094-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
The Allwinner A20/A31 clock module controls the transmit clock source
and interface type of the GMAC ethernet controller. Model this as
a single clock for GMAC drivers to use.
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/devicetree/bindings/clock/sunxi.txt | 26 +++++++
drivers/clk/sunxi/clk-sunxi.c | 83 +++++++++++++++++++++++
2 files changed, 109 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 0cf679b..f43b4c0 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -37,6 +37,7 @@ Required properties:
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
"allwinner,sun7i-a20-out-clk" - for the external output clocks
+ "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.
@@ -50,6 +51,9 @@ Required properties for all clocks:
If the clock module only has one output, the name shall be the
module name.
+For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
+dummy clocks at 25 MHz and 125 MHz, respectively. See example.
+
Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. This ID is the
@@ -96,3 +100,25 @@ mmc0_clk: clk@01c20088 {
clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
clock-output-names = "mmc0";
};
+
+mii_phy_tx_clk: clk@2 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <25000000>;
+ clock-output-names = "mii_phy_tx";
+};
+
+gmac_int_tx_clk: clk@3 {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <125000000>;
+ clock-output-names = "gmac_int_tx";
+};
+
+gmac_clk: clk@01c20164 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun7i-a20-gmac-clk";
+ reg = <0x01c20164 0x4>;
+ clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
+ clock-output-names = "gmac";
+};
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 736fb60..0b361d2 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -379,6 +379,89 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32 parent_rate,
/**
+ * sun7i_a20_gmac_clk_setup - Setup function for A20/A31 GMAC clock module
+ *
+ * This clock looks something like this
+ * ________________________
+ * MII TX clock from PHY >-----|___________ _________|----> to GMAC core
+ * GMAC Int. RGMII TX clk >----|___________\__/__gate---|----> to PHY
+ * Ext. 125MHz RGMII TX clk >--|__divider__/ |
+ * |________________________|
+ *
+ * The external 125 MHz reference is optional, i.e. GMAC can use its
+ * internal TX clock just fine. The A31 GMAC clock module does not have
+ * the divider controls for the external reference.
+ *
+ * To keep it simple, let the GMAC use either the MII TX clock for MII mode,
+ * and its internal TX clock for GMII and RGMII modes. The GMAC driver should
+ * select the appropriate source and gate/ungate the output to the PHY.
+ *
+ * Only the GMAC should use this clock. Altering the clock so that it doesn't
+ * match the GMAC's operation parameters will result in the GMAC not being
+ * able to send traffic out. The GMAC driver should set the clock rate and
+ * enable/disable this clock to configure the required state. The clock
+ * driver then responds by auto-reparenting the clock.
+ */
+
+#define SUN7I_A20_GMAC_GPIT 2
+#define SUN7I_A20_GMAC_MASK 0x3
+#define SUN7I_A20_GMAC_MAX_PARENTS 2
+
+static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_mux *mux;
+ struct clk_gate *gate;
+ const char *clk_name = node->name;
+ const char *parents[SUN7I_A20_GMAC_MAX_PARENTS];
+ void *reg;
+ int i = 0;
+
+ /* allocate mux and gate clock structs */
+ mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
+ if (!mux)
+ return;
+ gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
+ if (!gate) {
+ kfree(mux);
+ return;
+ }
+
+ reg = of_iomap(node, 0);
+
+ of_property_read_string(node, "clock-output-names", &clk_name);
+
+ while (i < SUN7I_A20_GMAC_MAX_PARENTS &&
+ (parents[i] = of_clk_get_parent_name(node, i)) != NULL)
+ i++;
+
+ /* set up gate and fixed rate properties */
+ gate->reg = reg;
+ gate->bit_idx = SUN7I_A20_GMAC_GPIT;
+ gate->lock = &clk_lock;
+ mux->reg = reg;
+ mux->mask = SUN7I_A20_GMAC_MASK;
+ mux->flags = CLK_MUX_INDEX_BIT;
+ mux->lock = &clk_lock;
+
+ clk = clk_register_composite(NULL, clk_name,
+ parents, i,
+ &mux->hw, &clk_mux_ops,
+ NULL, NULL,
+ &gate->hw, &clk_gate_ops,
+ 0);
+
+ if (!IS_ERR(clk)) {
+ of_clk_add_provider(node, of_clk_src_simple_get, clk);
+ clk_register_clkdev(clk, clk_name, NULL);
+ }
+}
+CLK_OF_DECLARE(sun7i_a20_gmac, "allwinner,sun7i-a20-gmac-clk",
+ sun7i_a20_gmac_clk_setup);
+
+
+
+/**
* sunxi_factors_clk_setup() - Setup function for factor clocks
*/
--
1.9.rc1
^ permalink raw reply related
* [PATCH v3 0/8] Add Allwinner A20 GMAC ethernet support
From: Chen-Yu Tsai @ 2014-02-03 3:32 UTC (permalink / raw)
To: Maxime Ripard, Emilio Lopez, Mike Turquette
Cc: Chen-Yu Tsai, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Hi,
This is the remaining part of v3 of the Allwinner A20 GMAC glue layer for
stmmac. The stmmac driver changes have been merged through net-next. The
remaining bits are clock and DT patches. The patches should be applied
over my clock renaming patches.
The Allwinner A20 SoC integrates an early version of dwmac
IP from Synopsys. On top of that is a hardware glue layer.
This layer needs to be configured before the dwmac can be
used.
Part of the glue layer is a clock mux, which controls the
source and direction of the TX clock used by GMAC.
Changes since v2:
* Added more comments on GMAC clock driver
* Drop CLK_SET_PARENT_GATE in GMAC clock driver
* Use macro for max clock parents
* Line wrapping
Changes since v1:
* Added optional reset control to stmmac driver core
* Added non CONFIG_RESET_CONROLLER routines for the above change
* Extended callback API, as discussed with Srinivas
* Used new stmmac_of_data to pass features and callbacks,
instead of platform data, as discussed
* Seperated clock module glue layer into clock driver
Cheers,
ChenYu
Chen-Yu Tsai (8):
clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
ARM: dts: sun7i: Add GMAC controller node to sun7i DTSI
ARM: dts: sun7i: Add pin muxing options for the GMAC
ARM: dts: sun7i: cubietruck: Enable the GMAC
ARM: dts: sun7i: cubieboard2: Enable GMAC instead of EMAC
ARM: dts: sun7i: olinuxino-micro: Enable GMAC instead of EMAC
ARM: dts: sun7i: Add ethernet alias for GMAC
Documentation/devicetree/bindings/clock/sunxi.txt | 26 +++++++
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 27 ++++----
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 12 ++++
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 27 ++++----
arch/arm/boot/dts/sun7i-a20.dtsi | 71 ++++++++++++++++++-
drivers/clk/sunxi/clk-sunxi.c | 83 +++++++++++++++++++++++
6 files changed, 215 insertions(+), 31 deletions(-)
--
1.9.rc1
^ permalink raw reply
* Re: [PATCH v2 RESEND 2/3] ARM: dts: clps711x: Add bindings documentation for CLPS711X irqchip driver
From: Rob Herring @ 2014-02-02 21:48 UTC (permalink / raw)
To: Alexander Shiyan
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Thomas Gleixner, Arnd Bergmann, Olof Johansson, Kevin Hilman,
Russell King, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1391328520-30923-1-git-send-email-shc_work-JGs/UdohzUI@public.gmane.org>
On Sun, Feb 2, 2014 at 2:08 AM, Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org> wrote:
> Add OF document for Cirrus Logic CLPS711X irqchip driver.
>
> Signed-off-by: Alexander Shiyan <shc_work-JGs/UdohzUI@public.gmane.org>
> ---
> .../interrupt-controller/cirrus,clps711x-intc.txt | 41 ++++++++++++++++++++++
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> 1 file changed, 41 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
>
> diff --git a/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
> new file mode 100644
> index 0000000..759339c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
> @@ -0,0 +1,41 @@
> +Cirrus Logic CLPS711X Interrupt Controller
> +
> +Required properties:
> +
> +- compatible: Should be "cirrus,clps711x-intc".
> +- reg: Specifies base physical address of the registers set.
> +- interrupt-controller: Identifies the node as an interrupt controller.
> +- #interrupt-cells: Specifies the number of cells needed to encode an
> + interrupt source. The value shall be 1.
> +
> +The interrupt sources are as follows:
> +ID Name Description
> +---------------------------
> +1: BLINT Battery low (FIQ)
> +3: MCINT Media changed (FIQ)
> +4: CSINT CODEC sound
> +5: EINT1 External 1
> +6: EINT2 External 2
> +7: EINT3 External 3
> +8: TC1OI TC1 under flow
> +9: TC2OI TC2 under flow
> +10: RTCMI RTC compare match
> +11: TINT 64Hz tick
> +12: UTXINT1 UART1 transmit FIFO half empty
> +13: URXINT1 UART1 receive FIFO half full
> +14: UMSINT UART1 modem status changed
> +15: SSEOTI SSI1 end of transfer
> +16: KBDINT Keyboard
> +17: SS2RX SSI2 receive FIFO half or greater full
> +18: SS2TX SSI2 transmit FIFO less than half empty
> +28: UTXINT2 UART2 transmit FIFO half empty
> +29: URXINT2 UART2 receive FIFO half full
> +32: DAIINT DAI interface (FIQ)
> +
> +Example:
> + intc: interrupt-controller {
> + compatible = "cirrus,clps711x-intc";
> + reg = <0x80000000 0x4000>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> + };
> --
> 1.8.3.2
>
> --
> 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
--
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
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