* [PATCH 0/5] ARM: dts: renesas: Remove skeleton.dtsi inclusion
From: Mark Rutland @ 2016-10-21 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477041370-22778-1-git-send-email-geert+renesas@glider.be>
On Fri, Oct 21, 2016 at 11:16:05AM +0200, Geert Uytterhoeven wrote:
> Hi Simon, Magnus,
>
> As of commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
> as deprecated"), including skeleton.dtsi is deprecated.
> Hence this series removes its use for all Renesas 32-bit ARM SoCs.
Thanks for doing this! FWIW, for the series:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Sekhar Nori @ 2016-10-21 9:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f6a0f61e-9d78-3df1-8e41-435eb47a1f00@ti.com>
On Friday 21 October 2016 02:55 PM, Tomi Valkeinen wrote:
> On 20/10/16 22:39, Kevin Hilman wrote:
>
>> However, after our discussion on IRC, we'll respin this without the DT
>> bindings at all. Next version will just use static configuration data
>> in the drivers/bus driver based on SoC compatible string, since for the
>> use-cases I'm aware of, the settings are boot-time only.
>
> If it's static boot time config, why not do it in the u-boot?
Hardware initialization dependencies with boot-loader are tough to track
and debug. The bootloader thats currently ships with the board may not
have these settings, for example. This forces everyone to update their
bootloader when shifting to mainline kernel.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Tomi Valkeinen @ 2016-10-21 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <278cac52-020f-da2f-54d7-e68d3b71eb65@ti.com>
On 21/10/16 12:53, Sekhar Nori wrote:
> On Friday 21 October 2016 02:55 PM, Tomi Valkeinen wrote:
>> On 20/10/16 22:39, Kevin Hilman wrote:
>>
>>> However, after our discussion on IRC, we'll respin this without the DT
>>> bindings at all. Next version will just use static configuration data
>>> in the drivers/bus driver based on SoC compatible string, since for the
>>> use-cases I'm aware of, the settings are boot-time only.
>>
>> If it's static boot time config, why not do it in the u-boot?
>
> Hardware initialization dependencies with boot-loader are tough to track
> and debug. The bootloader thats currently ships with the board may not
> have these settings, for example. This forces everyone to update their
> bootloader when shifting to mainline kernel.
Yep, true... We need something similar for AM335x too. And perhaps for
other SoCs too (AM4 comes to my mind).
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161021/4f710899/attachment.sig>
^ permalink raw reply
* [PATCH v5 5/7] ARM: dts: sun8i-h3: add HDMI audio and video nodes
From: Jean-Francois Moine @ 2016-10-21 10:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1477142934.git.moinejf@free.fr>
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
---
The patch for the A83T DT is not included in this patchset because
the clock driver sunxi-ng does not support the A83T clocks.
---
arch/arm/boot/dts/sun8i-h3.dtsi | 67 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 75a8654..869f3be 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -140,6 +140,16 @@
#size-cells = <1>;
ranges;
+ de: de-controller at 01000000 {
+ compatible = "allwinner,sun8i-h3-display-engine";
+ reg = <0x01000000 0x400000>;
+ clocks = <&ccu CLK_BUS_DE>, <&ccu CLK_DE>;
+ clock-names = "gate", "clock";
+ resets = <&ccu RST_BUS_DE>;
+ ports = <&lcd0_p>;
+ status = "disabled";
+ };
+
dma: dma-controller at 01c02000 {
compatible = "allwinner,sun8i-h3-dma";
reg = <0x01c02000 0x1000>;
@@ -149,6 +159,23 @@
#dma-cells = <1>;
};
+ lcd0: lcd-controller at 01c0c000 {
+ compatible = "allwinner,sun8i-a83t-lcd";
+ reg = <0x01c0c000 0x400>;
+ clocks = <&ccu CLK_BUS_TCON0>, <&ccu CLK_TCON0>;
+ clock-names = "gate", "clock";
+ resets = <&ccu RST_BUS_TCON0>;
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ lcd0_p: port {
+ lcd0_hdmi: endpoint {
+ remote-endpoint = <&hdmi_lcd0>;
+ };
+ };
+ };
+
mmc0: mmc at 01c0f000 {
compatible = "allwinner,sun7i-a20-mmc";
reg = <0x01c0f000 0x1000>;
@@ -439,6 +466,22 @@
status = "disabled";
};
+ i2s2: i2s at 1c22800 {
+ compatible = "allwinner,sun8i-h3-i2s";
+ reg = <0x01c22800 0x60>;
+ clocks = <&ccu CLK_I2S2>;
+ clock-names = "mod";
+ resets = <&ccu RST_BUS_I2S2>;
+ dmas = <&dma 27>;
+ dma-names = "tx";
+ status = "disabled";
+ port {
+ i2s2_hdmi: endpoint {
+ remote-endpoint = <&hdmi_i2s2>;
+ };
+ };
+ };
+
uart0: serial at 01c28000 {
compatible = "snps,dw-apb-uart";
reg = <0x01c28000 0x400>;
@@ -541,6 +584,30 @@
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ hdmi: hdmi at 01ee0000 {
+ compatible = "allwinner,sun8i-h3-hdmi";
+ reg = <0x01ee0000 0x20000>;
+ clocks = <&ccu CLK_HDMI>, <&ccu CLK_HDMI_DDC>;
+ clock-names = "clock", "ddc-clock";
+ resets = <&ccu RST_BUS_HDMI0>, <&ccu RST_BUS_HDMI1>;
+ reset-names = "hdmi0", "hdmi1";
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ port at 0 {
+ reg = <0>;
+ hdmi_lcd0: endpoint {
+ remote-endpoint = <&lcd0_hdmi>;
+ };
+ };
+ port at 1 {
+ reg = <1>;
+ hdmi_i2s2: endpoint {
+ remote-endpoint = <&i2s2_hdmi>;
+ };
+ };
+ };
+
rtc: rtc at 01f00000 {
compatible = "allwinner,sun6i-a31-rtc";
reg = <0x01f00000 0x54>;
--
2.10.1
^ permalink raw reply related
* [PATCH v2 1/9] irqchip: meson: add support for gpio interrupt controller
From: Mark Rutland @ 2016-10-21 10:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039751.15560.88.camel@baylibre.com>
On Fri, Oct 21, 2016 at 10:49:11AM +0200, Jerome Brunet wrote:
> On Thu, 2016-10-20 at 17:33 +0100, Marc Zyngier wrote:
> > On 19/10/16 16:21, Jerome Brunet wrote:
> > > +struct meson_gpio_irq_chip_data {
> > > + void __iomem *base;
> > > + int index;
> > > +};
> > > +
> > > +static irq_hw_number_t meson_parent_hwirqs[] = {
> > > + 64, 65, 66, 67, 68, 69, 70, 71,
> > > +};
> >
> > If that a guarantee that these numbers will always represent the
> > parent interrupt?
>
> At the moment, the 3 supported SoC use these parent interrupts, but we
> have absolutely no idea (or guarantee) that is will remain the same, or
> even contiguous, in the upcoming SoC (like the GXM or GXL)
>
> I reckon, it is likely that manufacturer will keep on using these
> parent irqs for a while but I would prefer not make an assumption about
> it in the driver.
>
> If a SoC get a different set of interrupts I would have added a new
> table like this and passed it to the appropriate params :
>
> static irq_hw_number_t meson_new_parent_hwirqs[] = {
> 143, 144, 150, 151, 152, 173, 178, 179,
> };
>
> > It feels a bit odd not to get that information directly from
> > the device tree, in the form of a device specific property. Something
> > like:
> >
> > upstream-interrupts = <64 65 66 ... >;
> >
>
> I wondered about putting this information in DT or in the driver for a
> while. Maybe DT would be a more suitable place holder for these data
> (parent irq and number of provided hwirq) but I was under the
> understanding that we should now put these information in the driver
> and use the compatible property to get the appropriate parameters.
>
> I'd love to get the view of the DT guys on this.
Please describe inter-device relationships in DT when you are aware of
them. The SoC-specific compatible string is more of a future-proofing
thing / last restort for things we realise too late.
To be clear, we should *also* have an soc-specific compatible string,
but for differences we already know about, we should use DT properties.
> > > +static const struct meson_gpio_irq_params meson8b_params = {
> > > + .nhwirq??= 119,
> > > + .source??= meson_parent_hwirqs,
> > > + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
> > > +};
> > > +
> > > +static const struct meson_gpio_irq_params meson_gxbb_params = {
> > > + .nhwirq??= 133,
> > > + .source??= meson_parent_hwirqs,
> > > + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
> > > +};
> >
> > Same thing. How big is the variability of these structures? Are we
> > going to see more of those? or is that now set into stone?
>
> The number of pad mapped to the controller seems to change with every
> SoC version. The parent irqs have not changed so far, but as explained
> above, there is no guarantee it will keep on being this way.
>
> So i'd say probably more of those ...
>
> > +Mark: what's the policy to describe this kind of things?
Generally, I'd prefer that we describe this in DT rather than
accumulating a set of string -> number mappings in the driver.
Thanks,
Mark.
^ permalink raw reply
* [STLinux Kernel] [PATCH v2 1/6] ARM: dts: STiH407: DT fix s/interrupts-names/interrupt-names/
From: Peter Griffin @ 2016-10-21 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039877-20227-2-git-send-email-geert+renesas@glider.be>
On Fri, 21 Oct 2016, Geert Uytterhoeven wrote:
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v2:
> - Add Acked-by.
> ---
Acked-by: Peter Griffin <peter.griffin@linaro.org>
^ permalink raw reply
* [PATCH] dt/bindings: arm-boards: Remove skeleton.dtsi inclusion from example
From: Geert Uytterhoeven @ 2016-10-21 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021094938.GB15372@leverpostej>
Hi Mark,
On Fri, Oct 21, 2016 at 11:50 AM, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Oct 21, 2016 at 11:20:29AM +0200, Geert Uytterhoeven wrote:
>> As of commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
>> as deprecated"), including skeleton.dtsi is deprecated.
>> Hence remove it from the example.
>>
>> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
>> ---
>> Documentation/devicetree/bindings/arm/arm-boards | 5 ++---
>> 1 file changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
>> index ab318a56fca2194f..e667ecbcf226dfe3 100644
>> --- a/Documentation/devicetree/bindings/arm/arm-boards
>> +++ b/Documentation/devicetree/bindings/arm/arm-boards
>> @@ -148,15 +148,14 @@ Example:
>>
>> /dts-v1/;
>> #include <dt-bindings/interrupt-controller/irq.h>
>> -#include "skeleton.dtsi"
>>
>> / {
>> model = "ARM RealView PB1176 with device tree";
>> compatible = "arm,realview-pb1176";
>> + #address-cells = <0>;
>> + #size-cells = <1>;
>>
>> soc {
>> - #address-cells = <1>;
>> - #size-cells = <1>;
>
> Strictly speaking, these two are still necessary for the ranges
> property. They're *not* inherited per the spec, no matter what Linux
> happens to do today.
I wasn't sure about that part of the change. OK, will fix.
> With those restored:
>
> Acked-by: Mark Rutland <mark.rutland@arm.com>
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH v2 1/9] irqchip: meson: add support for gpio interrupt controller
From: Jerome Brunet @ 2016-10-21 10:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021101029.GD15372@leverpostej>
On Fri, 2016-10-21 at 11:10 +0100, Mark Rutland wrote:
> On Fri, Oct 21, 2016 at 10:49:11AM +0200, Jerome Brunet wrote:
> >
> > On Thu, 2016-10-20 at 17:33 +0100, Marc Zyngier wrote:
> > >
> > > On 19/10/16 16:21, Jerome Brunet wrote:
> > > >
> > > > +struct meson_gpio_irq_chip_data {
> > > > + void __iomem *base;
> > > > + int index;
> > > > +};
> > > > +
> > > > +static irq_hw_number_t meson_parent_hwirqs[] = {
> > > > + 64, 65, 66, 67, 68, 69, 70, 71,
> > > > +};
> > >
> > > If that a guarantee that these numbers will always represent the
> > > parent interrupt?
> >
> > At the moment, the 3 supported SoC use these parent interrupts, but
> > we
> > have absolutely no idea (or guarantee) that is will remain the
> > same, or
> > even contiguous, in the upcoming SoC (like the GXM or GXL)
> >
> > I reckon, it is likely that manufacturer will keep on using these
> > parent irqs for a while but I would prefer not make an assumption
> > about
> > it in the driver.
> >
> > If a SoC get a different set of interrupts I would have added a new
> > table like this and passed it to the appropriate params :
> >
> > static irq_hw_number_t meson_new_parent_hwirqs[] = {
> > 143, 144, 150, 151, 152, 173, 178, 179,
> > };
> >
> > >
> > > It feels a bit odd not to get that information directly from
> > > the device tree, in the form of a device specific property.
> > > Something
> > > like:
> > >
> > > upstream-interrupts = <64 65 66 ... >;
> > >
> >
> > I wondered about putting this information in DT or in the driver
> > for a
> > while. Maybe DT would be a more suitable place holder for these
> > data
> > (parent irq and number of provided hwirq) but I was under the
> > understanding that we should now put these information in the
> > driver
> > and use the compatible property to get the appropriate parameters.
> >
> > I'd love to get the view of the DT guys on this.
>
> Please describe inter-device relationships in DT when you are aware
> of
> them. The SoC-specific compatible string is more of a future-proofing
> thing / last restort for things we realise too late.
>
> To be clear, we should *also* have an soc-specific compatible string,
> but for differences we already know about, we should use DT
> properties.
>
> >
> > >
> > > >
> > > > +static const struct meson_gpio_irq_params meson8b_params = {
> > > > + .nhwirq??= 119,
> > > > + .source??= meson_parent_hwirqs,
> > > > + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
> > > > +};
> > > > +
> > > > +static const struct meson_gpio_irq_params meson_gxbb_params =
> > > > {
> > > > + .nhwirq??= 133,
> > > > + .source??= meson_parent_hwirqs,
> > > > + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
> > > > +};
> > >
> > > Same thing. How big is the variability of these structures? Are
> > > we
> > > going to see more of those? or is that now set into stone?
> >
> > The number of pad mapped to the controller seems to change with
> > every
> > SoC version. The parent irqs have not changed so far, but as
> > explained
> > above, there is no guarantee it will keep on being this way.
> >
> > So i'd say probably more of those ...
> >
> > >
> > > +Mark: what's the policy to describe this kind of things?
>
> Generally, I'd prefer that we describe this in DT rather than
> accumulating a set of string -> number mappings in the driver.
Thx Marc. I will change it.
>
> Thanks,
> Mark.
^ permalink raw reply
* [PATCH] arm64: mm: fix __page_to_voff definition
From: Ard Biesheuvel @ 2016-10-21 10:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477040326-21260-1-git-send-email-neeraju@codeaurora.org>
On 21 October 2016 at 09:58, Neeraj Upadhyay <neeraju@codeaurora.org> wrote:
> Fix parameter name for __page_to_voff, to match its definition.
> At present, we don't see any issue, as page_to_virt's caller
> declares 'page'.
>
> Fixes: 9f2875912dac ("arm64: mm: restrict virt_to_page() to the linear mapping")
> Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
> ---
> arch/arm64/include/asm/memory.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
> index ba62df8..b71086d 100644
> --- a/arch/arm64/include/asm/memory.h
> +++ b/arch/arm64/include/asm/memory.h
> @@ -217,7 +217,7 @@ static inline void *phys_to_virt(phys_addr_t x)
> #define _virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
> #else
> #define __virt_to_pgoff(kaddr) (((u64)(kaddr) & ~PAGE_OFFSET) / PAGE_SIZE * sizeof(struct page))
> -#define __page_to_voff(kaddr) (((u64)(page) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
> +#define __page_to_voff(page) (((u64)(page) & ~VMEMMAP_START) * PAGE_SIZE / sizeof(struct page))
>
> #define page_to_virt(page) ((void *)((__page_to_voff(page)) | PAGE_OFFSET))
> #define virt_to_page(vaddr) ((struct page *)((__virt_to_pgoff(vaddr)) | VMEMMAP_START))
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
^ permalink raw reply
* [PATCH] kernel: irq: fix build failure
From: Stephen Rothwell @ 2016-10-21 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.20.1610211006370.4797@nanos>
Hi Thomas,
On Fri, 21 Oct 2016 10:07:41 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
>
> On Fri, 21 Oct 2016, Stephen Rothwell wrote:
> > On Thu, 20 Oct 2016 14:55:45 +0200 (CEST) Thomas Gleixner <tglx@linutronix.de> wrote:
> > > I know. This is under discussion with the driver folks as we are not going
> > > to blindly export stuff just because someone slapped a irq_set_parent()
> > > into the code w/o knowing why.
> >
> > Do we have any idea if a resolution is close. This was first reported
> > in linux-next in September 14/15. :-(
>
> Grr. Yes. As much as I hate it, I'll go and export it for now. Should be
> able to get it into rc2.
Thanks.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* [PATCH] net: stmmac: Add OXNAS Glue Driver
From: Joachim Eastwood @ 2016-10-21 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021084445.24989-1-narmstrong@baylibre.com>
Hi Neil,
On 21 October 2016 at 10:44, Neil Armstrong <narmstrong@baylibre.com> wrote:
> Add Synopsys Designware MAC Glue layer for the Oxford Semiconductor OX820.
>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/oxnas-dwmac.txt | 44 +++++
> drivers/net/ethernet/stmicro/stmmac/Kconfig | 11 ++
> drivers/net/ethernet/stmicro/stmmac/Makefile | 1 +
> drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c | 219 +++++++++++++++++++++
> 4 files changed, 275 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/oxnas-dwmac.txt
> create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
>
> Changes since RFC at https://patchwork.kernel.org/patch/9387257 :
> - Drop init/exit callbacks
> - Implement proper remove and PM callback
> - Call init from probe
> - Disable/Unprepare clock if stmmac probe fails
<snip>
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-oxnas.c
> @@ -0,0 +1,219 @@
> +/*
> + * Oxford Semiconductor OXNAS DWMAC glue layer
> + *
> + * Copyright (C) 2016 Neil Armstrong <narmstrong@baylibre.com>
> + * Copyright (C) 2014 Daniel Golle <daniel@makrotopia.org>
> + * Copyright (C) 2013 Ma Haijun <mahaijuns@gmail.com>
> + * Copyright (C) 2012 John Crispin <blogic@openwrt.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/mfd/syscon.h>
> +#include <linux/stmmac.h>
> +
> +#include "stmmac_platform.h"
> +
> +/* System Control regmap offsets */
> +#define OXNAS_DWMAC_CTRL_REGOFFSET 0x78
> +#define OXNAS_DWMAC_DELAY_REGOFFSET 0x100
> +
> +/* Control Register */
> +#define DWMAC_CKEN_RX_IN 14
> +#define DWMAC_CKEN_RXN_OUT 13
> +#define DWMAC_CKEN_RX_OUT 12
> +#define DWMAC_CKEN_TX_IN 10
> +#define DWMAC_CKEN_TXN_OUT 9
> +#define DWMAC_CKEN_TX_OUT 8
> +#define DWMAC_RX_SOURCE 7
> +#define DWMAC_TX_SOURCE 6
> +#define DWMAC_LOW_TX_SOURCE 4
> +#define DWMAC_AUTO_TX_SOURCE 3
> +#define DWMAC_RGMII 2
> +#define DWMAC_SIMPLE_MUX 1
> +#define DWMAC_CKEN_GTX 0
> +
> +/* Delay register */
> +#define DWMAC_TX_VARDELAY_SHIFT 0
> +#define DWMAC_TXN_VARDELAY_SHIFT 8
> +#define DWMAC_RX_VARDELAY_SHIFT 16
> +#define DWMAC_RXN_VARDELAY_SHIFT 24
> +#define DWMAC_TX_VARDELAY(d) ((d) << DWMAC_TX_VARDELAY_SHIFT)
> +#define DWMAC_TXN_VARDELAY(d) ((d) << DWMAC_TXN_VARDELAY_SHIFT)
> +#define DWMAC_RX_VARDELAY(d) ((d) << DWMAC_RX_VARDELAY_SHIFT)
> +#define DWMAC_RXN_VARDELAY(d) ((d) << DWMAC_RXN_VARDELAY_SHIFT)
> +
> +struct oxnas_dwmac {
> + struct device *dev;
> + struct clk *clk;
> + struct regmap *regmap;
> +};
> +
> +static int oxnas_dwmac_init(struct oxnas_dwmac *dwmac)
> +{
> + unsigned int value;
> + int ret;
> +
> + /* Reset HW here before changing the glue configuration */
> + ret = device_reset(dwmac->dev);
> + if (ret)
> + return ret;
> +
> + clk_prepare_enable(dwmac->clk);
You might want to check the return value from clk_prepare_enable() as well.
> +
> + ret = regmap_read(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, &value);
> + if (ret < 0)
> + return ret;
> +
> + /* Enable GMII_GTXCLK to follow GMII_REFCLK, required for gigabit PHY */
> + value |= BIT(DWMAC_CKEN_GTX);
> + /* Use simple mux for 25/125 Mhz clock switching */
> + value |= BIT(DWMAC_SIMPLE_MUX);
> + /* set auto switch tx clock source */
> + value |= BIT(DWMAC_AUTO_TX_SOURCE);
> + /* enable tx & rx vardelay */
> + value |= BIT(DWMAC_CKEN_TX_OUT);
> + value |= BIT(DWMAC_CKEN_TXN_OUT);
> + value |= BIT(DWMAC_CKEN_TX_IN);
> + value |= BIT(DWMAC_CKEN_RX_OUT);
> + value |= BIT(DWMAC_CKEN_RXN_OUT);
> + value |= BIT(DWMAC_CKEN_RX_IN);
> + regmap_write(dwmac->regmap, OXNAS_DWMAC_CTRL_REGOFFSET, value);
> +
> + /* set tx & rx vardelay */
> + value = DWMAC_TX_VARDELAY(4);
> + value |= DWMAC_TXN_VARDELAY(2);
> + value |= DWMAC_RX_VARDELAY(10);
> + value |= DWMAC_RXN_VARDELAY(8);
> + regmap_write(dwmac->regmap, OXNAS_DWMAC_DELAY_REGOFFSET, value);
> +
> + return 0;
> +}
> +
> +static int oxnas_dwmac_probe(struct platform_device *pdev)
> +{
> + struct plat_stmmacenet_data *plat_dat;
> + struct stmmac_resources stmmac_res;
> + struct device_node *sysctrl;
> + struct oxnas_dwmac *dwmac;
> + int ret;
> +
> + sysctrl = of_parse_phandle(pdev->dev.of_node, "oxsemi,sys-ctrl", 0);
> + if (!sysctrl) {
> + dev_err(&pdev->dev, "failed to get sys-ctrl node\n");
> + return -EINVAL;
> + }
> +
> + ret = stmmac_get_platform_resources(pdev, &stmmac_res);
> + if (ret)
> + return ret;
> +
> + plat_dat = stmmac_probe_config_dt(pdev, &stmmac_res.mac);
> + if (IS_ERR(plat_dat))
> + return PTR_ERR(plat_dat);
> +
> + dwmac = devm_kzalloc(&pdev->dev, sizeof(*dwmac), GFP_KERNEL);
> + if (!dwmac)
> + return -ENOMEM;
> +
> + dwmac->dev = &pdev->dev;
> + plat_dat->bsp_priv = dwmac;
> +
> + dwmac->regmap = syscon_node_to_regmap(sysctrl);
> + if (IS_ERR(dwmac->regmap)) {
> + dev_err(&pdev->dev, "failed to have sysctrl regmap\n");
> + return PTR_ERR(dwmac->regmap);
> + }
> +
> + dwmac->clk = devm_clk_get(&pdev->dev, "gmac");
> + if (IS_ERR(dwmac->clk))
> + return PTR_ERR(dwmac->clk);
> +
> + ret = oxnas_dwmac_init(dwmac);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_dvr_probe(&pdev->dev, plat_dat, &stmmac_res);
> + if (ret)
> + clk_disable_unprepare(dwmac->clk);
> +
> + return ret;
> +}
> +
> +static int oxnas_dwmac_remove(struct platform_device *pdev)
> +{
> + struct net_device *ndev = platform_get_drvdata(pdev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + struct oxnas_dwmac *dwmac = priv->plat->bsp_priv;
Instead of this long dance of variables use the get_stmmac_bsp_priv()-helper.
You can take a look at dwmac-meson8b.c for reference.
> + int ret = stmmac_dvr_remove(&pdev->dev);
> +
> + clk_disable_unprepare(dwmac->clk);
> +
> + return ret;
> +}
> +
> +#ifdef CONFIG_PM_SLEEP
> +static int oxnas_dwmac_suspend(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + struct oxnas_dwmac *dwmac = priv->plat->bsp_priv;
get_stmmac_bsp_priv()
> + int ret;
> +
> + ret = stmmac_suspend(dev);
> + clk_disable_unprepare(dwmac->clk);
> +
> + return ret;
> +}
> +
> +static int oxnas_dwmac_resume(struct device *dev)
> +{
> + struct net_device *ndev = dev_get_drvdata(dev);
> + struct stmmac_priv *priv = netdev_priv(ndev);
> + struct oxnas_dwmac *dwmac = priv->plat->bsp_priv;
get_stmmac_bsp_priv()
> + int ret;
> +
> + ret = oxnas_dwmac_init(dwmac);
> + if (ret)
> + return ret;
> +
> + ret = stmmac_resume(dev);
> +
> + return ret;
> +}
> +#endif /* CONFIG_PM_SLEEP */
With these changes:
Acked-by: Joachim Eastwood <manabian@gmail.com>
best regards,
Joachim Eastwood
^ permalink raw reply
* [PATCH] dt/bindings: arm-boards: Remove skeleton.dtsi inclusion from example
From: Geert Uytterhoeven @ 2016-10-21 10:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMuHMdVS3-xm+7gMkO59VtuN_pLAXSCNRBT1JekFE2cVbwngAQ@mail.gmail.com>
On Fri, Oct 21, 2016 at 12:16 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Fri, Oct 21, 2016 at 11:50 AM, Mark Rutland <mark.rutland@arm.com> wrote:
>> On Fri, Oct 21, 2016 at 11:20:29AM +0200, Geert Uytterhoeven wrote:
>>> --- a/Documentation/devicetree/bindings/arm/arm-boards
>>> +++ b/Documentation/devicetree/bindings/arm/arm-boards
>>> @@ -148,15 +148,14 @@ Example:
>>>
>>> /dts-v1/;
>>> #include <dt-bindings/interrupt-controller/irq.h>
>>> -#include "skeleton.dtsi"
>>>
>>> / {
>>> model = "ARM RealView PB1176 with device tree";
>>> compatible = "arm,realview-pb1176";
>>> + #address-cells = <0>;
How did I manage to turn the <1> into a <0> by moving and reindenting
two lines?!? Will fix, too.
>>> + #size-cells = <1>;
>>>
>>> soc {
>>> - #address-cells = <1>;
>>> - #size-cells = <1>;
>>
>> Strictly speaking, these two are still necessary for the ranges
>> property. They're *not* inherited per the spec, no matter what Linux
>> happens to do today.
>
> I wasn't sure about that part of the change. OK, will fix.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at 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
* [PATCH v2] dt/bindings: arm-boards: Remove skeleton.dtsi inclusion from example
From: Geert Uytterhoeven @ 2016-10-21 10:28 UTC (permalink / raw)
To: linux-arm-kernel
As of commit 9c0da3cc61f1233c ("ARM: dts: explicitly mark skeleton.dtsi
as deprecated"), including skeleton.dtsi is deprecated.
Hence remove it from the example.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Mark Rutland <mark.rutland@arm.com>
---
v2:
- Restore #address-cells/#size-cells in soc subnode,
- Add Acked-by,
- Correct #address-cells from <0> to <1>.
---
Documentation/devicetree/bindings/arm/arm-boards | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index ab318a56fca2194f..b6e810c2781a4ec8 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -148,11 +148,12 @@ Example:
/dts-v1/;
#include <dt-bindings/interrupt-controller/irq.h>
-#include "skeleton.dtsi"
/ {
model = "ARM RealView PB1176 with device tree";
compatible = "arm,realview-pb1176";
+ #address-cells = <1>;
+ #size-cells = <1>;
soc {
#address-cells = <1>;
--
1.9.1
^ permalink raw reply related
* [PATCH v2 1/9] irqchip: meson: add support for gpio interrupt controller
From: Marc Zyngier @ 2016-10-21 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1477039751.15560.88.camel@baylibre.com>
On 21/10/16 09:49, Jerome Brunet wrote:
> On Thu, 2016-10-20 at 17:33 +0100, Marc Zyngier wrote:
>> Jerome,
>>
>> On 19/10/16 16:21, Jerome Brunet wrote:
>>>
>>> Add support for the interrupt gpio controller found on Amlogic's
>>> meson
>>> SoC family.
>>>
>>> Unlike what the IP name suggest, it is not directly linked to the
>>> gpio
>>> subsystem. It is actually an independent IP that is able to spy on
>>> the
>>> SoC pad. For that purpose, it can mux and filter (edge or level and
>>> polarity) any single SoC pad to one of the 8 GIC's interrupts it
>>> owns.
>>>
>>> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
>>> ---
>>> drivers/irqchip/Kconfig | 9 +
>>> drivers/irqchip/Makefile | 1 +
>>> drivers/irqchip/irq-meson-gpio.c | 423
>>> +++++++++++++++++++++++++++++++++++++++
>>> 3 files changed, 433 insertions(+)
>>> create mode 100644 drivers/irqchip/irq-meson-gpio.c
>>>
>>> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
>>> index 82b0b5daf3f5..168837263e80 100644
>>> --- a/drivers/irqchip/Kconfig
>>> +++ b/drivers/irqchip/Kconfig
>>> @@ -279,3 +279,12 @@ config EZNPS_GIC
>>> config STM32_EXTI
>>> bool
>>> select IRQ_DOMAIN
>>> +
>>> +config MESON_GPIO_IRQ
>>> + bool "Meson GPIO Interrupt Multiplexer"
>>> + depends on ARCH_MESON || COMPILE_TEST
>>> + select IRQ_DOMAIN
>>> + select IRQ_DOMAIN_HIERARCHY
>>> + help
>>> + Support Meson SoC Family GPIO Interrupt Multiplexer
>>> +
>>> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
>>> index e4dbfc85abdb..33f913d037d0 100644
>>> --- a/drivers/irqchip/Makefile
>>> +++ b/drivers/irqchip/Makefile
>>> @@ -74,3 +74,4 @@ obj-$(CONFIG_LS_SCFG_MSI) += irq-
>>> ls-scfg-msi.o
>>> obj-$(CONFIG_EZNPS_GIC) += irq-eznps.o
>>> obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o
>>> obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
>>> +obj-$(CONFIG_MESON_GPIO_IRQ) += irq-meson-gpio.o
>>> diff --git a/drivers/irqchip/irq-meson-gpio.c
>>> b/drivers/irqchip/irq-meson-gpio.c
>>> new file mode 100644
>>> index 000000000000..869b4df8c483
>>> --- /dev/null
>>> +++ b/drivers/irqchip/irq-meson-gpio.c
>>> @@ -0,0 +1,423 @@
>>> +/*
>>> + * Copyright (c) 2015 Endless Mobile, Inc.
>>> + * Author: Carlo Caione <carlo@endlessm.com>
>>> + * Copyright (c) 2016 BayLibre, SAS.
>>> + * Author: Jerome Brunet <jbrunet@baylibre.com>
>>> + *
>>> + * This program is free software; you can redistribute it and/or
>>> modify
>>> + * it under the terms of version 2 of the GNU General Public
>>> License as
>>> + * published by the Free Software Foundation.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> but
>>> + * WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> GNU
>>> + * General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public
>>> License
>>> + * along with this program; if not, see <http://www.gnu.org/licens
>>> es/>.
>>> + * The full GNU General Public License is included in this
>>> distribution
>>> + * in the file called COPYING.
>>> + */
>>> +
>>> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>>> +
>>> +#include <linux/io.h>
>>> +#include <linux/module.h>
>>> +#include <linux/irq.h>
>>> +#include <linux/irqdomain.h>
>>> +#include <linux/irqchip.h>
>>> +#include <linux/of.h>
>>> +#include <linux/of_address.h>
>>> +
>>> +#define IRQ_FREE (-1)
>>> +
>>> +#define REG_EDGE_POL 0x00
>>> +#define REG_PIN_03_SEL 0x04
>>> +#define REG_PIN_47_SEL 0x08
>>> +#define REG_FILTER_SEL 0x0c
>>> +
>>> +#define REG_EDGE_POL_MASK(x) (BIT(x) | BIT(16 + (x)))
>>> +#define REG_EDGE_POL_EDGE(x) BIT(x)
>>> +#define REG_EDGE_POL_LOW(x) BIT(16 + (x))
>>> +#define REG_PIN_SEL_SHIFT(x) (((x) % 4) * 8)
>>> +#define REG_FILTER_SEL_SHIFT(x) ((x) * 4)
>>> +
>>> +struct meson_gpio_irq_params {
>>> + unsigned int nhwirq;
>>> + irq_hw_number_t *source;
>>> + int nsource;
>>> +};
>>> +
>>> +struct meson_gpio_irq_domain {
>>
>> The name of that structure is utterly confusing, as it doesn't
>> contain
>> anything related to an IRQ domain. Can you please clarify its usage?
>
> This structure is holding the data of the controller. The name is
> indeed misleading, I will change this. What about
> 'meson_gpio_irq_pdata' or 'meson_gpio_irq_controller' ?
>
>>
>>>
>>> + void __iomem *base;
>>> + int *map;
>>> + const struct meson_gpio_irq_params *params;
>>> +};
>>> +
>>> +struct meson_gpio_irq_chip_data {
>>> + void __iomem *base;
>>> + int index;
>>> +};
>>> +
>>> +static irq_hw_number_t meson_parent_hwirqs[] = {
>>> + 64, 65, 66, 67, 68, 69, 70, 71,
>>> +};
>>
>> If that a guarantee that these numbers will always represent the
>> parent interrupt?
>
> At the moment, the 3 supported SoC use these parent interrupts, but we
> have absolutely no idea (or guarantee) that is will remain the same, or
> even contiguous, in the upcoming SoC (like the GXM or GXL)
>
> I reckon, it is likely that manufacturer will keep on using these
> parent irqs for a while but I would prefer not make an assumption about
> it in the driver.
>
> If a SoC get a different set of interrupts I would have added a new
> table like this and passed it to the appropriate params :
>
> static irq_hw_number_t meson_new_parent_hwirqs[] = {
> 143, 144, 150, 151, 152, 173, 178, 179,
> };
>
>> It feels a bit odd not to get that information directly from
>> the device tree, in the form of a device specific property. Something
>> like:
>>
>> upstream-interrupts = <64 65 66 ... >;
>>
>
> I wondered about putting this information in DT or in the driver for a
> while. Maybe DT would be a more suitable place holder for these data
> (parent irq and number of provided hwirq) but I was under the
> understanding that we should now put these information in the driver
> and use the compatible property to get the appropriate parameters.
>
> I'd love to get the view of the DT guys on this.
>
> Also, since we already need to put some information about the pin the
> pinctrl driver (to get the appropriate mux value of each pad), I
> thought It would make sense to have the same approach here.
>
> If there is some kind of policy saying this should be in DT, I'd be
> happy to make the change.
>
>> or even as a base/range:
>>
>> upstream-interrupts = <64 8>;
>
> I would prefer to avoid using ranges as we have no guarantee the
> manufacturer will keep the parent irqs contiguous in the future.
>
>>
>> Also, how does it work if you have more than a single device like
>> this?
>> This driver seems a do a great deal of dynamic allocation, and yet
>> its
>> core resource is completely static... Please pick a side! ;-)
>
> I don't think we could have more than one instance per device and I
> certainly did not have this case in mind while writing the code. If it
> was the case someday, I guess having two compatibles would do the trick
> :)
This has nothing to do with compatible strings. Your current approach of
defining a static list of interrupts and then dynamically allocating
things that point directly to it feels wrong. just define a second
instance of this IP to be convinced of it.
So either you support something that is fully dynamic (supporting
multiple instances at every level), or you only support *one*, and
everything becomes mostly static.
>
>>
>>>
>>> +
>>> +static const struct meson_gpio_irq_params meson8_params = {
>>> + .nhwirq = 134,
>>> + .source = meson_parent_hwirqs,
>>> + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
>>
>> I find it utterly confusing that you are calling source something
>> that is an output for this controller.
>
> I had the call sequence (GIC->GPIO_IRQ->handler) in mind while writing
> it. I see your point and it is indeed confusing, I'll find something
> better
It infinitely better to describe the signal path rather than the call
stack (which is actually GIC->GPIO_IRQ->GIC->handler).
[...]
>>>
>>> +
>>> + cd = kzalloc(sizeof(*cd), GFP_KERNEL);
>>> + if (!cd)
>>> + return -ENOMEM;
>>> +
>>> + cd->base = domain_data->base;
>>> + cd->index = index;
>>
>> So what is the exact purpose of this structure? The base address is
>> essentially a global, or could be directly derived from the domain.
>> The
>> index is only used in set_type, and is the index of the pin connected
>> to
>> the GIC. It looks to me like you could have:
>>
>> irq_hw_number_t *out_line =
>> &meson_parent_hwirqs[index];
>
> meson_parent_hwirq is only declared this way to avoid writing the
> parent irqs 3 times (in each SoC params).
> Using it this way would make it global and imply it is the same
> whatever the SoC. This something I can't guarantee and I would prefer
> to avoid that.
Well, let's face it: It is global (see my earlier rant). And if you
device to support multiple instances, you can attach the parent array at
the irq domain level, and still perform that same index calculation.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 0/9] ARM: DRA7: Add support for DRA718-evm
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
This series does minor dts cleanup for dra72-evm and adds support for
DRA718-evm.
Changes since v1:
- Updated xxx-supply to xxx-in-supply in Documentation.
Lokesh Vutla (7):
ARM: dts: dra72-evm: Remove pinmux configurations for erratum i869
ARM: dra72-evm: Fix modelling of regulators
ARM: dts: dra72: Add separate dtsi for tps65917
regulator: lp873x: Add support for populating input supply
ARM: OMAP2+: board-generic: add support for DRA71x family
ARM: omap2plus_defconfig: Enable REGULATOR_GPIO
ARM: omap2plus_defconfig: Enable LP873X support
Nishanth Menon (2):
ARM: DRA7: hwmod: Do not register RTC on DRA71
ARM: dts: Add support for dra718-evm
.../devicetree/bindings/arm/omap/omap.txt | 6 +
Documentation/devicetree/bindings/mfd/lp873x.txt | 8 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/dra71-evm.dts | 230 ++++++++++++++
arch/arm/boot/dts/dra72-evm-common.dtsi | 348 +++------------------
arch/arm/boot/dts/dra72-evm-revc.dts | 21 +-
arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 134 ++++++++
arch/arm/boot/dts/dra72-evm.dts | 14 +-
arch/arm/configs/omap2plus_defconfig | 3 +
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 +-
drivers/regulator/lp873x-regulator.c | 1 +
12 files changed, 453 insertions(+), 326 deletions(-)
create mode 100644 arch/arm/boot/dts/dra71-evm.dts
create mode 100644 arch/arm/boot/dts/dra72-evm-tps65917.dtsi
--
2.10.1
^ permalink raw reply
* [PATCH v2 1/9] ARM: dts: dra72-evm: Remove pinmux configurations for erratum i869
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
Pinmuxing for DRA7x/AM57x family of processors need to be done in IO
isolation as part of initial bootloader executed from SRAM. This is
done as part of iodelay configuration sequence and is required due
to the limitations introduced by erratum ID: i869[1] (IO Glitches
can occur when changing IO settings) and elaborated in the Technical
Reference Manual[2] 18.4.6.1.7 Isolation Requirements.
Only peripheral that is permitted for dynamic pin mux configuration
is MMC and DCAN. MMC is permitted to change to accommodate the
requirements for varied speeds (which require IO-delay support in
kernel as well). DCAN is a result of i893[1] (DCAN initialization
sequence). With the exception of DCAN and MMC, all other pin mux
configurations are removed from the dts.
[1] http://www.ti.com/lit/er/sprz436a/sprz436a.pdf
[2] http://www.ti.com/lit/ug/spruhz7c/spruhz7c.pdf
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/dra72-evm-common.dtsi | 192 --------------------------------
1 file changed, 192 deletions(-)
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index c94d8d64..3c02612 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -69,9 +69,6 @@
tpd12s015: encoder {
compatible = "ti,tpd12s015";
- pinctrl-names = "default";
- pinctrl-0 = <&tpd12s015_pins>;
-
gpios = <&pcf_hdmi 4 GPIO_ACTIVE_HIGH>, /* P4, CT CP HPD */
<&pcf_hdmi 5 GPIO_ACTIVE_HIGH>, /* P5, LS OE */
<&gpio7 12 GPIO_ACTIVE_HIGH>; /* gpio7_12/sp1_cs2, HPD */
@@ -134,72 +131,6 @@
};
&dra7_pmx_core {
- i2c1_pins: pinmux_i2c1_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3800, PIN_INPUT | MUX_MODE0) /* i2c1_sda.i2c1_sda */
- DRA7XX_CORE_IOPAD(0x3804, PIN_INPUT | MUX_MODE0) /* i2c1_scl.i2c1_scl */
- >;
- };
-
- i2c5_pins: pinmux_i2c5_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x36b4, PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda */
- DRA7XX_CORE_IOPAD(0x36b8, PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl */
- >;
- };
-
- i2c5_pins: pinmux_i2c5_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x36b4, PIN_INPUT | MUX_MODE10) /* mcasp1_axr0.i2c5_sda */
- DRA7XX_CORE_IOPAD(0x36b8, PIN_INPUT | MUX_MODE10) /* mcasp1_axr1.i2c5_scl */
- >;
- };
-
- nand_default: nand_default {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3400, PIN_INPUT | MUX_MODE0) /* gpmc_ad0 */
- DRA7XX_CORE_IOPAD(0x3404, PIN_INPUT | MUX_MODE0) /* gpmc_ad1 */
- DRA7XX_CORE_IOPAD(0x3408, PIN_INPUT | MUX_MODE0) /* gpmc_ad2 */
- DRA7XX_CORE_IOPAD(0x340c, PIN_INPUT | MUX_MODE0) /* gpmc_ad3 */
- DRA7XX_CORE_IOPAD(0x3410, PIN_INPUT | MUX_MODE0) /* gpmc_ad4 */
- DRA7XX_CORE_IOPAD(0x3414, PIN_INPUT | MUX_MODE0) /* gpmc_ad5 */
- DRA7XX_CORE_IOPAD(0x3418, PIN_INPUT | MUX_MODE0) /* gpmc_ad6 */
- DRA7XX_CORE_IOPAD(0x341c, PIN_INPUT | MUX_MODE0) /* gpmc_ad7 */
- DRA7XX_CORE_IOPAD(0x3420, PIN_INPUT | MUX_MODE0) /* gpmc_ad8 */
- DRA7XX_CORE_IOPAD(0x3424, PIN_INPUT | MUX_MODE0) /* gpmc_ad9 */
- DRA7XX_CORE_IOPAD(0x3428, PIN_INPUT | MUX_MODE0) /* gpmc_ad10 */
- DRA7XX_CORE_IOPAD(0x342c, PIN_INPUT | MUX_MODE0) /* gpmc_ad11 */
- DRA7XX_CORE_IOPAD(0x3430, PIN_INPUT | MUX_MODE0) /* gpmc_ad12 */
- DRA7XX_CORE_IOPAD(0x3434, PIN_INPUT | MUX_MODE0) /* gpmc_ad13 */
- DRA7XX_CORE_IOPAD(0x3438, PIN_INPUT | MUX_MODE0) /* gpmc_ad14 */
- DRA7XX_CORE_IOPAD(0x343c, PIN_INPUT | MUX_MODE0) /* gpmc_ad15 */
- DRA7XX_CORE_IOPAD(0x34b4, PIN_OUTPUT | MUX_MODE0) /* gpmc_cs0 */
- DRA7XX_CORE_IOPAD(0x34c4, PIN_OUTPUT | MUX_MODE0) /* gpmc_advn_ale */
- DRA7XX_CORE_IOPAD(0x34cc, PIN_OUTPUT | MUX_MODE0) /* gpmc_wen */
- DRA7XX_CORE_IOPAD(0x34c8, PIN_OUTPUT | MUX_MODE0) /* gpmc_oen_ren */
- DRA7XX_CORE_IOPAD(0x34d0, PIN_OUTPUT | MUX_MODE0) /* gpmc_ben0 */
- DRA7XX_CORE_IOPAD(0x34d8, PIN_INPUT | MUX_MODE0) /* gpmc_wait0 */
- >;
- };
-
- usb1_pins: pinmux_usb1_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3680, PIN_INPUT_SLEW | MUX_MODE0) /* usb1_drvvbus */
- >;
- };
-
- usb2_pins: pinmux_usb2_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3684, PIN_INPUT_SLEW | MUX_MODE0) /* usb2_drvvbus */
- >;
- };
-
- tps65917_pins_default: tps65917_pins_default {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3824, PIN_INPUT_PULLUP | MUX_MODE1) /* wakeup3.sys_nirq1 */
- >;
- };
-
mmc1_pins_default: mmc1_pins_default {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x376c, PIN_INPUT | MUX_MODE14) /* mmc1sdcd.gpio219 */
@@ -240,59 +171,16 @@
DRA7XX_CORE_IOPAD(0x3818, MUX_MODE15 | PULL_UP) /* wakeup0.off */
>;
};
-
- hdmi_pins: pinmux_hdmi_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3808, PIN_INPUT | MUX_MODE1) /* i2c2_sda.hdmi1_ddc_scl */
- DRA7XX_CORE_IOPAD(0x380c, PIN_INPUT | MUX_MODE1) /* i2c2_scl.hdmi1_ddc_sda */
- >;
- };
-
- tpd12s015_pins: pinmux_tpd12s015_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x37b8, PIN_INPUT_PULLDOWN | MUX_MODE14) /* gpio7_12 HPD */
- >;
- };
-
- atl_pins: pinmux_atl_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3698, PIN_OUTPUT | MUX_MODE5) /* xref_clk1.atl_clk1 */
- DRA7XX_CORE_IOPAD(0x369c, PIN_OUTPUT | MUX_MODE5) /* xref_clk2.atl_clk2 */
- >;
- };
-
- mcasp3_pins: pinmux_mcasp3_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3724, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_aclkx */
- DRA7XX_CORE_IOPAD(0x3728, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_fsx */
- DRA7XX_CORE_IOPAD(0x372c, PIN_OUTPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr0 */
- DRA7XX_CORE_IOPAD(0x3730, PIN_INPUT_PULLDOWN | MUX_MODE0) /* mcasp3_axr1 */
- >;
- };
-
- mcasp3_sleep_pins: pinmux_mcasp3_sleep_pins {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x3724, PIN_INPUT_PULLDOWN | MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3728, PIN_INPUT_PULLDOWN | MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x372c, PIN_INPUT_PULLDOWN | MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3730, PIN_INPUT_PULLDOWN | MUX_MODE15)
- >;
- };
};
&i2c1 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&i2c1_pins>;
clock-frequency = <400000>;
tps65917: tps65917 at 58 {
compatible = "ti,tps65917";
reg = <0x58>;
- pinctrl-names = "default";
- pinctrl-0 = <&tps65917_pins_default>;
-
interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
interrupt-controller;
#interrupt-cells = <2>;
@@ -423,8 +311,6 @@
&i2c5 {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&i2c5_pins>;
clock-frequency = <400000>;
pcf_hdmi: pcf8575 at 26 {
@@ -462,8 +348,6 @@
&gpmc {
status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&nand_default>;
ranges = <0 0 0x08000000 0x01000000>; /* minimum GPMC partition = 16MB */
nand at 0,0 {
/* To use NAND, DIP switch SW5 must be set like so:
@@ -566,14 +450,10 @@
&usb1 {
dr_mode = "peripheral";
- pinctrl-names = "default";
- pinctrl-0 = <&usb1_pins>;
};
&usb2 {
dr_mode = "host";
- pinctrl-names = "default";
- pinctrl-0 = <&usb2_pins>;
};
&mmc1 {
@@ -603,71 +483,8 @@
max-frequency = <192000000>;
};
-&dra7_pmx_core {
- cpsw_default: cpsw_default {
- pinctrl-single,pins = <
- /* Slave 2 */
- DRA7XX_CORE_IOPAD(0x3598, PIN_OUTPUT | MUX_MODE3) /* vin2a_d12.rgmii1_txc */
- DRA7XX_CORE_IOPAD(0x359c, PIN_OUTPUT | MUX_MODE3) /* vin2a_d13.rgmii1_tctl */
- DRA7XX_CORE_IOPAD(0x35a0, PIN_OUTPUT | MUX_MODE3) /* vin2a_d14.rgmii1_td3 */
- DRA7XX_CORE_IOPAD(0x35a4, PIN_OUTPUT | MUX_MODE3) /* vin2a_d15.rgmii1_td2 */
- DRA7XX_CORE_IOPAD(0x35a8, PIN_OUTPUT | MUX_MODE3) /* vin2a_d16.rgmii1_td1 */
- DRA7XX_CORE_IOPAD(0x35ac, PIN_OUTPUT | MUX_MODE3) /* vin2a_d17.rgmii1_td0 */
- DRA7XX_CORE_IOPAD(0x35b0, PIN_INPUT | MUX_MODE3) /* vin2a_d18.rgmii1_rclk */
- DRA7XX_CORE_IOPAD(0x35b4, PIN_INPUT | MUX_MODE3) /* vin2a_d19.rgmii1_rctl */
- DRA7XX_CORE_IOPAD(0x35b8, PIN_INPUT | MUX_MODE3) /* vin2a_d20.rgmii1_rd3 */
- DRA7XX_CORE_IOPAD(0x35bc, PIN_INPUT | MUX_MODE3) /* vin2a_d21.rgmii1_rd2 */
- DRA7XX_CORE_IOPAD(0x35c0, PIN_INPUT | MUX_MODE3) /* vin2a_d22.rgmii1_rd1 */
- DRA7XX_CORE_IOPAD(0x35c4, PIN_INPUT | MUX_MODE3) /* vin2a_d23.rgmii1_rd0 */
- >;
-
- };
-
- cpsw_sleep: cpsw_sleep {
- pinctrl-single,pins = <
- /* Slave 2 */
- DRA7XX_CORE_IOPAD(0x3598, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x359c, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35a0, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35a4, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35a8, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35ac, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35b0, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35b4, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35b8, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35bc, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35c0, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x35c4, MUX_MODE15)
- >;
- };
-
- davinci_mdio_default: davinci_mdio_default {
- pinctrl-single,pins = <
- /* MDIO */
- DRA7XX_CORE_IOPAD(0x363c, PIN_OUTPUT_PULLUP | MUX_MODE0) /* mdio_d.mdio_d */
- DRA7XX_CORE_IOPAD(0x3640, PIN_INPUT_PULLUP | MUX_MODE0) /* mdio_clk.mdio_clk */
- >;
- };
-
- davinci_mdio_sleep: davinci_mdio_sleep {
- pinctrl-single,pins = <
- DRA7XX_CORE_IOPAD(0x363c, MUX_MODE15)
- DRA7XX_CORE_IOPAD(0x3640, MUX_MODE15)
- >;
- };
-};
-
&mac {
status = "okay";
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&cpsw_default>;
- pinctrl-1 = <&cpsw_sleep>;
-};
-
-&davinci_mdio {
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&davinci_mdio_default>;
- pinctrl-1 = <&davinci_mdio_sleep>;
};
&dcan1 {
@@ -748,9 +565,6 @@
&hdmi {
status = "ok";
- pinctrl-names = "default";
- pinctrl-0 = <&hdmi_pins>;
-
port {
hdmi_out: endpoint {
remote-endpoint = <&tpd12s015_in>;
@@ -759,9 +573,6 @@
};
&atl {
- pinctrl-names = "default";
- pinctrl-0 = <&atl_pins>;
-
assigned-clocks = <&abe_dpll_sys_clk_mux>,
<&atl_gfclk_mux>,
<&dpll_abe_ck>,
@@ -780,9 +591,6 @@
&mcasp3 {
#sound-dai-cells = <0>;
- pinctrl-names = "default", "sleep";
- pinctrl-0 = <&mcasp3_pins>;
- pinctrl-1 = <&mcasp3_sleep_pins>;
assigned-clocks = <&mcasp3_ahclkx_mux>;
assigned-clock-parents = <&atl_clkin2_ck>;
--
2.10.1
^ permalink raw reply related
* [PATCH v2 2/9] ARM: dra72-evm: Fix modelling of regulators
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
Add proper description of input voltage regulators and update the voltage
rail map for all the regulators.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/dra72-evm-common.dtsi | 48 +++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index 3c02612..8537b6a 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -18,11 +18,47 @@
display0 = &hdmi0;
};
+ evm_12v0: fixedregulator-evm12v0 {
+ /* main supply */
+ compatible = "regulator-fixed";
+ regulator-name = "evm_12v0";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ evm_5v0: fixedregulator-evm5v0 {
+ /* Output 1 of TPS43351QDAPRQ1 */
+ compatible = "regulator-fixed";
+ regulator-name = "evm_5v0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&evm_12v0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vsys_3v3: fixedregulator-vsys3v3 {
+ /* Output 2 of TPS43351QDAPRQ1 */
+ compatible = "regulator-fixed";
+ regulator-name = "vsys_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&evm_12v0>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
evm_3v3_sw: fixedregulator-evm_3v3 {
+ /* TPS22965DSG */
compatible = "regulator-fixed";
regulator-name = "evm_3v3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ vin-supply = <&vsys_3v3>;
+ regulator-always-on;
+ regulator-boot-on;
};
aic_dvdd: fixedregulator-aic_dvdd {
@@ -39,6 +75,7 @@
regulator-name = "evm_3v3_sd";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
+ vin-supply = <&evm_3v3_sw>;
enable-active-high;
gpio = <&pcf_gpio_21 5 GPIO_ACTIVE_HIGH>;
};
@@ -190,6 +227,17 @@
tps65917_pmic {
compatible = "ti,tps65917-pmic";
+ smps1-in-supply = <&vsys_3v3>;
+ smps2-in-supply = <&vsys_3v3>;
+ smps3-in-supply = <&vsys_3v3>;
+ smps4-in-supply = <&vsys_3v3>;
+ smps5-in-supply = <&vsys_3v3>;
+ ldo1-in-supply = <&vsys_3v3>;
+ ldo2-in-supply = <&vsys_3v3>;
+ ldo3-in-supply = <&vsys_3v3>;
+ ldo4-in-supply = <&evm_5v0>;
+ ldo5-in-supply = <&vsys_3v3>;
+
tps65917_regulators: regulators {
smps1_reg: smps1 {
/* VDD_MPU */
--
2.10.1
^ permalink raw reply related
* [PATCH v2 3/9] ARM: dts: dra72: Add separate dtsi for tps65917
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
dra72-evm-common.dtsi consolidates dra72-evm.dts and dra72-evm-revc.dts
which also include tps65917 pmic support as both the evms uses the same
pmic. But, dra71-evm has mostly similar features with a different pmic.
In order to exploit dra72-evm-common.dtsi, creating a separate dtsi
for tps65915 support and including it in respective board files.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/dra72-evm-common.dtsi | 128 ----------------------------
arch/arm/boot/dts/dra72-evm-revc.dts | 21 +++--
arch/arm/boot/dts/dra72-evm-tps65917.dtsi | 134 ++++++++++++++++++++++++++++++
arch/arm/boot/dts/dra72-evm.dts | 14 ++--
4 files changed, 154 insertions(+), 143 deletions(-)
create mode 100644 arch/arm/boot/dts/dra72-evm-tps65917.dtsi
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index 8537b6a..9903ac7 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -214,123 +214,6 @@
status = "okay";
clock-frequency = <400000>;
- tps65917: tps65917 at 58 {
- compatible = "ti,tps65917";
- reg = <0x58>;
-
- interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
- interrupt-controller;
- #interrupt-cells = <2>;
-
- ti,system-power-controller;
-
- tps65917_pmic {
- compatible = "ti,tps65917-pmic";
-
- smps1-in-supply = <&vsys_3v3>;
- smps2-in-supply = <&vsys_3v3>;
- smps3-in-supply = <&vsys_3v3>;
- smps4-in-supply = <&vsys_3v3>;
- smps5-in-supply = <&vsys_3v3>;
- ldo1-in-supply = <&vsys_3v3>;
- ldo2-in-supply = <&vsys_3v3>;
- ldo3-in-supply = <&vsys_3v3>;
- ldo4-in-supply = <&evm_5v0>;
- ldo5-in-supply = <&vsys_3v3>;
-
- tps65917_regulators: regulators {
- smps1_reg: smps1 {
- /* VDD_MPU */
- regulator-name = "smps1";
- regulator-min-microvolt = <850000>;
- regulator-max-microvolt = <1250000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- smps2_reg: smps2 {
- /* VDD_CORE */
- regulator-name = "smps2";
- regulator-min-microvolt = <850000>;
- regulator-max-microvolt = <1150000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- smps3_reg: smps3 {
- /* VDD_GPU IVA DSPEVE */
- regulator-name = "smps3";
- regulator-min-microvolt = <850000>;
- regulator-max-microvolt = <1250000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- smps4_reg: smps4 {
- /* VDDS1V8 */
- regulator-name = "smps4";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- smps5_reg: smps5 {
- /* VDD_DDR */
- regulator-name = "smps5";
- regulator-min-microvolt = <1350000>;
- regulator-max-microvolt = <1350000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo1_reg: ldo1 {
- /* LDO1_OUT --> SDIO */
- regulator-name = "ldo1";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-always-on;
- regulator-boot-on;
- regulator-allow-bypass;
- };
-
- ldo3_reg: ldo3 {
- /* VDDA_1V8_PHY */
- regulator-name = "ldo3";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-boot-on;
- regulator-always-on;
- };
-
- ldo5_reg: ldo5 {
- /* VDDA_1V8_PLL */
- regulator-name = "ldo5";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
- };
-
- ldo4_reg: ldo4 {
- /* VDDA_3V_USB: VDDA_USBHS33 */
- regulator-name = "ldo4";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- regulator-boot-on;
- };
- };
- };
-
- tps65917_power_button {
- compatible = "ti,palmas-pwrbutton";
- interrupt-parent = <&tps65917>;
- interrupts = <1 IRQ_TYPE_NONE>;
- wakeup-source;
- ti,palmas-long-press-seconds = <6>;
- };
- };
-
pcf_gpio_21: gpio at 21 {
compatible = "ti,pcf8575", "nxp,pcf8575";
reg = <0x21>;
@@ -480,14 +363,6 @@
};
};
-&usb2_phy1 {
- phy-supply = <&ldo4_reg>;
-};
-
-&usb2_phy2 {
- phy-supply = <&ldo4_reg>;
-};
-
&omap_dwc3_1 {
extcon = <&extcon_usb1>;
};
@@ -509,7 +384,6 @@
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins_default>;
vmmc-supply = <&evm_3v3_sd>;
- vmmc_aux-supply = <&ldo1_reg>;
bus-width = <4>;
/*
* SDCD signal is not being used here - using the fact that GPIO mode
@@ -606,8 +480,6 @@
&dss {
status = "ok";
-
- vdda_video-supply = <&ldo5_reg>;
};
&hdmi {
diff --git a/arch/arm/boot/dts/dra72-evm-revc.dts b/arch/arm/boot/dts/dra72-evm-revc.dts
index 064b322..4ea2a0c 100644
--- a/arch/arm/boot/dts/dra72-evm-revc.dts
+++ b/arch/arm/boot/dts/dra72-evm-revc.dts
@@ -17,17 +17,22 @@
};
};
-&tps65917_regulators {
- ldo2_reg: ldo2 {
- /* LDO2_OUT --> VDDA_1V8_PHY2 */
- regulator-name = "ldo2";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <1800000>;
- regulator-always-on;
- regulator-boot-on;
+&i2c1 {
+ tps65917: tps65917 at 58 {
+ reg = <0x58>;
+
+ interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
};
};
+#include "dra72-evm-tps65917.dtsi"
+
+&ldo2_reg {
+ /* LDO2_OUT --> VDDA_1V8_PHY2 */
+ regulator-always-on;
+ regulator-boot-on;
+};
+
&hdmi {
vdda-supply = <&ldo2_reg>;
};
diff --git a/arch/arm/boot/dts/dra72-evm-tps65917.dtsi b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
new file mode 100644
index 0000000..ee6dac4
--- /dev/null
+++ b/arch/arm/boot/dts/dra72-evm-tps65917.dtsi
@@ -0,0 +1,134 @@
+/*
+ * Copyright (C) 2016 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.
+ */
+
+/*
+ * Integrated Power Management Chip
+ * http://www.ti.com/lit/ds/symlink/tps65917-q1.pdf
+ */
+
+&tps65917 {
+ compatible = "ti,tps65917";
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ ti,system-power-controller;
+
+ tps65917_pmic {
+ compatible = "ti,tps65917-pmic";
+
+ smps1-in-supply = <&vsys_3v3>;
+ smps2-in-supply = <&vsys_3v3>;
+ smps3-in-supply = <&vsys_3v3>;
+ smps4-in-supply = <&vsys_3v3>;
+ smps5-in-supply = <&vsys_3v3>;
+ ldo1-in-supply = <&vsys_3v3>;
+ ldo2-in-supply = <&vsys_3v3>;
+ ldo3-in-supply = <&vsys_3v3>;
+ ldo4-in-supply = <&evm_5v0>;
+ ldo5-in-supply = <&vsys_3v3>;
+
+ tps65917_regulators: regulators {
+ smps1_reg: smps1 {
+ /* VDD_MPU */
+ regulator-name = "smps1";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps2_reg: smps2 {
+ /* VDD_CORE */
+ regulator-name = "smps2";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ smps3_reg: smps3 {
+ /* VDD_GPU IVA DSPEVE */
+ regulator-name = "smps3";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ smps4_reg: smps4 {
+ /* VDDS1V8 */
+ regulator-name = "smps4";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps5_reg: smps5 {
+ /* VDD_DDR */
+ regulator-name = "smps5";
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: ldo1 {
+ /* LDO1_OUT --> SDIO */
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-allow-bypass;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-allow-bypass;
+ };
+
+ ldo3_reg: ldo3 {
+ /* VDDA_1V8_PHY */
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo5_reg: ldo5 {
+ /* VDDA_1V8_PLL */
+ regulator-name = "ldo5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ /* VDDA_3V_USB: VDDA_USBHS33 */
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ };
+ };
+ };
+
+ tps65917_power_button {
+ compatible = "ti,palmas-pwrbutton";
+ interrupt-parent = <&tps65917>;
+ interrupts = <1 IRQ_TYPE_NONE>;
+ wakeup-source;
+ ti,palmas-long-press-seconds = <6>;
+ };
+};
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index e3a9b69..cd9c4ff 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -15,16 +15,16 @@
};
};
-&tps65917_regulators {
- ldo2_reg: ldo2 {
- /* LDO2_OUT --> TP1017 (UNUSED) */
- regulator-name = "ldo2";
- regulator-min-microvolt = <1800000>;
- regulator-max-microvolt = <3300000>;
- regulator-allow-bypass;
+&i2c1 {
+ tps65917: tps65917 at 58 {
+ reg = <0x58>;
+
+ interrupts = <GIC_SPI 2 IRQ_TYPE_NONE>; /* IRQ_SYS_1N */
};
};
+#include "dra72-evm-tps65917.dtsi"
+
&hdmi {
vdda-supply = <&ldo3_reg>;
};
--
2.10.1
^ permalink raw reply related
* [PATCH v2 4/9] regulator: lp873x: Add support for populating input supply
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
In order to have a proper topology of regulators for a platform, each
registering regulator needs to populate supply_name field for identifying
its supply's name. Add supply_name field for lp873x regulators.
Cc: Lee Jones <lee.jones@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
Documentation/devicetree/bindings/mfd/lp873x.txt | 8 ++++++++
drivers/regulator/lp873x-regulator.c | 1 +
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/lp873x.txt b/Documentation/devicetree/bindings/mfd/lp873x.txt
index 52766c2..998837a 100644
--- a/Documentation/devicetree/bindings/mfd/lp873x.txt
+++ b/Documentation/devicetree/bindings/mfd/lp873x.txt
@@ -7,6 +7,9 @@ Required properties:
- #gpio-cells: Should be two. The first cell is the pin number and
the second cell is used to specify flags.
See ../gpio/gpio.txt for more information.
+ - xxx-in-supply: Phandle to parent supply node of each regulator
+ populated under regulators node. xxx should match
+ the supply_name populated in driver.
- regulators: List of child nodes that specify the regulator
initialization data.
Example:
@@ -17,6 +20,11 @@ pmic: lp8733 at 60 {
gpio-controller;
#gpio-cells = <2>;
+ buck0-in-supply = <&vsys_3v3>;
+ buck1-in-supply = <&vsys_3v3>;
+ ldo0-in-supply = <&vsys_3v3>;
+ ldo1-in-supply = <&vsys_3v3>;
+
regulators {
lp8733_buck0: buck0 {
regulator-name = "lp8733-buck0";
diff --git a/drivers/regulator/lp873x-regulator.c b/drivers/regulator/lp873x-regulator.c
index e504b91..70e3df6 100644
--- a/drivers/regulator/lp873x-regulator.c
+++ b/drivers/regulator/lp873x-regulator.c
@@ -24,6 +24,7 @@
[_id] = { \
.desc = { \
.name = _name, \
+ .supply_name = _of "-in", \
.id = _id, \
.of_match = of_match_ptr(_of), \
.regulators_node = of_match_ptr("regulators"),\
--
2.10.1
^ permalink raw reply related
* [PATCH v2 5/9] ARM: OMAP2+: board-generic: add support for DRA71x family
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
DRA71x processor family is a derivative of DRA722 ES2.0 targetted for
infotainment systems.
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
Documentation/devicetree/bindings/arm/omap/omap.txt | 6 ++++++
arch/arm/mach-omap2/board-generic.c | 1 +
2 files changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index f53e2ee..454b1be 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -86,6 +86,9 @@ SoCs:
- DRA722
compatible = "ti,dra722", "ti,dra72", "ti,dra7"
+- DRA718
+ compatible = "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7"
+
- AM5728
compatible = "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
@@ -181,6 +184,9 @@ Boards:
- DRA722 EVM: Software Development Board for DRA722
compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7"
+- DRA718 EVM: Software Development Board for DRA718
+ compatible = "ti,dra718-evm", "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7"
+
- DM3730 Logic PD Torpedo + Wireless: Commercial System on Module with WiFi and Bluetooth
compatible = "logicpd,dm3730-torpedo-devkit", "ti,omap3630", "ti,omap3"
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index bab814d..981b23a 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -341,6 +341,7 @@ static const char *const dra72x_boards_compat[] __initconst = {
"ti,am5718",
"ti,am5716",
"ti,dra722",
+ "ti,dra718",
NULL,
};
--
2.10.1
^ permalink raw reply related
* [PATCH v2 6/9] ARM: DRA7: hwmod: Do not register RTC on DRA71
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
From: Nishanth Menon <nm@ti.com>
RTC is not available on DRA71x, so accessing any of the RTC
register or clkctrl register will lead to a crash. So, do not
register RTC hwmod for DRA71x.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 1ab7096..7f48577 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -3845,7 +3845,6 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
&dra7xx_l3_main_1__pciess2,
&dra7xx_l4_cfg__pciess2,
&dra7xx_l3_main_1__qspi,
- &dra7xx_l4_per3__rtcss,
&dra7xx_l4_cfg__sata,
&dra7xx_l4_cfg__smartreflex_core,
&dra7xx_l4_cfg__smartreflex_mpu,
@@ -3905,6 +3904,11 @@ static struct omap_hwmod_ocp_if *dra72x_hwmod_ocp_ifs[] __initdata = {
NULL,
};
+static struct omap_hwmod_ocp_if *dra74x_dra72x_hwmod_ocp_ifs[] __initdata = {
+ &dra7xx_l4_per3__rtcss,
+ NULL,
+};
+
int __init dra7xx_hwmod_init(void)
{
int ret;
@@ -3920,5 +3924,9 @@ int __init dra7xx_hwmod_init(void)
if (!ret && omap_type() == OMAP2_DEVICE_TYPE_GP)
ret = omap_hwmod_register_links(dra7xx_gp_hwmod_ocp_ifs);
+ /* now for the IPs *NOT* in dra71 */
+ if (!ret && !of_machine_is_compatible("ti,dra718"))
+ ret = omap_hwmod_register_links(dra74x_dra72x_hwmod_ocp_ifs);
+
return ret;
}
--
2.10.1
^ permalink raw reply related
* [PATCH v2 7/9] ARM: dts: Add support for dra718-evm
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
From: Nishanth Menon <nm@ti.com>
The DRA718-evm is a board based on TI's DRA718 processor targeting
BOM-optimized entry infotainment systems and is a reduced pin and
software compatible derivative of the DRA72 ES2.0 processor.
This platform features:
- 2GB of DDR3L
- Dual 1Gbps Ethernet
- HDMI,
- uSD
- 8GB eMMC
- CAN
- PCIe
- USB3.0
- Video Input Port
- LP873x PMIC
More information can be found here[1].
Adding support for this board while reusing the data available in
dra72-evm-common.dtsi.
[1] http://www.ti.com/product/dra718
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/dra71-evm.dts | 230 ++++++++++++++++++++++++++++++++
arch/arm/boot/dts/dra72-evm-common.dtsi | 6 +-
3 files changed, 236 insertions(+), 3 deletions(-)
create mode 100644 arch/arm/boot/dts/dra71-evm.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index befcd26..b92d501 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -590,7 +590,8 @@ dtb-$(CONFIG_SOC_DRA7XX) += \
am572x-idk.dtb \
dra7-evm.dtb \
dra72-evm.dtb \
- dra72-evm-revc.dtb
+ dra72-evm-revc.dtb \
+ dra71-evm.dtb
dtb-$(CONFIG_ARCH_ORION5X) += \
orion5x-kuroboxpro.dtb \
orion5x-lacie-d2-network.dtb \
diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
new file mode 100644
index 0000000..2b9a5a8
--- /dev/null
+++ b/arch/arm/boot/dts/dra71-evm.dts
@@ -0,0 +1,230 @@
+/*
+ * Copyright (C) 2016 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.
+ */
+
+#include "dra72-evm-common.dtsi"
+#include <dt-bindings/net/ti-dp83867.h>
+
+/ {
+ compatible = "ti,dra718-evm", "ti,dra718", "ti,dra722", "ti,dra72", "ti,dra7";
+ model = "TI DRA718 EVM";
+
+ memory {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x0 0x80000000>; /* 2GB */
+ };
+
+ vpo_sd_1v8_3v3: gpio-regulator-TPS74801 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "vddshv8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-boot-on;
+ vin-supply = <&evm_5v0>;
+
+ gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x0
+ 3000000 0x1>;
+ };
+
+ poweroff: gpio-poweroff {
+ compatible = "gpio-poweroff";
+ gpios = <&gpio7 30 GPIO_ACTIVE_HIGH>;
+ input;
+ };
+};
+
+&i2c1 {
+ status = "okay";
+ clock-frequency = <400000>;
+
+ lp8733: lp8733 at 60 {
+ compatible = "ti,lp8733";
+ reg = <0x60>;
+
+ buck0-in-supply =<&vsys_3v3>;
+ buck1-in-supply =<&vsys_3v3>;
+ ldo0-in-supply =<&evm_5v0>;
+ ldo1-in-supply =<&evm_5v0>;
+
+ lp8733_regulators: regulators {
+ lp8733_buck0_reg: buck0 {
+ /* FB_B0 -> LP8733-BUCK1 - VPO_S1_AVS - VDD_CORE_AVS (core, mpu, gpu) */
+ regulator-name = "lp8733-buck0";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ lp8733_buck1_reg: buck1 {
+ /* FB_B1 -> LP8733-BUCK2 - VPO_S2_AVS - VDD_DSP_AVS (DSP/eve/iva) */
+ regulator-name = "lp8733-buck1";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ lp8733_ldo0_reg: ldo0 {
+ /* LDO0 -> LP8733-LDO1 - VPO_L1_3V3 - VDDSHV8 (optional) */
+ regulator-name = "lp8733-ldo0";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ lp8733_ldo1_reg: ldo1 {
+ /* LDO1 -> LP8733-LDO2 - VPO_L2_3V3 - VDDA_USB3V3 */
+ regulator-name = "lp8733-ldo1";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+
+ lp8732: lp8732 at 61 {
+ compatible = "ti,lp8732";
+ reg = <0x61>;
+
+ buck0-in-supply =<&vsys_3v3>;
+ buck1-in-supply =<&vsys_3v3>;
+ ldo0-in-supply =<&vsys_3v3>;
+ ldo1-in-supply =<&vsys_3v3>;
+
+ lp8732_regulators: regulators {
+ lp8732_buck0_reg: buck0 {
+ /* FB_B0 -> LP8732-BUCK1 - VPO_S3_1V8 - VDDS_1V8 */
+ regulator-name = "lp8732-buck0";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ lp8732_buck1_reg: buck1 {
+ /* FB_B1 -> LP8732-BUCK2 - VPO_S4_DDR - VDD_DDR_1V35 */
+ regulator-name = "lp8732-buck1";
+ regulator-min-microvolt = <1350000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ lp8732_ldo0_reg: ldo0 {
+ /* LDO0 -> LP8732-LDO1 - VPO_L3_1V8 - VDA_1V8_PLL */
+ regulator-name = "lp8732-ldo0";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ lp8732_ldo1_reg: ldo1 {
+ /* LDO1 -> LP8732-LDO2 - VPO_L4_1V8 - VDA_1V8_PHY */
+ regulator-name = "lp8732-ldo1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+ };
+ };
+};
+
+&pcf_gpio_21 {
+ interrupt-parent = <&gpio7>;
+ interrupts = <31 IRQ_TYPE_EDGE_FALLING>;
+};
+
+&pcf_hdmi {
+ p0 {
+ /*
+ * PM_OEn to High: Disable routing I2C3 to PM_I2C
+ * With this PM_SEL(p3) should not matter
+ */
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_LOW>;
+ output-high;
+ line-name = "pm_oe_n";
+ };
+};
+
+&mmc1 {
+ vmmc_aux-supply = <&vpo_sd_1v8_3v3>;
+};
+
+&mac {
+ mode-gpios = <&pcf_gpio_21 4 GPIO_ACTIVE_LOW>,
+ <&pcf_hdmi 9 GPIO_ACTIVE_LOW>, /* P11 */
+ <&pcf_hdmi 10 GPIO_ACTIVE_LOW>; /* P12 */
+ dual_emac;
+};
+
+&cpsw_emac0 {
+ phy_id = <&davinci_mdio>, <2>;
+ phy-mode = "rgmii-id";
+ dual_emac_res_vlan = <1>;
+};
+
+&cpsw_emac1 {
+ phy_id = <&davinci_mdio>, <3>;
+ phy-mode = "rgmii-id";
+ dual_emac_res_vlan = <2>;
+};
+
+&davinci_mdio {
+ dp83867_0: ethernet-phy at 2 {
+ reg = <2>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,impedance-control = <0x1f>;
+ };
+
+ dp83867_1: ethernet-phy at 3 {
+ reg = <3>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_250_PS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_8_B_NIB>;
+ ti,impedance-control = <0x1f>;
+ };
+};
+
+/* No Sata on this device */
+&sata_phy {
+ status = "disabled";
+};
+
+&sata {
+ status = "disabled";
+};
+
+/* No RTC on this device */
+&rtc {
+ status = "disabled";
+};
+
+&usb2_phy1 {
+ phy-supply = <&lp8733_ldo1_reg>;
+};
+
+&usb2_phy2 {
+ phy-supply = <&lp8733_ldo1_reg>;
+};
+
+&dss {
+ /* Supplied by VDA_1V8_PLL */
+ vdda_video-supply = <&lp8732_ldo0_reg>;
+};
+
+&hdmi {
+ /* Supplied by VDA_1V8_PHY */
+ vdda_video-supply = <&lp8732_ldo1_reg>;
+};
diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi b/arch/arm/boot/dts/dra72-evm-common.dtsi
index 9903ac7..e50fbee 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -29,7 +29,8 @@
};
evm_5v0: fixedregulator-evm5v0 {
- /* Output 1 of TPS43351QDAPRQ1 */
+ /* Output 1 of TPS43351QDAPRQ1 on dra72-evm */
+ /* Output 1 of LM5140QRWGTQ1 on dra71-evm */
compatible = "regulator-fixed";
regulator-name = "evm_5v0";
regulator-min-microvolt = <5000000>;
@@ -40,7 +41,8 @@
};
vsys_3v3: fixedregulator-vsys3v3 {
- /* Output 2 of TPS43351QDAPRQ1 */
+ /* Output 2 of TPS43351QDAPRQ1 on dra72-evm */
+ /* Output 2 of LM5140QRWGTQ1 on dra71-evm */
compatible = "regulator-fixed";
regulator-name = "vsys_3v3";
regulator-min-microvolt = <3300000>;
--
2.10.1
^ permalink raw reply related
* [PATCH v2 8/9] ARM: omap2plus_defconfig: Enable REGULATOR_GPIO
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
GPIO regulator is used on dra71-evm platform to control MMCSD IO
voltage
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 53e1a88..5695cff 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -270,6 +270,7 @@ CONFIG_MFD_TPS65217=y
CONFIG_MFD_TPS65218=y
CONFIG_MFD_TPS65910=y
CONFIG_TWL6040_CORE=y
+CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_LP872X=y
CONFIG_REGULATOR_PALMAS=y
CONFIG_REGULATOR_PBIAS=y
--
2.10.1
^ permalink raw reply related
* [PATCH v2 9/9] ARM: omap2plus_defconfig: Enable LP873X support
From: Lokesh Vutla @ 2016-10-21 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161021103841.8044-1-lokeshvutla@ti.com>
LP873X family of PMICs are used in dra71x-evm, So enable the same.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index 5695cff..e3fdf4d 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -267,11 +267,13 @@ CONFIG_TWL4030_WATCHDOG=m
CONFIG_MFD_TI_AM335X_TSCADC=m
CONFIG_MFD_PALMAS=y
CONFIG_MFD_TPS65217=y
+CONFIG_MFD_TI_LP873X=y
CONFIG_MFD_TPS65218=y
CONFIG_MFD_TPS65910=y
CONFIG_TWL6040_CORE=y
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_LP872X=y
+CONFIG_REGULATOR_LP873X=y
CONFIG_REGULATOR_PALMAS=y
CONFIG_REGULATOR_PBIAS=y
CONFIG_REGULATOR_TI_ABB=y
--
2.10.1
^ permalink raw reply related
* [PATCH v3 5/6] ARM: sunxi: Remove useless allwinner, pull property
From: Maxime Ripard @ 2016-10-21 10:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161020173848.be9cf97854f8933b3ce90d55@free.fr>
Hi,
On Thu, Oct 20, 2016 at 05:38:48PM +0200, Jean-Francois Moine wrote:
> On Thu, 20 Oct 2016 15:49:06 +0200
> Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
>
> > The allwinner,pull property set to NO_PULL was really considered our
> > default (and wasn't even changing the default value in the code).
> >
> > Remove these properties to make it obvious that we do not set anything in
> > such a case.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > Acked-by: Chen-Yu Tsai <wens@csie.org>
> > Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
> > ---
> > arch/arm/boot/dts/ntc-gr8-evb.dts | 4 +-
> > arch/arm/boot/dts/ntc-gr8.dtsi | 14 +-----
> > arch/arm/boot/dts/sun4i-a10-a1000.dts | 2 +-
> > arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 1 +-
> > arch/arm/boot/dts/sun4i-a10-dserve-dsrv9703c.dts | 4 +-
> > arch/arm/boot/dts/sun4i-a10-gemei-g9.dts | 1 +-
> > arch/arm/boot/dts/sun4i-a10-hackberry.dts | 2 +-
> > arch/arm/boot/dts/sun4i-a10-inet1.dts | 2 +-
> > arch/arm/boot/dts/sun4i-a10-jesurun-q5.dts | 2 +-
> > arch/arm/boot/dts/sun4i-a10-marsboard.dts | 1 +-
> > arch/arm/boot/dts/sun4i-a10-mk802.dts | 3 +-
> > arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 2 +-
> > arch/arm/boot/dts/sun4i-a10-pcduino.dts | 2 +-
> > arch/arm/boot/dts/sun4i-a10-pcduino2.dts | 1 +-
> > arch/arm/boot/dts/sun4i-a10-pov-protab2-ips9.dts | 3 +-
> > arch/arm/boot/dts/sun4i-a10.dtsi | 24 +--------
> > arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts | 1 +-
> > arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts | 2 +-
> > arch/arm/boot/dts/sun5i-a10s-mk802.dts | 2 +-
> > arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 2 +-
> > arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts | 2 +-
> > arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts | 2 +-
> > arch/arm/boot/dts/sun5i-a10s.dtsi | 7 +--
> > arch/arm/boot/dts/sun5i-a13-hsg-h702.dts | 1 +-
> > arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts | 3 +-
> > arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 2 +-
> > arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 1 +-
> > arch/arm/boot/dts/sun5i-a13.dtsi | 3 +-
> > arch/arm/boot/dts/sun5i-r8-chip.dts | 2 +-
> > arch/arm/boot/dts/sun5i-reference-design-tablet.dtsi | 2 +-
> > arch/arm/boot/dts/sun5i.dtsi | 7 +--
> > arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 1 +-
> > arch/arm/boot/dts/sun6i-a31-colombus.dts | 1 +-
> > arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 2 +-
> > arch/arm/boot/dts/sun6i-a31-i7.dts | 2 +-
> > arch/arm/boot/dts/sun6i-a31-m9.dts | 2 +-
> > arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts | 2 +-
> > arch/arm/boot/dts/sun6i-a31.dtsi | 13 +----
> > arch/arm/boot/dts/sun6i-a31s-primo81.dts | 1 +-
> > arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 1 +-
> > arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 3 +-
> > arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 3 +-
> > arch/arm/boot/dts/sun7i-a20-bananapi.dts | 2 +-
> > arch/arm/boot/dts/sun7i-a20-bananapro.dts | 5 +--
> > arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 1 +-
> > arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 6 +--
> > arch/arm/boot/dts/sun7i-a20-hummingbird.dts | 4 +-
> > arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts | 4 +-
> > arch/arm/boot/dts/sun7i-a20-itead-ibox.dts | 1 +-
> > arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts | 2 +-
> > arch/arm/boot/dts/sun7i-a20-m3.dts | 1 +-
> > arch/arm/boot/dts/sun7i-a20-mk808c.dts | 2 +-
> > arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 4 +-
> > arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts | 2 +-
> > arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 1 +-
> > arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 3 +-
> > arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 1 +-
> > arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts | 4 +-
> > arch/arm/boot/dts/sun7i-a20-orangepi.dts | 4 +-
> > arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts | 3 +-
> > arch/arm/boot/dts/sun7i-a20-pcduino3.dts | 2 +-
> > arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 3 +-
> > arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts | 1 +-
> > arch/arm/boot/dts/sun7i-a20.dtsi | 37 +------------
> > arch/arm/boot/dts/sun8i-a23-a33.dtsi | 10 +---
> > arch/arm/boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts | 1 +-
> > arch/arm/boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts | 1 +-
> > arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 1 +-
> > arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 3 +-
> > arch/arm/boot/dts/sun8i-a33.dtsi | 1 +-
> > arch/arm/boot/dts/sun8i-a83t.dtsi | 3 +-
> > arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts | 3 +-
> > arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts | 2 +-
> > arch/arm/boot/dts/sun8i-h3-orangepi-2.dts | 4 +-
> > arch/arm/boot/dts/sun8i-h3-orangepi-lite.dts | 3 +-
> > arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 3 +-
> > arch/arm/boot/dts/sun8i-h3-orangepi-pc.dts | 3 +-
> > arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 1 +-
> > arch/arm/boot/dts/sun8i-h3.dtsi | 12 +----
> > arch/arm/boot/dts/sun8i-r16-parrot.dts | 3 +-
> > arch/arm/boot/dts/sun8i-reference-design-tablet.dtsi | 2 +-
> > arch/arm/boot/dts/sun9i-a80-cubieboard4.dts | 1 +-
> > arch/arm/boot/dts/sun9i-a80-optimus.dts | 4 +-
> > arch/arm/boot/dts/sun9i-a80.dtsi | 6 +--
> > arch/arm/boot/dts/sunxi-common-regulators.dtsi | 4 +-
> > 85 files changed, 0 insertions(+), 302 deletions(-)
> [snip]
>
> Is it really usefull to change all these files while in a previous
> patch you were writing:
> > The generic pin configuration and multiplexing should be preferred now,
> > even though we still support the old one.
> ?
I assume you wanted to comment on the sixth patch.
Yes, it's useful, because that way we avoid using a deprecated
binding, that we would have to mix the newer binding which would be
completely inconsistent, and that way we use the generic binding that
everyone uses everywhere.
The backward compatibility is just here to avoid breaking the ABI.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161021/b625a715/attachment.sig>
^ 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