* Re: [PATCH v3 2/5] clk: sunxi: Add USB clock register defintions
From: Maxime Ripard @ 2014-02-07 14:44 UTC (permalink / raw)
To: Hans de Goede
Cc: Emilio López, Mike Turquette,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Roman Byshko
In-Reply-To: <1391783553-8096-3-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3430 bytes --]
Hi,
On Fri, Feb 07, 2014 at 03:32:30PM +0100, Hans de Goede wrote:
> From: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Add register definitions for the usb-clk register found on sun4i, sun5i and
> sun7i SoCs.
>
> Signed-off-by: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 5 +++++
> drivers/clk/sunxi/clk-sunxi.c | 12 ++++++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 27f19f1..e368a86c 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -38,6 +38,8 @@ Required properties:
> "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
> "allwinner,sun7i-a20-out-clk" - for the external output clocks
> "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
> + "allwinner,sun4i-usb-clk" - for usb gates + resets on A10 / A20
I know I asked you otherwise, but since we're moving to sun4i-a10-*
compatibles, can you do it here too ? :)
Thanks!
Maxime
> + "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
>
> Required properties for all clocks:
> - reg : shall be the control register address for the clock.
> @@ -54,6 +56,9 @@ Required properties for all clocks:
> For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
> dummy clocks at 25 MHz and 125 MHz, respectively. See example.
>
> +And "allwinner,*-usb-clk" clocks also require:
> +- reset-cells : shall be set to 1
> +
> Clock consumers should specify the desired clocks they use with a
> "clocks" phandle cell. Consumers that are using a gated clock should
> provide an additional ID in their clock property. This ID is the
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 1e15e4c..3ba1402 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -910,6 +910,16 @@ static const struct gates_data sun4i_ahb_gates_data __initconst = {
> .mask = {0x7F77FFF, 0x14FB3F},
> };
>
> +static const struct gates_data sun4i_usb_gates_data __initconst = {
> + .mask = {0x1C0},
> + .reset_mask = 0x07,
> +};
> +
> +static const struct gates_data sun5i_a13_usb_gates_data __initconst = {
> + .mask = {0x140},
> + .reset_mask = 0x03,
> +};
> +
> static const struct gates_data sun5i_a10s_ahb_gates_data __initconst = {
> .mask = {0x147667e7, 0x185915},
> };
> @@ -1257,6 +1267,8 @@ static const struct of_device_id clk_gates_match[] __initconst = {
> {.compatible = "allwinner,sun6i-a31-apb1-gates-clk", .data = &sun6i_a31_apb1_gates_data,},
> {.compatible = "allwinner,sun7i-a20-apb1-gates-clk", .data = &sun7i_a20_apb1_gates_data,},
> {.compatible = "allwinner,sun6i-a31-apb2-gates-clk", .data = &sun6i_a31_apb2_gates_data,},
> + {.compatible = "allwinner,sun4i-usb-clk", .data = &sun4i_usb_gates_data,},
> + {.compatible = "allwinner,sun5i-a13-usb-clk", .data = &sun5i_a13_usb_gates_data,},
> {}
> };
>
> --
> 1.8.4.2
>
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 06/15] dt: binding: add binding for ImgTec IR block
From: Rob Herring @ 2014-02-07 14:33 UTC (permalink / raw)
To: James Hogan
Cc: Mauro Carvalho Chehab, linux-media, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala,
devicetree@vger.kernel.org, Rob Landley,
linux-doc@vger.kernel.org, Tomasz Figa
In-Reply-To: <52F39F30.70104@imgtec.com>
On Thu, Feb 6, 2014 at 8:41 AM, James Hogan <james.hogan@imgtec.com> wrote:
> Hi Rob,
>
> On 06/02/14 14:33, Rob Herring wrote:
>> On Fri, Jan 17, 2014 at 7:58 AM, James Hogan <james.hogan@imgtec.com> wrote:
>>> +Required properties:
>>> +- compatible: Should be "img,ir1"
>>
>> Kind of short for a name. I don't have anything much better, but how
>> about img,ir-rev1.
>
> Okay, that sounds reasonable.
>
>>> +Optional properties:
>>> +- clocks: List of clock specifiers as described in standard
>>> + clock bindings.
>>> +- clock-names: List of clock names corresponding to the clocks
>>> + specified in the clocks property.
>>> + Accepted clock names are:
>>> + "core": Core clock (defaults to 32.768KHz if omitted).
>>> + "sys": System side (fast) clock.
>>> + "mod": Power modulation clock.
>>
>> You need to define the order of clocks including how they are
>> interpreted with different number of clocks (not relying on the name).
>
> Would it be sufficient to specify that "clock-names" is required if
> "clocks" is provided (i.e. unnamed clocks aren't used), or is there some
> other reason that clock-names shouldn't be relied upon?
irq-names, reg-names, clock-names, etc. are considered optional to
their associated property and the order is supposed to be defined.
clock-names is a bit different in that clk_get needs a name, so it
effectively is required by Linux when there is more than 1 clock.
Really, we should fix Linux.
Regardless, my other point is still valid. A given h/w block has a
fixed number of clocks. You may have them all connected to the same
source in some cases, but that does not change the number of inputs.
Defining what are the valid combinations needs to be done. Seems like
this could be:
<none> - default to 32KHz
<core> - only a "baud" clock
<core>, <sys>, <mod> - all clocks
Rob
^ permalink raw reply
* [PATCH v3 5/5] ARM: sun7i: dt: Add bindings for USB clocks
From: Hans de Goede @ 2014-02-07 14:32 UTC (permalink / raw)
To: Emilio López, Mike Turquette
Cc: Maxime Ripard, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Roman Byshko, Hans de Goede
In-Reply-To: <1391783553-8096-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/arm/boot/dts/sun7i-a20.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 316cab8..6550e07c 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -289,6 +289,15 @@
clock-output-names = "ir1";
};
+ usb_clk: clk@01c200cc {
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ compatible = "allwinner,sun4i-usb-clk";
+ reg = <0x01c200cc 0x4>;
+ clocks = <&pll6 1>;
+ clock-output-names = "usb_ohci0", "usb_ohci1", "usb_phy";
+ };
+
spi3_clk: clk@01c200d4 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-mod0-clk";
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 4/5] ARM: sun5i: dt: Add bindings for USB clocks
From: Hans de Goede @ 2014-02-07 14:32 UTC (permalink / raw)
To: Emilio López, Mike Turquette
Cc: Maxime Ripard, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Roman Byshko, Hans de Goede
In-Reply-To: <1391783553-8096-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/arm/boot/dts/sun5i-a10s.dtsi | 9 +++++++++
arch/arm/boot/dts/sun5i-a13.dtsi | 9 +++++++++
2 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 38d01bd..2ed7429 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -264,6 +264,15 @@
clock-output-names = "ir0";
};
+ usb_clk: clk@01c200cc {
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ compatible = "allwinner,sun5i-a13-usb-clk";
+ reg = <0x01c200cc 0x4>;
+ clocks = <&pll6 1>;
+ clock-output-names = "usb_ohci0", "usb_phy";
+ };
+
mbus_clk: clk@01c2015c {
#clock-cells = <0>;
compatible = "allwinner,sun4i-mod0-clk";
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index ddd39d3..30ece67 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -261,6 +261,15 @@
clock-output-names = "ir0";
};
+ usb_clk: clk@01c200cc {
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ compatible = "allwinner,sun5i-a13-usb-clk";
+ reg = <0x01c200cc 0x4>;
+ clocks = <&pll6 1>;
+ clock-output-names = "usb_ohci0", "usb_phy";
+ };
+
mbus_clk: clk@01c2015c {
#clock-cells = <0>;
compatible = "allwinner,sun4i-mod0-clk";
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 3/5] ARM: sun4i: dt: Add bindings for USB clocks
From: Hans de Goede @ 2014-02-07 14:32 UTC (permalink / raw)
To: Emilio López, Mike Turquette
Cc: Maxime Ripard, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Roman Byshko, Hans de Goede
In-Reply-To: <1391783553-8096-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
arch/arm/boot/dts/sun4i-a10.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index ebb4cd0..c57df3e 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -301,6 +301,15 @@
clock-output-names = "ir1";
};
+ usb_clk: clk@01c200cc {
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ compatible = "allwinner,sun4i-usb-clk";
+ reg = <0x01c200cc 0x4>;
+ clocks = <&pll6 1>;
+ clock-output-names = "usb_ohci0", "usb_ohci1", "usb_phy";
+ };
+
spi3_clk: clk@01c200d4 {
#clock-cells = <0>;
compatible = "allwinner,sun4i-mod0-clk";
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 2/5] clk: sunxi: Add USB clock register defintions
From: Hans de Goede @ 2014-02-07 14:32 UTC (permalink / raw)
To: Emilio López, Mike Turquette
Cc: Maxime Ripard, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Roman Byshko, Hans de Goede
In-Reply-To: <1391783553-8096-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
From: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Add register definitions for the usb-clk register found on sun4i, sun5i and
sun7i SoCs.
Signed-off-by: Roman Byshko <rbyshko-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/clock/sunxi.txt | 5 +++++
drivers/clk/sunxi/clk-sunxi.c | 12 ++++++++++++
2 files changed, 17 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 27f19f1..e368a86c 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -38,6 +38,8 @@ Required properties:
"allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
"allwinner,sun7i-a20-out-clk" - for the external output clocks
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
+ "allwinner,sun4i-usb-clk" - for usb gates + resets on A10 / A20
+ "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
Required properties for all clocks:
- reg : shall be the control register address for the clock.
@@ -54,6 +56,9 @@ Required properties for all clocks:
For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
dummy clocks at 25 MHz and 125 MHz, respectively. See example.
+And "allwinner,*-usb-clk" clocks also require:
+- reset-cells : shall be set to 1
+
Clock consumers should specify the desired clocks they use with a
"clocks" phandle cell. Consumers that are using a gated clock should
provide an additional ID in their clock property. This ID is the
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 1e15e4c..3ba1402 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -910,6 +910,16 @@ static const struct gates_data sun4i_ahb_gates_data __initconst = {
.mask = {0x7F77FFF, 0x14FB3F},
};
+static const struct gates_data sun4i_usb_gates_data __initconst = {
+ .mask = {0x1C0},
+ .reset_mask = 0x07,
+};
+
+static const struct gates_data sun5i_a13_usb_gates_data __initconst = {
+ .mask = {0x140},
+ .reset_mask = 0x03,
+};
+
static const struct gates_data sun5i_a10s_ahb_gates_data __initconst = {
.mask = {0x147667e7, 0x185915},
};
@@ -1257,6 +1267,8 @@ static const struct of_device_id clk_gates_match[] __initconst = {
{.compatible = "allwinner,sun6i-a31-apb1-gates-clk", .data = &sun6i_a31_apb1_gates_data,},
{.compatible = "allwinner,sun7i-a20-apb1-gates-clk", .data = &sun7i_a20_apb1_gates_data,},
{.compatible = "allwinner,sun6i-a31-apb2-gates-clk", .data = &sun6i_a31_apb2_gates_data,},
+ {.compatible = "allwinner,sun4i-usb-clk", .data = &sun4i_usb_gates_data,},
+ {.compatible = "allwinner,sun5i-a13-usb-clk", .data = &sun5i_a13_usb_gates_data,},
{}
};
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 1/5] clk: sunxi: Add support for USB clock-register reset bits
From: Hans de Goede @ 2014-02-07 14:32 UTC (permalink / raw)
To: Emilio López, Mike Turquette
Cc: Maxime Ripard, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Hans de Goede
In-Reply-To: <1391783553-8096-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
The usb-clk register is special in that it not only contains clk gate bits,
but also has a few reset bits. This commit adds support for this by allowing
gates type sunxi clks to also register a reset controller.
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
drivers/clk/sunxi/clk-sunxi.c | 71 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 64bda21..1e15e4c 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -18,6 +18,7 @@
#include <linux/clkdev.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <linux/reset-controller.h>
#include "clk-factors.h"
@@ -838,6 +839,59 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
/**
+ * sunxi_gates_reset... - reset bits in leaf gate clk registers handling
+ */
+
+struct gates_reset_data {
+ void __iomem *reg;
+ spinlock_t *lock;
+ struct reset_controller_dev rcdev;
+};
+
+static int sunxi_gates_reset_assert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct gates_reset_data *data = container_of(rcdev,
+ struct gates_reset_data,
+ rcdev);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(data->lock, flags);
+
+ reg = readl(data->reg);
+ writel(reg & ~BIT(id), data->reg);
+
+ spin_unlock_irqrestore(data->lock, flags);
+
+ return 0;
+}
+
+static int sunxi_gates_reset_deassert(struct reset_controller_dev *rcdev,
+ unsigned long id)
+{
+ struct gates_reset_data *data = container_of(rcdev,
+ struct gates_reset_data,
+ rcdev);
+ unsigned long flags;
+ u32 reg;
+
+ spin_lock_irqsave(data->lock, flags);
+
+ reg = readl(data->reg);
+ writel(reg | BIT(id), data->reg);
+
+ spin_unlock_irqrestore(data->lock, flags);
+
+ return 0;
+}
+
+static struct reset_control_ops sunxi_gates_reset_ops = {
+ .assert = sunxi_gates_reset_assert,
+ .deassert = sunxi_gates_reset_deassert,
+};
+
+/**
* sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
*/
@@ -845,6 +899,7 @@ static void __init sunxi_divider_clk_setup(struct device_node *node,
struct gates_data {
DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
+ u32 reset_mask;
};
static const struct gates_data sun4i_axi_gates_data __initconst = {
@@ -915,6 +970,7 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
struct gates_data *data)
{
struct clk_onecell_data *clk_data;
+ struct gates_reset_data *reset_data;
const char *clk_parent;
const char *clk_name;
void *reg;
@@ -958,6 +1014,21 @@ static void __init sunxi_gates_clk_setup(struct device_node *node,
clk_data->clk_num = i;
of_clk_add_provider(node, of_clk_src_onecell_get, clk_data);
+
+ /* Register a reset controler for gates with reset bits */
+ if (data->reset_mask == 0)
+ return;
+
+ reset_data = kzalloc(sizeof(*reset_data), GFP_KERNEL);
+ if (!reset_data)
+ return;
+
+ reset_data->reg = reg;
+ reset_data->lock = &clk_lock;
+ reset_data->rcdev.nr_resets = __fls(data->reset_mask) + 1;
+ reset_data->rcdev.ops = &sunxi_gates_reset_ops;
+ reset_data->rcdev.of_node = node;
+ reset_controller_register(&reset_data->rcdev);
}
--
1.8.4.2
^ permalink raw reply related
* [PATCH v3 0/5] clk: sunxi usb clks support
From: Hans de Goede @ 2014-02-07 14:32 UTC (permalink / raw)
To: Emilio López, Mike Turquette
Cc: Maxime Ripard, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
Hi All,
Here is v3 of my sunxi usb clks support series.
Changes since v2:
-rename the compatibilty strings from foo-usb-gates-clk to foo-usb-clk
Note the dts bits (patches 3-5) of this series depends on Chen-Yu Tsai's clk
rename series.
Emilio, should Mike pick patches 1-2 up directly, or should they go through
your tree?
Maxime, can you please add patches 3-5 to your dts tree ? Assuming that
wens clk rename patches are already there.
Thanks & Regards,
Hans
^ permalink raw reply
* Re: Devicetree Maintenance in barebox
From: Jason Cooper @ 2014-02-07 14:10 UTC (permalink / raw)
To: Sascha Hauer, Grant Likely, Ian Campbell
Cc: barebox-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140207071332.GE16215-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Sascha,
+ Grant Likely, Ian Campbell, devicetree ML
This discussion started on the barebox bootloader mailinglist
On Fri, Feb 07, 2014 at 08:13:32AM +0100, Sascha Hauer wrote:
> It's becoming more obvious that devicetree maintenance is painful
> because we have to sync them to the kernel regularly. My hope was that
> this would get simpler once the devicetrees get their own repository
> outside the kernel, but it seems that won't happen anytime soon.
hmm. Ian Campbell has a tree he is working on:
git://xenbits.xen.org/people/ianc/device-tree-rebasing.git
Also, In the DT meeting earlier this week, Grant Likely said he has the
request in to create a separate mailinglist for collaboration between
the different devicetree users (BSD, Linux, etc).
> So my current idea to continue with barebox devicetrees is:
>
> - Maintain a kernel branch which has all devicetree changes we need in
> barebox in a clean step-by-step series
> - rebase this branch regularly on the newer kernel
> - Copy the resulting devicetrees to barebox
>
> The upside is that we have up to date devicetrees in barebox without
> having to resync them by hand on a per SoC basis. Of course this also
> means that we lose the devicetree history and breakage may be introduced
> with some huge commits saying "Update devicetrees to Linux-3.x".
>
> Any better ideas? I think we have to do something.
I think the proper solution will percolate out of the first
cross-project discussions on the new ML.
imho, the goal is to not have any project tied to a specific version of
the devicetree. iow, we don't break backwards compatibility in the
devicetrees, and projects should revert to default behavior if new dt
parameters are missing. This means Linux and BSD shouldn't need to keep
a current copy of the devicetree in their trees. However, building the
bootloader is a different animal. It needs to provide the dt blob...
Definitely fodder for the new ML.
Grant, can you please add Sascha to the list of folks to notify when the
new ML is ready?
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/4] Regulators: TPS65218: Add Regulator driver for TPS65218 PMIC
From: Keerthy @ 2014-02-07 13:58 UTC (permalink / raw)
To: Keerthy
Cc: rob.herring, pawel.moll, mark.rutland, swarren, ijc+devicetree,
rob, sameo, lee.jones, grant.likely, lgirdwood, broonie,
devicetree, linux-doc, linux-kernel, linux-omap
In-Reply-To: <1391665814-18814-4-git-send-email-j-keerthy@ti.com>
Hi Mark,
On Thursday 06 February 2014 11:20 AM, Keerthy wrote:
> This patch adds support for TPS65218 PMIC regulators.
>
> The regulators set consists of 6 DCDCs and 1 LDO. The output
> voltages are configurable and are meant to supply power to the
> main processor and other components.
If there are no further comments on this could you
please pull this?
Regards,
Keerthy
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
> drivers/regulator/Kconfig | 9 +
> drivers/regulator/Makefile | 1 +
> drivers/regulator/tps65218-regulator.c | 304 ++++++++++++++++++++++++++++++++
> 3 files changed, 314 insertions(+)
> create mode 100644 drivers/regulator/tps65218-regulator.c
>
> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
> index 6a79328..b05da880 100644
> --- a/drivers/regulator/Kconfig
> +++ b/drivers/regulator/Kconfig
> @@ -513,6 +513,15 @@ config REGULATOR_TPS65217
> voltage regulators. It supports software based voltage control
> for different voltage domains
>
> +config REGULATOR_TPS65218
> + tristate "TI TPS65218 Power regulators"
> + depends on MFD_TPS65218
> + help
> + This driver supports TPS65218 voltage regulator chips. TPS65218
> + provides six step-down converters and one general-purpose LDO
> + voltage regulators. It supports software based voltage control
> + for different voltage domains
> +
> config REGULATOR_TPS6524X
> tristate "TI TPS6524X Power regulators"
> depends on SPI
> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
> index 979f9dd..ba801a5 100644
> --- a/drivers/regulator/Makefile
> +++ b/drivers/regulator/Makefile
> @@ -67,6 +67,7 @@ obj-$(CONFIG_REGULATOR_TPS65023) += tps65023-regulator.o
> obj-$(CONFIG_REGULATOR_TPS6507X) += tps6507x-regulator.o
> obj-$(CONFIG_REGULATOR_TPS65090) += tps65090-regulator.o
> obj-$(CONFIG_REGULATOR_TPS65217) += tps65217-regulator.o
> +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
> diff --git a/drivers/regulator/tps65218-regulator.c b/drivers/regulator/tps65218-regulator.c
> new file mode 100644
> index 0000000..39fb189
> --- /dev/null
> +++ b/drivers/regulator/tps65218-regulator.c
> @@ -0,0 +1,304 @@
> +/*
> + * tps65218-regulator.c
> + *
> + * Regulator driver for TPS65218 PMIC
> + *
> + * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * 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.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/device.h>
> +#include <linux/init.h>
> +#include <linux/err.h>
> +#include <linux/platform_device.h>
> +#include <linux/of_device.h>
> +#include <linux/regulator/of_regulator.h>
> +#include <linux/regulator/driver.h>
> +#include <linux/regulator/machine.h>
> +#include <linux/mfd/tps65218.h>
> +
> +static unsigned int tps65218_ramp_delay = 4000;
> +
> +enum tps65218_regulators { DCDC1, DCDC2, DCDC3, DCDC4, DCDC5, DCDC6, LDO1 };
> +
> +#define TPS65218_REGULATOR(_name, _id, _ops, _n, _vr, _vm, _er, _em, _t, \
> + _lr, _nlr) \
> + { \
> + .name = _name, \
> + .id = _id, \
> + .ops = &_ops, \
> + .n_voltages = _n, \
> + .type = REGULATOR_VOLTAGE, \
> + .owner = THIS_MODULE, \
> + .vsel_reg = _vr, \
> + .vsel_mask = _vm, \
> + .enable_reg = _er, \
> + .enable_mask = _em, \
> + .volt_table = _t, \
> + .linear_ranges = _lr, \
> + .n_linear_ranges = _nlr, \
> + } \
> +
> +#define TPS65218_INFO(_id, _nm, _min, _max) \
> + { \
> + .id = _id, \
> + .name = _nm, \
> + .min_uV = _min, \
> + .max_uV = _max, \
> + }
> +
> +static const struct regulator_linear_range dcdc1_dcdc2_ranges[] = {
> + REGULATOR_LINEAR_RANGE(850000, 0x0, 0x32, 10000),
> + REGULATOR_LINEAR_RANGE(1375000, 0x33, 0x3f, 25000),
> +};
> +
> +static const struct regulator_linear_range ldo1_dcdc3_ranges[] = {
> + REGULATOR_LINEAR_RANGE(900000, 0x0, 0x1a, 25000),
> + REGULATOR_LINEAR_RANGE(1600000, 0x1b, 0x3f, 50000),
> +};
> +
> +static const struct regulator_linear_range dcdc4_ranges[] = {
> + REGULATOR_LINEAR_RANGE(1175000, 0x0, 0xf, 25000),
> + REGULATOR_LINEAR_RANGE(1550000, 0x10, 0x34, 50000),
> +};
> +
> +static struct tps_info tps65218_pmic_regs[] = {
> + TPS65218_INFO(0, "DCDC1", 850000, 167500),
> + TPS65218_INFO(1, "DCDC2", 850000, 1675000),
> + TPS65218_INFO(2, "DCDC3", 900000, 3400000),
> + TPS65218_INFO(3, "DCDC4", 1175000, 3400000),
> + TPS65218_INFO(4, "DCDC5", 1000000, 1000000),
> + TPS65218_INFO(5, "DCDC6", 1800000, 1800000),
> + TPS65218_INFO(6, "LDO1", 900000, 3400000),
> +};
> +
> +#define TPS65218_OF_MATCH(comp, label) \
> + { \
> + .compatible = comp, \
> + .data = &label, \
> + }
> +
> +static const struct of_device_id tps65218_of_match[] = {
> + TPS65218_OF_MATCH("ti,tps65218-dcdc1", tps65218_pmic_regs[DCDC1]),
> + TPS65218_OF_MATCH("ti,tps65218-dcdc2", tps65218_pmic_regs[DCDC2]),
> + TPS65218_OF_MATCH("ti,tps65218-dcdc3", tps65218_pmic_regs[DCDC3]),
> + TPS65218_OF_MATCH("ti,tps65218-dcdc4", tps65218_pmic_regs[DCDC4]),
> + TPS65218_OF_MATCH("ti,tps65218-dcdc5", tps65218_pmic_regs[DCDC5]),
> + TPS65218_OF_MATCH("ti,tps65218-dcdc6", tps65218_pmic_regs[DCDC6]),
> + TPS65218_OF_MATCH("ti,tps65218-ldo1", tps65218_pmic_regs[LDO1]),
> +};
> +MODULE_DEVICE_TABLE(of, tps65218_of_match);
> +
> +static int tps65218_pmic_set_voltage_sel(struct regulator_dev *dev,
> + unsigned selector)
> +{
> + int ret;
> + struct tps65218 *tps = rdev_get_drvdata(dev);
> + unsigned int rid = rdev_get_id(dev);
> +
> + /* Set the voltage based on vsel value and write protect level is 2 */
> + ret = tps65218_set_bits(tps, dev->desc->vsel_reg, dev->desc->vsel_mask,
> + selector, TPS65218_PROTECT_L1);
> +
> + /* Set GO bit for DCDC1/2 to initiate voltage transistion */
> + switch (rid) {
> + case TPS65218_DCDC_1:
> + case TPS65218_DCDC_2:
> + ret = tps65218_set_bits(tps, TPS65218_REG_CONTRL_SLEW_RATE,
> + TPS65218_SLEW_RATE_GO,
> + TPS65218_SLEW_RATE_GO,
> + TPS65218_PROTECT_L1);
> + break;
> + }
> +
> + return ret;
> +}
> +
> +static int tps65218_pmic_enable(struct regulator_dev *dev)
> +{
> + struct tps65218 *tps = rdev_get_drvdata(dev);
> + unsigned int rid = rdev_get_id(dev);
> +
> + if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
> + return -EINVAL;
> +
> + /* Enable the regulator and password protection is level 1 */
> + return tps65218_set_bits(tps, dev->desc->enable_reg,
> + dev->desc->enable_mask, dev->desc->enable_mask,
> + TPS65218_PROTECT_L1);
> +}
> +
> +static int tps65218_pmic_disable(struct regulator_dev *dev)
> +{
> + struct tps65218 *tps = rdev_get_drvdata(dev);
> + unsigned int rid = rdev_get_id(dev);
> +
> + if (rid < TPS65218_DCDC_1 || rid > TPS65218_LDO_1)
> + return -EINVAL;
> +
> + /* Disable the regulator and password protection is level 1 */
> + return tps65218_clear_bits(tps, dev->desc->enable_reg,
> + dev->desc->enable_mask, TPS65218_PROTECT_L1);
> +}
> +
> +static int tps65218_set_voltage_time_sel(struct regulator_dev *rdev,
> + unsigned int old_selector, unsigned int new_selector)
> +{
> + int old_uv, new_uv;
> +
> + old_uv = regulator_list_voltage_linear_range(rdev, old_selector);
> + if (old_uv < 0)
> + return old_uv;
> +
> + new_uv = regulator_list_voltage_linear_range(rdev, new_selector);
> + if (new_uv < 0)
> + return new_uv;
> +
> + return DIV_ROUND_UP(abs(old_uv - new_uv), tps65218_ramp_delay);
> +}
> +
> +/* Operations permitted on DCDC1, DCDC2 */
> +static struct regulator_ops tps65218_dcdc12_ops = {
> + .is_enabled = regulator_is_enabled_regmap,
> + .enable = tps65218_pmic_enable,
> + .disable = tps65218_pmic_disable,
> + .get_voltage_sel = regulator_get_voltage_sel_regmap,
> + .set_voltage_sel = tps65218_pmic_set_voltage_sel,
> + .list_voltage = regulator_list_voltage_linear_range,
> + .map_voltage = regulator_map_voltage_linear_range,
> + .set_voltage_time_sel = tps65218_set_voltage_time_sel,
> +};
> +
> +/* Operations permitted on DCDC3, DCDC4 and LDO1 */
> +static struct regulator_ops tps65218_ldo1_dcdc34_ops = {
> + .is_enabled = regulator_is_enabled_regmap,
> + .enable = tps65218_pmic_enable,
> + .disable = tps65218_pmic_disable,
> + .get_voltage_sel = regulator_get_voltage_sel_regmap,
> + .set_voltage_sel = tps65218_pmic_set_voltage_sel,
> + .list_voltage = regulator_list_voltage_linear_range,
> + .map_voltage = regulator_map_voltage_linear_range,
> +};
> +
> +/* Operations permitted on DCDC5, DCDC6 */
> +static struct regulator_ops tps65218_dcdc56_pmic_ops = {
> + .is_enabled = regulator_is_enabled_regmap,
> + .enable = tps65218_pmic_enable,
> + .disable = tps65218_pmic_disable,
> +};
> +
> +static const struct regulator_desc regulators[] = {
> + TPS65218_REGULATOR("DCDC1", TPS65218_DCDC_1, tps65218_dcdc12_ops, 64,
> + TPS65218_REG_CONTROL_DCDC1,
> + TPS65218_CONTROL_DCDC1_MASK,
> + TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC1_EN, NULL,
> + dcdc1_dcdc2_ranges, 2),
> + TPS65218_REGULATOR("DCDC2", TPS65218_DCDC_2, tps65218_dcdc12_ops, 64,
> + TPS65218_REG_CONTROL_DCDC2,
> + TPS65218_CONTROL_DCDC2_MASK,
> + TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC2_EN, NULL,
> + dcdc1_dcdc2_ranges, 2),
> + TPS65218_REGULATOR("DCDC3", TPS65218_DCDC_3, tps65218_ldo1_dcdc34_ops,
> + 64, TPS65218_REG_CONTROL_DCDC3,
> + TPS65218_CONTROL_DCDC3_MASK, TPS65218_REG_ENABLE1,
> + TPS65218_ENABLE1_DC3_EN, NULL,
> + ldo1_dcdc3_ranges, 2),
> + TPS65218_REGULATOR("DCDC4", TPS65218_DCDC_4, tps65218_ldo1_dcdc34_ops,
> + 53, TPS65218_REG_CONTROL_DCDC4,
> + TPS65218_CONTROL_DCDC4_MASK,
> + TPS65218_REG_ENABLE1, TPS65218_ENABLE1_DC4_EN, NULL,
> + dcdc4_ranges, 2),
> + TPS65218_REGULATOR("DCDC5", TPS65218_DCDC_5, tps65218_dcdc56_pmic_ops,
> + 1, -1, -1, TPS65218_REG_ENABLE1,
> + TPS65218_ENABLE1_DC5_EN, NULL, NULL, 0),
> + TPS65218_REGULATOR("DCDC6", TPS65218_DCDC_6, tps65218_dcdc56_pmic_ops,
> + 1, -1, -1, TPS65218_REG_ENABLE1,
> + TPS65218_ENABLE1_DC6_EN, NULL, NULL, 0),
> + TPS65218_REGULATOR("LDO1", TPS65218_LDO_1, tps65218_ldo1_dcdc34_ops, 64,
> + TPS65218_REG_CONTROL_DCDC4,
> + TPS65218_CONTROL_LDO1_MASK, TPS65218_REG_ENABLE2,
> + TPS65218_ENABLE2_LDO1_EN, NULL, ldo1_dcdc3_ranges,
> + 2),
> +};
> +
> +static int tps65218_regulator_probe(struct platform_device *pdev)
> +{
> + struct tps65218 *tps = dev_get_drvdata(pdev->dev.parent);
> + struct regulator_init_data *init_data;
> + const struct tps_info *template;
> + struct regulator_dev *rdev;
> + const struct of_device_id *match;
> + struct regulator_config config = { };
> + int id;
> +
> + match = of_match_device(tps65218_of_match, &pdev->dev);
> + if (match) {
> + template = match->data;
> + id = template->id;
> + init_data = of_get_regulator_init_data(&pdev->dev,
> + pdev->dev.of_node);
> + } else {
> + return -ENODEV;
> + }
> +
> + platform_set_drvdata(pdev, tps);
> +
> + tps->info[id] = &tps65218_pmic_regs[id];
> + config.dev = &pdev->dev;
> + config.init_data = init_data;
> + config.driver_data = tps;
> + config.regmap = tps->regmap;
> +
> + rdev = devm_regulator_register(&pdev->dev, ®ulators[id], &config);
> + if (IS_ERR(rdev)) {
> + dev_err(tps->dev, "failed to register %s regulator\n",
> + pdev->name);
> + return PTR_ERR(rdev);
> + }
> +
> + /* Save regulator */
> + tps->rdev[id] = rdev;
> +
> + return 0;
> +}
> +
> +static int tps65218_regulator_remove(struct platform_device *pdev)
> +{
> + struct tps65218 *tps = platform_get_drvdata(pdev);
> + const struct of_device_id *match;
> + const struct tps_info *template;
> +
> + match = of_match_device(tps65218_of_match, &pdev->dev);
> + template = match->data;
> + regulator_unregister(tps->rdev[template->id]);
> + platform_set_drvdata(pdev, NULL);
> +
> + return 0;
> +}
> +
> +static struct platform_driver tps65218_regulator_driver = {
> + .driver = {
> + .name = "tps65218-pmic",
> + .owner = THIS_MODULE,
> + .of_match_table = of_match_ptr(tps65218_of_match),
> + },
> + .probe = tps65218_regulator_probe,
> + .remove = tps65218_regulator_remove,
> +};
> +
> +module_platform_driver(tps65218_regulator_driver);
> +
> +MODULE_AUTHOR("J Keerthy <j-keerthy@ti.com>");
> +MODULE_DESCRIPTION("TPS65218 voltage regulator driver");
> +MODULE_ALIAS("platform:tps65218-pmic");
> +MODULE_LICENSE("GPL v2");
^ permalink raw reply
* Re: [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
From: Hans de Goede @ 2014-02-07 13:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Emilio Lopez, Mike Turquette, Philipp Zabel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Roman Byshko
In-Reply-To: <20140207134831.GJ3192@lukather>
Hi,
On 02/07/2014 02:48 PM, Maxime Ripard wrote:
> On Tue, Feb 04, 2014 at 11:14:44AM +0100, Hans de Goede wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Hi,
>>
>> On 02/04/2014 10:40 AM, Maxime Ripard wrote:
>>> Hi Hans,
>>>
>>> On Tue, Jan 28, 2014 at 11:00:45AM +0100, Hans de Goede wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>>>>
>>>> Hi,
>>>>
>>>> On 01/28/2014 10:44 AM, Maxime Ripard wrote:
>>>>> On Mon, Jan 27, 2014 at 03:54:14PM +0100, Hans de Goede wrote:
>>>>>>>> "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13
>>>>>>>
>>>>>>> Maybe we can just remove the gates from there? Even though they are gates, they are also (a bit) more than that.
>>>>>>
>>>>>> To be clear you mean s/usb-gates-clk/usb-clk/ right ?
>>>>>
>>>>> Yep, exactly
>>>>>
>>>>>>> I guess that means that we will have the OHCI0 gate declared with <&...-gates-clk 6>, while it's actually the first gate for this clock?
>>>>>>
>>>>>> Correct.
>>>>>>
>>>>>>> Maybe introducing an offset field in the gates_data would be a good idea, so that we always start from indexing the gates from 0 in the DT?
>>>>>>
>>>>>> Well for the other "gates" type clks we also have holes in the range, and we always refer to the clk with the bit number in the reg as the clock-cell value.
>>>>>
>>>>> Yes, we have holes, but I see two majors differences here: - the other gates are just gates, while the usb clocks are a bit more than that.
>>>>
>>>> The usb-clk registers contain more then that, but the bits we are talking about now are gates.
>>>>
>>>>> - the other gates' gating bits thus all start at bit 0, while - here, since it's kind of a "mixed" clock, the gating bits start - at bit 6 (on the A20 at least)
>>>>
>>>> Right, still I believe that the consistent thing to do is keeping the bit-number for the bit in the register controlling the gate as the specifier. When adding new dts entries / reviewing existing ones I'm used to matching the specifier to the bit-nr in the data-sheet, I think making things different just for this one register is counter productive.
>>>
>>> And if you turn it the other way around, it would be inconsistent that all gates indices start at 0, and we would start at 6 here :)
>>
>> I think the problem here is that you see the specifier part of the clk
>> phandle as an index, which it is not. All devicetree docs / code talks
>> about specifiers or arguments not indexes. Once you stop seeing this as
>> an index, you will hopefully also stop insisting this needs to
>> start at 0 :)
>>
>> Also note that it already is not an index for existing sunxi clks which have
>> cells != 0, as there are holes in the bits used in the gates registers and
>> calling the specifier an index suggest we're dealing with an array, and
>> arrays never have holes.
>>
>> The clk specifier as currently used in sunxi clks is a 1:1 mapping of the
>> gate register bit numbers, as is clearly documented in ie:
>> Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
>> Where the datasheet is referenced as the source for (most) of the values
>> to put in the specifier.
>>
>> My biggest objection is that this would loose 1:1 mapping we currently
>> have between the specifier and bit-nr in the register, which really is
>> convenient when writing new dts bindings.
>>
>> When we add an offset users will need to first lookup which clk they need in
>> the datasheet and then look at both the dts bindings doc to find how this is
>> mapped to the specifier. In my experience such an extra level of indirection
>> in documentation is a PITA, and all that just so that some random number
>> (it is not an index!) can start at 0 ?
>>
>> To me adding an offset here and making the clk gates different form all
>> our other clock gates just feels wrong.
>
> Emilio pretty much share your feeling. I won't get in the way then :)
>
> I only had the compatible name comment left then.
Yes I've already fixed that in my latest sunxi-devel tree:
https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel
Which is also rebased to 3.14-rc1 for those interested, I'll resend
the usb-clk patches with this + Emilio's reverted remark fixed soon-ish
then.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH v2 2/5] clk: sunxi: Add USB clock register defintions
From: Maxime Ripard @ 2014-02-07 13:48 UTC (permalink / raw)
To: Hans de Goede
Cc: Emilio Lopez, Mike Turquette, Philipp Zabel,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Roman Byshko
In-Reply-To: <52F0BD94.1060601-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4054 bytes --]
On Tue, Feb 04, 2014 at 11:14:44AM +0100, Hans de Goede wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> On 02/04/2014 10:40 AM, Maxime Ripard wrote:
> > Hi Hans,
> >
> > On Tue, Jan 28, 2014 at 11:00:45AM +0100, Hans de Goede wrote:
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
> >>
> >> Hi,
> >>
> >> On 01/28/2014 10:44 AM, Maxime Ripard wrote:
> >>> On Mon, Jan 27, 2014 at 03:54:14PM +0100, Hans de Goede wrote:
> >>>>>> "allwinner,sun5i-a13-usb-gates-clk" - for usb gates + resets on A13
> >>>>>
> >>>>> Maybe we can just remove the gates from there? Even though they are gates, they are also (a bit) more than that.
> >>>>
> >>>> To be clear you mean s/usb-gates-clk/usb-clk/ right ?
> >>>
> >>> Yep, exactly
> >>>
> >>>>> I guess that means that we will have the OHCI0 gate declared with <&...-gates-clk 6>, while it's actually the first gate for this clock?
> >>>>
> >>>> Correct.
> >>>>
> >>>>> Maybe introducing an offset field in the gates_data would be a good idea, so that we always start from indexing the gates from 0 in the DT?
> >>>>
> >>>> Well for the other "gates" type clks we also have holes in the range, and we always refer to the clk with the bit number in the reg as the clock-cell value.
> >>>
> >>> Yes, we have holes, but I see two majors differences here: - the other gates are just gates, while the usb clocks are a bit more than that.
> >>
> >> The usb-clk registers contain more then that, but the bits we are talking about now are gates.
> >>
> >>> - the other gates' gating bits thus all start at bit 0, while - here, since it's kind of a "mixed" clock, the gating bits start - at bit 6 (on the A20 at least)
> >>
> >> Right, still I believe that the consistent thing to do is keeping the bit-number for the bit in the register controlling the gate as the specifier. When adding new dts entries / reviewing existing ones I'm used to matching the specifier to the bit-nr in the data-sheet, I think making things different just for this one register is counter productive.
> >
> > And if you turn it the other way around, it would be inconsistent that all gates indices start at 0, and we would start at 6 here :)
>
> I think the problem here is that you see the specifier part of the clk
> phandle as an index, which it is not. All devicetree docs / code talks
> about specifiers or arguments not indexes. Once you stop seeing this as
> an index, you will hopefully also stop insisting this needs to
> start at 0 :)
>
> Also note that it already is not an index for existing sunxi clks which have
> cells != 0, as there are holes in the bits used in the gates registers and
> calling the specifier an index suggest we're dealing with an array, and
> arrays never have holes.
>
> The clk specifier as currently used in sunxi clks is a 1:1 mapping of the
> gate register bit numbers, as is clearly documented in ie:
> Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
> Where the datasheet is referenced as the source for (most) of the values
> to put in the specifier.
>
> My biggest objection is that this would loose 1:1 mapping we currently
> have between the specifier and bit-nr in the register, which really is
> convenient when writing new dts bindings.
>
> When we add an offset users will need to first lookup which clk they need in
> the datasheet and then look at both the dts bindings doc to find how this is
> mapped to the specifier. In my experience such an extra level of indirection
> in documentation is a PITA, and all that just so that some random number
> (it is not an index!) can start at 0 ?
>
> To me adding an offset here and making the clk gates different form all
> our other clock gates just feels wrong.
Emilio pretty much share your feeling. I won't get in the way then :)
I only had the compatible name comment left then.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
From: Keerthy @ 2014-02-07 13:41 UTC (permalink / raw)
To: Lee Jones
Cc: Keerthy, rob.herring, pawel.moll, mark.rutland, swarren,
ijc+devicetree, rob, sameo, grant.likely, lgirdwood, broonie,
devicetree, linux-doc, linux-kernel, linux-omap
In-Reply-To: <20140207111229.GN14727@lee--X1>
On Friday 07 February 2014 04:42 PM, Lee Jones wrote:
> On Thu, 06 Feb 2014, Keerthy wrote:
>
>> The TPS65218 chip is a power management IC for Portable Navigation Systems
>> and Tablet Computing devices. It contains the following components:
>>
>> - Regulators.
>> - Over Temperature warning and Shut down.
>>
>> This patch adds support for tps65218 mfd device. At this time only
>> the regulator functionality is made available.
>>
>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>> ---
>> drivers/mfd/Kconfig | 15 +++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/tps65218.c | 281 +++++++++++++++++++++++++++++++++++++++++
>> include/linux/mfd/tps65218.h | 284 ++++++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 581 insertions(+)
>> create mode 100644 drivers/mfd/tps65218.c
>> create mode 100644 include/linux/mfd/tps65218.h
> Applied, thanks.
>
Thanks Lee Jones!
^ permalink raw reply
* Re: [PATCH v6 05/19] watchdog: orion: Make sure the watchdog is initially stopped
From: Guenter Roeck @ 2014-02-07 13:38 UTC (permalink / raw)
To: Ezequiel Garcia, Jason Gunthorpe
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA, Wim Van Sebroeck,
Jason Cooper, Thomas Petazzoni, Gregory Clement, Lior Amsalem,
Sebastian Hesselbarth, Andrew Lunn
In-Reply-To: <20140207104044.GA11063@localhost>
On 02/07/2014 02:40 AM, Ezequiel Garcia wrote:
> On Thu, Feb 06, 2014 at 06:02:56PM -0800, Guenter Roeck wrote:
>> On 02/06/2014 09:20 AM, Ezequiel Garcia wrote:
>>> Having the watchdog initially fully stopped is important to avoid
>>> any spurious watchdog triggers, in case the registers are not in
>>> its reset state.
>>>
>>> Reviewed-by: Guenter Roeck <linux-0h96xk9xTtrk1uMJSBkQmQ@public.gmane.org>
>>> Tested-by: Sebastian Hesselbarth <sebastian.hesselbarth-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>>> Tested-by: Willy Tarreau <w@1wt.eu>
>>> Signed-off-by: Ezequiel Garcia <ezequiel.garcia-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>>> ---
>>> drivers/watchdog/orion_wdt.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
>>> index 6746033..2dbeee9 100644
>>> --- a/drivers/watchdog/orion_wdt.c
>>> +++ b/drivers/watchdog/orion_wdt.c
>>> @@ -142,6 +142,9 @@ static int orion_wdt_probe(struct platform_device *pdev)
>>> orion_wdt.max_timeout = wdt_max_duration;
>>> watchdog_init_timeout(&orion_wdt, heartbeat, &pdev->dev);
>>>
>>> + /* Let's make sure the watchdog is fully stopped */
>>> + orion_wdt_stop(&orion_wdt);
>>> +
>>
>> Actually we just had that in another driver, and I stumbled over it there.
>>
>> Problem with stopping the watchdog in probe unconditionally is that you can
>> use it to defeat nowayout: unload the module, then load it again,
>> and the watchdog is stopped even if nowayout is true.
>>
>
> Hm... I see.
>
>> Is this really what you want ? Or, in other words, what is the problem
>> you are trying to solve ?
>>
>
> Well, this is related to the discussion about the bootloader not
> reseting the watchdog properly, provoking spurious watchdog triggering.
>
> Jason Gunthorpe explained [1] that we needed a particular sequence:
>
> 1. Disable WDT
> 2. Clear bridge
> 3. Enable WDT
>
> We added the irq handling to satisfy (2), and the watchdog stop for (1).
>
> The watchdog stop was agreed specifically [2].
>
> Ideas?
>
Other drivers assume that if the watchdog is running, it is supposed
to be running. The more common approach in such cases is to ping the
watchdog once to give userspace more time to get ready, but leave
it enabled. So you could check if the watchdog is enabled, and if
it was enabled re-enable it after initialization is complete
(and maybe log a message stating that the watchdog is enabled).
If you don't want to do that, and if you are defeating nowayout
on purpose to fix a problem with a broken bootloader,
you should at least put in comment describing the problem you are
trying to solve, and that you accept breaking nowayout with your fix.
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH RESEND 1/2] spi: qup: Add device tree bindings information
From: Ivan T. Ivanov @ 2014-02-07 13:35 UTC (permalink / raw)
To: Mark Brown
Cc: Grant Likely, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Rob Landley, linux-spi, devicetree, linux-doc,
linux-arm-msm, linux-kernel
In-Reply-To: <20140207131359.GM32298@sirena.org.uk>
On Fri, 2014-02-07 at 13:13 +0000, Mark Brown wrote:
> On Fri, Feb 07, 2014 at 03:00:43PM +0200, Ivan T. Ivanov wrote:
> > On Fri, 2014-02-07 at 12:27 +0000, Mark Brown wrote:
>
> > > Please fix the formatting of this document so the lines are less than 80
> > > columns, it's hard to read as is. Otherwise this is fine.
>
> > File is looking fine in editor with smart tab support
>
> I don't know what "smart tab support" is intended to be in this context
> but whatever it is it's not working well in the e-mail you sent, bear in
> mind that you're looking for a readable patch.
Right. will fix it.
Regards,
Ivan
^ permalink raw reply
* Re: [PATCH v4] gpio: davinci: reuse for keystone soc
From: Sekhar Nori @ 2014-02-07 13:25 UTC (permalink / raw)
To: Linus Walleij, Grygorii Strashko
Cc: Alexandre Courbot,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring,
Santosh Shilimkar,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <CACRpkdbgteBtuwdEn+Bg+kA1JnEHus2FOfTbj-hm5fKBsw7XeA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Linus,
On Thursday 06 February 2014 06:50 PM, Linus Walleij wrote:
> On Wed, Feb 5, 2014 at 4:47 PM, Grygorii Strashko
> <grygorii.strashko-l0cyMroinI0@public.gmane.org> wrote:
>
>> The similar GPIO HW block is used by keystone SoCs as
>> in Davinci SoCs.
>> Hence, reuse Davinci GPIO driver for Keystone taking into
>> account that Keystone contains ARM GIC IRQ controller which
>> is implemented using IRQ Chip.
>>
>> Documentation:
>> http://www.ti.com/lit/ug/sprugv1/sprugv1.pdf
>>
>> Acked-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
>> Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko-l0cyMroinI0@public.gmane.org>
>> ---
>> Changes in v4:
>> - rebased on top of v3.14 +
>> [patch] gpio: davinci: signedness bug in davinci_gpio_irq_setup()
>
> Are you taking this through ARM SoC or is this something
> I should be merging?
Can you please merge this through your tree as there aren't any
dependencies with mach-davinci anymore.
Thanks,
Sekhar
^ permalink raw reply
* Re: [PATCH RESEND 1/2] spi: qup: Add device tree bindings information
From: Mark Brown @ 2014-02-07 13:13 UTC (permalink / raw)
To: Ivan T. Ivanov
Cc: Grant Likely, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Rob Landley, linux-spi, devicetree, linux-doc,
linux-arm-msm, linux-kernel
In-Reply-To: <1391778043.27491.61.camel@iivanov-dev>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
On Fri, Feb 07, 2014 at 03:00:43PM +0200, Ivan T. Ivanov wrote:
> On Fri, 2014-02-07 at 12:27 +0000, Mark Brown wrote:
> > Please fix the formatting of this document so the lines are less than 80
> > columns, it's hard to read as is. Otherwise this is fine.
> File is looking fine in editor with smart tab support
I don't know what "smart tab support" is intended to be in this context
but whatever it is it's not working well in the e-mail you sent, bear in
mind that you're looking for a readable patch.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3] sh_eth: add device tree support
From: Sergei Shtylyov @ 2014-02-07 13:05 UTC (permalink / raw)
To: Simon Horman
Cc: robh+dt, pawel.moll, mark.rutland, grant.likely, devicetree,
linux-sh, ijc+devicetree, galak, nobuhiro.iwamatsu.yj, rob,
linux-doc
In-Reply-To: <20140207012902.GH19799@verge.net.au>
Hello.
On 07-02-2014 5:29, Simon Horman wrote:
>> Add support of the device tree probing for the Renesas SH-Mobile SoCs
>> documenting the device tree binding as necessary.
>> This work is loosely based on the original patch by Nobuhiro Iwamatsu
>> <nobuhiro.iwamatsu.yj@renesas.com>.
>> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Acked-by: Simon Horman <horms+renesas@verge.net.au>
>> ---
>> This patch is against DaveM's 'net-next.git' repo but should also apply to the
>> recent 'renesas.git' repo's 'devel' branch. It assumes the patch documenting all
>> Ethernet bindings in one file to be applied as well.
>> Not posting it to netdev@vger.kernel.org this time, or Dave will scold me. :-)
> I would prefer if such orthogonal dependencies weren't introduced.
> I'm quite fine if you want to refactor things, but from my point
> of view it would be nice to tackle such projects after merging new features.
I don't agree. I didn't want to repeat e.g. all the values for "phy-mode"
prop for the Nth time, hence I suggested that I'd gather all Ethernet props in
the single file first and got a consent from the bindings reviewer.
WBR, Sergei
^ permalink raw reply
* Re: [PATCH RESEND 1/2] spi: qup: Add device tree bindings information
From: Ivan T. Ivanov @ 2014-02-07 13:00 UTC (permalink / raw)
To: Mark Brown
Cc: Grant Likely, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Rob Landley, linux-spi, devicetree, linux-doc,
linux-arm-msm, linux-kernel
In-Reply-To: <20140207122716.GH32298@sirena.org.uk>
On Fri, 2014-02-07 at 12:27 +0000, Mark Brown wrote:
> On Fri, Feb 07, 2014 at 09:43:27AM +0200, Ivan T. Ivanov wrote:
> > From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
> >
> > The Qualcomm Universal Peripheral (QUP) core is an
> > AHB slave that provides a common data path (an output
> > FIFO and an input FIFO) for serial peripheral interface
> > (SPI) mini-core.
>
> Please fix the formatting of this document so the lines are less than 80
> columns, it's hard to read as is. Otherwise this is fine.
File is looking fine in editor with smart tab support
Regards,
Ivan
^ permalink raw reply
* Re: [PATCH v2 1/8] ASoC: da9055: Fix device registration of PMIC and CODEC devices
From: Mark Brown @ 2014-02-07 12:58 UTC (permalink / raw)
To: Lee Jones
Cc: Adam Thomson, alsa-devel, linux-kernel, devicetree, Rob Herring,
Linus Walleij, Dmitry Torokhov, Alessandro Zummo, Guenter Roeck
In-Reply-To: <20140207105657.GL14727@lee--X1>
[-- Attachment #1: Type: text/plain, Size: 912 bytes --]
On Fri, Feb 07, 2014 at 10:56:57AM +0000, Lee Jones wrote:
> > +/*
> > + * DO NOT change the device Ids. The naming is intentionally specific as both
> > + * the PMIC and CODEC parts of this chip are instantiated separately as I2C
> > + * devices (both have configurable I2C addresses, and are to all intents and
> > + * purposes separate). As a result there are specific DA9055 ids for PMIC
> > + * and CODEC, which must be different to operate together.
> > + */
> I'm not sure this comment is required.
They are, we've already had the suffixes removed from both PMIC and
CODEC drivers by people doing code review causing the drivers to fail to
load for several kernel releases (this should be tagged to stable as a
result).
> Most device IDs are named this way.
Having the suffix on a subdevice would be normal but it's not normal for
the primary I2C device, usually you can just put the part number in.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/6] ARM: STi reset controller support
From: srinivas kandagatla @ 2014-02-07 12:54 UTC (permalink / raw)
To: Philipp Zabel
Cc: Mark Rutland, devicetree, Russell King, kernel, Pawel Moll,
Ian Campbell, Olof Johansson, linux-doc, linux-kernel,
stephen.gallimore, Stuart Menefy, Rob Herring, Arnd Bergmann,
Rob Landley, Kumar Gala, Grant Likely, linux-arm-kernel
In-Reply-To: <1391592486.11239.4.camel@pizza.hi.pengutronix.de>
Hi Philipp,
Thankyou for looking at the patches.
On 05/02/14 09:28, Philipp Zabel wrote:
> Hi Srinivas,
>
...
>
> the patchset looks good to me for the soft resets. But for the powerdown
> bits I am wondering whether the reset controller API is the right
> abstraction. Depending on whether those bits really just put the IPs
> into reset or there is some power gating / sequencing involved,
> shouldn't this rather be handled as a set of pm domains?
The hardware name of these control signals into the devices is
slightly unfortunate and a bit misleading. We do not generally
have separate power domains for peripheral devices in our
current STB SoCs, in the sense that the voltage cannot actually be
removed from individual devices. In the USB case we believe the
powerdown signals internally gate off two of the three
incoming clocks to most of the USB controller's logic blocks,
essentially holding the device in a disabled (enable/disable
might have been a better name for the signal) state.
The primary requirement to manipulate these signals is to bring
the device out of its cold boot default powerdown/disabled/reset
(whatever you want to call it) state when the device is probed or
after a SoC wide power loss when resuming from PM_SUSPEND_MEM.
> I see that for example on STiH415 there are both soft resets and
> powerdown bits for USB[012].
Our IPs typically have two or sometimes three signals going into
them, controlled from outside of the IP block itself (typically using
SoC global system configuration registers) that you could view
as "reset-a-like"; that is toggling each of the signals puts the IP
into a state where it is in some way unusable and then back to
being useable again. The reset controller API appeared to be the
natural abstraction for the drivers to be given access to such control
signals, regardless of the precise effect the signals have on the
device's internal state.
With regards to sequencing between these signals; it is the case that
there is a likely sequencing because at least in the USB case it is
thought that the "powerdown" stops the clock going to the reset chain
logic. But we did not see that as an issue as the reset controller
framework allows for multiple named "reset" lines being defined for
a device through its DT attributes. The driver knows which signal
is which and what each does, because it asks for them by name;
therefore, it knows how to impose any required ordering when changing
the state of those signals.
Thanks,
srini
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: s5m8767: Use GPIO for controlling Buck9/eMMC
From: Mark Brown @ 2014-02-07 12:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sangbeom Kim, Liam Girdwood, Samuel Ortiz, Lee Jones,
linux-kernel, devicetree, linux-samsung-soc, Sachin Kamat,
Kyungmin Park, Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <1391776833.16500.1.camel@AMDC1943>
[-- Attachment #1: Type: text/plain, Size: 183 bytes --]
On Fri, Feb 07, 2014 at 01:40:33PM +0100, Krzysztof Kozlowski wrote:
> I can't find these patches in your tree. Did you applied them or am I
> missing something?
They're there now.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/2] regulator: s5m8767: Use GPIO for controlling Buck9/eMMC
From: Krzysztof Kozlowski @ 2014-02-07 12:40 UTC (permalink / raw)
To: Mark Brown
Cc: Sangbeom Kim, Liam Girdwood, Samuel Ortiz, Lee Jones,
linux-kernel, devicetree, linux-samsung-soc, Sachin Kamat,
Kyungmin Park, Marek Szyprowski, Bartlomiej Zolnierkiewicz
In-Reply-To: <20140127202524.GQ11841@sirena.org.uk>
Hi Mark,
On Mon, 2014-01-27 at 20:25 +0000, Mark Brown wrote:
> On Fri, Jan 24, 2014 at 02:37:57PM +0100, Krzysztof Kozlowski wrote:
> > Add support for GPIO control (enable/disable) over Buck9. The Buck9
> > Converter is used as a supply for eMMC Host Controller.
>
> Applied, thanks.
I can't find these patches in your tree. Did you applied them or am I
missing something?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RESEND 1/2] spi: qup: Add device tree bindings information
From: Mark Brown @ 2014-02-07 12:27 UTC (permalink / raw)
To: Ivan T. Ivanov
Cc: Grant Likely, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala, Rob Landley, linux-spi, devicetree, linux-doc,
linux-arm-msm, linux-kernel
In-Reply-To: <1391759007-25305-1-git-send-email-iivanov@mm-sol.com>
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
On Fri, Feb 07, 2014 at 09:43:27AM +0200, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
>
> The Qualcomm Universal Peripheral (QUP) core is an
> AHB slave that provides a common data path (an output
> FIFO and an input FIFO) for serial peripheral interface
> (SPI) mini-core.
Please fix the formatting of this document so the lines are less than 80
columns, it's hard to read as is. Otherwise this is fine.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/4] MFD: TPS65218: Add driver for the TPS65218 PMIC
From: Lee Jones @ 2014-02-07 11:12 UTC (permalink / raw)
To: Keerthy
Cc: rob.herring, pawel.moll, mark.rutland, swarren, ijc+devicetree,
rob, sameo, grant.likely, lgirdwood, broonie, devicetree,
linux-doc, linux-kernel, linux-omap
In-Reply-To: <1391665814-18814-3-git-send-email-j-keerthy@ti.com>
On Thu, 06 Feb 2014, Keerthy wrote:
> The TPS65218 chip is a power management IC for Portable Navigation Systems
> and Tablet Computing devices. It contains the following components:
>
> - Regulators.
> - Over Temperature warning and Shut down.
>
> This patch adds support for tps65218 mfd device. At this time only
> the regulator functionality is made available.
>
> Signed-off-by: Keerthy <j-keerthy@ti.com>
> ---
> drivers/mfd/Kconfig | 15 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/tps65218.c | 281 +++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/tps65218.h | 284 ++++++++++++++++++++++++++++++++++++++++++
> 4 files changed, 581 insertions(+)
> create mode 100644 drivers/mfd/tps65218.c
> create mode 100644 include/linux/mfd/tps65218.h
Applied, thanks.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox