[PATCH] extcon: gpio: Add the support for Device tree bindings
This patch adds the support for Device tree bindings of extcon-gpio driver.
The extcon-gpio device tree node must include the both 'extcon-id' and
'extcon-gpio' property.
For exmaple:
usb_cable: extcon-gpio-0 {
compatible = "extcon-gpio";
extcon-id = <1>;/* EXTCON_USB */
extcon-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
}
ta_cable: extcon-gpio-1 {
compatible = "extcon-gpio";
extcon-id = <3>;/* EXTCON_TA */
extcon-gpio = <&gpio3 2 GPIO_ACTIVE_LOW>;
debounce-ms = <50>; /* 50 millisecond */
wakeup-source;
}
&dwc3_usb {
extcon = <&usb_cable>;
};
&charger {
extcon = <&ta_cable>;
};
Signed-off-by: Chanwoo Choi
---
.../devicetree/bindings/extcon/extcon-gpio.txt | 35 +++
drivers/extcon/extcon-gpio.c | 108 -
include/linux/extcon/extcon-gpio.h | 6 +-
3 files changed, 124 insertions(+), 25 deletions(-)
create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt
diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index ..dc99a1d99b63
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,35 @@
+GPIO Extcon device
+
+Required properties:
+- compatible: Must be "extcon-gpio".
+- extcon-id: unique id for specific external connector.
+See include/linux/extcon.h.
+- extcon-gpio: GPIO pin to detect the external connector. See gpio binding.
+
+Optional properties:
+- debounce-ms: the debounce dealy for GPIO pin in millisecond.
+- wakeup-source: Boolean, extcon can wake-up the system.
+
+Example: Examples of extcon-gpio node as listed below:
+
+ usb_cable: extcon-gpio-0 {
+ compatible = "extcon-gpio";
+ extcon-id = <1>;/* EXTCON_USB */
+ extcon-gpio = <&gpio6 1 GPIO_ACTIVE_HIGH>;
+ }
+
+ ta_cable: extcon-gpio-1 {
+ compatible = "extcon-gpio";
+ extcon-id = <3>;/* EXTCON_TA */
+ extcon-gpio = <&gpio3 2 GPIO_ACTIVE_LOW>;
+ debounce-ms = <50>; /* 50 millisecond */
+ wakeup-source;
+ }
+
+ &dwc3_usb {
+ extcon = <&usb_cable>;
+ };
+
+ &charger {
+ extcon = <&ta_cable>;
+ };
diff --git a/drivers/extcon/extcon-gpio.c b/drivers/extcon/extcon-gpio.c
index 279ff8f6637d..611eb69392bb 100644
--- a/drivers/extcon/extcon-gpio.c
+++ b/drivers/extcon/extcon-gpio.c
@@ -1,8 +1,8 @@
/*
* extcon_gpio.c - Single-state GPIO extcon driver based on extcon class
*
- * Copyright (C) 2008 Google, Inc.
- * Author: Mike Lockwood
+ * Copyright (C) 2015 Chanwoo Choi , Samsung Electronics
+ * Copyright (C) 2008 Mike Lockwood , Google, Inc.
*
* Modified by MyungJoo Ham to support extcon
* (originally switch class is supported)
@@ -26,12 +26,14 @@
#include
#include
#include
+#include
#include
#include
struct gpio_extcon_data {
struct extcon_dev *edev;
int irq;
+ bool irq_wakeup;
struct delayed_work work;
unsigned long debounce_jiffies;
@@ -61,19 +63,50 @@ static irqreturn_t gpio_irq_handler(int irq, void *dev_id)
return IRQ_HANDLED;
}
-static int gpio_extcon_init(struct device *dev, struct gpio_extcon_data *data)
+static int gpio_extcon_parse_of(struct device *dev,
+ struct gpio_extcon_data *data)
{
- struct gpio_extcon_pdata *pdata = data->pdata;
+ struct gpio_extcon_pdata *pdata;
int ret;
- ret = devm_gpio_request_one(dev, pdata->gpio, GPIOF_DIR_IN,
- dev_name(dev));
+ pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata)
+ return -ENOMEM;
+
+ ret = device_property_read_u32(dev, "extcon-id", &pdata->extcon_id);
+ if (ret < 0)
+ return -EINVAL;
+
+ data->id_gpiod = devm_gpiod_get(dev, "extcon", GPIOD_IN);
if (ret < 0)
return ret;
- data->id_gpiod = gpio_to_desc(pdata->gpio);
- if (!data->id_gpiod)
- return -EINVAL;
+ data->irq_wakeup = device_property_read_bool(dev, "wakeup-source");
+
+ device_property_read_u32(dev, "debounce-ms", &pdata->debounce);
+
+ pdata->irq_flags = (IRQF_TRIGGER_RISING | IRQF_TRIGGER_FALLING
+ | IRQF_ONESHOT);
+
+ data->pdata = pdata;
+ return 0;
+}
+
+static int gpio_extcon_init(struct device *dev, struct gpio_extcon_data *data)
+{
+ struct gpio_extcon_pdata *pdata = data->pdata;
+ int ret;
+
+ if (!data->id_gpiod) {
+ ret = devm_gpio_request_one(dev, pdata->gpio, GPIOF_
Re: [PATCH v3 2/5] mailbox: Add support for ST's Mailbox IP
On Wed, Aug 19, 2015 at 7:52 PM, Lee Jones wrote:
> +
> +#define MBOX_BASE(mdev, inst) ((mdev)->base + (inst * 4))
>
It should be(inst) * 4
> +/**
> + * STi Mailbox device data
> + *
> + * An IP Mailbox is currently composed of 4 instances
> + * Each instance is currently composed of 32 channels
> + * This means that we have 128 channels per Mailbox
> + * A channel an be used for TX or RX
> + *
> + * @dev: Device to which it is attached
> + * @mbox: Representation of a communication channel controller
> + * @base: Base address of the register mapping region
> + * @name: Name of the mailbox
> + * @enabled: Local copy of enabled channels
> + * @lock: Mutex protecting enabled status
> + */
> +struct sti_mbox_device {
> + struct device *dev;
> + struct mbox_controller *mbox;
> + void __iomem*base;
> + const char *name;
> + u32 enabled[STI_MBOX_INST_MAX];
> + spinlock_t lock;
> + booltxonly;
>
txonly is never used after being initialized from DT :) which is a
good sign. So maybe just drop it and the optional property 'tx-only'.
Cheers!
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 1/3] ARM: uniphier: add outer cache support
This commit adds support for UniPhier outer cache controller.
All the UniPhier SoCs are equipped with the L2 cache, while the L3
cache is currently only integrated on PH1-Pro5 SoC.
Signed-off-by: Masahiro Yamada
Acked-by: Rob Herring
---
.../bindings/arm/uniphier/cache-uniphier.txt | 60 +++
MAINTAINERS| 2 +
arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++
arch/arm/kernel/irq.c | 3 +
arch/arm/mm/Kconfig| 10 +
arch/arm/mm/Makefile | 1 +
arch/arm/mm/cache-uniphier.c | 555 +
7 files changed, 677 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h
create mode 100644 arch/arm/mm/cache-uniphier.c
diff --git a/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
new file mode 100644
index 000..d27a646
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt
@@ -0,0 +1,60 @@
+UniPhier outer cache controller
+
+UniPhier SoCs are integrated with a full-custom outer cache controller system.
+All of them have a level 2 cache controller, and some have a level 3 cache
+controller as well.
+
+Required properties:
+- compatible: should be "socionext,uniphier-system-cache"
+- reg: offsets and lengths of the register sets for the device. It should
+ contain 3 regions: control register, revision register, operation register,
+ in this order.
+- cache-unified: specifies the cache is a unified cache.
+- cache-size: specifies the size in bytes of the cache
+- cache-sets: specifies the number of associativity sets of the cache
+- cache-line-size: specifies the line size in bytes
+- cache-level: specifies the level in the cache hierarchy. The value should
+ be 2 for L2 cache, 3 for L3 cache, etc.
+
+Optional properties:
+- next-level-cache: phandle to the next level cache if present. The next level
+ cache should be also compatible with "socionext,uniphier-system-cache".
+
+The L2 cache must exist to use the L3 cache; the cache hierarchy must be
+indicated correctly with "next-level-cache" properties.
+
+Example 1 (system with L2):
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ cache-unified;
+ cache-size = <0x8>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
+Example 2 (system with L2 and L3):
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ cache-unified;
+ cache-size = <0x20>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ next-level-cache = <&l3>;
+ };
+
+ l3: l3-cache@500c8000 {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
+ <0x506c8000 0x400>;
+ cache-unified;
+ cache-size = <0x40>;
+ cache-sets = <512>;
+ cache-line-size = <256>;
+ cache-level = <3>;
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 9f6685f..bced05f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1606,7 +1606,9 @@ M:Masahiro Yamada
L: linux-arm-ker...@lists.infradead.org (moderated for non-subscribers)
S: Maintained
F: arch/arm/boot/dts/uniphier*
+F: arch/arm/include/asm/hardware/cache-uniphier.h
F: arch/arm/mach-uniphier/
+F: arch/arm/mm/cache-uniphier.c
F: drivers/pinctrl/uniphier/
F: drivers/tty/serial/8250/8250_uniphier.c
N: uniphier
diff --git a/arch/arm/include/asm/hardware/cache-uniphier.h
b/arch/arm/include/asm/hardware/cache-uniphier.h
new file mode 100644
index 000..102e3fb
--- /dev/null
+++ b/arch/arm/include/asm/hardware/cache-uniphier.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ */
+
+#ifndef __CACHE_UNIPHIER_H
+#def
[PATCH v5 0/3] ARM: uniphier: add outer cache support and rework SMP operations
Hi Olof, Now Linux 4.3-rc1 is out, so I am back to this. 1/3: add outer cache support 2/3: rework SMP operations 3/3: add device tree nodes Because 2/3 highly depends on 1/3, I hope whole of this series is applied through ARM-SOC tree. Changes in v5: - Add __init to __uniphier_cache_set_locked_ways() function Changes in v4: - Add more detailed comments to explain why no spin lock is needed - Add two examples to the binding document Changes in v3: - Drop bogus includes Changes in v2: - Use pr_fmt() to have pr_ are automatically prefixed - Re-design to initialize the outer cache earlier in init_IRQ() - Require DT properties such as "cacne-unified", "cache-size", "cache-sets", "cache-size", "cache-line-size". - Follow "next-level-cache" property to search further outer caches Masahiro Yamada (3): ARM: uniphier: add outer cache support ARM: uniphier: rework SMP operations to use trampoline code ARM: dts: uniphier: add outer cache controller nodes .../bindings/arm/uniphier/cache-uniphier.txt | 60 +++ MAINTAINERS| 2 + arch/arm/boot/dts/uniphier-ph1-ld4.dtsi| 13 + arch/arm/boot/dts/uniphier-ph1-pro4.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-pro5.dtsi | 27 + arch/arm/boot/dts/uniphier-ph1-sld3.dtsi | 14 + arch/arm/boot/dts/uniphier-ph1-sld8.dtsi | 13 + arch/arm/boot/dts/uniphier-proxstream2.dtsi| 16 + arch/arm/include/asm/hardware/cache-uniphier.h | 46 ++ arch/arm/kernel/irq.c | 3 + arch/arm/mach-uniphier/Makefile| 2 +- arch/arm/mach-uniphier/headsmp.S | 43 ++ arch/arm/mach-uniphier/platsmp.c | 185 +-- arch/arm/mm/Kconfig| 10 + arch/arm/mm/Makefile | 1 + arch/arm/mm/cache-uniphier.c | 555 + 16 files changed, 973 insertions(+), 31 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/uniphier/cache-uniphier.txt create mode 100644 arch/arm/include/asm/hardware/cache-uniphier.h create mode 100644 arch/arm/mach-uniphier/headsmp.S create mode 100644 arch/arm/mm/cache-uniphier.c -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 3/3] ARM: dts: uniphier: add outer cache controller nodes
Add L2 cache controller nodes for all the UniPhier SoC DTSI.
Also, add an L3 cache controller node for PH1-Pro5 DTSI.
Signed-off-by: Masahiro Yamada
---
arch/arm/boot/dts/uniphier-ph1-ld4.dtsi | 13 +
arch/arm/boot/dts/uniphier-ph1-pro4.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-pro5.dtsi| 27 +++
arch/arm/boot/dts/uniphier-ph1-sld3.dtsi| 14 ++
arch/arm/boot/dts/uniphier-ph1-sld8.dtsi| 13 +
arch/arm/boot/dts/uniphier-proxstream2.dtsi | 16
6 files changed, 97 insertions(+)
diff --git a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
index a6a185f..ae13469 100644
--- a/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-ld4.dtsi
@@ -55,6 +55,7 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <&l2>;
};
};
@@ -91,6 +92,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(512 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
index e8bbc45..85377b2 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro4.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <&l2>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <&l2>;
};
};
@@ -98,6 +100,18 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x4>,
+ <0x506c 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+ cache-size = <(768 * 1024)>;
+ cache-sets = <256>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ };
+
serial0: serial@54006800 {
compatible = "socionext,uniphier-uart";
status = "disabled";
diff --git a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
index 59c2b12..96da01e 100644
--- a/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/boot/dts/uniphier-ph1-pro5.dtsi
@@ -56,12 +56,14 @@
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <0>;
+ next-level-cache = <&l2>;
};
cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a9";
reg = <1>;
+ next-level-cache = <&l2>;
};
};
@@ -98,6 +100,31 @@
#size-cells = <1>;
};
+ l2: l2-cache@500c {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c 0x2000>, <0x503c0100 0x8>,
+ <0x506c 0x400>;
+ interrupts = <0 190 4>, <0 191 4>;
+ cache-unified;
+ cache-size = <(2 * 1024 * 1024)>;
+ cache-sets = <512>;
+ cache-line-size = <128>;
+ cache-level = <2>;
+ next-level-cache = <&l3>;
+ };
+
+ l3: l3-cache@500c8000 {
+ compatible = "socionext,uniphier-system-cache";
+ reg = <0x500c8000 0x2000>, <0x503c8100 0x8>,
+ <0x506c8000 0x400>;
+ interrupts = <0 174 4>, <0 175 4>;
+ cache-unified;
+
Re: [PATCH v4 0/3] ARM: uniphier: add outer cache support and rework SMP operations
2015-09-30 20:01 GMT+09:00 Masahiro Yamada : > Hi Olof, > > Now Linux 4.3-rc1 is out, so I am back to this. > > 1/3: add outer cache support > 2/3: rework SMP operations > 3/3: add device tree nodes > > Because 2/3 highly depends on 1/3, I hope whole of this series > is applied through ARM-SOC tree. > > > Changes in v4: > - Add more detailed comments to explain why no spin lock is needed > - Add two examples to the binding document > > Changes in v3: > - Drop bogus includes > > Changes in v2: > - Use pr_fmt() to have pr_ are automatically prefixed > - Re-design to initialize the outer cache earlier in init_IRQ() > - Require DT properties such as "cacne-unified", "cache-size", > "cache-sets", "cache-size", "cache-line-size". > - Follow "next-level-cache" property to search further outer caches > I found something to be fixed. I will send v5. -- Best Regards Masahiro Yamada -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc: mediatek: Fix random hang up issue while kernel init
Hi Daniel, On Thu, 2015-10-01 at 18:08 +0800, Daniel Kurtz wrote: > I see two cases where "a power domain is a consumer of a clock": > (a) the clock is needed to access the power domain control > registers. The clock must actually be in another power domain, since > otherwise you could never turn *on* the power domain in question. > (b) the clock is needed to talk to the power domain that is about to > turn off, or that was just turned on - these clocks are usually used > to control some kind of bus arbitration, etc. In this case, the > clocks are only accessed when the power domain is on. > > I would argue that in both cases, the clock should in theory should > only be enabled/disabled by the power on/off routine for the duration > of time that is needed, and that it should not be "left enabled" by > the power domain on/off function... I can see how this might be a > useful optimization - but it also seems like a way to burn extra power > by leaving on a clock that is not necessarily being used. > > But - perhaps I am over thinking this, and it is standard practice to > bundle power domains with the clocks that service components in the > power domain. Yes, you are right. Power domain on/off operations need clocks to get status of the subsystem. Keeping clocks on during power domain on is an optimization. But to model a clock controller as a power domain consumer, or say we need to control power domain before clock on/off, is not a good practice because we always consider clock operations should be light weight. Power domains should be controlled explicitly by subsystem drivers, instead of hiding behind clock controls. > Or, alternatively, just prepare venc_sel once during init, for each > clock controller that needs it, when configuring the clock controller > node (for example, in mtk_vencsys_init()). This is similar to how we > set up 'critical clocks'. > By just preparing the clock, you tell the common clock core: > "my clock controller will need this clock later; please make sure > that it can be enabled/disabled later during atomic context." In current implementation, PLLs will be turned on in clk_prepare(). So if a clock is always prepared, its parent PLL will be kept on even if the clock is not enabled. It consumes extra power, so we don't prefer this kind of solution. Best regards, James -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: dt: Rename incorrect interrupt related binding
[CCed linux-sh, Magnus] On Tue, Sep 29, 2015 at 09:43:08AM +0100, Lee Jones wrote: > interrupts-names => interrupt-names > > Other line changes are re-aligning. > > Signed-off-by: Lee Jones Thanks, I have queued this up as a cleanup for v4.4. > --- > .../bindings/memory-controllers/renesas-memory-controllers.txt | 6 > +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git > a/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt > > b/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt > index c64b792..9f78e6c 100644 > --- > a/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt > +++ > b/Documentation/devicetree/bindings/memory-controllers/renesas-memory-controllers.txt > @@ -24,9 +24,9 @@ Required properties: > Optional properties: >- interrupts: Must contain a list of interrupt specifiers for memory > controller interrupts, if available. > - - interrupts-names: Must contain a list of interrupt names corresponding to > - the interrupts in the interrupts property, if available. > - Valid interrupt names are: > + - interrupt-names: Must contain a list of interrupt names corresponding to > + the interrupts in the interrupts property, if available. > + Valid interrupt names are: > - "sec" (secure interrupt) > - "temp" (normal (temperature) interrupt) >- power-domains: Must contain a reference to the PM domain that the memory > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: shmobile: r8a7794: link PCI USB devices to USB PHY
Hi Sergei, On Tue, Sep 29, 2015 at 03:52:39PM +0300, Sergei Shtylyov wrote: > Hello. > > On 9/29/2015 3:37 AM, Simon Horman wrote: > > >>Describe the PCI USB devices that are behind the PCI bridges, adding > >>necessary > >>links to the USB PHY device. > >> > >>Signed-off-by: Sergei Shtylyov > >> > >>--- > >>This patch is against 'renesas-devel-20150911v2-v4.2' tag of Simon Horman's > >>'renesas.git' repo plus the R8A7794/SILK PCI USB and USB PHY support patches > >>just posted. > > >Does this series have any dependencies (e.g. bindings) other > >This patch, you mean? > > >than the aforementioned R8A7794/SILK PCI USB and USB PHY support patches? Thanks, I have queued this up for v4.4. I think I have got everything now but please let me know if you have any shmobile DT patches outstanding which are ready to be queued-up. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/2] Add USB PHY device tree support for R8A7794/SILK board
Hi Sergei, On Fri, Oct 02, 2015 at 01:03:41AM +0300, Sergei Shtylyov wrote: > Hello. > >Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's > 'renesas-devel-20151001-v4.3-rc3' tag. Here we add the USB PHY device tree > support on the R8A7794/SILK low cost board. > > [1/2] ARM: shmobile: r8a7794: add USB PHY DT support > [2/2] ARM: shmobile: silk: enable USB PHY Thanks, I have queued these up for v4.4. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/2] ARM: shmobile: add Porter board DT bindings
On Thu, Oct 01, 2015 at 02:01:38AM +0300, Sergei Shtylyov wrote: > Add Porter device tree bindings documentation, listing it as a supported > board. > > This allows to use checkpatch to validate DTSes referring to the Porter board. > > Signed-off-by: Sergei Shtylyov Thanks Sergei, I have queued this and the following patch up for v4.4. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/4] irqchip/gic-v3-its: Add handling of PCI requester id.
From: David Daney
Replace open coded generation PCI/MSI requester id with call to the
new function pci_msi_domain_get_msi_rid() which applies the "msi-map"
to the id value.
Signed-off-by: David Daney
---
drivers/irqchip/irq-gic-v3-its-pci-msi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
index cf351c6..7bbf64a 100644
--- a/drivers/irqchip/irq-gic-v3-its-pci-msi.c
+++ b/drivers/irqchip/irq-gic-v3-its-pci-msi.c
@@ -42,7 +42,6 @@ static struct irq_chip its_msi_irq_chip = {
struct its_pci_alias {
struct pci_dev *pdev;
- u32 dev_id;
u32 count;
};
@@ -60,7 +59,6 @@ static int its_get_pci_alias(struct pci_dev *pdev, u16 alias,
void *data)
{
struct its_pci_alias *dev_alias = data;
- dev_alias->dev_id = alias;
if (pdev != dev_alias->pdev)
dev_alias->count += its_pci_msi_vec_count(dev_alias->pdev);
@@ -86,7 +84,7 @@ static int its_pci_msi_prepare(struct irq_domain *domain,
struct device *dev,
pci_for_each_dma_alias(pdev, its_get_pci_alias, &dev_alias);
/* ITS specific DeviceID, as the core ITS ignores dev. */
- info->scratchpad[0].ul = dev_alias.dev_id;
+ info->scratchpad[0].ul = pci_msi_domain_get_msi_rid(domain, pdev);
return msi_info->ops->msi_prepare(domain->parent,
dev, dev_alias.count, info);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 2/4] of/irq: Add new function of_msi_map_rid()
From: David Daney
The device tree property "msi-map" specifies how to create the PCI
requester id used in some MSI controllers. Add a new function
of_msi_map_rid() that finds the msi-map property and applies its
translation to a given requester id.
Reviewed-by: Marc Zyngier
Acked-by: Rob Herring
Signed-off-by: David Daney
---
drivers/of/irq.c | 84 ++
include/linux/of_irq.h | 7 +
2 files changed, 91 insertions(+)
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 55317fa..c90bd4e 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -598,3 +598,87 @@ void of_msi_configure(struct device *dev, struct
device_node *np)
d = irq_find_host(msi_np);
dev_set_msi_domain(dev, d);
}
+
+/**
+ * of_msi_map_rid - Map a MSI requester ID for a device.
+ * @dev: device for which the mapping is to be done.
+ * @msi_np: device node of the expected msi controller.
+ * @rid_in: unmapped MSI requester ID for the device.
+ *
+ * Walk up the device hierarchy looking for devices with a "msi-map"
+ * property. If found, apply the mapping to @rid_in.
+ *
+ * Returns the mapped MSI requester ID.
+ */
+u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in)
+{
+ struct device *parent_dev;
+ struct device_node *msi_controller_node;
+ u32 map_mask, masked_rid, rid_base, msi_base, rid_len, phandle;
+ int msi_map_len;
+ bool matched;
+ u32 rid_out = rid_in;
+ const __be32 *msi_map = NULL;
+
+ /*
+* Walk up the device parent links looking for one with a
+* "msi-map" property.
+*/
+ for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
+ if (!parent_dev->of_node)
+ continue;
+
+ msi_map = of_get_property(parent_dev->of_node,
+ "msi-map", &msi_map_len);
+ if (!msi_map)
+ continue;
+
+ if (msi_map_len % (4 * sizeof(__be32))) {
+ dev_err(parent_dev, "Error: Bad msi-map length: %d\n",
+ msi_map_len);
+ return rid_out;
+ }
+ /* We have a good parent_dev and msi_map, let's use them. */
+ break;
+ }
+ if (!msi_map)
+ return rid_out;
+
+ /* The default is to select all bits. */
+ map_mask = 0x;
+
+ /*
+* Can be overridden by "msi-map-mask" property. If
+* of_property_read_u32() fails, the default is used.
+*/
+ of_property_read_u32(parent_dev->of_node, "msi-map-mask", &map_mask);
+
+ masked_rid = map_mask & rid_in;
+ matched = false;
+ while (!matched && msi_map_len >= 4 * sizeof(__be32)) {
+ rid_base = be32_to_cpup(msi_map + 0);
+ phandle = be32_to_cpup(msi_map + 1);
+ msi_base = be32_to_cpup(msi_map + 2);
+ rid_len = be32_to_cpup(msi_map + 3);
+
+ msi_controller_node = of_find_node_by_phandle(phandle);
+
+ matched = masked_rid >= rid_base &&
+ masked_rid < rid_base + rid_len &&
+ msi_np == msi_controller_node;
+
+ of_node_put(msi_controller_node);
+ msi_map_len -= 4 * sizeof(__be32);
+ msi_map += 4;
+ }
+ if (!matched)
+ return rid_out;
+
+ rid_out = masked_rid + msi_base;
+ dev_dbg(dev,
+ "msi-map at: %s, using mask %08x, rid-base: %08x, msi-base:
%08x, length: %08x, rid: %08x -> %08x\n",
+ dev_name(parent_dev), map_mask, rid_base, msi_base,
+ rid_len, rid_in, rid_out);
+
+ return rid_out;
+}
diff --git a/include/linux/of_irq.h b/include/linux/of_irq.h
index 4bcbd58..8cd9334 100644
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@ -75,6 +75,7 @@ static inline int of_irq_to_resource_table(struct device_node
*dev,
extern unsigned int irq_of_parse_and_map(struct device_node *node, int index);
extern struct device_node *of_irq_find_parent(struct device_node *child);
extern void of_msi_configure(struct device *dev, struct device_node *np);
+u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 rid_in);
#else /* !CONFIG_OF */
static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
@@ -87,6 +88,12 @@ static inline void *of_irq_find_parent(struct device_node
*child)
{
return NULL;
}
+
+static inline u32 of_msi_map_rid(struct device *dev,
+struct device_node *msi_np, u32 rid_in)
+{
+ return rid_in;
+}
#endif /* !CONFIG_OF */
#endif /* __OF_IRQ_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majo
[PATCH v4 1/4] Docs: dt: Add PCI MSI map bindings
From: Mark Rutland
Currently msi-parent is used by a few bindings to describe the
relationship between a PCI root complex and a single MSI controller, but
this property does not have a generic binding document.
Additionally, msi-parent is insufficient to describe more complex
relationships between MSI controllers and devices under a root complex,
where devices may be able to target multiple MSI controllers, or where
MSI controllers use (non-probeable) sideband information to distinguish
devices.
This patch adds a generic binding for mapping PCI devices to MSI
controllers. This document covers msi-parent, and a new msi-map property
(specific to PCI*) which may be used to map devices (identified by their
Requester ID) to sideband data for each MSI controller that they may
target.
Acked-by: Marc Zyngier
Signed-off-by: Mark Rutland
Signed-off-by: David Daney
---
Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++
1 file changed, 220 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt
diff --git a/Documentation/devicetree/bindings/pci/pci-msi.txt
b/Documentation/devicetree/bindings/pci/pci-msi.txt
new file mode 100644
index 000..9b3cc81
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-msi.txt
@@ -0,0 +1,220 @@
+This document describes the generic device tree binding for describing the
+relationship between PCI devices and MSI controllers.
+
+Each PCI device under a root complex is uniquely identified by its Requester ID
+(AKA RID). A Requester ID is a triplet of a Bus number, Device number, and
+Function number.
+
+For the purpose of this document, when treated as a numeric value, a RID is
+formatted such that:
+
+* Bits [15:8] are the Bus number.
+* Bits [7:3] are the Device number.
+* Bits [2:0] are the Function number.
+* Any other bits required for padding must be zero.
+
+MSIs may be distinguished in part through the use of sideband data accompanying
+writes. In the case of PCI devices, this sideband data may be derived from the
+Requester ID. A mechanism is required to associate a device with both the MSI
+controllers it can address, and the sideband data that will be associated with
+its writes to those controllers.
+
+For generic MSI bindings, see
+Documentation/devicetree/bindings/interrupt-controller/msi.txt.
+
+
+PCI root complex
+
+
+Optional properties
+---
+
+- msi-map: Maps a Requester ID to an MSI controller and associated
+ msi-specifier data. The property is an arbitrary number of tuples of
+ (rid-base,msi-controller,msi-base,length), where:
+
+ * rid-base is a single cell describing the first RID matched by the entry.
+
+ * msi-controller is a single phandle to an MSI controller
+
+ * msi-base is an msi-specifier describing the msi-specifier produced for the
+first RID matched by the entry.
+
+ * length is a single cell describing how many consecutive RIDs are matched
+following the rid-base.
+
+ Any RID r in the interval [rid-base, rid-base + length) is associated with
+ the listed msi-controller, with the msi-specifier (r - rid-base + msi-base).
+
+- msi-map-mask: A mask to be applied to each Requester ID prior to being mapped
+ to an msi-specifier per the msi-map property.
+
+- msi-parent: Describes the MSI parent of the root complex itself. Where
+ the root complex and MSI controller do not pass sideband data with MSI
+ writes, this property may be used to describe the MSI controller(s)
+ used by PCI devices under the root complex, if defined as such in the
+ binding for the root complex.
+
+
+Example (1)
+===
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ msi: msi-controller@a {
+ reg = <0xa 0x1>;
+ compatible = "vendor,some-controller";
+ msi-controller;
+ #msi-cells = <1>;
+ };
+
+ pci: pci@f {
+ reg = <0xf 0x1>;
+ compatible = "vendor,pcie-root-complex";
+ device_type = "pci";
+
+ /*
+* The sideband data provided to the MSI controller is
+* the RID, identity-mapped.
+*/
+ msi-map = <0x0 &msi_a 0x0 0x1>,
+ };
+};
+
+
+Example (2)
+===
+
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ msi: msi-controller@a {
+ reg = <0xa 0x1>;
+ compatible = "vendor,some-controller";
+ msi-controller;
+ #msi-cells = <1>;
+ };
+
+ pci: pci@f {
+ reg = <0xf 0x1>;
+ compatible = "vendor,pcie-root-complex";
+ device_type = "pci";
+
+ /*
+* The sideband data provided to the MSI controller is
+* the RID, masked to only the device and function bits.
+*/
+ msi-map = <0x0 &msi_a 0x0 0x100>,
+ msi-map-mask = <0xff>
+
[PATCH v4 3/4] PCI/MSI: Add helper function pci_msi_domain_get_msi_rid().
From: David Daney
Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
Initially needed by gic-v3 based systems. It will be used by follow on
patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c
Initially supports mapping the RID via OF device tree. In the future,
this could be extended to use ACPI _IORT tables as well.
Signed-off-by: David Daney
---
drivers/pci/msi.c | 30 ++
include/linux/msi.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d449714..81a2798 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "pci.h"
@@ -1327,4 +1328,33 @@ struct irq_domain
*pci_msi_create_default_irq_domain(struct device_node *node,
return domain;
}
+
+static int get_msi_id_cb(struct pci_dev *pdev, u16 alias, void *data)
+{
+ u32 *pa = data;
+
+ *pa = alias;
+ return 0;
+}
+/**
+ * pci_msi_domain_get_msi_rid - Get the MSI requester id (RID)
+ * @domain:The interrupt domain
+ * @pdev: The PCI device.
+ *
+ * The RID for a device is formed from the alias, with a firmware
+ * supplied mapping applied
+ *
+ * Returns: The RID.
+ */
+u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev *pdev)
+{
+ u32 rid = 0;
+
+ pci_for_each_dma_alias(pdev, get_msi_id_cb, &rid);
+
+ if (domain->of_node)
+ rid = of_msi_map_rid(&pdev->dev, domain->of_node, rid);
+
+ return rid;
+}
#endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ad939d0..56e3b76 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -293,6 +293,7 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct pci_dev
*dev,
struct msi_desc *desc);
int pci_msi_domain_check_cap(struct irq_domain *domain,
struct msi_domain_info *info, struct device *dev);
+u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev
*pdev);
#endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
#endif /* LINUX_MSI_H */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/4] MSI, of, irqchip/gicv3-its: Handle "msi-map" properties.
From: David Daney The first patch from Mark Rutland adds the OF device tree binding description, which explains what we are attempting to do here. For MSI messages on GICv3 systems there is some side-band data that accompanies the message, this data is specified in the OF device tree "msi-map" property of the PCI host driver. The second patch adds a parser to get the required information out of the device tree. The third patch creates the pci_msi_domain_get_msi_rid() function to make it more convenient to generate the proper PCI/MSI requester id. The final patch converts gicv3-its to use the new infrastructure. Changes from v1: Factor out the device tree access code to a separate function in drivers/of/irq.c Changes from v2: Added the pci_msi_domain_get_msi_rid() patch to generalize the support a bit more. Changes from v3: Added Acked-by to 2/4. Simplified and improved pci_msi_domain_get_msi_rid() as suggested by Marc Zyngier in 3/4. 1/4 and 4/4 unchanged. David Daney (3): of/irq: Add new function of_msi_map_rid() PCI/MSI: Add helper function pci_msi_domain_get_msi_rid(). irqchip/gic-v3-its: Add handling of PCI requester id. Mark Rutland (1): Docs: dt: Add PCI MSI map bindings Documentation/devicetree/bindings/pci/pci-msi.txt | 220 ++ drivers/irqchip/irq-gic-v3-its-pci-msi.c | 4 +- drivers/of/irq.c | 84 + drivers/pci/msi.c | 30 +++ include/linux/msi.h | 1 + include/linux/of_irq.h| 7 + 6 files changed, 343 insertions(+), 3 deletions(-) create mode 100644 Documentation/devicetree/bindings/pci/pci-msi.txt -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] PCI: Xilinx-NWL-PCIe: Added support for Xilinx NWL PCIe Host Controller
Hi Arnd,
On 10/1/2015 2:52 AM, Arnd Bergmann wrote:
> On Thursday 01 October 2015 14:29:21 Bharat Kumar Gogada wrote:
>> Adding PCIe Root Port driver for Xilinx PCIe NWL bridge IP.
>>
>> Signed-off-by: Bharat Kumar Gogada
>> Signed-off-by: Ravi Kiran Gummaluri
>> ---
>> Removed unneccessary comments
>> Modified setup_sspl implementation
>> Added more details in binding Documentation
>> ---
>> .../devicetree/bindings/pci/xilinx-nwl-pcie.txt| 49 +
>> drivers/pci/host/Kconfig |9 +
>> drivers/pci/host/Makefile |1 +
>> drivers/pci/host/pcie-xilinx-nwl.c | 1029
>>
>> 4 files changed, 1088 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>> create mode 100644 drivers/pci/host/pcie-xilinx-nwl.c
>>
>> diff --git a/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>> b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>> new file mode 100644
>> index 000..ed87184
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/pci/xilinx-nwl-pcie.txt
>> @@ -0,0 +1,49 @@
>> +* Xilinx NWL PCIe Root Port Bridge DT description
>> +
>> +Required properties:
>> +- compatible: Should contain "xlnx,nwl-pcie-2.11"
>> +- #address-cells: Address representation for root ports, set to <3>
>> +- #size-cells: Size representation for root ports, set to <2>
>> +- #interrupt-cells: specifies the number of cells needed to encode an
>> +interrupt source. The value must be 1.
>> +- reg: Should contain Bridge, PCIe Controller registers location,
>> +configuration sapce, and length
>> +- reg-names: Must include the following entries:
>> +"breg": bridge registers
>> +"pcireg": PCIe controller registers
>> +"cfg": configuration space region
>> +- device_type: must be "pci"
>> +- interrupts: Should contain NWL PCIe interrupt
>> +- interrupt-names: Must include the following entries:
>> +"misc": interrupt asserted when miscellaneous is recieved
>> +"intx": interrupt that is asserted when an legacy interrupt is received
>> +"msi_1, msi_0": interrupt asserted when msi is recieved
>
> The msi and intx interrupts don't really belong here: For intx, please
> use an interrupt-map property as the other host drivers do.
>
> For MSI, the usual answer is that there should be a separate device node
> for the MSI controller, and an msi-parent property in the PCI host.
>
> This lets you use the same code for hosts that have a GICv2m or GICv3
> that comes with its own MSI controller.
>
Sorry for stealing this discussion, :)
I have some questions here, since this affects how I should implement
the MSI support for iProc based PCIe controller. I understand it makes
more sense to use separate device node for MSI and have "msi-parent"
from the pci node points to the MSI node, and that MSI node can be
gicv2m or gicv3 based on more advanced ARMv8 platforms.
Then I would assume the MSI controller would deserve its own driver?
Which is a lot of people do nowadays. In that case, how I should handle
the case when the iProc MSI support is handled through some event queue
mechanism with their registers embedded in the PCIe controller register
space?
Does the following logic make sense to you?
1. parse phandle of "msi-parent"
2. Call of_pci_find_msi_chip_by_node to hook it up to msi chip already
registered (in the gicv2m and gicv3 case)
3. If failed, fall back to use the iProc's own event queue logic by
calling iproc_pcie_msi_init.
The iProc MSI still has its own node that looks like this:
141 msi0: msi@2002 {
142 msi-controller;
143 interrupt-parent = <&gic>;
144 interrupts = ,
145 ,
146 ,
147 ,
148 ,
149 ;
150 brcm,num-eq-region = <1>;
151 brcm,num-msi-msg-region = <1>;
152 };
But it does not have its own "reg" since they are embedded in the PCI
controller's registers and it relies on one calling iproc_pcie_msi_init
to pass in base register value and some other information.
Thanks,
Ray
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/8] clk: qoriq: Move chip-specific knowledge into driver
[Resending to updated e-mail address] On Tue, 2015-08-11 at 11:25 -0700, Michael Turquette wrote: > Hi Scott, > > Quoting Scott Wood (2015-06-18 19:49:10) > > The existing device tree bindings are error-prone and inflexible. > > Correct the mistake by moving the knowledge into the driver, which > > has more flexibility in describing the quirks of each chip. This leaves > > the device tree to its proper role of identifying a programming interface > > rather than describing its individual registers. > > Sorry for not responding to this one sooner. Fell through the cracks. > > All of the changes to drives/clk/clk-qoriq.c look great to me. I assume > you need to keep all of these patches together and want to the take > through the freescale tree? If so feel free to add, > > Acked-by: Michael Turquette Is the ack still valid for the v3 patchset? -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/8] clk: qoriq: Move chip-specific knowledge into driver
On Tue, 2015-08-11 at 11:25 -0700, Michael Turquette wrote: > Hi Scott, > > Quoting Scott Wood (2015-06-18 19:49:10) > > The existing device tree bindings are error-prone and inflexible. > > Correct the mistake by moving the knowledge into the driver, which > > has more flexibility in describing the quirks of each chip. This leaves > > the device tree to its proper role of identifying a programming interface > > rather than describing its individual registers. > > Sorry for not responding to this one sooner. Fell through the cracks. > > All of the changes to drives/clk/clk-qoriq.c look great to me. I assume > you need to keep all of these patches together and want to the take > through the freescale tree? If so feel free to add, > > Acked-by: Michael Turquette Is the ack still valid for the v3 patchset? -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] clk: bcm2835: Add a driver for the auxiliary peripheral clock gates.
On 09/10, Eric Anholt wrote:
> diff --git a/drivers/clk/bcm/clk-bcm2835-aux.c
> b/drivers/clk/bcm/clk-bcm2835-aux.c
> new file mode 100644
> index 000..1efa6fb
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-bcm2835-aux.c
> @@ -0,0 +1,80 @@
> +/*
> + * Copyright (C) 2015 Broadcom
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * 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.
> + */
> +
> +#include
> +#include
Is this include used?
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static int bcm2835_aux_clk_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct clk_onecell_data *onecell;
> + const char *parent;
> + struct clk *parent_clk;
> + void __iomem *reg;
> +
> + parent_clk = of_clk_get(dev->of_node, 0);
> + if (IS_ERR(parent_clk))
> + return PTR_ERR(parent_clk);
We have a device, any reason we can't use clk_get() directly?
> + parent = __clk_get_name(parent_clk);
> +
> + reg = of_iomap(dev->of_node, 0);
We have a platform device here, why aren't we using platform
device APIs like platform_get_resource() and
devm_ioremap_resource()?
> + if (!reg)
> + return -ENODEV;
> +
> + onecell = kmalloc(sizeof(*onecell), GFP_KERNEL);
> + if (!onecell)
> + return -ENOMEM;
> + onecell->clk_num = BCM2835_AUX_CLOCK_COUNT;
> + onecell->clks = kzalloc(sizeof(*onecell->clks) *
kcalloc?
> + BCM2835_AUX_CLOCK_COUNT, GFP_KERNEL);
> + if (!onecell->clks)
> + return -ENOMEM;
> +
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/4] clk: bcm2835: Add binding docs for the new platform clock driver.
On 09/28, Eric Anholt wrote: > Previously we've only supported a few fixed clocks based on > assumptions about how the firmware sets up the clocks, but this > binding will let us control the actual (audio power domain) clock > manager. > > Signed-off-by: Eric Anholt > Acked-by: Stephen Warren > --- Applied to clk-bcm2385 and merged into clk-next. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/4] clk: bcm2835: Move under bcm/ with other Broadcom SoC clk drivers.
On 09/28, Eric Anholt wrote: > clk-bcm2835.c predates the drivers under bcm/, but all the new BCM > drivers are going in there so let's follow them. > > Signed-off-by: Eric Anholt > Acked-by: Stephen Warren > --- Applied to clk-bcm2385 and merged into clk-next. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] clk: bcm2835: Add support for programming the audio domain clocks.
On 09/28, Eric Anholt wrote:
> +
> +static const char *bcm2835_clock_per_parents[] = {
> +static const char *bcm2835_clock_vpu_parents[] = {
> +static const char *bcm2835_clock_osc_parents[] = {
Can these parent arrays be const char * const ?
> + "gnd",
> + "xosc",
> + "testdebug0",
> + "testdebug1"
> +};
> +
> +/*
> + * Used for a 1Mhz clock for the system clocksource, and also used by
> + * the watchdog timer and the camera pulse generator.
> + */
> +static struct bcm2835_clock_data bcm2835_clock_timer_data = {
> +static struct bcm2835_clock_data bcm2835_clock_otp_data = {
> +static struct bcm2835_clock_data bcm2835_clock_vpu_data = {
> +static struct bcm2835_clock_data bcm2835_clock_v3d_data = {
> +static struct bcm2835_clock_data bcm2835_clock_isp_data = {
> +static struct bcm2835_clock_data bcm2835_clock_h264_data = {
> +static struct bcm2835_clock_data bcm2835_clock_vec_data = {
> +static struct bcm2835_clock_data bcm2835_clock_uart_data = {
> +static struct bcm2835_clock_data bcm2835_clock_hsm_data = {
> +static struct bcm2835_clock_data bcm2835_clock_sdram_data = {
> +static struct bcm2835_clock_data bcm2835_clock_tsens_data = {
> +static struct bcm2835_clock_data bcm2835_clock_emmc_data = {
Can all these data structures be const?
> +static int bcm2835_pll_is_on(struct clk_hw *hw)
> +{
> + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw);
> + struct bcm2835_cprman *cprman = pll->cprman;
> + const struct bcm2835_pll_data *data = pll->data;
> +
> + return (cprman_read(cprman, data->a2w_ctrl_reg) &
> + A2W_PLL_CTRL_PRST_DISABLE);
Useless parenthesis.
> +}
> +
> +static void bcm2835_pll_choose_ndiv_and_fdiv(unsigned long rate,
> + unsigned long parent_rate,
> + u32 *ndiv, u32 *fdiv)
> +{
> + u64 div;
> +
> + div = ((u64)rate << A2W_PLL_FRAC_BITS);
> + do_div(div, parent_rate);
> +
> + *ndiv = div >> A2W_PLL_FRAC_BITS;
> + *fdiv = div & ((1 << A2W_PLL_FRAC_BITS) - 1);
> +}
[..]
> +static unsigned long bcm2835_pll_get_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw);
> + struct bcm2835_cprman *cprman = pll->cprman;
> + const struct bcm2835_pll_data *data = pll->data;
> + u32 a2wctrl = cprman_read(cprman, data->a2w_ctrl_reg);
> + u32 ndiv, pdiv, fdiv;
> +
> + if (parent_rate == 0)
> + return 0;
> +
> + fdiv = cprman_read(cprman, data->frac_reg) & A2W_PLL_FRAC_MASK;
> + ndiv = (a2wctrl & A2W_PLL_CTRL_NDIV_MASK) >> A2W_PLL_CTRL_NDIV_SHIFT;
> + pdiv = (a2wctrl & A2W_PLL_CTRL_PDIV_MASK) >> A2W_PLL_CTRL_PDIV_SHIFT;
> +
> + if (cprman_read(cprman, data->ana_reg_base + 4) &
> + data->ana->fb_prediv_mask) {
> + ndiv *= 2;
> + }
How about a local variable so that we can put the if on one line
and drop the braces?
> +
> + return bcm2835_pll_rate_from_divisors(parent_rate, ndiv, fdiv, pdiv);
> +}
> +
[..]
> +static int bcm2835_pll_on(struct clk_hw *hw)
> +{
> + struct bcm2835_pll *pll = container_of(hw, struct bcm2835_pll, hw);
> + struct bcm2835_cprman *cprman = pll->cprman;
> + const struct bcm2835_pll_data *data = pll->data;
> +
> + /* Take the PLL out of reset. */
> + cprman_write(cprman, data->cm_ctrl_reg,
> + cprman_read(cprman, data->cm_ctrl_reg) & ~CM_PLL_ANARST);
> +
> + /* Wait for the PLL to lock. */
> + while (!(cprman_read(cprman, CM_LOCK) & data->lock_mask))
> + cpu_relax();
Is there any reasonable timeout that we can put here? Hopefully
this isn't an infinite loop.
> +
> + return 0;
> +}
> +
> +static int bcm2835_pll_set_rate(struct clk_hw *hw,
> + unsigned long rate, unsigned long parent_rate)
> +{
[..]
> +
> + /* Unmask the reference clock from the oscillator. */
> + cprman_write(cprman, A2W_XOSC_CTRL,
> + cprman_read(cprman, A2W_XOSC_CTRL) |
> + data->reference_enable_mask);
> +
> + if (do_ana_setup_first) {
> + cprman_write(cprman, data->ana_reg_base + 12, ana3);
> + cprman_write(cprman, data->ana_reg_base + 8, ana2);
ana2 never changes, so why do we need to write it again?
> + cprman_write(cprman, data->ana_reg_base + 4, ana1);
> + cprman_write(cprman, data->ana_reg_base + 0, ana0);
Maybe this should be a function that takes a u32 array of size 4.
> + }
> +
> + /* Set the PLL multiplier from the oscillator. */
> + cprman_write(cprman, data->frac_reg, fdiv);
> + cprman_write(cprman, data->a2w_ctrl_reg,
> + (cprman_read(cprman, data->a2w_ctrl_reg) &
> + ~(A2W_PLL_CTRL_NDIV_MASK |
> + A2W_PLL_CTRL_PDIV_MASK)) |
> + (ndiv << A2W_PLL_CTRL_NDIV_SHIFT) |
> +
Re: [PATCH v4 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC
On 10/01/2015 03:37 PM, Andrew F. Davis wrote:
This patch adds support for TPS65912 mfd device. It provides
communication through the I2C and SPI interfaces. It contains
the following components:
- Regulators
- GPIO controller
Signed-off-by: Andrew F. Davis
Forgot to mention, as the kbuild bot figured out, this patch needs
b4fe8ba ("regmap: Add generic macro to define regmap_irq")
from Lee Jones' tree to build.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] Add driver for the si514 clock generator chip
On 09/17, Mike Looijmans wrote:
> This patch adds the driver and devicetree documentation for the
> Silicon Labs SI514 clock generator chip. This is an I2C controlled
> oscilator capable of generating clock signals ranging from 100kHz
s/oscilator/oscillator/
> to 250MHz.
>
> Signed-off-by: Mike Looijmans
> ---
> diff --git a/Documentation/devicetree/bindings/clock/silabs,si514.txt
> b/Documentation/devicetree/bindings/clock/silabs,si514.txt
> new file mode 100644
> index 000..05964d1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/silabs,si514.txt
> @@ -0,0 +1,27 @@
> +Binding for Silicon Labs 514 programmable I2C clock generator.
> +
> +Reference
> +This binding uses the common clock binding[1]. Details about the device can
> be
> +found in the datasheet[2].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +[2] Si514 datasheet
> +http://www.silabs.com/Support%20Documents/TechnicalDocs/si514.pdf
> +
> +Required properties:
> + - compatible: Shall be "silabs,si514"
> + - reg: I2C device address.
> + - #clock-cells: From common clock bindings: Shall be 0.
> +
> +Optional properties:
> + - clock-output-names: From common clock bindings. Recommended to be "si514".
> + - clock-frequency: Output frequency to generate. This defines the output
> + frequency set during boot. It can be reprogrammed during
> + runtime through the common clock framework.
Can we use assigned clock rates instead of this property?
> +
> +Example:
> + si514: clock-generator@55 {
> + reg = <0x55>;
> + #clock-cells = <0>;
> + compatible = "silabs,si514";
> + };
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index 42f7120..6ac7deb5 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -68,6 +68,16 @@ config COMMON_CLK_SI5351
> This driver supports Silicon Labs 5351A/B/C programmable clock
> generators.
>
> +config COMMON_CLK_SI514
> + tristate "Clock driver for SiLabs 514 devices"
> + depends on I2C
> + depends on OF
It actually depends on this to build?
> + select REGMAP_I2C
> + help
> + ---help---
> + This driver supports the Silicon Labs 514 programmable clock
> + generator.
> +
> config COMMON_CLK_SI570
> tristate "Clock driver for SiLabs 570 and compatible devices"
> depends on I2C
> diff --git a/drivers/clk/clk-si514.c b/drivers/clk/clk-si514.c
> new file mode 100644
> index 000..ca70818
> --- /dev/null
> +++ b/drivers/clk/clk-si514.c
> @@ -0,0 +1,393 @@
> +
> +#include
I'd expect some sort of linux/clk.h include here if we're using
clk APIs.
> +#include
> +#include
> +#include
> +#include
> +#include
[...]
> +
> +/* Program clock settings into hardware */
This comment is useless.
> +static int si514_set_muldiv(struct clk_si514 *data,
> + struct clk_si514_muldiv *settings)
> +{
> + u8 lp;
> + u8 reg[7];
> + int err;
> +
> + /* Calculate LP1/LP2 according to table 13 in the datasheet */
> + /* 65.259980246 */
> + if ((settings->m_int < 65) ||
> + ((settings->m_int == 65) && (settings->m_frac <= 139575831)))
> + lp = 0x22;
> + /* 67.859763463 */
> + else if ((settings->m_int < 67) ||
> + ((settings->m_int == 67) && (settings->m_frac <= 461581994)))
> + lp = 0x23;
> + /* 72.937624981 */
> + else if ((settings->m_int < 72) ||
> + ((settings->m_int == 72) && (settings->m_frac <= 503383578)))
> + lp = 0x33;
> + /* 75.843265046 */
> + else if ((settings->m_int < 75) ||
> + ((settings->m_int == 75) && (settings->m_frac <= 452724474)))
> + lp = 0x34;
Drop the extra parenthesis on these if statements.
> + else
> + lp = 0x44;
> +
> + err = regmap_write(data->regmap, SI514_REG_LP, lp);
> + if (err < 0)
> + return err;
> +
> + reg[0] = settings->m_frac & 0xff;
> + reg[1] = (settings->m_frac >> 8) & 0xff;
> + reg[2] = (settings->m_frac >> 16) & 0xff;
> + reg[3] = ((settings->m_frac >> 24) | (settings->m_int << 5)) & 0xff;
> + reg[4] = (settings->m_int >> 3) & 0xff;
> + reg[5] = (settings->hs_div) & 0xff;
> + reg[6] = (((settings->hs_div) >> 8) |
> + (settings->ls_div_bits << 4)) & 0xff;
The & 0xff part is redundant. Assignment truncates for us.
> +
> + err = regmap_bulk_write(data->regmap, SI514_REG_HS_DIV, reg + 5, 2);
> + if (err < 0)
> + return err;
> + /* Writing to SI514_REG_M_INT_FRAC triggers the clock change, so that
> + * must be written last */
Please fix multi-line commenting style.
> + return regmap_bulk_write(data->regmap, SI514_REG_M_FRAC1, reg, 5);
> +}
> +
> +/* Calculate divider settings for a given frequency */
> +static int si514_calc_muldiv(struct clk_si514_muldiv *settings,
> + unsigned long frequency)
> +{
> + u64 m;
>
Re: [PATCH 4/5] dt-bindings: add binding for marvell berlin4ct SoC
On 09/22, Jisheng Zhang wrote:
> +This binding uses the common clock binding[1].
> +
> +[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +The berlin4ct clock subsystem generates and supplies clock to various
> +controllers within the berlin4ct SoC. The berlin4ct contains 3 clock
> controller
> +blocks: pll, gateclk, berlin-clk.
> +
> +Required Properties:
> +
> +- compatible: should be one of the following.
> + - "marvell,berlin-pll" - pll compatible
> + - "marvell,berlin4ct-clk" - berlin clk compatible
> + - "marvell,berlin4ct-gateclk" - gateclk compatible
> +- reg: physical base address of the clock controller and length of memory
> mapped
> + region. For pll, the second reg defines the bypass register base address
> and
> + length of memory mapped region.
> +- #clock-cells: for pll should 0, for gateclk and berlin clk should be 1.
> +- #bypass-shift: the bypass bit in bypass register.
> +
> +Example:
> +
> +syspll: syspll {
> + compatible = "marvell,berlin-pll";
> + reg = <0xea0200 0x14>, <0xea0710 4>;
> + #clock-cells = <0>;
> + clocks = <&osc>;
> + bypass-shift = /bits/ 8 <0>;
> +};
> +
> +clk: clk {
> + compatible = "marvell,berlin4ct-clk";
> + reg = <0xea0720 0x144>;
> + #clock-cells = <1>;
> + clocks = <&syspll>;
> +};
Is there one clock controller at 0xea of size 0x1000? We've
been trying to push people towards using the device model and
writing drivers with probe instead of using CLK_OF_DECLARE() for
their platform clocks. From the looks of this binding, we're
splitting up the different types of clocks into their own nodes
and then registering them with CLK_OF_DECLARE.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/5] clk: berlin: add clk support for berlin4ct
On 09/22, Jisheng Zhang wrote:
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "clk.h"
> +
> +#define CLK_SOURCE_MAX 5
> +
> +static struct clk_onecell_data gateclk_data;
> +static struct clk_onecell_data clk_data;
> +
> +static DEFINE_SPINLOCK(lock);
This is really generic. How about berlin4ct_lock? That will make
lockdep happy because the name for the key will have some
meaning.
> +static void __init berlin4ct_gateclk_setup(struct device_node *np)
> +{
> + int i, n, ret;
> + void __iomem *base;
> + struct clk **clks;
> +
> + base = of_iomap(np, 0);
> + if (WARN_ON(!base))
> + return;
> +
> + n = ARRAY_SIZE(berlin4ct_gates);
> + clks = kzalloc(n * sizeof(struct clk *), GFP_KERNEL);
kcalloc()
> + if (WARN_ON(!clks))
Same comment about dropping WARN_ON for an allocation failure.
> + return;
> +
> + for (i = 0; i < n; i++) {
> + clks[i] = clk_register_gate(NULL, berlin4ct_gates[i].name,
> + berlin4ct_gates[i].parent_name,
> + berlin4ct_gates[i].flags, base,
> + berlin4ct_gates[i].bit_idx, 0, &lock);
> + WARN_ON(IS_ERR(clks[i]));
> + }
> +
> + gateclk_data.clks = clks;
> + gateclk_data.clk_num = i;
> +
> + ret = of_clk_add_provider(np, of_clk_src_onecell_get,
> + &gateclk_data);
> + if (WARN_ON(ret))
> + return;
Drop that return please.
> +
> +}
> +CLK_OF_DECLARE(berlin4ct_gateclk, "marvell,berlin4ct-gateclk",
> +berlin4ct_gateclk_setup);
> +
> +static void __init berlin4ct_clk_setup(struct device_node *np)
> +{
> + int i, n, ret, num_parents;
> + void __iomem *base;
> + struct clk **clks;
> + const char *parent_names[CLK_SOURCE_MAX];
> +
> + num_parents = of_clk_get_parent_count(np);
> + if (num_parents <= 0 || num_parents > CLK_SOURCE_MAX)
> + return;
> +
> + of_clk_parent_fill(np, parent_names, num_parents);
> +
> + base = of_iomap(np, 0);
> + if (WARN_ON(!base))
> + return;
> +
> + n = ARRAY_SIZE(berlin4ct_descs);
> + clks = kzalloc(n * sizeof(struct clk *), GFP_KERNEL);
kcalloc()
> + if (WARN_ON(!clks))
Same comment about dropping WARN_ON for an allocation failure.
> + return;
> +
> + for (i = 0; i < n; i++) {
> + clks[i] = berlin_clk_register(berlin4ct_descs[i].name,
> + num_parents, parent_names,
> + berlin4ct_descs[i].flags,
> + base + berlin4ct_descs[i].offset);
> + WARN_ON(IS_ERR(clks[i]));
> + }
> +
> + clk_data.clks = clks;
> + clk_data.clk_num = i;
> +
> + ret = of_clk_add_provider(np, of_clk_src_onecell_get,
> + &clk_data);
> + if (WARN_ON(ret))
> + return;
Drop that return please.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] dts/ls2085a: Update DTSI to add support of various peripherals
On Thu, Oct 1, 2015 at 4:58 PM, Scott Wood wrote:
> On Thu, 2015-10-01 at 16:42 -0500, Li Yang wrote:
>> On Thu, Oct 1, 2015 at 3:05 PM, Stuart Yoder
>> wrote:
>> > Hi Rob,
>> >
>> > Had a question about your comments on the patch below.
>> >
>> > You singled out 3 nodes (gic,uart,clockgen) and said "This should be
>> > under a bus node."
>> >
>> > What is special about those 3 nodes types? There are a bunch of other
>> > memory
>> > mapped SoC devices as well in the DTS.
>> >
>> > I skimmed the dts files under arch/arm64 and it looks like most have a
>> > simple-bus
>> > SoC node like this where SoC devices are under:
>> >
>> > soc {
>> > #address-cells = <2>;
>> > #size-cells = <2>;
>> > compatible = "simple-bus";
>> > ranges;
>> >
>> > Is that what you are looking for-- for all SoC devices?
>>
>> I think the key is to have the soc node and have all the on-chip
>> devices defined underneath it.
>>
>> I read the following from the booting-without-of.txt document:
>>
>> f) the /soc node
>>
>> This node is used to represent a system-on-a-chip (SoC) and must be
>> present if the processor is a SoC. The top-level soc node contains
>> information that is global to all devices on the SoC. The node name
>> should contain a unit address for the SoC, which is the base address
>> of the memory-mapped register set for the SoC. The name of an SoC
>> node should start with "soc", and the remainder of the name should
>> represent the part number for the soc. For example, the MPC8540's
>> soc node would be called "soc8540".
>>
>> A lot of device trees didn't follow the soc naming scheme and
>> just used "soc" as the node name. I am not sure if we want to enforce
>> the naming in the future or update the document to make it more relax.
>
> Update the document. Having the SoC name in the node name was a pain, which
> is why we don't do it anymore. Ideally, this text should be moved into a
> binding for Freescale PPC/LS SoCs. It really doesn't have the broad
> applicability that this historical document suggests, and even on our SoCs it
> doesn't represent the entire SoC. It represents CCSR/IMMR.
Having the soc node to represent the CCSR space is a Freescale
specific thing. But using the soc node to be the parent for all the
on-chip devices seems to be a good practice for all device trees. I
do think we should maintain a standard for the top level nodes of a
device tree.
Regards,
Leo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] clk: berlin: add common clk driver for newer SoCs
On 09/22, Jisheng Zhang wrote:
> +
> +static u8 clk_div[] = {1, 2, 4, 6, 8, 12, 1, 1};
> +
> +static unsigned long berlin_clk_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + u32 val, divider;
> + struct berlin_clk *clk = to_berlin_clk(hw);
> +
> + val = readl_relaxed(clk->base);
> + if (val & CLKD3SWITCH)
> + divider = 3;
> + else {
> + if (val & CLKSWITCH) {
> + val >>= CLKSEL_SHIFT;
> + val &= CLKSEL_MASK;
> + divider = clk_div[val];
> + } else
> + divider = 1;
> + }
How about we drop the clk_div array and use code?
if (val & CLKSWITCH) {
val >>= CLKSEL_SHIFT;
val &= CLKSEL_MASK;
}
divider = 1
if (val < 6)
divider <<= val;
> +
> + return parent_rate / divider;
> +}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] clk: berlin: add common pll driver
On 09/22, Jisheng Zhang wrote:
> diff --git a/drivers/clk/berlin/pll.c b/drivers/clk/berlin/pll.c
> new file mode 100644
> index 000..9aad0b6
> --- /dev/null
> +++ b/drivers/clk/berlin/pll.c
> @@ -0,0 +1,119 @@
> +
> +#define to_berlin_pll(hw) container_of(hw, struct berlin_pll, hw)
> +
> +static u8 vcodiv_berlin[] = {1, 2, 4, 8, 16, 32, 64, 128};
This is an array of 1 << index position...
> +
> +static unsigned long berlin_pll_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + u32 val, fbdiv, rfdiv, vcodivsel, bypass;
> + struct berlin_pll *pll = to_berlin_pll(hw);
> +
> + bypass = readl_relaxed(pll->bypass);
> + if (bypass & (1 << pll->bypass_shift))
> + return parent_rate;
> +
> + val = readl_relaxed(pll->ctrl + PLL_CTRL0);
> + fbdiv = (val >> 12) & 0x1FF;
> + rfdiv = (val >> 3) & 0x1FF;
> + val = readl_relaxed(pll->ctrl + PLL_CTRL1);
> + vcodivsel = (val >> 9) & 0x7;
> + return parent_rate * fbdiv * 4 / rfdiv /
> + vcodiv_berlin[vcodivsel];
so we can replace this with 1 << vcodivsel?
> +}
> +
> +static u8 berlin_pll_get_parent(struct clk_hw *hw)
> +{
> + struct berlin_pll *pll = to_berlin_pll(hw);
> + u32 bypass = readl_relaxed(pll->bypass);
> +
> + if (bypass & (1 << pll->bypass_shift))
> + return 1;
> + else
> + return 0;
Simplify this to
if (bypass & (1 << pll->bypass_shift))
return 1;
return 0;
or
return !!(bypass & (1 << pll->bypass_shift))
> +}
> +
> +static const struct clk_ops berlin_pll_ops = {
> + .recalc_rate= berlin_pll_recalc_rate,
> + .get_parent = berlin_pll_get_parent,
> +};
> +
> +void __init berlin_pll_setup(struct device_node *np)
static?
> +{
> + struct clk_init_data init;
> + struct berlin_pll *pll;
> + const char *parent_names[PLL_SOURCE_MAX];
> + struct clk *clk;
> + int ret, num_parents;
> +
> + num_parents = of_clk_get_parent_count(np);
> + if (num_parents <= 0 || num_parents > PLL_SOURCE_MAX)
> + return;
> +
> + of_clk_parent_fill(np, parent_names, num_parents);
> +
> + pll = kzalloc(sizeof(*pll), GFP_KERNEL);
> + if (WARN_ON(!pll))
We already print a big warning on allocation failures, so drop
the WARN_ON please.
> + return;
> +
> + pll->ctrl = of_iomap(np, 0);
> + pll->bypass = of_iomap(np, 1);
> + ret = of_property_read_u8(np, "bypass-shift", &pll->bypass_shift);
> + if (WARN_ON(!pll->ctrl || !pll->bypass || ret))
> + return;
> +
> + init.name = np->name;
> + init.ops = &berlin_pll_ops;
> + init.parent_names = parent_names;
> + init.num_parents = num_parents;
init.flags is not initialized. Please initialize the init struct
on the stack to 0 to avoid future problems.
> +
> + pll->hw.init = &init;
> +
> + clk = clk_register(NULL, &pll->hw);
> + if (WARN_ON(IS_ERR(clk)))
> + return;
> +
> + ret = of_clk_add_provider(np, of_clk_src_simple_get, clk);
> + if (WARN_ON(ret))
> + return;
This return is useless.
> +}
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/8] dt-bindings: move backlight bindings under leds
Backlights are generally a subtype of LEDs at least from a software
point of view if not always electrically. Move the bindings from the
video directory to underneath the leds dir.
Signed-off-by: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
Documentation/devicetree/bindings/{video => leds}/backlight/88pm860x.txt | 0
.../devicetree/bindings/{video => leds}/backlight/gpio-backlight.txt | 0
Documentation/devicetree/bindings/{video => leds}/backlight/lp855x.txt| 0
.../devicetree/bindings/{video => leds}/backlight/max8925-backlight.txt | 0
.../devicetree/bindings/{video => leds}/backlight/pm8941-wled.txt | 0
.../devicetree/bindings/{video => leds}/backlight/pwm-backlight.txt | 0
.../devicetree/bindings/{video => leds}/backlight/sky81452-backlight.txt | 0
.../devicetree/bindings/{video => leds}/backlight/tps65217-backlight.txt | 0
8 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{video =>
leds}/backlight/88pm860x.txt (100%)
rename Documentation/devicetree/bindings/{video =>
leds}/backlight/gpio-backlight.txt (100%)
rename Documentation/devicetree/bindings/{video => leds}/backlight/lp855x.txt
(100%)
rename Documentation/devicetree/bindings/{video =>
leds}/backlight/max8925-backlight.txt (100%)
rename Documentation/devicetree/bindings/{video =>
leds}/backlight/pm8941-wled.txt (100%)
rename Documentation/devicetree/bindings/{video =>
leds}/backlight/pwm-backlight.txt (100%)
rename Documentation/devicetree/bindings/{video =>
leds}/backlight/sky81452-backlight.txt (100%)
rename Documentation/devicetree/bindings/{video =>
leds}/backlight/tps65217-backlight.txt (100%)
diff --git a/Documentation/devicetree/bindings/video/backlight/88pm860x.txt
b/Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/video/backlight/88pm860x.txt
rename to Documentation/devicetree/bindings/leds/backlight/88pm860x.txt
diff --git
a/Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt
b/Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt
similarity index 100%
rename from Documentation/devicetree/bindings/video/backlight/gpio-backlight.txt
rename to Documentation/devicetree/bindings/leds/backlight/gpio-backlight.txt
diff --git a/Documentation/devicetree/bindings/video/backlight/lp855x.txt
b/Documentation/devicetree/bindings/leds/backlight/lp855x.txt
similarity index 100%
rename from Documentation/devicetree/bindings/video/backlight/lp855x.txt
rename to Documentation/devicetree/bindings/leds/backlight/lp855x.txt
diff --git
a/Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
b/Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt
similarity index 100%
rename from
Documentation/devicetree/bindings/video/backlight/max8925-backlight.txt
rename to Documentation/devicetree/bindings/leds/backlight/max8925-backlight.txt
diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
similarity index 100%
rename from Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
rename to Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
diff --git
a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
similarity index 100%
rename from Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
rename to Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
diff --git
a/Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
b/Documentation/devicetree/bindings/leds/backlight/sky81452-backlight.txt
similarity index 100%
rename from
Documentation/devicetree/bindings/video/backlight/sky81452-backlight.txt
rename to
Documentation/devicetree/bindings/leds/backlight/sky81452-backlight.txt
diff --git
a/Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt
b/Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
similarity index 100%
rename from
Documentation/devicetree/bindings/video/backlight/tps65217-backlight.txt
rename to
Documentation/devicetree/bindings/leds/backlight/tps65217-backlight.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/8] dt-bindings: consolidate eeprom bindings
Create a top level eeprom binding directory and move several scattered
binding files there.
Signed-off-by: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
Documentation/devicetree/bindings/{misc => eeprom}/at25.txt | 0
Documentation/devicetree/bindings/{ => eeprom}/eeprom.txt | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{misc => eeprom}/at25.txt (100%)
rename Documentation/devicetree/bindings/{ => eeprom}/eeprom.txt (100%)
diff --git a/Documentation/devicetree/bindings/misc/at25.txt
b/Documentation/devicetree/bindings/eeprom/at25.txt
similarity index 100%
rename from Documentation/devicetree/bindings/misc/at25.txt
rename to Documentation/devicetree/bindings/eeprom/at25.txt
diff --git a/Documentation/devicetree/bindings/eeprom.txt
b/Documentation/devicetree/bindings/eeprom/eeprom.txt
similarity index 100%
rename from Documentation/devicetree/bindings/eeprom.txt
rename to Documentation/devicetree/bindings/eeprom/eeprom.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/8] dt-bindings: consolidate display related bindings
This is a quite large renaming to consolidate display related bindings
into a single "display" directory from various scattered locations of
video, drm, gpu, fb, mipi, and panel. The prior location was somewhat
based on the Linux driver location, but bindings should be independent
of that.
Signed-off-by: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
Documentation/devicetree/bindings/{video => display}/arm,pl11x.txt| 0
.../devicetree/bindings/{drm => display}/armada/marvell,dove-lcd.txt | 0
Documentation/devicetree/bindings/{video => display}/atmel,lcdc.txt | 0
Documentation/devicetree/bindings/{drm => display}/atmel/hlcdc-dc.txt | 0
.../devicetree/bindings/{video => display/bridge}/adi,adv7123.txt | 0
.../devicetree/bindings/{video => display/bridge}/adi,adv7511.txt | 0
Documentation/devicetree/bindings/{drm => display}/bridge/dw_hdmi.txt | 0
Documentation/devicetree/bindings/{video => display}/bridge/ps8622.txt| 0
Documentation/devicetree/bindings/{video => display}/bridge/ptn3460.txt | 0
Documentation/devicetree/bindings/{drm/i2c => display/bridge}/tda998x.txt | 0
.../{video/thine,thc63lvdm83d => display/bridge/thine,thc63lvdm83d.txt} | 0
.../devicetree/bindings/{video => display}/cirrus,clps711x-fb.txt | 0
.../bindings/{video => display/connector}/analog-tv-connector.txt | 0
.../devicetree/bindings/{video => display/connector}/dvi-connector.txt| 0
.../devicetree/bindings/{video => display/connector}/hdmi-connector.txt | 0
.../devicetree/bindings/{video => display/connector}/vga-connector.txt| 0
.../devicetree/bindings/{video => display/exynos}/exynos-mic.txt | 0
.../devicetree/bindings/{video => display/exynos}/exynos5433-decon.txt| 0
.../devicetree/bindings/{video => display/exynos}/exynos7-decon.txt | 0
Documentation/devicetree/bindings/{video => display/exynos}/exynos_dp.txt | 0
.../devicetree/bindings/{video => display/exynos}/exynos_dsim.txt | 0
.../devicetree/bindings/{video => display/exynos}/exynos_hdmi.txt | 0
.../devicetree/bindings/{video => display/exynos}/exynos_hdmiddc.txt | 0
.../devicetree/bindings/{video => display/exynos}/exynos_hdmiphy.txt | 0
.../devicetree/bindings/{video => display/exynos}/exynos_mixer.txt| 0
.../devicetree/bindings/{video => display/exynos}/samsung-fimd.txt| 0
Documentation/devicetree/bindings/{video => display}/fsl,dcu.txt | 0
Documentation/devicetree/bindings/{video => display/imx}/fsl,imx-fb.txt | 0
Documentation/devicetree/bindings/{drm => display}/imx/fsl-imx-drm.txt| 0
Documentation/devicetree/bindings/{drm => display}/imx/hdmi.txt | 0
Documentation/devicetree/bindings/{drm => display}/imx/ldb.txt| 0
Documentation/devicetree/bindings/{mipi/dsi => display}/mipi-dsi-bus.txt | 0
Documentation/devicetree/bindings/{drm => display}/msm/dsi.txt| 0
Documentation/devicetree/bindings/{drm => display}/msm/edp.txt| 0
Documentation/devicetree/bindings/{drm => display}/msm/gpu.txt| 0
Documentation/devicetree/bindings/{drm => display}/msm/hdmi.txt | 0
Documentation/devicetree/bindings/{drm => display}/msm/mdp.txt| 0
Documentation/devicetree/bindings/{fb => display}/mxsfb.txt | 0
.../devicetree/bindings/{ => display}/panel/ampire,am800480r3tmqwa1h.txt | 0
Documentation/devicetree/bindings/{ => display}/panel/auo,b080uan01.txt | 0
Documentation/devicetree/bindings/{ => display}/panel/auo,b101aw03.txt| 0
Documentation/devicetree/bindings/{ => display}/panel/auo,b101ean01.txt | 0
Documentation/devicetree/bindings/{ => display}/panel/auo,b101xtn01.txt | 0
Documentation/devicetree/bindings/{ => display}/panel/auo,b116xw03.txt| 0
Documentation/devicetree/bindings/{ => display}/panel/auo,b133htn01.txt | 0
Documentation/devicetree/bindings/{ => display}/panel/auo,b133xtn01.txt | 0
Documentation/devicetree/bindings/{ => display}/panel/avic,tm070ddh03.txt | 0
.../devicetree/bindings/{ => display}/panel/chunghwa,claa101wa01a.txt | 0
.../devicetree/bindings/{ => display}/panel/chunghwa,claa101wb03.txt | 0
.../devicetree/bindings/{video => display/panel}/display-timing.txt | 0
Documentation/devicetree/bindings/{ => display}/panel/edt,et057090dhu.txt | 0
Documentation/devicetree/bindings/{ => display}/panel/edt,et070080dh6.txt | 0
.../devicetree/bindings/{ => display}/panel/edt,etm0700g0dh6.txt | 0
.../devicetree/bindings/{ => display}/panel/foxlink,fl500wvr00-a0t.txt| 0
.../devicetree/bindings/{ => display}/panel/giantplus,gpg482739qs5.txt| 0
.../devicetree/bindings/{ => display}/panel/hannstar,hsd070pww1.txt | 0
.../devicetree/bindings/{ => display}/panel/hannstar,hsd100pxn1.txt | 0
.../devicetree/bindings/{ => display}/panel/hit,tx23d38vm0caa.txt | 0
.../devicetree/bindings/
[PATCH 5/8] dt-bindings: consolidate various misc bindings
Move various bindings in misc to appropriate subsystem directories.
Signed-off-by: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
Documentation/devicetree/bindings/{nvec => arm/tegra}/nvidia,nvec.txt | 0
Documentation/devicetree/bindings/{misc => iio/accel}/lis302.txt | 0
Documentation/devicetree/bindings/{misc => iio/dac}/ti,dac7512.txt| 0
Documentation/devicetree/bindings/{misc => iio/pressure}/bmp085.txt | 0
Documentation/devicetree/bindings/{hid => input}/hid-over-i2c.txt | 0
Documentation/devicetree/bindings/{ => interrupt-controller}/open-pic.txt | 0
6 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{nvec => arm/tegra}/nvidia,nvec.txt
(100%)
rename Documentation/devicetree/bindings/{misc => iio/accel}/lis302.txt (100%)
rename Documentation/devicetree/bindings/{misc => iio/dac}/ti,dac7512.txt
(100%)
rename Documentation/devicetree/bindings/{misc => iio/pressure}/bmp085.txt
(100%)
rename Documentation/devicetree/bindings/{hid => input}/hid-over-i2c.txt (100%)
rename Documentation/devicetree/bindings/{ =>
interrupt-controller}/open-pic.txt (100%)
diff --git a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
b/Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt
similarity index 100%
rename from Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
rename to Documentation/devicetree/bindings/arm/tegra/nvidia,nvec.txt
diff --git a/Documentation/devicetree/bindings/misc/lis302.txt
b/Documentation/devicetree/bindings/iio/accel/lis302.txt
similarity index 100%
rename from Documentation/devicetree/bindings/misc/lis302.txt
rename to Documentation/devicetree/bindings/iio/accel/lis302.txt
diff --git a/Documentation/devicetree/bindings/misc/ti,dac7512.txt
b/Documentation/devicetree/bindings/iio/dac/ti,dac7512.txt
similarity index 100%
rename from Documentation/devicetree/bindings/misc/ti,dac7512.txt
rename to Documentation/devicetree/bindings/iio/dac/ti,dac7512.txt
diff --git a/Documentation/devicetree/bindings/misc/bmp085.txt
b/Documentation/devicetree/bindings/iio/pressure/bmp085.txt
similarity index 100%
rename from Documentation/devicetree/bindings/misc/bmp085.txt
rename to Documentation/devicetree/bindings/iio/pressure/bmp085.txt
diff --git a/Documentation/devicetree/bindings/hid/hid-over-i2c.txt
b/Documentation/devicetree/bindings/input/hid-over-i2c.txt
similarity index 100%
rename from Documentation/devicetree/bindings/hid/hid-over-i2c.txt
rename to Documentation/devicetree/bindings/input/hid-over-i2c.txt
diff --git a/Documentation/devicetree/bindings/open-pic.txt
b/Documentation/devicetree/bindings/interrupt-controller/open-pic.txt
similarity index 100%
rename from Documentation/devicetree/bindings/open-pic.txt
rename to Documentation/devicetree/bindings/interrupt-controller/open-pic.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/8] dt-bindings: consolidate RNG bindings
We have RNG bindings in hwrng/ and rng/. Consolidate them all under rng/.
Signed-off-by: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
Documentation/devicetree/bindings/{hwrng => rng}/atmel-trng.txt| 0
Documentation/devicetree/bindings/{hwrng => rng}/brcm,iproc-rng200.txt | 0
Documentation/devicetree/bindings/{hwrng => rng}/omap_rng.txt | 0
Documentation/devicetree/bindings/{hwrng => rng}/timeriomem_rng.txt| 0
4 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{hwrng => rng}/atmel-trng.txt (100%)
rename Documentation/devicetree/bindings/{hwrng => rng}/brcm,iproc-rng200.txt
(100%)
rename Documentation/devicetree/bindings/{hwrng => rng}/omap_rng.txt (100%)
rename Documentation/devicetree/bindings/{hwrng => rng}/timeriomem_rng.txt
(100%)
diff --git a/Documentation/devicetree/bindings/hwrng/atmel-trng.txt
b/Documentation/devicetree/bindings/rng/atmel-trng.txt
similarity index 100%
rename from Documentation/devicetree/bindings/hwrng/atmel-trng.txt
rename to Documentation/devicetree/bindings/rng/atmel-trng.txt
diff --git a/Documentation/devicetree/bindings/hwrng/brcm,iproc-rng200.txt
b/Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt
similarity index 100%
rename from Documentation/devicetree/bindings/hwrng/brcm,iproc-rng200.txt
rename to Documentation/devicetree/bindings/rng/brcm,iproc-rng200.txt
diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt
b/Documentation/devicetree/bindings/rng/omap_rng.txt
similarity index 100%
rename from Documentation/devicetree/bindings/hwrng/omap_rng.txt
rename to Documentation/devicetree/bindings/rng/omap_rng.txt
diff --git a/Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt
b/Documentation/devicetree/bindings/rng/timeriomem_rng.txt
similarity index 100%
rename from Documentation/devicetree/bindings/hwrng/timeriomem_rng.txt
rename to Documentation/devicetree/bindings/rng/timeriomem_rng.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/8] dt-bindings: move Calxeda bindings to appropriate subsystems
Move the Calxeda memory controller and PHY bindings to appropriate
subsystem directories.
Signed-off-by: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
.../calxeda/mem-ctrlr.txt => memory-controllers/calxeda-ddr-ctrlr.txt}| 0
.../bindings/{arm/calxeda/combophy.txt => phy/calxeda-combophy.txt} | 0
2 files changed, 0 insertions(+), 0 deletions(-)
rename Documentation/devicetree/bindings/{arm/calxeda/mem-ctrlr.txt =>
memory-controllers/calxeda-ddr-ctrlr.txt} (100%)
rename Documentation/devicetree/bindings/{arm/calxeda/combophy.txt =>
phy/calxeda-combophy.txt} (100%)
diff --git a/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt
b/Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt
rename to
Documentation/devicetree/bindings/memory-controllers/calxeda-ddr-ctrlr.txt
diff --git a/Documentation/devicetree/bindings/arm/calxeda/combophy.txt
b/Documentation/devicetree/bindings/phy/calxeda-combophy.txt
similarity index 100%
rename from Documentation/devicetree/bindings/arm/calxeda/combophy.txt
rename to Documentation/devicetree/bindings/phy/calxeda-combophy.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/8] dt-bindings: consolidate USB PHYs in bindings/phy
Move USB PHY bindings under usb directory to phy directory which already
contains other USB PHY bindings.
The Samsung USB PHY binding is obsolete and can be removed.
Signed-off-by: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
.../keystone-phy.txt => phy/keystone-usb-phy.txt} | 0
.../{usb/mxs-phy.txt => phy/mxs-usb-phy.txt} | 0
.../{usb => phy}/nvidia,tegra20-usb-phy.txt| 0
.../bindings/{usb => phy}/qcom,usb-8x16-phy.txt| 0
.../devicetree/bindings/usb/samsung-usbphy.txt | 117 -
5 files changed, 117 deletions(-)
rename Documentation/devicetree/bindings/{usb/keystone-phy.txt =>
phy/keystone-usb-phy.txt} (100%)
rename Documentation/devicetree/bindings/{usb/mxs-phy.txt =>
phy/mxs-usb-phy.txt} (100%)
rename Documentation/devicetree/bindings/{usb =>
phy}/nvidia,tegra20-usb-phy.txt (100%)
rename Documentation/devicetree/bindings/{usb => phy}/qcom,usb-8x16-phy.txt
(100%)
delete mode 100644 Documentation/devicetree/bindings/usb/samsung-usbphy.txt
diff --git a/Documentation/devicetree/bindings/usb/keystone-phy.txt
b/Documentation/devicetree/bindings/phy/keystone-usb-phy.txt
similarity index 100%
rename from Documentation/devicetree/bindings/usb/keystone-phy.txt
rename to Documentation/devicetree/bindings/phy/keystone-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt
b/Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
similarity index 100%
rename from Documentation/devicetree/bindings/usb/mxs-phy.txt
rename to Documentation/devicetree/bindings/phy/mxs-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
b/Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.txt
similarity index 100%
rename from Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
rename to Documentation/devicetree/bindings/phy/nvidia,tegra20-usb-phy.txt
diff --git a/Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt
b/Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt
similarity index 100%
rename from Documentation/devicetree/bindings/usb/qcom,usb-8x16-phy.txt
rename to Documentation/devicetree/bindings/phy/qcom,usb-8x16-phy.txt
diff --git a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
b/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
deleted file mode 100644
index 33fd354..000
--- a/Documentation/devicetree/bindings/usb/samsung-usbphy.txt
+++ /dev/null
@@ -1,117 +0,0 @@
-SAMSUNG USB-PHY controllers
-
-** Samsung's usb 2.0 phy transceiver
-
-The Samsung's usb 2.0 phy transceiver is used for controlling
-usb 2.0 phy for s3c-hsotg as well as ehci-s5p and ohci-exynos
-usb controllers across Samsung SOCs.
-TODO: Adding the PHY binding with controller(s) according to the under
-development generic PHY driver.
-
-Required properties:
-
-Exynos4210:
-- compatible : should be "samsung,exynos4210-usb2phy"
-- reg : base physical address of the phy registers and length of memory mapped
- region.
-- clocks: Clock IDs array as required by the controller.
-- clock-names: names of clock correseponding IDs clock property as requested
- by the controller driver.
-
-Exynos5250:
-- compatible : should be "samsung,exynos5250-usb2phy"
-- reg : base physical address of the phy registers and length of memory mapped
- region.
-
-Optional properties:
-- #address-cells: should be '1' when usbphy node has a child node with 'reg'
- property.
-- #size-cells: should be '1' when usbphy node has a child node with 'reg'
- property.
-- ranges: allows valid translation between child's address space and parent's
- address space.
-
-- The child node 'usbphy-sys' to the node 'usbphy' is for the system controller
- interface for usb-phy. It should provide the following information required
by
- usb-phy controller to control phy.
- - reg : base physical address of PHY_CONTROL registers.
- The size of this register is the total sum of size of all PHY_CONTROL
- registers that the SoC has. For example, the size will be
- '0x4' in case we have only one PHY_CONTROL register (e.g.
- OTHERS register in S3C64XX or USB_PHY_CONTROL register in S5PV210)
- and, '0x8' in case we have two PHY_CONTROL registers (e.g.
- USBDEVICE_PHY_CONTROL and USBHOST_PHY_CONTROL registers in exynos4x).
- and so on.
-
-Example:
- - Exynos4210
-
- usbphy@125B {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "samsung,exynos4210-usb2phy";
- reg = <0x125B 0x100>;
- ranges;
-
- clocks = <&clock 2>, <&clock 305>;
- clock-names = "xusbxti", "otg";
-
- usbphy-sys {
- /* USB device and host PHY_CONTROL registers */
- reg = <0x10020704 0x8>;
- };
- };
-
-
-** Samsung's usb
[PATCH 8/8] dt-bindings: merge ina209 binding into ina2xx binding
The ina209 binding only differs from other ina2xx bindings in the
compatible string, so add it to the common binding and remove the ina209
binding file.
Signed-off-by: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
---
Documentation/devicetree/bindings/hwmon/ina209.txt | 18 --
Documentation/devicetree/bindings/hwmon/ina2xx.txt | 1 +
2 files changed, 1 insertion(+), 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/hwmon/ina209.txt
diff --git a/Documentation/devicetree/bindings/hwmon/ina209.txt
b/Documentation/devicetree/bindings/hwmon/ina209.txt
deleted file mode 100644
index 9dd2bee..000
--- a/Documentation/devicetree/bindings/hwmon/ina209.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-ina209 properties
-
-Required properties:
-- compatible: Must be "ti,ina209"
-- reg: I2C address
-
-Optional properties:
-
-- shunt-resistor
- Shunt resistor value in micro-Ohm
-
-Example:
-
-temp-sensor@4c {
- compatible = "ti,ina209";
- reg = <0x4c>;
- shunt-resistor = <5000>;
-};
diff --git a/Documentation/devicetree/bindings/hwmon/ina2xx.txt
b/Documentation/devicetree/bindings/hwmon/ina2xx.txt
index a2ad85d..9bcd5e8 100644
--- a/Documentation/devicetree/bindings/hwmon/ina2xx.txt
+++ b/Documentation/devicetree/bindings/hwmon/ina2xx.txt
@@ -2,6 +2,7 @@ ina2xx properties
Required properties:
- compatible: Must be one of the following:
+ - "ti,ina209" for ina209
- "ti,ina219" for ina219
- "ti,ina220" for ina220
- "ti,ina226" for ina226
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8] DT binding doc reorganization
The DT binding docs are in need of some love. To start with, there are
various bindings which are not grouped with other similar classes of
hardware. The display related bindings are the worst with several
choices of location somewhat aligned to kernel subsystems (e.g. drm and
video). This series consolidates various bindings to common locations.
No doubt, more work is needed from here.
I don't think this will cause much issue in the merge window since
binding docs don't change often, are not built, and any new files can be
moved after the merge window.
Rob
Rob Herring (8):
dt-bindings: consolidate display related bindings
dt-bindings: move backlight bindings under leds
dt-bindings: consolidate eeprom bindings
dt-bindings: consolidate RNG bindings
dt-bindings: consolidate various misc bindings
dt-bindings: consolidate USB PHYs in bindings/phy
dt-bindings: move Calxeda bindings to appropriate subsystems
dt-bindings: merge ina209 binding into ina2xx binding
.../bindings/{nvec => arm/tegra}/nvidia,nvec.txt | 0
.../bindings/{video => display}/arm,pl11x.txt | 0
.../{drm => display}/armada/marvell,dove-lcd.txt | 0
.../bindings/{video => display}/atmel,lcdc.txt | 0
.../bindings/{drm => display}/atmel/hlcdc-dc.txt | 0
.../{video => display/bridge}/adi,adv7123.txt | 0
.../{video => display/bridge}/adi,adv7511.txt | 0
.../bindings/{drm => display}/bridge/dw_hdmi.txt | 0
.../bindings/{video => display}/bridge/ps8622.txt | 0
.../bindings/{video => display}/bridge/ptn3460.txt | 0
.../{drm/i2c => display/bridge}/tda998x.txt| 0
.../bridge/thine,thc63lvdm83d.txt} | 0
.../{video => display}/cirrus,clps711x-fb.txt | 0
.../connector}/analog-tv-connector.txt | 0
.../{video => display/connector}/dvi-connector.txt | 0
.../connector}/hdmi-connector.txt | 0
.../{video => display/connector}/vga-connector.txt | 0
.../{video => display/exynos}/exynos-mic.txt | 0
.../{video => display/exynos}/exynos5433-decon.txt | 0
.../{video => display/exynos}/exynos7-decon.txt| 0
.../{video => display/exynos}/exynos_dp.txt| 0
.../{video => display/exynos}/exynos_dsim.txt | 0
.../{video => display/exynos}/exynos_hdmi.txt | 0
.../{video => display/exynos}/exynos_hdmiddc.txt | 0
.../{video => display/exynos}/exynos_hdmiphy.txt | 0
.../{video => display/exynos}/exynos_mixer.txt | 0
.../{video => display/exynos}/samsung-fimd.txt | 0
.../bindings/{video => display}/fsl,dcu.txt| 0
.../bindings/{video => display/imx}/fsl,imx-fb.txt | 0
.../bindings/{drm => display}/imx/fsl-imx-drm.txt | 0
.../bindings/{drm => display}/imx/hdmi.txt | 0
.../bindings/{drm => display}/imx/ldb.txt | 0
.../{mipi/dsi => display}/mipi-dsi-bus.txt | 0
.../bindings/{drm => display}/msm/dsi.txt | 0
.../bindings/{drm => display}/msm/edp.txt | 0
.../bindings/{drm => display}/msm/gpu.txt | 0
.../bindings/{drm => display}/msm/hdmi.txt | 0
.../bindings/{drm => display}/msm/mdp.txt | 0
.../devicetree/bindings/{fb => display}/mxsfb.txt | 0
.../panel/ampire,am800480r3tmqwa1h.txt | 0
.../bindings/{ => display}/panel/auo,b080uan01.txt | 0
.../bindings/{ => display}/panel/auo,b101aw03.txt | 0
.../bindings/{ => display}/panel/auo,b101ean01.txt | 0
.../bindings/{ => display}/panel/auo,b101xtn01.txt | 0
.../bindings/{ => display}/panel/auo,b116xw03.txt | 0
.../bindings/{ => display}/panel/auo,b133htn01.txt | 0
.../bindings/{ => display}/panel/auo,b133xtn01.txt | 0
.../{ => display}/panel/avic,tm070ddh03.txt| 0
.../{ => display}/panel/chunghwa,claa101wa01a.txt | 0
.../{ => display}/panel/chunghwa,claa101wb03.txt | 0
.../{video => display/panel}/display-timing.txt| 0
.../{ => display}/panel/edt,et057090dhu.txt| 0
.../{ => display}/panel/edt,et070080dh6.txt| 0
.../{ => display}/panel/edt,etm0700g0dh6.txt | 0
.../{ => display}/panel/foxlink,fl500wvr00-a0t.txt | 0
.../{ => display}/panel/giantplus,gpg482739qs5.txt | 0
.../{ => display}/panel/hannstar,hsd070pww1.txt| 0
.../{ => display}/panel/hannstar,hsd100pxn1.txt| 0
.../{ => display}/panel/hit,tx23d38vm0caa.txt | 0
.../{ => display}/panel/innolux,at043tn24.txt | 0
.../{ => display}/panel/innolux,g121i1-l01.txt | 0
.../{ => display}/panel/innolux,n116bge.txt| 0
.../{ => display}/panel/innolux,n156bge-l21.txt| 0
.../{ => display}/panel/innolux,zj070na-01p.txt| 0
.../bindings/{ => display}/panel/lg,lb070wv8.txt | 0
.../{ => display}/panel/lg,ld070wx3-sl01.txt | 0
.../bindings/{ => display}/panel/lg,lg4573.txt | 0
.../{ => display}/panel/lg,lh500wx1-sd03.txt | 0
.../bindings/{ => display}/panel/lg,lp129qe.txt| 0
[PATCH v2 2/2] ARM: shmobile: silk: enable USB PHY
Enable USB PHY device for the SILK board.
Signed-off-by: Sergei Shtylyov
---
arch/arm/boot/dts/r8a7794-silk.dts |4
1 file changed, 4 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794-silk.dts
===
--- renesas.orig/arch/arm/boot/dts/r8a7794-silk.dts
+++ renesas/arch/arm/boot/dts/r8a7794-silk.dts
@@ -210,3 +210,7 @@
pinctrl-0 = <&usb1_pins>;
pinctrl-names = "default";
};
+
+&usbphy {
+ status = "okay";
+};
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: shmobile: r8a7794: add USB PHY DT support
Define the R8A7794 generic part of the USB PHY device node. It is up to the
board file to enable the device.
Signed-off-by: Sergei Shtylyov
---
Changes in version 2:
- added the "power-domains" property.
arch/arm/boot/dts/r8a7794.dtsi | 20
1 file changed, 20 insertions(+)
Index: renesas/arch/arm/boot/dts/r8a7794.dtsi
===
--- renesas.orig/arch/arm/boot/dts/r8a7794.dtsi
+++ renesas/arch/arm/boot/dts/r8a7794.dtsi
@@ -690,6 +690,26 @@
0x1000 0 0 2 &gic 0 113 IRQ_TYPE_LEVEL_HIGH>;
};
+ usbphy: usb-phy@e6590100 {
+ compatible = "renesas,usb-phy-r8a7794";
+ reg = <0 0xe6590100 0 0x100>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clocks = <&mstp7_clks R8A7794_CLK_HSUSB>;
+ clock-names = "usbhs";
+ power-domains = <&cpg_clocks>;
+ status = "disabled";
+
+ usb0: usb-channel@0 {
+ reg = <0>;
+ #phy-cells = <1>;
+ };
+ usb2: usb-channel@2 {
+ reg = <2>;
+ #phy-cells = <1>;
+ };
+ };
+
clocks {
#address-cells = <2>;
#size-cells = <2>;
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] Add USB PHY device tree support for R8A7794/SILK board
Hello. Here's the set of 2 patches against Simon Horman's 'renesas.git' repo's 'renesas-devel-20151001-v4.3-rc3' tag. Here we add the USB PHY device tree support on the R8A7794/SILK low cost board. [1/2] ARM: shmobile: r8a7794: add USB PHY DT support [2/2] ARM: shmobile: silk: enable USB PHY WBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 07/10] dts/ls2085a: Update DTSI to add support of various peripherals
On Thu, Oct 1, 2015 at 3:05 PM, Stuart Yoder wrote:
> Hi Rob,
>
> Had a question about your comments on the patch below.
>
> You singled out 3 nodes (gic,uart,clockgen) and said "This should be under a
> bus node."
>
> What is special about those 3 nodes types? There are a bunch of other memory
> mapped SoC devices as well in the DTS.
>
> I skimmed the dts files under arch/arm64 and it looks like most have a
> simple-bus
> SoC node like this where SoC devices are under:
>
> soc {
> #address-cells = <2>;
> #size-cells = <2>;
> compatible = "simple-bus";
> ranges;
>
> Is that what you are looking for-- for all SoC devices?
I think the key is to have the soc node and have all the on-chip
devices defined underneath it.
I read the following from the booting-without-of.txt document:
f) the /soc node
This node is used to represent a system-on-a-chip (SoC) and must be
present if the processor is a SoC. The top-level soc node contains
information that is global to all devices on the SoC. The node name
should contain a unit address for the SoC, which is the base address
of the memory-mapped register set for the SoC. The name of an SoC
node should start with "soc", and the remainder of the name should
represent the part number for the soc. For example, the MPC8540's
soc node would be called "soc8540".
A lot of device trees didn't follow the soc naming scheme and
just used "soc" as the node name. I am not sure if we want to enforce
the naming in the future or update the document to make it more relax.
Regards,
Leo
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC
Hi Andrew, [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore] config: xtensa-allyesconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout d617dea974adf7dc262f2d49dea24a673e0403e2 # save the attached .config to linux build tree make.cross ARCH=xtensa All warnings (new ones prefixed by >>): drivers/mfd/tps65912-core.c:29:2: error: implicit declaration of function 'REGMAP_IRQ_REG' [-Werror=implicit-function-declaration] REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_F, 0, TPS65912_INT_STS_PWRHOLD_F), ^ >> drivers/mfd/tps65912-core.c:29:2: warning: missing braces around initializer >> [-Wmissing-braces] >> drivers/mfd/tps65912-core.c:29:2: warning: (near initialization for >> 'tps65912_irqs[0]') [-Wmissing-braces] drivers/mfd/tps65912-core.c:29:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:29:2: error: (near initialization for 'tps65912_irqs[0].reg_offset') drivers/mfd/tps65912-core.c:30:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_VMON, 0, TPS65912_INT_STS_VMON), ^ drivers/mfd/tps65912-core.c:30:2: error: (near initialization for 'tps65912_irqs[0].mask') drivers/mfd/tps65912-core.c:31:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_PWRON, 0, TPS65912_INT_STS_PWRON), ^ drivers/mfd/tps65912-core.c:31:2: error: (near initialization for 'tps65912_irqs[1].reg_offset') drivers/mfd/tps65912-core.c:32:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_PWRON_LP, 0, TPS65912_INT_STS_PWRON_LP), ^ drivers/mfd/tps65912-core.c:32:2: error: (near initialization for 'tps65912_irqs[1].mask') drivers/mfd/tps65912-core.c:33:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_R, 0, TPS65912_INT_STS_PWRHOLD_R), ^ drivers/mfd/tps65912-core.c:33:2: error: (near initialization for 'tps65912_irqs[2].reg_offset') drivers/mfd/tps65912-core.c:34:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_HOTDIE, 0, TPS65912_INT_STS_HOTDIE), ^ drivers/mfd/tps65912-core.c:34:2: error: (near initialization for 'tps65912_irqs[2].mask') drivers/mfd/tps65912-core.c:35:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_R, 0, TPS65912_INT_STS_GPIO1_R), ^ drivers/mfd/tps65912-core.c:35:2: error: (near initialization for 'tps65912_irqs[3].reg_offset') drivers/mfd/tps65912-core.c:36:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_F, 0, TPS65912_INT_STS_GPIO1_F), ^ drivers/mfd/tps65912-core.c:36:2: error: (near initialization for 'tps65912_irqs[3].mask') drivers/mfd/tps65912-core.c:38:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_R, 1, TPS65912_INT_STS2_GPIO2_R), ^ drivers/mfd/tps65912-core.c:38:2: error: (near initialization for 'tps65912_irqs[4].reg_offset') drivers/mfd/tps65912-core.c:39:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_F, 1, TPS65912_INT_STS2_GPIO2_F), ^ drivers/mfd/tps65912-core.c:39:2: error: (near initialization for 'tps65912_irqs[4].mask') drivers/mfd/tps65912-core.c:40:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_R, 1, TPS65912_INT_STS2_GPIO3_R), ^ drivers/mfd/tps65912-core.c:40:2: error: (near initialization for 'tps65912_irqs[5].reg_offset') drivers/mfd/tps65912-core.c:41:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_F, 1, TPS65912_INT_STS2_GPIO3_F), ^ drivers/mfd/tps65912-core.c:41:2: error: (near initialization for 'tps65912_irqs[5].mask') drivers/mfd/tps65912-core.c:42:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_R, 1, TPS65912_INT_STS2_GPIO4_R), ^ drivers/mfd/tps65912-core.c:42:2: error: (near initialization for 'tps65912_irqs[6].reg_offset') drivers/mfd/tps65912-core.c:43:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_F, 1, TPS65912_INT_STS2_GPIO4_F), ^ drivers/mfd/tps65912-core.c:43:2: error: (near initialization for 'tps65912_irqs[6].mask') drivers/mfd/tps65912-core.c:44:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO5_R, 1, TPS65912_INT_STS2_GPIO5_R), ^ drivers/mfd/tps65912-core.c:44:2: error: (near initialization for 'tps65912_irqs[7].reg_offset') drivers/mfd/tps65912-core.c:45:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO5_F, 1, TPS65912_INT_STS2_GPIO5_F), ^ drivers/mfd/tps65912-core.c:45:2: error: (near initialization for 'tps65912_irqs[7].mask') drivers/mfd/tps65912-c
Re: [PATCH v4 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC
Hi Andrew, [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore] config: tile-allyesconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout d617dea974adf7dc262f2d49dea24a673e0403e2 # save the attached .config to linux build tree make.cross ARCH=tile All warnings (new ones prefixed by >>): drivers/mfd/tps65912-core.c:29:2: error: implicit declaration of function 'REGMAP_IRQ_REG' drivers/mfd/tps65912-core.c:29:2: warning: missing braces around initializer >> drivers/mfd/tps65912-core.c:29:2: warning: (near initialization for drivers/mfd/tps65912-core.c:29:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:29:2: error: (near initialization for drivers/mfd/tps65912-core.c:30:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:30:2: error: (near initialization for drivers/mfd/tps65912-core.c:31:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:31:2: error: (near initialization for drivers/mfd/tps65912-core.c:32:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:32:2: error: (near initialization for drivers/mfd/tps65912-core.c:33:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:33:2: error: (near initialization for drivers/mfd/tps65912-core.c:34:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:34:2: error: (near initialization for drivers/mfd/tps65912-core.c:35:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:35:2: error: (near initialization for drivers/mfd/tps65912-core.c:36:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:36:2: error: (near initialization for drivers/mfd/tps65912-core.c:38:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:38:2: error: (near initialization for drivers/mfd/tps65912-core.c:39:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:39:2: error: (near initialization for drivers/mfd/tps65912-core.c:40:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:40:2: error: (near initialization for drivers/mfd/tps65912-core.c:41:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:41:2: error: (near initialization for drivers/mfd/tps65912-core.c:42:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:42:2: error: (near initialization for drivers/mfd/tps65912-core.c:43:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:43:2: error: (near initialization for drivers/mfd/tps65912-core.c:44:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:44:2: error: (near initialization for drivers/mfd/tps65912-core.c:45:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:45:2: error: (near initialization for drivers/mfd/tps65912-core.c:47:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:47:2: error: (near initialization for drivers/mfd/tps65912-core.c:48:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:48:2: error: (near initialization for drivers/mfd/tps65912-core.c:49:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:49:2: error: (near initialization for drivers/mfd/tps65912-core.c:50:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:50:2: error: (near initialization for drivers/mfd/tps65912-core.c:51:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:51:2: error: (near initialization for drivers/mfd/tps65912-core.c:52:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:52:2: error: (near initialization for drivers/mfd/tps65912-core.c:53:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:53:2: error: (near initialization for drivers/mfd/tps65912-core.c:54:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:54:2: error: (near initialization for drivers/mfd/tps65912-core.c:56:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:56:2: error: (near initialization for drivers/mfd/tps65912-core.c:57:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:57:2: error: (near initialization for drivers/mfd/tps65912-core.c:58:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:58:2: error: (near initialization for drivers/mfd/tps65912-core.c:59:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:59:2: error: (near initialization for drivers/mfd/tps65912-core.c:60:2: error: initializer element is not constant
[PATCH 12/16] ARM: dts: lpc4357-ea4357: add ssp0
The SSP0 can be found on the EA4357 Dev Kit on J15 pin 3-6.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc4357-ea4357-devkit.dts | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
index 9fcc0f357c2d..4d2d74a064c4 100644
--- a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
+++ b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
@@ -389,6 +389,23 @@
};
};
+ ssp0_pins: ssp0-pins {
+ ssp0_sck_miso_mosi {
+ pins = "pf_0", "pf_2", "pf_3";
+ function = "ssp0";
+ slew-rate = <1>;
+ bias-pull-down;
+ input-enable;
+ input-schmitt-disable;
+ };
+
+ ssp0_ssel {
+ pins = "pf_1";
+ function = "ssp0";
+ bias-pull-up;
+ };
+ };
+
uart0_pins: uart0-pins {
uart0_rx_cfg {
pins = "pf_11";
@@ -535,6 +552,13 @@
};
};
+&ssp0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&ssp0_pins>;
+ num-cs = <1>;
+};
+
&uart0 {
status = "okay";
pinctrl-names = "default";
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/16] ARM: dts: lpc4350-hitex-eval: add i2c0 and devices
From: Ariel D'Alessandro
Add the I2C0 bus and the some of the I2C devices on the Hitex
LPC4350 eval board.
Signed-off-by: Ariel D'Alessandro
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc4350-hitex-eval.dts | 33
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
index c1dd76e5fc45..5c529f45947b 100644
--- a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
+++ b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
@@ -186,6 +186,14 @@
};
};
+ i2c0_pins: i2c0-pins {
+ i2c0_pins_cfg {
+ pins = "i2c0_scl", "i2c0_sda";
+ function = "i2c0";
+ input-enable;
+ };
+ };
+
spifi_pins: spifi-pins {
spifi_clk_cfg {
pins = "p3_3";
@@ -300,6 +308,31 @@
clock-frequency = <2500>;
};
+&i2c0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ clock-frequency = <40>;
+
+ /* NXP SE97BTP with temperature sensor + eeprom */
+ sensor@18 {
+ compatible = "nxp,jc42";
+ reg = <0x18>;
+ };
+
+ eeprom@50 {
+ compatible = "nxp,24c02";
+ reg = <0x50>;
+ };
+
+ pca_gpio: gpio@24 {
+ compatible = "nxp,pca9673";
+ reg = <0x24>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+};
+
&mac {
status = "okay";
phy-mode = "mii";
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/16] ARM: dts: lpc4357-ea4357: add spifi and flash device
The EA4357 dev kit has a Spansion S25FL016K SPI-NOR Flash connected
to the SPIFI perherial.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc4357-ea4357-devkit.dts | 46 +
1 file changed, 46 insertions(+)
diff --git a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
index 5f7bdad80963..9fcc0f357c2d 100644
--- a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
+++ b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
@@ -363,6 +363,32 @@
};
};
+ spifi_pins: spifi-pins {
+ spifi_clk_cfg {
+ pins = "p3_3";
+ function = "spifi";
+ slew-rate = <1>;
+ bias-disable;
+ input-enable;
+ input-schmitt-disable;
+ };
+
+ spifi_mosi_miso_sio2_3_cfg {
+ pins = "p3_7", "p3_6", "p3_5", "p3_4";
+ function = "spifi";
+ slew-rate = <0>;
+ bias-disable;
+ input-enable;
+ input-schmitt-disable;
+ };
+
+ spifi_cs_cfg {
+ pins = "p3_8";
+ function = "spifi";
+ bias-disable;
+ };
+ };
+
uart0_pins: uart0-pins {
uart0_rx_cfg {
pins = "pf_11";
@@ -489,6 +515,26 @@
pinctrl-0 = <&sdmmc_pins>;
};
+&spifi {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spifi_pins>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-cpol;
+ spi-cpha;
+ spi-rx-bus-width = <4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "data";
+ reg = <0 0x20>;
+ };
+ };
+};
+
&uart0 {
status = "okay";
pinctrl-names = "default";
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/16] ARM: dts: lpc18xx: add resets entry to device nodes
Most of the peripherals on LPC18xx/43xx devices have their reset
lines hooked up to internal reset controller (RGU). Add reset
entries to the device nodes so a driver can use the reset line.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc18xx.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 19c6f2951129..52591d83e8cd 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -115,6 +115,7 @@
num-slots = <1>;
clocks = <&ccu2 CLK_SDIO>, <&ccu1 CLK_CPU_SDIO>;
clock-names = "ciu", "biu";
+ resets = <&rgu 20>;
status = "disabled";
};
@@ -123,6 +124,7 @@
reg = <0x40006100 0x100>;
interrupts = <8>;
clocks = <&ccu1 CLK_CPU_USB0>;
+ resets = <&rgu 17>;
phys = <&usb0_otg_phy>;
phy-names = "usb";
has-transaction-translator;
@@ -134,6 +136,7 @@
reg = <0x40007100 0x100>;
interrupts = <9>;
clocks = <&ccu1 CLK_CPU_USB1>;
+ resets = <&rgu 18>;
status = "disabled";
};
@@ -142,6 +145,7 @@
reg = <0x40005000 0x1000>;
clocks = <&ccu1 CLK_CPU_EMCDIV>, <&ccu1 CLK_CPU_EMC>;
clock-names = "mpmcclk", "apb_pclk";
+ resets = <&rgu 21>;
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x1c00 0x100
@@ -158,6 +162,7 @@
interrupt-names = "combined";
clocks = <&cgu BASE_LCD_CLK>, <&ccu1 CLK_CPU_LCD>;
clock-names = "clcdclk", "apb_pclk";
+ resets = <&rgu 16>;
status = "disabled";
};
@@ -168,6 +173,8 @@
interrupt-names = "macirq";
clocks = <&ccu1 CLK_CPU_ETHERNET>;
clock-names = "stmmaceth";
+ resets = <&rgu 22>;
+ reset-names = "stmmaceth";
status = "disabled";
};
@@ -175,6 +182,7 @@
compatible = "nxp,lpc1850-creg", "syscon", "simple-mfd";
reg = <0x40043000 0x1000>;
clocks = <&ccu1 CLK_CPU_CREG>;
+ resets = <&rgu 5>;
usb0_otg_phy: phy@004 {
compatible = "nxp,lpc1850-usb-otg-phy";
@@ -248,6 +256,7 @@
interrupts = <24>;
clocks = <&ccu2 CLK_APB0_UART0>, <&ccu1 CLK_CPU_UART0>;
clock-names = "uartclk", "reg";
+ resets = <&rgu 44>;
dmas = <&dmamux 1 1 2
&dmamux 2 1 2
&dmamux 11 2 2
@@ -263,6 +272,7 @@
interrupts = <25>;
clocks = <&ccu2 CLK_APB0_UART1>, <&ccu1 CLK_CPU_UART1>;
clock-names = "uartclk", "reg";
+ resets = <&rgu 45>;
dmas = <&dmamux 3 1 2
&dmamux 4 1 2>;
dma-names = "tx", "rx";
@@ -275,6 +285,7 @@
interrupts = <22>;
clocks = <&ccu2 CLK_APB0_SSP0>, <&ccu1 CLK_CPU_SSP0>;
clock-names = "sspclk", "apb_pclk";
+ resets = <&rgu 50>;
dmas = <&dmamux 9 0 2
&dmamux 10 0 2>;
dma-names = "rx", "tx";
@@ -289,6 +300,7 @@
interrupts = <12>;
clocks = <&ccu1 CLK_CPU_TIMER0>;
clock-names = "timerclk";
+ resets = <&rgu 32>;
};
timer1: timer@40085000 {
@@ -297,6 +309,7 @@
interrupts = <13>;
clocks = <&ccu1 CLK_CPU_TIMER1>;
clock-names = "timerclk";
+ resets = <&rgu 33>;
};
pinctrl: pinctrl@40086000 {
@@ -321,6 +334,7 @@
reg = <0x400a4000 0x1000>;
interrupts = <43>;
clocks = <&ccu1 CLK_APB1_CAN1>;
+ resets = <&rgu 54>;
status = "disabled";
};
@@ -331,6 +345,7 @@
interrupts = <26>;
clocks = <&ccu2 CLK_APB2_UART2>, <&ccu1 CL
[PATCH 13/16] ARM: dts: lpc4357-ea4357: add i2c0 and devices
Add I2C0 and some of the I2C devices on the EA4357 dev kit.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc4357-ea4357-devkit.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
index 4d2d74a064c4..391121d24daa 100644
--- a/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
+++ b/arch/arm/boot/dts/lpc4357-ea4357-devkit.dts
@@ -332,6 +332,14 @@
};
};
+ i2c0_pins: i2c0-pins {
+ i2c0_pins_cfg {
+ pins = "i2c0_scl", "i2c0_sda";
+ function = "i2c0";
+ input-enable;
+ };
+ };
+
sdmmc_pins: sdmmc-pins {
sdmmc_clk_cfg {
pins = "pc_0";
@@ -453,6 +461,23 @@
};
};
+&i2c0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins>;
+ clock-frequency = <40>;
+
+ lm75@48 {
+ compatible = "nxp,lm75";
+ reg = <0x48>;
+ };
+
+ eeprom@57 {
+ compatible = "microchip,24c64";
+ reg = <0x57>;
+ };
+};
+
&emc {
status = "okay";
pinctrl-names = "default";
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/16] ARM: dts: lpc4350-hitex-eval: add spifi and flash device
The Hitex LPC4350 eval board has a Spansion S25SL064P SPI-NOR Flash connected
to the SPIFI perherial.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc4350-hitex-eval.dts | 57
1 file changed, 57 insertions(+)
diff --git a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
index 32bc7ff4eb2a..c1dd76e5fc45 100644
--- a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
+++ b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
@@ -186,6 +186,35 @@
};
};
+ spifi_pins: spifi-pins {
+ spifi_clk_cfg {
+ pins = "p3_3";
+ function = "spifi";
+ slew-rate = <1>;
+ bias-disable;
+ input-enable;
+ input-schmitt-disable;
+ };
+
+ spifi_mosi_miso_sio2_3_cfg {
+ pins = "p3_7", "p3_6", "p3_5", "p3_4";
+ function = "spifi";
+ slew-rate = <1>;
+ bias-disable;
+ input-enable;
+ input-schmitt-disable;
+ };
+
+ spifi_cs_cfg {
+ pins = "p3_8";
+ function = "spifi";
+ slew-rate = <1>;
+ bias-disable;
+ input-enable;
+ input-schmitt-disable;
+ };
+ };
+
uart0_pins: uart0-pins {
uart0_rx_cfg {
pins = "pf_11";
@@ -278,6 +307,34 @@
pinctrl-0 = <&enet_mii_pins>;
};
+&spifi {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&spifi_pins>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ spi-rx-bus-width = <4>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "bootloader";
+ reg = <0x00 0x04>; /* 256 KiB */
+ };
+
+ partition@1 {
+ label = "kernel";
+ reg = <0x04 0x2c>; /* 2.75 MiB */
+ };
+
+ partition@2 {
+ label = "rootfs";
+ reg = <0x30 0x50>; /* 5 MiB */
+ };
+ };
+};
+
&uart0 {
status = "okay";
pinctrl-names = "default";
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/16] ARM: dts: lpc4350-hitex-eval: add joystick, buttons and leds
Add the joystick, buttons and LEDs connected to the I2C I/O expander.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc4350-hitex-eval.dts | 85
1 file changed, 85 insertions(+)
diff --git a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
index 5c529f45947b..022d495432c1 100644
--- a/arch/arm/boot/dts/lpc4350-hitex-eval.dts
+++ b/arch/arm/boot/dts/lpc4350-hitex-eval.dts
@@ -15,6 +15,9 @@
#include "lpc18xx.dtsi"
#include "lpc4350.dtsi"
+#include "dt-bindings/input/input.h"
+#include "dt-bindings/gpio/gpio.h"
+
/ {
model = "Hitex LPC4350 Evaluation Board";
compatible = "hitex,lpc4350-eval-board", "nxp,lpc4350";
@@ -34,6 +37,88 @@
device_type = "memory";
reg = <0x2800 0x80>; /* 8 MB */
};
+
+ pca_buttons {
+ compatible = "gpio-keys-polled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ poll-interval = <100>;
+ autorepeat;
+
+ button@0 {
+ label = "joy:right";
+ linux,code = ;
+ gpios = <&pca_gpio 8 GPIO_ACTIVE_LOW>;
+ };
+
+ button@1 {
+ label = "joy:up";
+ linux,code = ;
+ gpios = <&pca_gpio 9 GPIO_ACTIVE_LOW>;
+ };
+
+
+ button@2 {
+ label = "joy:enter";
+ linux,code = ;
+ gpios = <&pca_gpio 10 GPIO_ACTIVE_LOW>;
+ };
+
+ button@3 {
+ label = "joy:left";
+ linux,code = ;
+ gpios = <&pca_gpio 11 GPIO_ACTIVE_LOW>;
+ };
+
+ button@4 {
+ label = "joy:down";
+ linux,code = ;
+ gpios = <&pca_gpio 12 GPIO_ACTIVE_LOW>;
+ };
+
+ button@5 {
+ label = "user:sw3";
+ linux,code = ;
+ gpios = <&pca_gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ button@6 {
+ label = "user:sw4";
+ linux,code = ;
+ gpios = <&pca_gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ button@7 {
+ label = "user:sw5";
+ linux,code = ;
+ gpios = <&pca_gpio 15 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ pca_leds {
+ compatible = "gpio-leds";
+
+ led0 {
+ label = "ext:led0";
+ gpios = <&pca_gpio 0 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led1 {
+ label = "ext:led1";
+ gpios = <&pca_gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led2 {
+ label = "ext:led2";
+ gpios = <&pca_gpio 2 GPIO_ACTIVE_LOW>;
+ };
+
+ led3 {
+ label = "ext:led3";
+ gpios = <&pca_gpio 3 GPIO_ACTIVE_LOW>;
+ };
+ };
};
&pinctrl {
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/16] ARM: dts: lpc18xx: add sct pwm node
From: Ariel D'Alessandro
NXP LPC SoCs family, which includes LPC18xx/LPC43xx, provides a State
Configurable Timer (SCT) which can be configured as a Pulse Width
Modulator.
Signed-off-by: Ariel D'Alessandro
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc18xx.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 4ea82536a8a0..19c6f2951129 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -68,6 +68,16 @@
};
soc {
+ sct_pwm: pwm@4000 {
+ compatible = "nxp,lpc1850-sct-pwm";
+ reg = <0x4000 0x1000>;
+ clocks =<&ccu1 CLK_CPU_SCT>;
+ clock-names = "pwm";
+ resets = <&rgu 37>;
+ #pwm-cells = <3>;
+ status = "disabled";
+ };
+
dmac: dma-controller@40002000 {
compatible = "arm,pl080", "arm,primecell";
arm,primecell-periphid = <0x00041080>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/16] ARM: dts: lpc18xx: add dmac node
Add the ARM PL080 DMA controller node to the dtsi for all
lpc18xx/43xx devices.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc18xx.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index a428a0946be2..5516c3ee8c5a 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -68,6 +68,25 @@
};
soc {
+ dmac: dma-controller@40002000 {
+ compatible = "arm,pl080", "arm,primecell";
+ arm,primecell-periphid = <0x00041080>;
+ reg = <0x40002000 0x1000>;
+ interrupts = <2>;
+ clocks = <&ccu1 CLK_CPU_DMA>;
+ clock-names = "apb_pclk";
+ resets = <&rgu 19>;
+ #dma-cells = <2>;
+ dma-channels = <8>;
+ dma-requests = <16>;
+ lli-bus-interface-ahb1;
+ lli-bus-interface-ahb2;
+ mem-bus-interface-ahb1;
+ mem-bus-interface-ahb2;
+ memcpy-burst-size = <256>;
+ memcpy-bus-width = <32>;
+ };
+
spifi: flash-controller@40003000 {
compatible = "nxp,lpc1773-spifi";
reg = <0x40003000 0x1000>, <0x1400 0x400>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/16] LPC18xx DTS changes for 4.4
This patch set includes the DTS changes for lpc18xx for v4.4. Mostly additions of new nodes to lpc18xx.dtsi for drivers that when upstream during the last cycle and board updates to the Hitex and Embedded Artists boards. Ariel D'Alessandro (3): ARM: dts: lpc18xx: add watchdog node ARM: dts: lpc18xx: add sct pwm node ARM: dts: lpc4350-hitex-eval: add i2c0 and devices Joachim Eastwood (13): ARM: dts: lpc18xx: add rgu node ARM: dts: lpc18xx: add spifi node ARM: dts: lpc18xx: add dmac node ARM: dts: lpc18xx: add dmamux node ARM: dts: lpc18xx: add dma to ssp0/1 ARM: dts: lpc18xx: add dma to uart0/1/2/3 ARM: dts: lpc18xx: add i2c nodes ARM: dts: lpc18xx: add resets entry to device nodes ARM: dts: lpc4357-ea4357: add spifi and flash device ARM: dts: lpc4357-ea4357: add ssp0 ARM: dts: lpc4357-ea4357: add i2c0 and devices ARM: dts: lpc4350-hitex-eval: add spifi and flash device ARM: dts: lpc4350-hitex-eval: add joystick, buttons and leds arch/arm/boot/dts/lpc18xx.dtsi | 134 + arch/arm/boot/dts/lpc4350-hitex-eval.dts| 175 arch/arm/boot/dts/lpc4357-ea4357-devkit.dts | 95 +++ 3 files changed, 404 insertions(+) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/16] ARM: dts: lpc18xx: add spifi node
Add the NXP LPC1773 SPIFI (SPI Flash Interface) flash controller
node to the dtsi for all lpc18xx/43xx devices.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc18xx.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 29a62b600ae5..a428a0946be2 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -68,6 +68,17 @@
};
soc {
+ spifi: flash-controller@40003000 {
+ compatible = "nxp,lpc1773-spifi";
+ reg = <0x40003000 0x1000>, <0x1400 0x400>;
+ reg-names = "spifi", "flash";
+ interrupts = <30>;
+ clocks = <&ccu1 CLK_SPIFI>, <&ccu1 CLK_CPU_SPIFI>;
+ clock-names = "spifi", "reg";
+ resets = <&rgu 53>;
+ status = "disabled";
+ };
+
mmcsd: mmcsd@40004000 {
compatible = "snps,dw-mshc";
reg = <0x40004000 0x1000>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/16] ARM: dts: lpc18xx: add dma to ssp0/1
Add dmas entries to the two SSP peripherals on LPC18xx/43xx devices so that DMA can be used to transfer data. Signed-off-by: Joachim Eastwood --- arch/arm/boot/dts/lpc18xx.dtsi | 13 + 1 file changed, 13 insertions(+) diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi index f0d1a099507f..5b7ca7066161 100644 --- a/arch/arm/boot/dts/lpc18xx.dtsi +++ b/arch/arm/boot/dts/lpc18xx.dtsi @@ -249,6 +249,9 @@ interrupts = <22>; clocks = <&ccu2 CLK_APB0_SSP0>, <&ccu1 CLK_CPU_SSP0>; clock-names = "sspclk", "apb_pclk"; + dmas = <&dmamux 9 0 2 + &dmamux 10 0 2>; + dma-names = "rx", "tx"; #address-cells = <1>; #size-cells = <0>; status = "disabled"; @@ -326,6 +329,16 @@ interrupts = <23>; clocks = <&ccu2 CLK_APB2_SSP1>, <&ccu1 CLK_CPU_SSP1>; clock-names = "sspclk", "apb_pclk"; + dmas = <&dmamux 11 2 2 + &dmamux 12 2 2 + &dmamux 3 3 2 + &dmamux 4 3 2 + &dmamux 5 2 2 + &dmamux 6 2 2 + &dmamux 13 2 2 + &dmamux 14 2 2>; + dma-names = "rx", "tx", "tx", "rx", + "tx", "rx", "rx", "tx"; #address-cells = <1>; #size-cells = <0>; status = "disabled"; -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/16] ARM: dts: lpc18xx: add watchdog node
From: Ariel D'Alessandro
Add node for the watchdog timer found on LPC18xx/LPC43xx.
Signed-off-by: Ariel D'Alessandro
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc18xx.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 04bea2dc0e66..4ea82536a8a0 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -223,6 +223,14 @@
#reset-cells = <1>;
};
+ watchdog@4008 {
+ compatible = "nxp,lpc1850-wwdt";
+ reg = <0x4008 0x24>;
+ interrupts = <49>;
+ clocks = <&cgu BASE_SAFE_CLK>, <&ccu1 CLK_CPU_WWDT>;
+ clock-names = "wdtclk", "reg";
+ };
+
uart0: serial@40081000 {
compatible = "nxp,lpc1850-uart", "ns16550a";
reg = <0x40081000 0x1000>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/16] ARM: dts: lpc18xx: add dmamux node
Add node for the DMA multiplexer placed in front of the PL080 DMA
controller on lpc18xx/43xx devices.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc18xx.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 5516c3ee8c5a..f0d1a099507f 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -171,6 +171,13 @@
clocks = <&ccu1 CLK_USB0>;
#phy-cells = <0>;
};
+
+ dmamux: dma-mux@11c {
+ compatible = "nxp,lpc1850-dmamux";
+ #dma-cells = <3>;
+ dma-requests = <64>;
+ dma-masters = <&dmac>;
+ };
};
cgu: clock-controller@4005 {
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/16] ARM: dts: lpc18xx: add rgu node
Add the NXP LPC1850 RGU (Reset Generation Unit) reset controller
node to the dtsi for all lpc18xx/43xx devices.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc18xx.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index 2c569a6ddc9a..29a62b600ae5 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -178,6 +178,14 @@
"base_ssp0_clk", "base_sdio_clk";
};
+ rgu: reset-controller@40053000 {
+ compatible = "nxp,lpc1850-rgu";
+ reg = <0x40053000 0x1000>;
+ clocks = <&cgu BASE_SAFE_CLK>, <&ccu1 CLK_CPU_BUS>;
+ clock-names = "delay", "reg";
+ #reset-cells = <1>;
+ };
+
uart0: serial@40081000 {
compatible = "nxp,lpc1850-uart", "ns16550a";
reg = <0x40081000 0x1000>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/16] ARM: dts: lpc18xx: add i2c nodes
Add NXP LPC1778 I2C controller nodes to the dtsi for all
lpc18xx/43xx devices.
Signed-off-by: Joachim Eastwood
---
arch/arm/boot/dts/lpc18xx.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi
index f97feea5f5da..04bea2dc0e66 100644
--- a/arch/arm/boot/dts/lpc18xx.dtsi
+++ b/arch/arm/boot/dts/lpc18xx.dtsi
@@ -287,6 +287,17 @@
clocks = <&ccu1 CLK_CPU_SCU>;
};
+ i2c0: i2c@400a1000 {
+ compatible = "nxp,lpc1788-i2c";
+ reg = <0x400a1000 0x1000>;
+ interrupts = <18>;
+ clocks = <&ccu1 CLK_APB1_I2C0>;
+ resets = <&rgu 48>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
can1: can@400a4000 {
compatible = "bosch,c_can";
reg = <0x400a4000 0x1000>;
@@ -360,6 +371,17 @@
status = "disabled";
};
+ i2c1: i2c@400e {
+ compatible = "nxp,lpc1788-i2c";
+ reg = <0x400e 0x1000>;
+ interrupts = <19>;
+ clocks = <&ccu1 CLK_APB3_I2C1>;
+ resets = <&rgu 49>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "disabled";
+ };
+
can0: can@400e2000 {
compatible = "bosch,c_can";
reg = <0x400e2000 0x1000>;
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/16] ARM: dts: lpc18xx: add dma to uart0/1/2/3
Add dmas entries to the four UART peripherals on LPC18xx/43xx devices so that DMA can be used to transfer data. Signed-off-by: Joachim Eastwood --- arch/arm/boot/dts/lpc18xx.dtsi | 16 1 file changed, 16 insertions(+) diff --git a/arch/arm/boot/dts/lpc18xx.dtsi b/arch/arm/boot/dts/lpc18xx.dtsi index 5b7ca7066161..f97feea5f5da 100644 --- a/arch/arm/boot/dts/lpc18xx.dtsi +++ b/arch/arm/boot/dts/lpc18xx.dtsi @@ -230,6 +230,11 @@ interrupts = <24>; clocks = <&ccu2 CLK_APB0_UART0>, <&ccu1 CLK_CPU_UART0>; clock-names = "uartclk", "reg"; + dmas = <&dmamux 1 1 2 + &dmamux 2 1 2 + &dmamux 11 2 2 + &dmamux 12 2 2>; + dma-names = "tx", "rx", "tx", "rx"; status = "disabled"; }; @@ -240,6 +245,9 @@ interrupts = <25>; clocks = <&ccu2 CLK_APB0_UART1>, <&ccu1 CLK_CPU_UART1>; clock-names = "uartclk", "reg"; + dmas = <&dmamux 3 1 2 + &dmamux 4 1 2>; + dma-names = "tx", "rx"; status = "disabled"; }; @@ -294,6 +302,9 @@ interrupts = <26>; clocks = <&ccu2 CLK_APB2_UART2>, <&ccu1 CLK_CPU_UART2>; clock-names = "uartclk", "reg"; + dmas = <&dmamux 5 1 2 + &dmamux 6 1 2>; + dma-names = "tx", "rx"; status = "disabled"; }; @@ -304,6 +315,11 @@ interrupts = <27>; clocks = <&ccu2 CLK_APB2_UART3>, <&ccu1 CLK_CPU_UART3>; clock-names = "uartclk", "reg"; + dmas = <&dmamux 7 1 2 + &dmamux 8 1 2 + &dmamux 13 3 2 + &dmamux 14 3 2>; + dma-names = "tx", "rx", "rx", "tx"; status = "disabled"; }; -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC
Hi Andrew, [auto build test results on v4.3-rc3 -- if it's inappropriate base, please ignore] config: x86_64-allmodconfig (attached as .config) reproduce: git checkout d617dea974adf7dc262f2d49dea24a673e0403e2 # save the attached .config to linux build tree make ARCH=x86_64 All error/warnings (new ones prefixed by >>): >> drivers/mfd/tps65912-core.c:29:2: error: implicit declaration of function >> 'REGMAP_IRQ_REG' [-Werror=implicit-function-declaration] REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_F, 0, TPS65912_INT_STS_PWRHOLD_F), ^ >> drivers/mfd/tps65912-core.c:29:2: error: initializer element is not constant drivers/mfd/tps65912-core.c:29:2: note: (near initialization for 'tps65912_irqs[0].reg_offset') drivers/mfd/tps65912-core.c:30:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_VMON, 0, TPS65912_INT_STS_VMON), ^ drivers/mfd/tps65912-core.c:30:2: note: (near initialization for 'tps65912_irqs[0].mask') drivers/mfd/tps65912-core.c:31:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_PWRON, 0, TPS65912_INT_STS_PWRON), ^ drivers/mfd/tps65912-core.c:31:2: note: (near initialization for 'tps65912_irqs[1].reg_offset') drivers/mfd/tps65912-core.c:32:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_PWRON_LP, 0, TPS65912_INT_STS_PWRON_LP), ^ drivers/mfd/tps65912-core.c:32:2: note: (near initialization for 'tps65912_irqs[1].mask') drivers/mfd/tps65912-core.c:33:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_R, 0, TPS65912_INT_STS_PWRHOLD_R), ^ drivers/mfd/tps65912-core.c:33:2: note: (near initialization for 'tps65912_irqs[2].reg_offset') drivers/mfd/tps65912-core.c:34:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_HOTDIE, 0, TPS65912_INT_STS_HOTDIE), ^ drivers/mfd/tps65912-core.c:34:2: note: (near initialization for 'tps65912_irqs[2].mask') drivers/mfd/tps65912-core.c:35:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_R, 0, TPS65912_INT_STS_GPIO1_R), ^ drivers/mfd/tps65912-core.c:35:2: note: (near initialization for 'tps65912_irqs[3].reg_offset') drivers/mfd/tps65912-core.c:36:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_F, 0, TPS65912_INT_STS_GPIO1_F), ^ drivers/mfd/tps65912-core.c:36:2: note: (near initialization for 'tps65912_irqs[3].mask') drivers/mfd/tps65912-core.c:38:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_R, 1, TPS65912_INT_STS2_GPIO2_R), ^ drivers/mfd/tps65912-core.c:38:2: note: (near initialization for 'tps65912_irqs[4].reg_offset') drivers/mfd/tps65912-core.c:39:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_F, 1, TPS65912_INT_STS2_GPIO2_F), ^ drivers/mfd/tps65912-core.c:39:2: note: (near initialization for 'tps65912_irqs[4].mask') drivers/mfd/tps65912-core.c:40:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_R, 1, TPS65912_INT_STS2_GPIO3_R), ^ drivers/mfd/tps65912-core.c:40:2: note: (near initialization for 'tps65912_irqs[5].reg_offset') drivers/mfd/tps65912-core.c:41:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_F, 1, TPS65912_INT_STS2_GPIO3_F), ^ drivers/mfd/tps65912-core.c:41:2: note: (near initialization for 'tps65912_irqs[5].mask') drivers/mfd/tps65912-core.c:42:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_R, 1, TPS65912_INT_STS2_GPIO4_R), ^ drivers/mfd/tps65912-core.c:42:2: note: (near initialization for 'tps65912_irqs[6].reg_offset') drivers/mfd/tps65912-core.c:43:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_F, 1, TPS65912_INT_STS2_GPIO4_F), ^ drivers/mfd/tps65912-core.c:43:2: note: (near initialization for 'tps65912_irqs[6].mask') drivers/mfd/tps65912-core.c:44:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO5_R, 1, TPS65912_INT_STS2_GPIO5_R), ^ drivers/mfd/tps65912-core.c:44:2: note: (near initialization for 'tps65912_irqs[7].reg_offset') drivers/mfd/tps65912-core.c:45:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_GPIO5_F, 1, TPS65912_INT_STS2_GPIO5_F), ^ drivers/mfd/tps65912-core.c:45:2: note: (near initialization for 'tps65912_irqs[7].mask') drivers/mfd/tps65912-core.c:47:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_PGOOD_DCDC1, 2, TPS65912_INT_STS3_PGOOD_DCDC1), ^ drivers/mfd/tps65912-core.c:47:2: note: (near initialization for 'tps65912_irqs[8].reg_offset') drivers/mfd/tps65912-core.c:48:2: error: initializer element is not constant REGMAP_IRQ_REG(TPS65912_IRQ_PGOOD_DCDC2, 2, TPS65912_INT
Re: "clk: sunxi: Add a simple gates driver" breaks kernel with older DTB
Hi Ian, On Thu, Oct 01, 2015 at 09:47:11AM +0100, Ian Campbell wrote: > Booting a recent kernel with the DTB supplied with Debian Jessie (3.16 > based) breaks on Cubietruck because that DTB lacks the clock-indices nodes > which the new driver from the commit below adds (replacing the hardcoding > which used to be in clk-sunxi.c). > > It is panicing in drivers/clocksource/timer-sun5i.c with: > > [0.015413] clocksource: timer: mask: 0x max_cycles: 0x, > max_idle_ns: 79635851949 ns > [0.025049] Kernel panic - not syncing: Can't get timer clock > [0.030794] CPU: 0 PID: 0 Comm: swapper/0 Not tainted > 4.3.0-rc2-arm-native+ #6 > [0.038002] Hardware name: Allwinner sun7i (A20) Family > [0.043253] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [0.050992] [] (show_stack) from [] > (dump_stack+0x88/0x98) > [0.058213] [] (dump_stack) from [] (panic+0xa4/0x22c) > [0.065090] [] (panic) from [] > (sun5i_timer_init+0x80/0x384) > [0.072482] [] (sun5i_timer_init) from [] > (clocksource_of_init+0x4c/0x8c) > [0.081001] [] (clocksource_of_init) from [] > (start_kernel+0x28c/0x3c4) > [0.089343] [] (start_kernel) from [<4020807c>] (0x4020807c) > [0.095866] ---[ end Kernel panic - not syncing: Can't get timer clock > > Reverting ee38b2698ae2 fixes this specific issue for me (it boots further, > but there seems to be other problems later when earlycon hands over to > proper console, which I've not yet looked into). > > Is this considered acceptable linkage between the kernel and the dtbs? > > I suspect that even if anyone does care this is going to be an uphill > struggle for that minority so I'm going to adjust our test infrastructure > to pickup the dtbs from the kernel it is trying to test rather then reusing > the one from the OS install. It's never been something we supported (or even claim to support), so it's actually surprising that it's the only commit that need to be reverted, but yeah, you should keep your DTB in sync. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v2 resend 0/4] ARM: dts: sunxi: q8 A13 tablet backlight support
Hi, On Tue, Sep 29, 2015 at 12:29:47PM +0200, Hans de Goede wrote: > Hi Maxime, > > This series seems to have fallen through the cracks, hence this > resend. No, it didn't fall through the cracks, I asked a question on the first patch and never got a reply. The way we handled *all* the controllers so far is that the compatible was representing what the controllers what features the controller was exposing. This is the case for the clocks or pinctrl for example. We should be consistent with that (beside the fact that using a compatible from a later SoC is wrong). Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[PATCH v4 5/5] gpio: tps65912: Add GPIO driver for the TPS65912 PMIC
This patch adds support for the TPS65912 PMIC GPIOs.
TPS65912 has five configurable GPIOs that can be used for several
purposes.
Signed-off-by: Andrew F. Davis
Reviewed-by: Alexandre Courbot
---
drivers/gpio/Kconfig | 6 ++
drivers/gpio/Makefile| 1 +
drivers/gpio/gpio-tps65912.c | 137 +++
3 files changed, 144 insertions(+)
create mode 100644 drivers/gpio/gpio-tps65912.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index fb28483..82218fa 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -838,6 +838,12 @@ config GPIO_TPS65910
Select this option to enable GPIO driver for the TPS65910
chip family.
+config GPIO_TPS65912
+ tristate "TI TPS65912 GPIO"
+ depends on MFD_TPS65912
+ help
+ This driver supports TPS65912 gpio chip
+
config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 605bf89..f79a7c4 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -96,6 +96,7 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
obj-$(CONFIG_GPIO_PALMAS) += gpio-palmas.o
obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
+obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
obj-$(CONFIG_GPIO_TS5500) += gpio-ts5500.o
obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
new file mode 100644
index 000..096c3ea
--- /dev/null
+++ b/drivers/gpio/gpio-tps65912.c
@@ -0,0 +1,137 @@
+/*
+ * TI TPS65912x GPIO Driver
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the Arizona GPIO driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera
+ */
+
+#include
+#include
+#include
+
+#include
+
+struct tps65912_gpio {
+ struct gpio_chip gpio_chip;
+ struct tps65912 *tps;
+};
+
+#define to_tps65912_gpio(gc) container_of(gc, struct tps65912_gpio, gpio_chip)
+
+static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
+{
+ struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+ int ret, val;
+
+ ret = regmap_read(gpio->tps->regmap, TPS65912_GPIO1 + offset, &val);
+ if (ret < 0)
+ return ret;
+
+ return val & GPIO_STS_MASK;
+}
+
+static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
+ int value)
+{
+ struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+ regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_SET_MASK, value ? GPIO_SET_MASK : 0);
+}
+
+static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
+ int value)
+{
+ struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+ /* Set the initial value */
+ tps65912_gpio_set(gc, offset, value);
+
+ return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, GPIO_CFG_MASK);
+}
+
+static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
+{
+ struct tps65912_gpio *gpio = to_tps65912_gpio(gc);
+
+ return regmap_update_bits(gpio->tps->regmap, TPS65912_GPIO1 + offset,
+ GPIO_CFG_MASK, 0);
+}
+
+static struct gpio_chip template_chip = {
+ .label = "tps65912-gpio",
+ .owner = THIS_MODULE,
+ .direction_input= tps65912_gpio_input,
+ .direction_output = tps65912_gpio_output,
+ .get= tps65912_gpio_get,
+ .set= tps65912_gpio_set,
+ .can_sleep = true,
+ .ngpio = 5,
+ .base = -1,
+};
+
+static int tps65912_gpio_probe(struct platform_device *pdev)
+{
+ struct tps65912_gpio *gpio;
+ int ret;
+
+ gpio = devm_kzalloc(&pdev->dev, sizeof(*gpio), GFP_KERNEL);
+ if (!gpio)
+ return -ENOMEM;
+
+ gpio->tps = dev_get_drvdata(pdev->dev.parent);
+ gpio->gpio_chip = template_chip;
+ ret = gpiochip_add(&gpio->gpio_chip);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "Could not register gpiochip, %d\n", ret);
+ return re
[PATCH v4 4/5] regulator: tps65912: Add regulator driver for the TPS65912 PMIC
This patch adds support for TPS65912 PMIC regulators.
The regulators set consists of 4 DCDCs and 10 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: Andrew F. Davis
---
drivers/regulator/Kconfig | 6 ++
drivers/regulator/Makefile | 1 +
drivers/regulator/tps65912-regulator.c | 171 +
3 files changed, 178 insertions(+)
create mode 100644 drivers/regulator/tps65912-regulator.c
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 3cb2de9..1dec96a 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -727,6 +727,12 @@ config REGULATOR_TPS65910
help
This driver supports TPS65910/TPS65911 voltage regulator chips.
+config REGULATOR_TPS65912
+ tristate "TI TPS65912 Power regulator"
+ depends on MFD_TPS65912
+ help
+ This driver supports TPS65912 voltage regulator chip.
+
config REGULATOR_TPS80031
tristate "TI TPS80031/TPS80032 power regualtor driver"
depends on MFD_TPS80031
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 222ff5f..0f81749 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -91,6 +91,7 @@ obj-$(CONFIG_REGULATOR_TPS65218) += tps65218-regulator.o
obj-$(CONFIG_REGULATOR_TPS6524X) += tps6524x-regulator.o
obj-$(CONFIG_REGULATOR_TPS6586X) += tps6586x-regulator.o
obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
+obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o
obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress.o
diff --git a/drivers/regulator/tps65912-regulator.c
b/drivers/regulator/tps65912-regulator.c
new file mode 100644
index 000..854c63d
--- /dev/null
+++ b/drivers/regulator/tps65912-regulator.c
@@ -0,0 +1,171 @@
+/*
+ * Regulator driver for TPS65912x PMIC
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65218 driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+enum tps65912_regulators { DCDC1, DCDC2, DCDC3, DCDC4, LDO1, LDO2, LDO3,
+ LDO4, LDO5, LDO6, LDO7, LDO8, LDO9, LDO10 };
+
+#define TPS65912_REGULATOR(_name, _id, _of_match, _ops, _vr, _er, _lr) \
+ [_id] = { \
+ .name = _name,\
+ .of_match = of_match_ptr(_of_match), \
+ .id = _id, \
+ .ops= &_ops,\
+ .n_voltages = 64, \
+ .type = REGULATOR_VOLTAGE,\
+ .owner = THIS_MODULE, \
+ .vsel_reg = _vr, \
+ .vsel_mask = 0x3f, \
+ .enable_reg = _er, \
+ .enable_mask= BIT(7), \
+ .volt_table = NULL, \
+ .linear_ranges = _lr, \
+ .n_linear_ranges= ARRAY_SIZE(_lr), \
+ }
+
+static const struct regulator_linear_range tps65912_dcdc_ranges[] = {
+ REGULATOR_LINEAR_RANGE(50, 0x0, 0x3f, 5),
+};
+
+static const struct regulator_linear_range tps65912_ldo_ranges[] = {
+ REGULATOR_LINEAR_RANGE(80, 0x0, 0x20, 25000),
+ REGULATOR_LINEAR_RANGE(165, 0x21, 0x3c, 5),
+ REGULATOR_LINEAR_RANGE(310, 0x3d, 0x3f, 10),
+};
+
+/* Operations permitted on DCDCx */
+static struct regulator_ops tps65912_ops_dcdc = {
+ .is_enabled = regulator_is_enabled_regmap,
+ .enable = regulator_enable_regmap,
+ .disable= regulator_disable_regmap,
+ .get_voltage_sel= regulator_get_voltage_sel_regmap,
+ .set_voltage_sel= regulator_set_voltage_sel_regmap,
+ .list_voltage = regulator_list_voltage_linear_range,
+};
+
+/* Operations perm
[PATCH v4 1/5] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC
The TPS65912 PMIC contains several regulators and a GPIO controller.
Add bindings for the TPS65912 PMIC.
Signed-off-by: Andrew F. Davis
---
.../devicetree/bindings/gpio/gpio-tps65912.txt | 16 +++
Documentation/devicetree/bindings/mfd/tps65912.txt | 51 ++
.../bindings/regulator/tps65912-regulator.txt | 28
3 files changed, 95 insertions(+)
create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
create mode 100644
Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
new file mode 100644
index 000..0c5c05c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
@@ -0,0 +1,16 @@
+* TPS65912 GPIO Controller bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65912-gpio".
+ - gpio-controller : Marks the device node as a GPIO Controller.
+ - #gpio-cells : Should be two. The first cell is the pin number and
+ the second cell is used to specify flags.
+ See include/dt-bindings/gpio/gpio.h for possible values.
+
+Example:
+
+ gpio4: tps65912_gpio {
+ compatible = "ti,tps65912-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
diff --git a/Documentation/devicetree/bindings/mfd/tps65912.txt
b/Documentation/devicetree/bindings/mfd/tps65912.txt
new file mode 100644
index 000..da5804a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/tps65912.txt
@@ -0,0 +1,51 @@
+* TPS65912 Power Management Integrated Circuit bindings
+
+Required properties:
+ - compatible : Should be "ti,tps65912".
+ - reg : Slave address or chip select number (I2C / SPI).
+ - interrupt-parent : The parent interrupt controller.
+ - interrupts : The interrupt line the device is connected to.
+ - interrupt-controller : Marks the device node as an interrupt controller.
+ - #interrupt-cells: The number of cells to describe an IRQ, this should be 2.
+ The first cell is the IRQ number.
+ The second cell is the flags, encoded as the trigger masks from
+ ../interrupt-controller/interrupts.txt
+
+Additional nodes defined in:
+ - Regulators: ../regulator/tps65912-regulator.txt
+ - GPIO: ../gpio/gpio-tps65912.txt.
+
+Example:
+
+ pmic: tps65912@2d {
+ compatible = "ti,tps65912";
+ reg = <0x2d>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+
+ regulators {
+ compatible = "ti,tps65912-regulator";
+
+ dcdc1 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <190>;
+ regulator-max-microvolt = <190>;
+ };
+ };
+
+ gpio4: tps65912_gpio {
+ compatible = "ti,tps65912-gpio";
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+ };
diff --git a/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
new file mode 100644
index 000..4cd05fa
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
@@ -0,0 +1,28 @@
+* TPS65912 regulator bindings
+
+Required properties:
+ - compatible: "ti,tps65912-regulator"
+ - list of regulators provided by this controller, must be named
+ after their hardware counterparts: dcdc[1-4] and ldo[1-10]
+
+Each regulator is defined using the standard binding for regulators.
+
+Example:
+
+ tps65912_regulator {
+ compatible = "ti,tps65912-regulator";
+
+ dcdc1 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <1144000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <190>;
+ regulator-max-microvolt = <190>;
+ };
+ };
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger
[PATCH v4 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC
This patch adds support for TPS65912 mfd device. It provides
communication through the I2C and SPI interfaces. It contains
the following components:
- Regulators
- GPIO controller
Signed-off-by: Andrew F. Davis
---
drivers/mfd/Kconfig | 25
drivers/mfd/Makefile | 3 +
drivers/mfd/tps65912-core.c | 108 ++
drivers/mfd/tps65912-i2c.c | 82 ++
drivers/mfd/tps65912-spi.c | 81 ++
include/linux/mfd/tps65912.h | 345 +++
6 files changed, 644 insertions(+)
create mode 100644 drivers/mfd/tps65912-core.c
create mode 100644 drivers/mfd/tps65912-i2c.c
create mode 100644 drivers/mfd/tps65912-spi.c
create mode 100644 include/linux/mfd/tps65912.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 9a8df8e..02b321f 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1167,6 +1167,31 @@ config MFD_TPS65910
if you say yes here you get support for the TPS65910 series of
Power Management chips.
+config MFD_TPS65912
+ tristate
+ select REGMAP
+ select REGMAP_IRQ
+
+config MFD_TPS65912_I2C
+ tristate "TI TPS65912 Power Management chip with I2C"
+ select MFD_TPS65912
+ select REGMAP_I2C
+ depends on I2C
+ depends on OF || COMPILE_TEST
+ help
+ If you say yes here you get support for the TPS65912 series of
+ PM chips with I2C interface.
+
+config MFD_TPS65912_SPI
+ tristate "TI TPS65912 Power Management chip with SPI"
+ select MFD_TPS65912
+ select REGMAP_SPI
+ depends on SPI_MASTER
+ depends on OF || COMPILE_TEST
+ help
+ If you say yes here you get support for the TPS65912 series of
+ PM chips with SPI interface.
+
config MFD_TPS80031
bool "TI TPS80031/TPS80032 Power Management chips"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 004aa76..49c3530 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -69,6 +69,9 @@ obj-$(CONFIG_TPS6507X)+= tps6507x.o
obj-$(CONFIG_MFD_TPS65217) += tps65217.o
obj-$(CONFIG_MFD_TPS65218) += tps65218.o
obj-$(CONFIG_MFD_TPS65910) += tps65910.o
+obj-$(CONFIG_MFD_TPS65912) += tps65912-core.o
+obj-$(CONFIG_MFD_TPS65912_I2C) += tps65912-i2c.o
+obj-$(CONFIG_MFD_TPS65912_SPI) += tps65912-spi.o
obj-$(CONFIG_MFD_TPS80031) += tps80031.o
obj-$(CONFIG_MENELAUS) += menelaus.o
diff --git a/drivers/mfd/tps65912-core.c b/drivers/mfd/tps65912-core.c
new file mode 100644
index 000..e787950
--- /dev/null
+++ b/drivers/mfd/tps65912-core.c
@@ -0,0 +1,108 @@
+/*
+ * Core functions for TI TPS65912x PMIC
+ *
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * Author: Andrew F. Davis
+ *
+ * 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.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether expressed or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License version 2 for more details.
+ *
+ * Based on the TPS65218 driver and the previous TPS65912 driver by
+ * Margarita Olaya Cabrera
+ */
+
+#include
+#include
+#include
+
+#include
+
+static const struct regmap_irq tps65912_irqs[] = {
+ /* INT_STS IRQs */
+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_F, 0, TPS65912_INT_STS_PWRHOLD_F),
+ REGMAP_IRQ_REG(TPS65912_IRQ_VMON, 0, TPS65912_INT_STS_VMON),
+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRON, 0, TPS65912_INT_STS_PWRON),
+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRON_LP, 0, TPS65912_INT_STS_PWRON_LP),
+ REGMAP_IRQ_REG(TPS65912_IRQ_PWRHOLD_R, 0, TPS65912_INT_STS_PWRHOLD_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_HOTDIE, 0, TPS65912_INT_STS_HOTDIE),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_R, 0, TPS65912_INT_STS_GPIO1_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO1_F, 0, TPS65912_INT_STS_GPIO1_F),
+ /* INT_STS2 IRQs */
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_R, 1, TPS65912_INT_STS2_GPIO2_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO2_F, 1, TPS65912_INT_STS2_GPIO2_F),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_R, 1, TPS65912_INT_STS2_GPIO3_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO3_F, 1, TPS65912_INT_STS2_GPIO3_F),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_R, 1, TPS65912_INT_STS2_GPIO4_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO4_F, 1, TPS65912_INT_STS2_GPIO4_F),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO5_R, 1, TPS65912_INT_STS2_GPIO5_R),
+ REGMAP_IRQ_REG(TPS65912_IRQ_GPIO5_F, 1, TPS65912_INT_STS2_GPIO5_F),
+ /* INT_STS3 IRQs */
+ REGMAP_IRQ_REG(TPS65912_IRQ_PGOOD_DCDC1, 2,
TPS65912_INT_STS3_PGOOD_DCDC1),
+ REGMAP_IRQ_REG(TPS65912_IRQ_PGOOD_DCDC2, 2,
TPS65912_INT_STS3_PGOOD_DCDC2),
+ REGMAP_IRQ_REG(TPS65912
[PATCH v4 2/5] mfd: tps65912: Remove old driver in preparation for new driver
The old tps65912 driver is being replaced, delete old driver.
Signed-off-by: Andrew F. Davis
---
drivers/gpio/Kconfig | 6 -
drivers/gpio/Makefile | 1 -
drivers/gpio/gpio-tps65912.c | 153 --
drivers/mfd/Kconfig| 26 --
drivers/mfd/Makefile | 4 -
drivers/mfd/tps65912-core.c| 175 ---
drivers/mfd/tps65912-i2c.c | 139 -
drivers/mfd/tps65912-irq.c | 217 -
drivers/mfd/tps65912-spi.c | 141 -
drivers/regulator/Kconfig | 6 -
drivers/regulator/Makefile | 1 -
drivers/regulator/tps65912-regulator.c | 541 -
include/linux/mfd/tps65912.h | 328
13 files changed, 1738 deletions(-)
delete mode 100644 drivers/gpio/gpio-tps65912.c
delete mode 100644 drivers/mfd/tps65912-core.c
delete mode 100644 drivers/mfd/tps65912-i2c.c
delete mode 100644 drivers/mfd/tps65912-irq.c
delete mode 100644 drivers/mfd/tps65912-spi.c
delete mode 100644 drivers/regulator/tps65912-regulator.c
delete mode 100644 include/linux/mfd/tps65912.h
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4..fb28483 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -838,12 +838,6 @@ config GPIO_TPS65910
Select this option to enable GPIO driver for the TPS65910
chip family.
-config GPIO_TPS65912
- tristate "TI TPS65912 GPIO"
- depends on (MFD_TPS65912_I2C || MFD_TPS65912_SPI)
- help
- This driver supports TPS65912 gpio chip
-
config GPIO_TWL4030
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
depends on TWL4030_CORE
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index f79a7c4..605bf89 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -96,7 +96,6 @@ obj-$(CONFIG_GPIO_TIMBERDALE) += gpio-timberdale.o
obj-$(CONFIG_GPIO_PALMAS) += gpio-palmas.o
obj-$(CONFIG_GPIO_TPS6586X)+= gpio-tps6586x.o
obj-$(CONFIG_GPIO_TPS65910)+= gpio-tps65910.o
-obj-$(CONFIG_GPIO_TPS65912)+= gpio-tps65912.o
obj-$(CONFIG_GPIO_TS5500) += gpio-ts5500.o
obj-$(CONFIG_GPIO_TWL4030) += gpio-twl4030.o
obj-$(CONFIG_GPIO_TWL6040) += gpio-twl6040.o
diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
deleted file mode 100644
index 9cdbc0c..000
--- a/drivers/gpio/gpio-tps65912.c
+++ /dev/null
@@ -1,153 +0,0 @@
-/*
- * Copyright 2011 Texas Instruments Inc.
- *
- * Author: Margarita Olaya
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2 of the License, or (at your
- * option) any later version.
- *
- * This driver is based on wm8350 implementation.
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-#include
-
-struct tps65912_gpio_data {
- struct tps65912 *tps65912;
- struct gpio_chip gpio_chip;
-};
-
-#define to_tgd(gc) container_of(gc, struct tps65912_gpio_data, gpio_chip)
-
-static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
-{
- struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
- struct tps65912 *tps65912 = tps65912_gpio->tps65912;
- int val;
-
- val = tps65912_reg_read(tps65912, TPS65912_GPIO1 + offset);
-
- if (val & GPIO_STS_MASK)
- return 1;
-
- return 0;
-}
-
-static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
- int value)
-{
- struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
- struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
- if (value)
- tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
- GPIO_SET_MASK);
- else
- tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
- GPIO_SET_MASK);
-}
-
-static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
- int value)
-{
- struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
- struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
- /* Set the initial value */
- tps65912_gpio_set(gc, offset, value);
-
- return tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
- GPIO_CFG_MASK);
-}
-
-static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
-{
- struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
- struct tps65912 *tps65912 = tps65912_gpio->tps65912;
-
- return tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
- GPIO_CFG_MASK);
-}
-
-static
[PATCH v4 0/5] mfd: tps65912: Driver rewrite with DT support
In an effort to cleanup this driver and add Device Tree support the driver has been rewritten based on new driver styles and modern kernel driver helpers. This has nearly halved the lines of code while keeping all previous functionality. Platform file based initialization has been dropped as there is no examples of this use in the kernel. v1 can be found here: [1] v2: [2] v3: [3] Changes from v3: - Reorganized regulator driver and related DT node - Other small fixes as discussed in v3 thread Changes from v2: - Split the series further into subsystems Changes from v1: - Split the rewrite into delete/create patches - Several small fixes as discussed in v1 thread [1] http://www.spinics.net/lists/devicetree/msg93863.html [2] http://www.spinics.net/lists/devicetree/msg95003.html [3] http://www.spinics.net/lists/devicetree/msg95133.html Andrew F. Davis (5): Documentation: tps65912: Add DT bindings for the TPS65912 PMIC mfd: tps65912: Remove old driver in preparation for new driver mfd: tps65912: Add driver for the TPS65912 PMIC regulator: tps65912: Add regulator driver for the TPS65912 PMIC gpio: tps65912: Add GPIO driver for the TPS65912 PMIC .../devicetree/bindings/gpio/gpio-tps65912.txt | 16 + Documentation/devicetree/bindings/mfd/tps65912.txt | 51 ++ .../bindings/regulator/tps65912-regulator.txt | 28 + drivers/gpio/Kconfig | 2 +- drivers/gpio/gpio-tps65912.c | 290 - drivers/mfd/Kconfig| 23 +- drivers/mfd/Makefile | 3 +- drivers/mfd/tps65912-core.c| 283 drivers/mfd/tps65912-i2c.c | 221 +++ drivers/mfd/tps65912-irq.c | 217 --- drivers/mfd/tps65912-spi.c | 222 +++ drivers/regulator/Kconfig | 2 +- drivers/regulator/tps65912-regulator.c | 712 + include/linux/mfd/tps65912.h | 211 +++--- 14 files changed, 802 insertions(+), 1479 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt create mode 100644 Documentation/devicetree/bindings/regulator/tps65912-regulator.txt rewrite drivers/gpio/gpio-tps65912.c (69%) rewrite drivers/mfd/tps65912-core.c (96%) rewrite drivers/mfd/tps65912-i2c.c (93%) delete mode 100644 drivers/mfd/tps65912-irq.c rewrite drivers/mfd/tps65912-spi.c (92%) rewrite drivers/regulator/tps65912-regulator.c (94%) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: DRA7: hwmod: Add data for GPTimer 12
Add the hwmod data for GPTimer 12. GPTimer 12 is present in
WKUPAON power domain and is clocked from a secure 32K clock.
GPTimer 12 serves as a secure timer on HS devices, but is
available for kernel on regular GP devices.
The hwmod link is registered only on GP devices. The hwmod data
also reused the existing timer class instead of reintroducing
the identical dra7xx_timer_secure_sysc class which was dropped
in commit edec17863362 ("ARM: DRA7: hwmod: Fix the hwmod class
for GPTimer4").
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +--
1 file changed, 34 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
index 562247bced49..37a10f87fbcd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
@@ -1929,6 +1929,20 @@ static struct omap_hwmod dra7xx_timer11_hwmod = {
},
};
+/* timer12 */
+static struct omap_hwmod dra7xx_timer12_hwmod = {
+ .name = "timer12",
+ .class = &dra7xx_timer_hwmod_class,
+ .clkdm_name = "wkupaon_clkdm",
+ .main_clk = "secure_32k_clk_src_ck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs =
DRA7XX_CM_WKUPAON_TIMER12_CLKCTRL_OFFSET,
+ .context_offs =
DRA7XX_RM_WKUPAON_TIMER12_CONTEXT_OFFSET,
+ },
+ },
+};
+
/* timer13 */
static struct omap_hwmod dra7xx_timer13_hwmod = {
.name = "timer13",
@@ -3135,6 +3149,14 @@ static struct omap_hwmod_ocp_if dra7xx_l4_per1__timer11
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* l4_wkup -> timer12 */
+static struct omap_hwmod_ocp_if dra7xx_l4_wkup__timer12 = {
+ .master = &dra7xx_l4_wkup_hwmod,
+ .slave = &dra7xx_timer12_hwmod,
+ .clk= "wkupaon_iclk_mux",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* l4_per3 -> timer13 */
static struct omap_hwmod_ocp_if dra7xx_l4_per3__timer13 = {
.master = &dra7xx_l4_per3_hwmod,
@@ -3429,6 +3451,13 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[]
__initdata = {
NULL,
};
+/* GP-only hwmod links */
+static struct omap_hwmod_ocp_if *dra7xx_gp_hwmod_ocp_ifs[] __initdata = {
+ &dra7xx_l4_wkup__timer12,
+ NULL,
+};
+
+/* SoC variant specific hwmod links */
static struct omap_hwmod_ocp_if *dra74x_hwmod_ocp_ifs[] __initdata = {
&dra7xx_l4_per3__usb_otg_ss4,
NULL,
@@ -3446,9 +3475,12 @@ int __init dra7xx_hwmod_init(void)
ret = omap_hwmod_register_links(dra7xx_hwmod_ocp_ifs);
if (!ret && soc_is_dra74x())
- return omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
+ ret = omap_hwmod_register_links(dra74x_hwmod_ocp_ifs);
else if (!ret && soc_is_dra72x())
- return omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
+ ret = omap_hwmod_register_links(dra72x_hwmod_ocp_ifs);
+
+ if (!ret && omap_type() == OMAP2_DEVICE_TYPE_GP)
+ ret = omap_hwmod_register_links(dra7xx_gp_hwmod_ocp_ifs);
return ret;
}
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: DRA7: Add timer12 node
Add the DT node for Timer12 present on DRA7 family of
SoCs. Timer12 is present in PD_WKUPAON power domain, and
has the same capabilities as the other timers, except for
the fact that it serves as a secure timer on HS devices
and is clocked only from the secure 32K clock.
The node is marked disabled for now, and the kernel should
refrain from using this secure timer on HS devices.
Signed-off-by: Suman Anna
---
arch/arm/boot/dts/dra7.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index e289c706d27d..37d632dad576 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -762,6 +762,16 @@
ti,hwmods = "timer11";
};
+ timer12: timer@4ae2 {
+ compatible = "ti,omap5430-timer";
+ reg = <0x4ae2 0x80>;
+ interrupts = ;
+ ti,hwmods = "timer12";
+ ti,timer-alwon;
+ ti,timer-secure;
+ status = "disabled";
+ };
+
timer13: timer@48828000 {
compatible = "ti,omap5430-timer";
reg = <0x48828000 0x80>;
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: OMAP2+: timer: Remove secure timer for DRA7xx devices
Timer 12 on DRA7 SoCs is reserved for secure usage on high-secure (HS)
devices. The timer cannot be used by the kernel on HS devices, but is
available on regular general purpose (GP) devices. This is similar to the
behavior on OMAP3 devices, so extend the logic used in commit ad24bde8f102
("ARM: OMAP3: Dynamically disable secure timer nodes for secure devices")
to remove the secure timer on DRA7xx SoCs at run-time based on the SoC
device type.
Signed-off-by: Suman Anna
---
arch/arm/mach-omap2/timer.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index a55655127ef2..1e346aa0a687 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -193,8 +193,8 @@ static struct device_node * __init omap_get_timer_dt(const
struct of_device_id *
/**
* omap_dmtimer_init - initialisation function when device tree is used
*
- * For secure OMAP3 devices, timers with device type "timer-secure" cannot
- * be used by the kernel as they are reserved. Therefore, to prevent the
+ * For secure OMAP3/DRA7xx devices, timers with device type "timer-secure"
+ * cannot be used by the kernel as they are reserved. Therefore, to prevent the
* kernel registering these devices remove them dynamically from the device
* tree on boot.
*/
@@ -202,7 +202,7 @@ static void __init omap_dmtimer_init(void)
{
struct device_node *np;
- if (!cpu_is_omap34xx())
+ if (!cpu_is_omap34xx() && !soc_is_dra7xx())
return;
/* If we are a secure device, remove any secure timer nodes */
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] DRA7 Timer12 Support
Hi Tony, The DRA7 Timer12 is completely missing from the kernel. This series adds the support for it, so that all the Timers on DRA7 are represented in the kernel. Timer12 is a special Timer, and is not available for kernel on HS devices, very much similar to the equivalent timer on OMAP3. Patch 1 is a bit debatable, as I am not entirely sure if the clk API used are acceptable outside the drivers/clk folders. It keeps intact the omap_dm_timer_set_source() API though, and allows it to handle the non-configurability of Timer12 parent within that API. The need for this API is questionable, I am not a big fan as the dmtimer code blindly tries to set the source of every requested API to OMAP_TIMER_SRC_32_KHZ, and then the requestors would have to reset the proper parent source again. It also supports configuring only one of 3 parents (which are valid when added originally for the then SoCs), requiring specific clock aliases to work across different SoCs, but the DRA7 SoC does have more than 3 configurable clock parents, and the indexes may not necessarily match for different timers on different SoCs. Patch 1 won't be needed if we can kill the omap_dm_timer_set_source() API. Patches baselined on 4.3-rc3, but should apply just fine on -rc1 as well. regards Suman Suman Anna (4): ARM: OMAP: dmtimer: check for fixed timers during config ARM: OMAP2+: timer: Remove secure timer for DRA7xx devices ARM: dts: DRA7: Add timer12 node ARM: DRA7: hwmod: Add data for GPTimer 12 arch/arm/boot/dts/dra7.dtsi | 10 + arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 36 +-- arch/arm/mach-omap2/timer.c | 6 +++--- arch/arm/plat-omap/dmtimer.c | 5 + 4 files changed, 52 insertions(+), 5 deletions(-) -- 2.6.0 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] ARM: OMAP: dmtimer: check for fixed timers during config
The omap_dm_timer_set_source() function provides a means for client
users to configure the mux parent for a GPTimer's functional clock.
However, not all timers are configurable (Eg: Timer12 on DRA7 is fed
by an internal 32k oscillator clock, and does not have configurable
parent clocks). So, check for such cases and proceed with out throwing
an error.
Signed-off-by: Suman Anna
---
arch/arm/plat-omap/dmtimer.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 8ca94d379bc3..25693e722f1f 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -36,6 +36,7 @@
*/
#include
+#include
#include
#include
#include
@@ -504,6 +505,10 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
if (IS_ERR(timer->fclk))
return -EINVAL;
+ /* Check if the clock has parents if not no point checking */
+ if (!clk_hw_get_num_parents(__clk_get_hw(timer->fclk)))
+ return 0;
+
switch (source) {
case OMAP_TIMER_SRC_SYS_CLK:
parent_name = "timer_sys_ck";
--
2.6.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] fsl: Add binding for RCPM
On Thu, 2015-10-01 at 12:05 -0500, Yoder Stuart-B08248 wrote: > > +++ b/Documentation/devicetree/bindings/soc/fsl/rcpm.txt > > @@ -0,0 +1,63 @@ > > +* Run Control and Power Management > > +--- > > +The RCPM performs all device-level tasks associated with device run > > control > > +and power management. > > + > > +Required properites: > > + - reg : Offset and length of the register set of RCPM block. > > s/RCPM block/the RCPM block/ > > > + - fsl,#rcpm-wakeup-cells : The number of cells in rcpm-wakeup property. > > s/rcpm-wakeup-property/the rcpm-wakeup-property/ > > > + - compatible : Sould contain a chip-specific RCPM block compatible > > string > > s/Sould/Should > > "Should" means it is recommended, but does not mean "must". Is it really > optional? > > > + and (if applicable) may contain a chassis-version RCPM compatible > > + string. Chip-specific strings are of the form "fsl,-rcpm", > > + such as: > > + * "fsl,p2041-rcpm" > > + * "fsl,p3041-rcpm" > > + * "fsl,p4080-rcpm" > > + * "fsl,p5020-rcpm" > > + * "fsl,p5040-rcpm" > > + * "fsl,t4240-rcpm" > > + * "fsl,b4420-rcpm" > > + * "fsl,b4860-rcpm" > > 2 or 3 examples is enough. > > > + Chassis-version strings are of the form "fsl,qoriq-rcpm- > > ", > > + such as: > > + * "fsl,qoriq-rcpm-1.0": for chassis 1.0 rcpm > > + * "fsl,qoriq-rcpm-2.0": for chassis 2.0 rcpm > > + * "fsl,qoriq-rcpm-2.1": for chassis 2.1 rcpm > > + > > +All references to "1.0" and "2.0" refer to the QorIQ chassis version to > > +which the chip complies. > > +Chassis VersionExample Chips > > +------ > > +1.0p4080, p5020, p5040, p2041, p3041 > > +2.0t4240, b4860, b4420 > > +2.1t1040, ls1021 > > Not sure this binding is the place to maintain a table of chassis > versions to SoCs. This is something I've been encouraging, given that the block versions are not publicly documented. It lets people find a manual that describes the advertised programming interface. -Scott -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] powerpc/512x: add LocalPlus Bus FIFO device driver
On 09/30/2015 04:24 PM, Alexander Popov wrote: Can you test for "!cs" here instead? +e = -EFAULT; +goto err_param; +} Unfortunately no: 0 is a valid value for Chip Select. Is it OK to leave it like that? Yes. +lpbfifo.ram_bus_addr = sg_dma_address(&sg); /* For freeing later */ +sg_dma_len(&sg) = lpbfifo.req->size; I don't think sg_dma_len() is meant to be used as an lvalue. I've double-checked and found many cases of such usage of this macro. It seems that I can't avoid it too. Ok. Driver code that has to parse #address-cells or #size-cells is usually wrong. I would not call it "parsing", I just check whether the dts-file is good. Anyway, could you give me a clue how to do better? You should use of_n_size_cells() and of_n_addr_cells(). -- -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 00/14] power: bq24257: Add support for bq24250/bq24251
On Thu, Oct 01, 2015 at 04:58:47AM +0200, Sebastian Reichel wrote: > Hi, > > On Mon, Sep 28, 2015 at 05:33:48PM -0500, Andreas Dannenberg wrote: > > This patch series extends the driver to also support bq24250/bq24251. > > > > The bq24250/251/257 devices have a very similar feature set and are > > virtually identical from a control register point of view so it made > > sense to extend the existing driver rather than submitting a new driver. > > In addition to the new device support the driver is also extended to > > allow access to some device features previously hidden. Basic and > > potentially dangerous charger config parameters affecting the actual > > charging of the Li-Ion battery are only configurable through firmware > > rather than sysfs properties. However some newly introduced properties > > are exposed through sysfs properties as access to them may be desired > > from userspace. For example, it is now possible to manually configure > > the maximum current drawn from the input source to accommodate different > > chargers (0.5A, 1.5A, 2.0A and so on) based on system knowledge a > > userspace application may have rather than rely on the auto-detection > > mechanism that may not work in all possible scenarios. > > Thanks, I queued all remaining patches except for Sebastian, I just pulled your tree and re-ran some of my tests. Looks like everything is still working as it should. Thanks again for your help reviewing. Same goes for Krzysztof and Laurentiu -- thanks for your time and feedback too. > > power: bq24257: Add platform data based initialization > > I'm still not convinced, that it should be added without any > consumer in the mainline kernel. Well I tried to make my case (giving access to the largest audience possible). If you don't want to include it that's fine. I guess it can always get added if a specific need arises... For future reference here is the link to the latest version of that patch: http://marc.info/?l=linux-pm&m=144347973708093&w=2 -- Andreas Dannenberg Texas Instruments Inc -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] PCI/MSI: Add helper function pci_msi_domain_get_msi_rid().
On 01/10/15 17:13, David Daney wrote:
> On 10/01/2015 02:24 AM, Marc Zyngier wrote:
>> Hi David,
>>
>> On 30/09/15 23:47, David Daney wrote:
>>> From: David Daney
>>>
>>> Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
>>> Initially needed by gic-v3 based systems. It will be used by follow on
>>> patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c
>>>
>>> Initially supports mapping the RID via OF device tree. In the future,
>>> this could be extended to use ACPI _IORT tables as well.
>>>
>>> Signed-off-by: David Daney
>>> ---
>>> drivers/pci/msi.c | 31 +++
>>> include/linux/msi.h | 1 +
>>> 2 files changed, 32 insertions(+)
>>>
>>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>>> index d449714..92b6dc9 100644
>>> --- a/drivers/pci/msi.c
>>> +++ b/drivers/pci/msi.c
>>> @@ -20,6 +20,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>>
>>> #include "pci.h"
>>>
>>> @@ -1327,4 +1328,34 @@ struct irq_domain
>>> *pci_msi_create_default_irq_domain(struct device_node *node,
>>>
>>> return domain;
>>> }
>>> +
>>> +struct get_mis_id_data {
>>> + u32 alias;
>>> +};
>>> +
>>> +static int get_msi_id_cb(struct pci_dev *pdev, u16 alias, void *data)
>>> +{
>>> + struct get_mis_id_data *s = data;
>>> +
>>> + s->alias = alias;
>>> + return 0;
>>> +}
>>
>> Why not use a naked u32, since you only have a single field in this
>> structure? Or is it that you are anticipating other fields there?
>
> In this case, I think using a pointer to u32 is a good idea. It would
> simplify the source code somewhat. Although, I think the generated
> binary would likely be the same. I don't foresee adding things to this
> structure. If it becomes necessary in the future, we can just go back
> to using a pointer to a structure.
>
>>
>>> +/**
>>> + * pci_msi_domain_get_msi_rid - Get the MSI requester id (RID)
>>> + * @domain:The interrupt domain
>>> + * @pdev: The PCI device.
>>> + *
>>> + * The RID for a device is formed from the alias, with a firmware
>>> + * supplied mapping applied
>>> + *
>>> + * Returns: The RID.
>>> + */
>>> +u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev
>>> *pdev)
>>> +{
>>> + struct get_mis_id_data d;
>>> +
>>> + d.alias = 0;
>>> + pci_for_each_dma_alias(pdev, get_msi_id_cb, &d);
>>> + return of_msi_map_rid(&pdev->dev, domain->of_node, d.alias);
>>
>> Should you check whether domain->of_node is NULL first? I don't think
>> of_msi_map_rid would have any problem with that, but a domain that is
>> not backed by an of_node makes me feel a bit uneasy and would tend to
>> indicate that we're not using DT.
>
> Yes, that makes sense. As you observe, I think it probably works as is,
> but it would be good to make it more clear. This is especially true
> when we add ACPI support. We will want to be clear on which of
> device-tree or ACPI we are using.
>
>
>>
>>> +}
>>> #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
>>> diff --git a/include/linux/msi.h b/include/linux/msi.h
>>> index ad939d0..56e3b76 100644
>>> --- a/include/linux/msi.h
>>> +++ b/include/linux/msi.h
>>> @@ -293,6 +293,7 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct
>>> pci_dev *dev,
>>> struct msi_desc *desc);
>>> int pci_msi_domain_check_cap(struct irq_domain *domain,
>>> struct msi_domain_info *info, struct device *dev);
>>> +u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev
>>> *pdev);
>>> #endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
>>>
>>> #endif /* LINUX_MSI_H */
>>>
>>
>> Otherwise looks good to me.
>
> I will send what I hope is the final revision of the patches later today.
Excellent. In related news, I've rebased my msi-parent stuff on top of
this series, and extended it to also deal with msi-map for matching MSI
domains.
With the two series, we should now have something vaguely coherent that
deals with both the old version of msi-parent, its new definition, and
msi-map in its whole glory. Fun times!
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] QEMU fw_cfg DMA interface
On 10/01/15 18:21, Eric Blake wrote: > On 10/01/2015 10:17 AM, Laszlo Ersek wrote: >> On 10/01/15 18:03, Eric Blake wrote: >>> [meta-comment] >>> >>> On 10/01/2015 06:14 AM, Marc Marí wrote: Implementation of the FW CFG DMA interface. >>> >>> The subject line is missing "v4" and "0/7". Also, the cover letter is >>> missing a diffstat. That makes it harder to see from the cover letter >>> what the rest of the series is about. 'git format-patch/send-email >>> --cover-letter' does what you want; you can even 'git config >>> format.coverletter=auto' to always include a decent cover letter on any >>> multi-patch series. >>> >> >> This posting follows a little bit different pattern, one that I myself >> follow when posting patches for two (or more) components that must work >> in sync. > > Ok, makes sense. Maybe the only additional suggestions would be to make > it more obvious in the subject line (put the text 'cross-post' > somewhere?) or have the first paragraph of the meta-cover be more > explicit that there are going to be multiple sub-threads, one per > project, where all subthreads must be applied to their corresponding > project for the overall feature to be complete? That's a good idea. I think prefixing the main blurb's subject with [cross-post], and a "standard" first paragraph based on your above suggestion, would be helpful. > [And maybe I should wait a few minutes for the full thread to appear in > my inbox, rather than immediately replying to the first mail while the > series is still incomplete due to mail delays...] I'm not patient; it would be unfair from me to expect others to be... :) Laszlo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC
On Thu, Oct 01, 2015 at 10:33:49AM -0500, Grygorii Strashko wrote: > So, in my opinion, the tps65217-regulator.c driver is really good > example of how it could be done. Yes, this should be a good example to refer to. signature.asc Description: Digital signature
Re: [Qemu-devel] QEMU fw_cfg DMA interface
On 10/01/15 18:11, Eric Blake wrote: > On 10/01/2015 10:03 AM, Eric Blake wrote: >> [meta-comment] >> >> On 10/01/2015 06:14 AM, Marc Marí wrote: >>> Implementation of the FW CFG DMA interface. >> >> The subject line is missing "v4" and "0/7". Also, the cover letter is >> missing a diffstat. That makes it harder to see from the cover letter >> what the rest of the series is about. 'git format-patch/send-email >> --cover-letter' does what you want; you can even 'git config >> format.coverletter=auto' to always include a decent cover letter on any >> multi-patch series. > > Oh, I see - you sent a meta-cover letter (the one I replied to in this > subthread), and then a patch series including a cover letter (the real > 0/7, then 1/7 and friends in-reply-to the 0/7) as a child of the > meta-cover. It's still a bit awkward for tools that expect the 0/7 as > the start of the thread, Yep, the pattern I just described doesn't consider those tools. Is that a bad problem? Maybe the pattern is not so clever then. :) (I'm allowed to say bad things about it, because I "invented" it "independently". :)) > and part of my confusion was caused by > out-of-order mail delivery due to the nongnu.org mail server still > recovering from its mail delays. > Right, those delays are not helping. Thanks Laszlo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] QEMU fw_cfg DMA interface
On 10/01/2015 10:17 AM, Laszlo Ersek wrote: > On 10/01/15 18:03, Eric Blake wrote: >> [meta-comment] >> >> On 10/01/2015 06:14 AM, Marc Marí wrote: >>> Implementation of the FW CFG DMA interface. >> >> The subject line is missing "v4" and "0/7". Also, the cover letter is >> missing a diffstat. That makes it harder to see from the cover letter >> what the rest of the series is about. 'git format-patch/send-email >> --cover-letter' does what you want; you can even 'git config >> format.coverletter=auto' to always include a decent cover letter on any >> multi-patch series. >> > > This posting follows a little bit different pattern, one that I myself > follow when posting patches for two (or more) components that must work > in sync. Ok, makes sense. Maybe the only additional suggestions would be to make it more obvious in the subject line (put the text 'cross-post' somewhere?) or have the first paragraph of the meta-cover be more explicit that there are going to be multiple sub-threads, one per project, where all subthreads must be applied to their corresponding project for the overall feature to be complete? [And maybe I should wait a few minutes for the full thread to appear in my inbox, rather than immediately replying to the first mail while the series is still incomplete due to mail delays...] -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Qemu-devel] QEMU fw_cfg DMA interface
On 10/01/15 18:03, Eric Blake wrote: > [meta-comment] > > On 10/01/2015 06:14 AM, Marc Marí wrote: >> Implementation of the FW CFG DMA interface. > > The subject line is missing "v4" and "0/7". Also, the cover letter is > missing a diffstat. That makes it harder to see from the cover letter > what the rest of the series is about. 'git format-patch/send-email > --cover-letter' does what you want; you can even 'git config > format.coverletter=auto' to always include a decent cover letter on any > multi-patch series. > This posting follows a little bit different pattern, one that I myself follow when posting patches for two (or more) components that must work in sync. Usually, a top-level blurb is manually cross-posted to all relevant mailing lists. Then, each separate patch series is posted only to the relevant mailing list, with its own cover letter (as usual with git), *in response* to the manually posted blurb. This has the following benefits: - in mailing list archives that organize messages into threads *across* mailing lists (like Gmane does, for example), the top-level manual blurb is a good "root" for referencing the entire posting. - The same is true for personal mailboxes, if a recipient is explicitly CC'd on all of the messages. Because the top level blurb is parent to several patch series, and those child series can all have different version numbers (due to different numbers of respinds), it is not always straightforward to assign a version number to the top blurb. Thanks Laszlo -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 3/4] PCI/MSI: Add helper function pci_msi_domain_get_msi_rid().
On 10/01/2015 02:24 AM, Marc Zyngier wrote:
Hi David,
On 30/09/15 23:47, David Daney wrote:
From: David Daney
Add pci_msi_domain_get_msi_rid() to return the MSI requester id (RID).
Initially needed by gic-v3 based systems. It will be used by follow on
patch to drivers/irqchip/irq-gic-v3-its-pci-msi.c
Initially supports mapping the RID via OF device tree. In the future,
this could be extended to use ACPI _IORT tables as well.
Signed-off-by: David Daney
---
drivers/pci/msi.c | 31 +++
include/linux/msi.h | 1 +
2 files changed, 32 insertions(+)
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index d449714..92b6dc9 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "pci.h"
@@ -1327,4 +1328,34 @@ struct irq_domain
*pci_msi_create_default_irq_domain(struct device_node *node,
return domain;
}
+
+struct get_mis_id_data {
+ u32 alias;
+};
+
+static int get_msi_id_cb(struct pci_dev *pdev, u16 alias, void *data)
+{
+ struct get_mis_id_data *s = data;
+
+ s->alias = alias;
+ return 0;
+}
Why not use a naked u32, since you only have a single field in this
structure? Or is it that you are anticipating other fields there?
In this case, I think using a pointer to u32 is a good idea. It would
simplify the source code somewhat. Although, I think the generated
binary would likely be the same. I don't foresee adding things to this
structure. If it becomes necessary in the future, we can just go back
to using a pointer to a structure.
+/**
+ * pci_msi_domain_get_msi_rid - Get the MSI requester id (RID)
+ * @domain:The interrupt domain
+ * @pdev: The PCI device.
+ *
+ * The RID for a device is formed from the alias, with a firmware
+ * supplied mapping applied
+ *
+ * Returns: The RID.
+ */
+u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev *pdev)
+{
+ struct get_mis_id_data d;
+
+ d.alias = 0;
+ pci_for_each_dma_alias(pdev, get_msi_id_cb, &d);
+ return of_msi_map_rid(&pdev->dev, domain->of_node, d.alias);
Should you check whether domain->of_node is NULL first? I don't think
of_msi_map_rid would have any problem with that, but a domain that is
not backed by an of_node makes me feel a bit uneasy and would tend to
indicate that we're not using DT.
Yes, that makes sense. As you observe, I think it probably works as is,
but it would be good to make it more clear. This is especially true
when we add ACPI support. We will want to be clear on which of
device-tree or ACPI we are using.
+}
#endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ad939d0..56e3b76 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -293,6 +293,7 @@ irq_hw_number_t pci_msi_domain_calc_hwirq(struct pci_dev
*dev,
struct msi_desc *desc);
int pci_msi_domain_check_cap(struct irq_domain *domain,
struct msi_domain_info *info, struct device *dev);
+u32 pci_msi_domain_get_msi_rid(struct irq_domain *domain, struct pci_dev
*pdev);
#endif /* CONFIG_PCI_MSI_IRQ_DOMAIN */
#endif /* LINUX_MSI_H */
Otherwise looks good to me.
I will send what I hope is the final revision of the patches later today.
David Daney
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Qemu-devel] QEMU fw_cfg DMA interface
On 10/01/2015 10:03 AM, Eric Blake wrote: > [meta-comment] > > On 10/01/2015 06:14 AM, Marc Marí wrote: >> Implementation of the FW CFG DMA interface. > > The subject line is missing "v4" and "0/7". Also, the cover letter is > missing a diffstat. That makes it harder to see from the cover letter > what the rest of the series is about. 'git format-patch/send-email > --cover-letter' does what you want; you can even 'git config > format.coverletter=auto' to always include a decent cover letter on any > multi-patch series. Oh, I see - you sent a meta-cover letter (the one I replied to in this subthread), and then a patch series including a cover letter (the real 0/7, then 1/7 and friends in-reply-to the 0/7) as a child of the meta-cover. It's still a bit awkward for tools that expect the 0/7 as the start of the thread, and part of my confusion was caused by out-of-order mail delivery due to the nongnu.org mail server still recovering from its mail delays. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC
On 10/01/2015 10:33 AM, Grygorii Strashko wrote: Hi Andrew, On 09/30/2015 03:29 PM, Andrew F. Davis wrote: On 09/30/2015 12:28 PM, Mark Brown wrote: On Tue, Sep 29, 2015 at 01:58:41PM -0500, Andrew F. Davis wrote: On 09/29/2015 01:38 PM, Mark Brown wrote: Oh, ick. The binding has a compatible string in the individual regulator bindings which is broken unless there really are lots of variants being configured via DT (which is just not the case here). It's not only more typing in the DT, I don't see this, the alternative is matching to this "regulator-compatible", why not just use the existing compatible. No, you don't need to use regulator-compatible - that's deprecated. Just use the node names. Are we sure matching on node names is a good idea? Most are just arbitrary names meant to be human readable and reference-able, giving them function may lead to confusion. This seems to be why we have "compatible", for specific identification of node function. But I'm new so maybe I'm wrong? it also means that we can't read back the configuration of the device unless the user goes and creates a DT which explicitly lists each regulator on the device which is unhelpful. We should be able to read back the configurations of all the regulators by simply listing the device in DT. Could you expand this? I'm not sure I understand why we still cant do this using this new way. I'm not sure what there is to add... if the regulator is only instantiated when it features in the device tree then obviously it must be included in the device to be instantiated. This is already the case then, missing regulator nodes in old drivers will not get instantiated ether. And old drivers don't always store any more info about available regulators than mine does. Bindings should have compatible strings when they describe hardware like this, we can then do stuff like put the LDO and DCDC drivers in separate modules for instance, letting DT only load what we need. There are other benefits like not having to search our own DT binding for data, and we only get probed for devices in the DT. Only getting probed for device is in DT is exactly the problem here, and nothing prevents us having separate modules for things without enumerating everything in DT. Sure, but then we have to do some fiddling with MFD_CORE to do that work, why not remove the dependency and let DT do that for DT only drivers? This also eliminates the need for MFD_CORE, we just call of_platform_populate on ourself and DT helpers do the rest. Why hard code mfd_cell's and do matching when DT does the same thing. Putting everything in DT means more work for people integrating the device and means that we have to have a full and complete understanding of the device at the time we write the DT, including decions about how we split the functionality of the device between subsystems. We are not adding anything extra to the DT node, we just use the "compatible" string to identify and match the node vs. "regulator-name", or the nodes name, or whatever else has been used. The node is then just filled with the standard optional properties just like every other driver's node. The fact that this is different to the bindings for other regulator drivers and requires more code ought to have been a big warning sign here :( The binding is the same as the new tps65218 driver, different isn't always a warning sign. And what do you mean "requires more code"? This regulator driver is smaller than almost any other. DT takes care of everything for us relating to hardware instantiation like it should. That's not a new driver, it's from more than a year ago (before or about the same time the helpers got added IIRC). Newer than a lot, I chose to base my driver off of that not just because it is a similar TI part, but because it was the cleanest, simplest looking one IMHO. The helpers would require more code (you need to know how many regulators you have and call the helpers in a loop). I have another PMIC I'm about to push a driver for when this gets figured out that does the same thing, and it's more important I think to do it this way for this new part. Some of the new regulators are designed without a dedicated SOC or board to power in mind, so they will have a whole bunch for different regulator types on one chip and it will be up to the designer to pick which ones to turn on and use. With this DT approach you can just list the ones you want, and we may even be able to split different types into different modules, then we can use the same regulator driver in different spins of the PMIC with more or less of that type of regulator, we just add that same node under a different parent PMIC driver. That's all make sense only if you have all information required for driver probing in DT. But you don't, because a lot of information are still hard-coded in driver: - regulator IDs, - registers required to control regulator - ranges information and etc.
Re: [Qemu-devel] QEMU fw_cfg DMA interface
[meta-comment] On 10/01/2015 06:14 AM, Marc Marí wrote: > Implementation of the FW CFG DMA interface. The subject line is missing "v4" and "0/7". Also, the cover letter is missing a diffstat. That makes it harder to see from the cover letter what the rest of the series is about. 'git format-patch/send-email --cover-letter' does what you want; you can even 'git config format.coverletter=auto' to always include a decent cover letter on any multi-patch series. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[PATCH 1/4] ARM: dts: Fix RGMII pinctrl timings
These new re-timing values provides a better stability on Ethernet link. Signed-off-by: Maxime Coquelin --- arch/arm/boot/dts/stih407-pinctrl.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arm/boot/dts/stih407-pinctrl.dtsi b/arch/arm/boot/dts/stih407-pinctrl.dtsi index 8fe542a..a538ae5 100644 --- a/arch/arm/boot/dts/stih407-pinctrl.dtsi +++ b/arch/arm/boot/dts/stih407-pinctrl.dtsi @@ -216,9 +216,9 @@ rxd2 = <&pio1 6 ALT1 IN DE_IO 0 CLK_A>; rxd3 = <&pio1 7 ALT1 IN DE_IO 0 CLK_A>; rxdv = <&pio2 0 ALT1 IN DE_IO 0 CLK_A>; - rxclk = <&pio2 2 ALT1 IN NICLK 500 CLK_A>; + rxclk = <&pio2 2 ALT1 IN NICLK 0 CLK_A>; clk125 = <&pio3 7 ALT4 IN NICLK 0 CLK_A>; - phyclk = <&pio2 3 ALT4 OUT NICLK 1750 CLK_B>; + phyclk = <&pio2 3 ALT4 OUT NICLK 1250 CLK_B>; }; }; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] ARM: dts: Enable Ethernet on STi's B2120 boards
These boards are mounted with Realtek RTL8367 switch.
We consider the bootloader will have intiliazed the switch before jumping into
the kernel, so we declare it as a fixed link.
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stih407-b2120.dts | 1 +
arch/arm/boot/dts/stih410-b2120.dts | 1 +
arch/arm/boot/dts/stihxxx-b2120.dtsi | 6 ++
3 files changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-b2120.dts
b/arch/arm/boot/dts/stih407-b2120.dts
index 6d93475..c8ad905 100644
--- a/arch/arm/boot/dts/stih407-b2120.dts
+++ b/arch/arm/boot/dts/stih407-b2120.dts
@@ -25,6 +25,7 @@
aliases {
ttyAS0 = &sbc_serial0;
+ ethernet0 = ðernet0;
};
};
diff --git a/arch/arm/boot/dts/stih410-b2120.dts
b/arch/arm/boot/dts/stih410-b2120.dts
index 8af1e73..118ac28 100644
--- a/arch/arm/boot/dts/stih410-b2120.dts
+++ b/arch/arm/boot/dts/stih410-b2120.dts
@@ -25,6 +25,7 @@
aliases {
ttyAS0 = &sbc_serial0;
+ ethernet0 = ðernet0;
};
soc {
diff --git a/arch/arm/boot/dts/stihxxx-b2120.dtsi
b/arch/arm/boot/dts/stihxxx-b2120.dtsi
index ab029f7..ad21a42 100644
--- a/arch/arm/boot/dts/stihxxx-b2120.dtsi
+++ b/arch/arm/boot/dts/stihxxx-b2120.dtsi
@@ -87,5 +87,11 @@
status = "okay";
};
+ ethernet0: dwmac@963 {
+ st,tx-retime-src = "clkgen";
+ status = "okay";
+ phy-mode = "rgmii";
+ fixed-link = <0 1 1000 0 0>;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] ARM: dts: Enable Ethernet on STi's B2199 board
The B2199 board is mounted with Realtek RTL8367 switch.
We consider the bootloader will have intiliazed the switch before jumping into
the kernel, so we declare it as a fixed link.
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stih418-b2199.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/stih418-b2199.dts
b/arch/arm/boot/dts/stih418-b2199.dts
index 82eee39..772d2bb 100644
--- a/arch/arm/boot/dts/stih418-b2199.dts
+++ b/arch/arm/boot/dts/stih418-b2199.dts
@@ -24,6 +24,7 @@
aliases {
ttyAS0 = &sbc_serial0;
+ ethernet0 = ðernet0;
};
soc {
@@ -101,5 +102,12 @@
st_dwc3: dwc3@8f94000 {
status = "okay";
};
+
+ ethernet0: dwmac@963 {
+ st,tx-retime-src = "clkgen";
+ status = "okay";
+ phy-mode = "rgmii";
+ fixed-link = <0 1 1000 0 0>;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Enable Ethernet on StiH407 family boards
This series enables Ethernet support on STiH407 family reference design boards. These boards use the RTL8367 Switch as PHY. As it is previously configured by the bootloader, we declare it as a fixed link. Maxime Coquelin (4): ARM: dts: Fix RGMII pinctrl timings ARM: dts: Add Ethernet node to STiH407 family ARM: dts: Enable Ethernet on STi's B2120 boards ARM: dts: Enable Ethernet on STi's B2199 board arch/arm/boot/dts/stih407-b2120.dts| 1 + arch/arm/boot/dts/stih407-family.dtsi | 27 +++ arch/arm/boot/dts/stih407-pinctrl.dtsi | 4 ++-- arch/arm/boot/dts/stih410-b2120.dts| 1 + arch/arm/boot/dts/stih418-b2199.dts| 8 arch/arm/boot/dts/stihxxx-b2120.dtsi | 6 ++ 6 files changed, 45 insertions(+), 2 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] ARM: dts: Add Ethernet node to STiH407 family
STiH407 family uses the Synopsys IP.
Signed-off-by: Maxime Coquelin
---
arch/arm/boot/dts/stih407-family.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/stih407-family.dtsi
b/arch/arm/boot/dts/stih407-family.dtsi
index 582154b..c944d3a 100644
--- a/arch/arm/boot/dts/stih407-family.dtsi
+++ b/arch/arm/boot/dts/stih407-family.dtsi
@@ -653,5 +653,32 @@
clocks = <&clk_sysin>;
status = "okay";
};
+
+ ethernet0: dwmac@963 {
+ device_type = "network";
+ status = "disabled";
+ compatible = "st,stih407-dwmac", "snps,dwmac",
"snps,dwmac-3.710";
+ reg = <0x963 0x8000>, <0x80 0x4>;
+ reg-names = "stmmaceth", "sti-ethconf";
+
+ st,syscon = <&syscfg_sbc_reg 0x80>;
+ st,gmac_en;
+ resets = <&softreset STIH407_ETH1_SOFTRESET>;
+ reset-names = "stmmaceth";
+
+ interrupts = ,
+;
+ interrupt-names = "macirq", "eth_wake_irq";
+
+ /* DMA Bus Mode */
+ snps,pbl = <8>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii1>;
+
+ clock-names = "stmmaceth", "sti-ethclk";
+ clocks = <&clk_s_c0_flexgen CLK_EXT2F_A9>,
+<&clk_s_c0_flexgen CLK_ETH_PHY>;
+ };
};
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC
Hi Andrew, On 09/30/2015 03:29 PM, Andrew F. Davis wrote: > On 09/30/2015 12:28 PM, Mark Brown wrote: >> On Tue, Sep 29, 2015 at 01:58:41PM -0500, Andrew F. Davis wrote: >>> On 09/29/2015 01:38 PM, Mark Brown wrote: >> Oh, ick. The binding has a compatible string in the individual regulator bindings which is broken unless there really are lots of variants being configured via DT (which is just not the case here). It's not only more typing in the DT, >> >>> I don't see this, the alternative is matching to this >>> "regulator-compatible", >>> why not just use the existing compatible. >> >> No, you don't need to use regulator-compatible - that's deprecated. >> Just use the node names. >> > > Are we sure matching on node names is a good idea? Most are just arbitrary > names meant to be human readable and reference-able, giving them function > may lead to confusion. This seems to be why we have "compatible", for > specific > identification of node function. But I'm new so maybe I'm wrong? > it also means that we can't read back the configuration of the device unless the user goes and creates a DT which explicitly lists each regulator on the device which is unhelpful. We should be able to read back the configurations of all the regulators by simply listing the device in DT. >> >>> Could you expand this? I'm not sure I understand why we still cant do >>> this >>> using this new way. >> >> I'm not sure what there is to add... if the regulator is only >> instantiated when it features in the device tree then obviously it must >> be included in the device to be instantiated. >> > > This is already the case then, missing regulator nodes in old drivers > will not > get instantiated ether. And old drivers don't always store any more info > about > available regulators than mine does. > >>> Bindings should have compatible strings when they describe hardware >>> like this, >>> we can then do stuff like put the LDO and DCDC drivers in separate >>> modules for >>> instance, letting DT only load what we need. There are other benefits >>> like >>> not having to search our own DT binding for data, and we only get >>> probed for >>> devices in the DT. >> >> Only getting probed for device is in DT is exactly the problem here, and >> nothing prevents us having separate modules for things without >> enumerating everything in DT. >> > > Sure, but then we have to do some fiddling with MFD_CORE to do that work, > why not remove the dependency and let DT do that for DT only drivers? > >>> This also eliminates the need for MFD_CORE, we just call >>> of_platform_populate on ourself and DT helpers do the rest. Why hard >>> code >>> mfd_cell's and do matching when DT does the same thing. >> >> Putting everything in DT means more work for people integrating the >> device and means that we have to have a full and complete understanding >> of the device at the time we write the DT, including decions about how >> we split the functionality of the device between subsystems. >> > > We are not adding anything extra to the DT node, we just use the > "compatible" > string to identify and match the node vs. "regulator-name", or the nodes > name, > or whatever else has been used. The node is then just filled with the > standard > optional properties just like every other driver's node. > The fact that this is different to the bindings for other regulator drivers and requires more code ought to have been a big warning sign here :( >> >>> The binding is the same as the new tps65218 driver, different isn't >>> always >>> a warning sign. And what do you mean "requires more code"? This >>> regulator >>> driver is smaller than almost any other. DT takes care of everything for >>> us relating to hardware instantiation like it should. >> >> That's not a new driver, it's from more than a year ago (before or about >> the same time the helpers got added IIRC). >> > > Newer than a lot, I chose to base my driver off of that not just because > it is a similar TI part, but because it was the cleanest, simplest looking > one IMHO. The helpers would require more code (you need to know how many > regulators you have and call the helpers in a loop). > > I have another PMIC I'm about to push a driver for when this gets > figured out > that does the same thing, and it's more important I think to do it this > way for > this new part. Some of the new regulators are designed without a dedicated > SOC or board to power in mind, so they will have a whole bunch for > different > regulator types on one chip and it will be up to the designer to pick > which ones > to turn on and use. With this DT approach you can just list the ones you > want, > and we may even be able to split different types into different modules, > then > we can use the same regulator driver in different spins of the PMIC with > more > or less of that type of regulator, we just add that same node under a
Re: [PATCH 2/2] arm64: dts: mt8173: add timer node
On 01/10/15 15:33, Yingjoe Chen wrote: On Thu, 2015-09-17 at 17:13 +0100, Sudeep Holla wrote: [...] I think your are confusing the system counter with arch timers. System counter is always-on, but the arch timers(logic implementing timers comparators) might not be off when the processor is powered down. I think you need this timer and are using it for low power idle states in which case you will use this as a clock event and not clock source. It will be used as a hardware broadcast event source. There's no call to sched_clock_register in mtk_timer.c, so it can't be the sched clock, so you need to fix the commit log. Hi Sudeep, Sorry for late reply. For sched_clock_register, please see http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001547.html which was accepted in https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/clockevents/4.4 The commit message makes no sense to me. The counters should continue to work as long as they are in always-on domain. Only timers are lost when you enter deeper idle states. So I agree with using MTK timer as broadcast timer/eventsource. You still didn't answer what's the need to use MTK timer as sched clocksource ? Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm64: dts: mt8173: add timer node
On Thu, 2015-09-17 at 17:41 +0100, Mark Rutland wrote: > On Thu, Sep 17, 2015 at 03:56:56PM +0100, Yingjoe Chen wrote: > > On Thu, 2015-09-17 at 14:51 +0100, Sudeep Holla wrote: > > > > > > On 16/09/15 03:04, Yingjoe Chen wrote: > > > > From: Daniel Kurtz > > > > > > > > Add device node to enable GPT timer. This timer will be > > > > used as sched clock source. > > > > > > > > > > Interesting any known issues with or advantage over the arch timers > > > to prefer it as sched clock source. I see even arch timers are present > > > in DT, hence the question. Or is it just a incorrect commit log ? > > > > > > How does this get selected as sched clock source ? I don't see > > > sched_clock_register in mtk_timer.c > > > > > > To be clear, I am not against adding this timer support, but just want > > > to know is it preferred for sched clock source ? if yes why ? better > > > resolution ? > > > > Hi Sudeep, > > > > Thanks for your review. > > > > I hit the send too soon and missed cover letter, please see: > > http://lists.infradead.org/pipermail/linux-mediatek/2015-September/002303.html > > > > The main reason to use GPT as sched clock is it won't stop during idle. > > You don't mean sched clock, you just mean a clock_event_device. > > A sched_clock is a high-precision clocksource that is read from (which > by definition requires the CPUs to be non-idle). It doesn't have > anything to do with interrupts and therefore cannot wake devices from > idle. > > While the clock_event_device for the generic timer can't necessarily > wake CPUs from idle. The generic timer system counter counts even if > CPUs are idle, so the generic timer is fine as a sched_clock. Hi, Mark, Thanks for your info and sorry for late reply. I notice ARM ARM said the arch timer shouldn't stop when idle, but unfortunately that not true for mt8173. The last CPU enter idle can choose to enter deep idle mode and the counter value would be lost. Our firmware backup/recover the counter so it looks like it is stopped. We will change the firmware to add missing count when back from deep idle to make it looks like the counter never stop. Joe.C -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/5] Input: goodix - reset device at init
> -Original Message- > From: mrgarna...@gmail.com [mailto:mrgarna...@gmail.com] On Behalf Of Carlos > Garnacho > Sent: 30 September, 2015 17:02 > To: Bastien Nocera > Cc: Tirdea, Irina; linux-in...@vger.kernel.org; Cosimo Cecchi; Christian > Hergert; linux-ker...@vger.kernel.org; Rob Herring; Pawel > Moll; Ian Campbell; Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark > Rutland; devicetree@vger.kernel.org > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init > > Hey, > Hi Carlos and Bastien, Thanks for your help and for testing these patches! > >> > I'm not sure how we can detect, and blacklist, those devices. At > >> > least > >> > my original device, the Onda v975w, and the WinBook TW100 would > >> > have > >> > those problems. > >> > > >> > >> I can use DMI quirks to exclude these devices from using the features > >> that > >> depend on the gpio pins. I already have the DMI information for > >> WinBook TW100 > >> and WinBook TW700. Could you tell me the DMI_SYS_VENDOR and > >> DMI_PRODUCT_NAME for Onda v975w so I can add it as well? > > > > I don't have access to the Onda v975w anymore, but let me CC: a few > > people that could also help with testing. > > > > Carlos, Cosimo, Christian, there's a patchset for you to test on the > > Onda v975w at: > > https://github.com/hadess/gt9xx/commits/irina-tirdea > > > > Doing an "rmmod goodix ; insmod ./goodix_backport.ko" should be enough > > to test whether the patch set works. If it doesn't work correctly, > > you'll need to reboot the machine, swap the irq_idx and rst_idx values > > at: > > https://github.com/hadess/gt9xx/commit/c27de79f494c2b2e7a198ff4d27976ae93669dbd#diff- > dddc2849e36327439530f3e2faacec4fR321 > > > > and try again. > > Unswapped does fail with: > > sep 30 15:37:29 tablet kernel: Goodix-TS i2c-GDIX1001:00: i2c test > failed attempt 1: -121 > sep 30 15:37:29 tablet kernel: Goodix-TS i2c-GDIX1001:00: i2c test > failed attempt 2: -121 > sep 30 15:37:29 tablet kernel: Goodix-TS i2c-GDIX1001:00: I2C > communication failure: -121 > sep 30 15:37:29 tablet kernel: Goodix-TS: probe of i2c-GDIX1001:00 > failed with error -121 > > Swapping the values triggers some errors: > > sep 30 15:48:17 tablet kernel: [ cut here ] > sep 30 15:48:17 tablet kernel: WARNING: CPU: 1 PID: 2341 at > drivers/pinctrl/intel/pinctrl-baytrail.c:342 > byt_gpio_direction_output+0xa1/0xb0() > sep 30 15:48:17 tablet kernel: Potential Error: Setting GPIO with > direct_irq_en to output > sep 30 15:48:17 tablet kernel: Modules linked in: > sep 30 15:48:17 tablet kernel: goodix_backport(OE+) r8723bs(OE) nfsd > lockd grace sunrpc [last unloaded: goodix] > sep 30 15:48:17 tablet kernel: CPU: 1 PID: 2341 Comm: insmod Tainted: > G OE 4.3.0-rc1+ #36 > sep 30 15:48:17 tablet kernel: Hardware name: To be filled by O.E.M. > To be filled by O.E.M./Aptio CRB, BIOS 5.6.5 07/25/2014 > sep 30 15:48:17 tablet kernel: d3f61c08 c13b347f > d3f61c48 d3f61c38 c10a9e1d c20f10e0 > sep 30 15:48:17 tablet kernel: d3f61c64 0925 c20f111c 0156 > c13e7ce1 c13e7ce1 f80580b8 f53a4b0c > sep 30 15:48:17 tablet kernel: 0156 d3f61c50 c10a9e93 0009 > d3f61c48 c20f10e0 d3f61c64 d3f61c78 > sep 30 15:48:17 tablet kernel: Call Trace: > sep 30 15:48:17 tablet kernel: [] dump_stack+0x48/0x69 > sep 30 15:48:17 tablet kernel: [] warn_slowpath_common+0x8d/0xd0 > sep 30 15:48:17 tablet kernel: [] ? > byt_gpio_direction_output+0xa1/0xb0 > sep 30 15:48:17 tablet kernel: [] ? > byt_gpio_direction_output+0xa1/0xb0 > sep 30 15:48:17 tablet kernel: [] warn_slowpath_fmt+0x33/0x40 > sep 30 15:48:17 tablet kernel: [] > byt_gpio_direction_output+0xa1/0xb0 > sep 30 15:48:17 tablet kernel: [] ? byt_gpio_irq_handler+0xb0/0xb0 > sep 30 15:48:17 tablet kernel: [] > _gpiod_direction_output_raw+0x63/0x350 > sep 30 15:48:17 tablet kernel: [] gpiod_direction_output+0x2a/0x50 > sep 30 15:48:17 tablet kernel: [] ? msleep+0x36/0x40 > sep 30 15:48:17 tablet kernel: [] goodix_reset+0x3e/0x90 > [goodix_backport] > sep 30 15:48:17 tablet kernel: [] > goodix_ts_probe+0x12a/0x5aa [goodix_backport] > sep 30 15:48:17 tablet kernel: [] ? acpi_device_wakeup+0x7a/0x80 > sep 30 15:48:17 tablet kernel: [] ? acpi_dev_pm_attach+0x71/0x87 > sep 30 15:48:17 tablet kernel: [] i2c_device_probe+0x121/0x1d0 > sep 30 15:48:17 tablet kernel: [] ? _raw_spin_unlock+0x22/0x30 > sep 30 15:48:17 tablet kernel: [] ? > goodix_config_cb+0xc0/0xc0 [goodix_backport] > sep 30 15:48:17 tablet kernel: [] ? driver_sysfs_add+0x75/0xa0 > sep 30 15:48:17 tablet kernel: [] driver_probe_device+0x204/0x4c0 > sep 30 15:48:17 tablet kernel: [] ? __driver_attach+0x5c/0xa0 > sep 30 15:48:17 tablet kernel: [] ? __driver_attach+0x5c/0xa0 > sep 30 15:48:17 tablet kernel: [] __driver_attach+0x99/0xa0 > sep 30 15:48:17 tablet kernel: [] ? driver_probe_device+0x4c0/0x4c0 > sep 30 15:48:17 tablet kernel: [] bus_for_each_dev+0x4f/0x80 > sep 30 15:48:17 tablet ke
Re: [PATCH 1/4] clk: bcm2835: Move under bcm/ with other Broadcom SoC clk drivers.
On Tue, 08 Sep 2015, Stephen Boyd wrote: > On 09/07, Lee Jones wrote: > > On Sun, 06 Sep 2015, Eric Anholt wrote: > > > > > clk-bcm2835.c predates the drivers under bcm/, but all the new BCM > > > drivers are going in there so let's follow them. > > > > > > Signed-off-by: Eric Anholt > > > --- > > > drivers/clk/Makefile | 1 - > > > drivers/clk/bcm/Makefile | 1 + > > > drivers/clk/bcm/clk-bcm2835.c | 60 > > > +++ > > > drivers/clk/clk-bcm2835.c | 60 > > > --- > > > > You need to resubmit this with `git format-patch -M`. > > You don't have to. It would have been nice if it was formatted > with -M so that review is easier, but we can always apply the > patch and then check the result to make sure things look the > same. I vehemently avoid having to apply patches to my local repo in order to review them. Submitters should always be encouraged to use -M, especially in cases where there have been changes. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] arm64: dts: mt8173: add timer node
On Thu, 2015-09-17 at 17:13 +0100, Sudeep Holla wrote:
>
> On 17/09/15 15:56, Yingjoe Chen wrote:
> > On Thu, 2015-09-17 at 14:51 +0100, Sudeep Holla wrote:
> >>
> >> On 16/09/15 03:04, Yingjoe Chen wrote:
> >>> From: Daniel Kurtz
> >>>
> >>> Add device node to enable GPT timer. This timer will be
> >>> used as sched clock source.
> >>>
> >>
> >> Interesting any known issues with or advantage over the arch timers
> >> to prefer it as sched clock source. I see even arch timers are present
> >> in DT, hence the question. Or is it just a incorrect commit log ?
> >>
> >> How does this get selected as sched clock source ? I don't see
> >> sched_clock_register in mtk_timer.c
> >>
> >> To be clear, I am not against adding this timer support, but just want
> >> to know is it preferred for sched clock source ? if yes why ? better
> >> resolution ?
> >
> > Hi Sudeep,
> >
> > Thanks for your review.
> >
> > I hit the send too soon and missed cover letter, please see:
> > http://lists.infradead.org/pipermail/linux-mediatek/2015-September/002303.html
> >
>
> OK
>
> > The main reason to use GPT as sched clock is it won't stop during idle.
> >
> >
>
> I think your are confusing the system counter with arch timers. System
> counter is always-on, but the arch timers(logic implementing timers
> comparators) might not be off when the processor is powered down.
>
> I think you need this timer and are using it for low power idle states
> in which case you will use this as a clock event and not clock source.
> It will be used as a hardware broadcast event source.
>
> There's no call to sched_clock_register in mtk_timer.c, so it can't be
> the sched clock, so you need to fix the commit log.
Hi Sudeep,
Sorry for late reply.
For sched_clock_register, please see
http://lists.infradead.org/pipermail/linux-mediatek/2015-July/001547.html
which was accepted in
https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/clockevents/4.4
You are right it is also used as clock event. I think we don't need to
mention those detail in commit message, so I'll change to just:
"Add device node to enable GPT timer."
>
> [...]
>
> >>> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >>> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >>> index d18ee42..d763803 100644
> >>> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >>> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> >>> @@ -238,6 +238,15 @@
> >>> reg = <0 0x10007000 0 0x100>;
> >>> };
> >>>
> >>> + timer: timer@10008000 {
> >>> + compatible = "mediatek,mt8173-timer",
> >>
> >> Missing documentation ? I am referring upstream and it might be in some
> >> patches already queued perhaps ?
> >
> > This is documented in
> > Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt.
> > Do you mean I should add "mediatek,mt8173-timer" to that file?
> >
>
> Yes
Will do in next round.
Thanks
Joe.C
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
