* Re: [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Nishanth Menon @ 2014-02-11 14:17 UTC (permalink / raw)
To: Roger Quadros, tony
Cc: bcousson, balbi, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, Hans de Goede
In-Reply-To: <52FA2B4F.3010408@ti.com>
On 02/11/2014 07:53 AM, Roger Quadros wrote:
> On 02/10/2014 08:10 PM, Roger Quadros wrote:
>> The OMAP EHCI controller is not compatible with the EHCI
>> platform HCD driver so don't claim that we are.
>>
>> This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
>> e.g. multi_v7_defconfig
>>
>> Reported-by: Nishanth Menon <nm@ti.com>
>> Signed-off-by: Roger Quadros <rogerq@ti.com>
>
> Please ignore this patch as Hans has agreed to do a more proper fix in
>
> http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7015
umm.. even then, drivers/usb/host/ehci-ppc-of.c claims compatibility
with usb,ehci -> and we wont function with that driver either.
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] can: xilinx CAN controller support.
From: Arnd Bergmann @ 2014-02-11 14:12 UTC (permalink / raw)
To: monstr
Cc: Marc Kleine-Budde, Michal Simek, robh+dt@kernel.org,
Appana Durga Kedareswara Rao, wg@grandegger.com,
grant.likely@linaro.org, linux-can@vger.kernel.org,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <52FA2419.70102@monstr.eu>
On Tuesday 11 February 2014, Michal Simek wrote:
> >> The only remaining question is if we should create generic DT binding
> >> for fifo depth. Arnd, Rob: Any opinion about it?
> >> Definitely will be worth to have one generic binding if this is generic feature.
> >> But if this is just specific feature for us then current properties should
> >> be fine.
> >>
> >> In general all these xlnx,XXX properties just reflect all configurable options
> >> which you can setup in design tool which means that provide full hw description
> >> with all variants and they are automatically generated from tools.
> >>
> >> Please let me know what you think.
> >
> > I like:
> >
> > rx-fifo-depth
> > tx-fifo-depth
>
> No problem with that. Let Kedar to fix it according this and he will send v2 with this.
>
Sounds reasonable to me too.
Arnd
^ permalink raw reply
* [PATCH 2/2] ehci-platform: Change compatible string from usb-ehci to ehci-platform
From: Hans de Goede @ 2014-02-11 14:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Roger Quadros, Alan Stern, Tony Prisk, Florian Fainelli,
Maxime Ripard, linux-usb, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Hans de Goede
In-Reply-To: <1392127826-31290-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
The initial versions of the devicetree enablement patches for ehci-platform
used "ehci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up, added a:
"depends on !PPC_OF" to Kconfig to avoid a known conflict with PPC-OF platforms
and went with the generic usb-ehci as requested.
In retro-spect I should have stuck to my guns, because the dts files for many
existing boards already claim to be compatible with "usb-ehci", ie they have:
compatible = "ti,ehci-omap", "usb-ehci";
In theory this should not be a problem since the "ti,ehci-omap" entry takes
presedence, but in practice using a conflicting compatible string is an issue,
because it makes which driver gets used depent on driver registration order.
This patch changes the compatible string claimed by ehci-platform (back) to
"ehci-platform", avoiding the driver registration / module loading ordering
problems, and removes the "depends on !PPC_OF" workaround.
Note that there already is a precedent for using ?hci-platform, in the form
of xhci-platform.c using "xhci-platfrom" as compatible string.
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/usb/usb-ehci.txt | 4 ++--
drivers/usb/host/Kconfig | 1 -
drivers/usb/host/ehci-platform.c | 2 +-
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index 2c1aeeb..46f428a 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -1,7 +1,7 @@
USB EHCI controllers
Required properties:
- - compatible : should be "usb-ehci".
+ - compatible : should be "ehci-platform".
- reg : should contain at least address and length of the standard EHCI
register set for the device. Optional platform-dependent registers
(debug-port or other) can be also specified here, but only after
@@ -27,7 +27,7 @@ Example (Sequoia 440EPx):
Example (Allwinner sun4i A10 SoC):
ehci0: usb@01c14000 {
- compatible = "allwinner,sun4i-a10-ehci", "usb-ehci";
+ compatible = "allwinner,sun4i-a10-ehci", "ehci-platform";
reg = <0x01c14000 0x100>;
interrupts = <39>;
clocks = <&ahb_gates 1>;
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index e28cbe0..a9707da 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -255,7 +255,6 @@ config USB_EHCI_ATH79
config USB_EHCI_HCD_PLATFORM
tristate "Generic EHCI driver for a platform device"
- depends on !PPC_OF
default n
---help---
Adds an EHCI host driver for a generic platform device, which
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 8fde649..4f4d78f 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -333,7 +333,7 @@ static int ehci_platform_resume(struct device *dev)
static const struct of_device_id vt8500_ehci_ids[] = {
{ .compatible = "via,vt8500-ehci", },
{ .compatible = "wm,prizm-ehci", },
- { .compatible = "usb-ehci", },
+ { .compatible = "ehci-platform", },
{}
};
MODULE_DEVICE_TABLE(of, vt8500_ehci_ids);
--
1.8.5.3
^ permalink raw reply related
* [PATCH 1/2] ohci-platform: Change compatible string from usb-ohci to ohci-platform
From: Hans de Goede @ 2014-02-11 14:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Roger Quadros, Alan Stern, Tony Prisk, Florian Fainelli,
Maxime Ripard, linux-usb, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Hans de Goede
In-Reply-To: <1392127826-31290-1-git-send-email-hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
The initial versions of the devicetree enablement patches for ohci-platform
used "ohci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up and went with
the generic usb-ohci as requested.
In retro-spect I should have stuck to my guns, because the dts files for many
existing boards already claim to be compatible with "usb-ohci", ie they have:
compatible = "ti,ohci-omap3", "usb-ohci";
In theory this should not be a problem since the "ti,ohci-omap3" entry takes
presedence, but in practice using a conflicting compatible string is an issue,
because it makes which driver gets used depent on driver registration order.
This patch changes the compatible string claimed by ohci-platform (back) to
"ohci-platform", avoiding the driver registration / module loading ordering
problems. Note that there already is a precedent for using ?hci-platform, in
the form of xhci-platform.c using "xhci-platfrom" as compatible string.
Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
---
Documentation/devicetree/bindings/usb/usb-ohci.txt | 4 ++--
drivers/usb/host/ohci-platform.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 6933b0c..a8e576a 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -1,7 +1,7 @@
USB OHCI controllers
Required properties:
-- compatible : "usb-ohci"
+- compatible : "ohci-platform"
- reg : ohci controller register range (address and length)
- interrupts : ohci controller interrupt
@@ -16,7 +16,7 @@ Optional properties:
Example:
ohci0: usb@01c14400 {
- compatible = "allwinner,sun4i-a10-ohci", "usb-ohci";
+ compatible = "allwinner,sun4i-a10-ohci", "ohci-platform";
reg = <0x01c14400 0x100>;
interrupts = <64>;
clocks = <&usb_clk 6>, <&ahb_gates 2>;
diff --git a/drivers/usb/host/ohci-platform.c b/drivers/usb/host/ohci-platform.c
index e2c28fd..59f3551 100644
--- a/drivers/usb/host/ohci-platform.c
+++ b/drivers/usb/host/ohci-platform.c
@@ -319,7 +319,7 @@ static int ohci_platform_resume(struct device *dev)
#endif /* CONFIG_PM */
static const struct of_device_id ohci_platform_ids[] = {
- { .compatible = "usb-ohci", },
+ { .compatible = "ohci-platform", },
{ }
};
MODULE_DEVICE_TABLE(of, ohci_platform_ids);
--
1.8.5.3
^ permalink raw reply related
* ohci-/ehci-platform: Change compatible string to ?hci-platform
From: Hans de Goede @ 2014-02-11 14:10 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Roger Quadros, Alan Stern, Tony Prisk, Florian Fainelli,
Maxime Ripard, linux-usb, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree
Hi Greg,
Can you please add these 2 patches to usb-next, to unbreak usb on various
ARM platforms?
These 2 patches can either be squashed into the first 2 patches of my previous
set or added as is to preserve history, either way is fine with me.
The 2nd patch also fixes one of the Kconfig issues and I've a better plan
for the 2nd Kconfig issue too, so please consider this a self-nack for my
drivers/usb/host/Kconfig patches.
Here is a copy of the echi-platform commit-msg to explain the rationale of
these changes, as well as how the breakage happened in the first place:
The initial versions of the devicetree enablement patches for ehci-platform
used "ehci-platform" as compatible string. However this was disliked by various
reviewers because the platform bus is a Linux invention and devicetree is
supposed to be OS agnostic. After much discussion I gave up, added a:
"depends on !PPC_OF" to Kconfig to avoid a known conflict with PPC-OF platforms
and went with the generic usb-ehci as requested.
In retro-spect I should have stuck to my guns, because the dts files for many
existing boards already claim to be compatible with "usb-ehci", ie they have:
compatible = "ti,ehci-omap", "usb-ehci";
In theory this should not be a problem since the "ti,ehci-omap" entry takes
presedence, but in practice using a conflicting compatible string is an issue,
because it makes which driver gets used depend on driver registration order.
This patch changes the compatible string claimed by ehci-platform (back) to
"ehci-platform", avoiding the driver registration / module loading ordering
problems, and removes the "depends on !PPC_OF" workaround.
Note that there already is a precedent for using ?hci-platform, in the form
of xhci-platform.c using "xhci-platfrom" as compatible string.
Thanks & Regards,
Hans
^ permalink raw reply
* Re: [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Arnd Bergmann @ 2014-02-11 14:08 UTC (permalink / raw)
To: Mark Brown
Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
Linus Walleij
In-Reply-To: <20140211120645.GH13533-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Tuesday 11 February 2014, Mark Brown wrote:
> On Tue, Feb 11, 2014 at 11:37:09AM +0000, Mark Rutland wrote:
>
> > - pl022->clk = devm_clk_get(&adev->dev, NULL);
> > + /*
> > + * For compatibility with old DTBs and platform data, fall back to the
> > + * first clock if there's not an explicitly named "sspclk" entry.
> > + */
> > + pl022->clk = devm_clk_get(&adev->dev, "sspclk");
> > + if (IS_ERR(pl022->clk))
> > + pl022->clk = devm_clk_get(&adev->dev, NULL);
> > +
>
> I'll just have a bit of a grumble here and point out that this sort of
> stuff always worries me with the convention of using nameless clocks -
> it causes hassle adding further clocks.
I think the best solution for this is to continue with anonymous clocks
rather than adding names after the fact. This could be done (for DT-only
drivers) using the of_clk_get() interface that takes an index, or
we could add a generic dev_clk_get_index() or similar interface that
has the same behavior but also works for clkdev.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/7] primecell: make correct clock parsing possible
From: Mark Rutland @ 2014-02-11 13:59 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Pawel Moll,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
broonie-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20140211123356.GH26684-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>
On Tue, Feb 11, 2014 at 12:33:56PM +0000, Russell King - ARM Linux wrote:
> On Tue, Feb 11, 2014 at 11:37:05AM +0000, Mark Rutland wrote:
> > These patches attempt to harmonize the bindings and the drivers with what's in
> > use today, in a backwards compatible fashion, relieving us of our present
> > Kafkaesque nightmare. Each peripheral's clock(s) are given explicit names which
> > can be used, though code will fall back to the existing behaviour if said names
> > are not provided. Additionally the currently unmet ordering requirement of
> > apb_pclk is dropped, given all existing that code requires this to be named
> > anyway.
>
> The reason why these clocks ended up with NULL names was to force the
> issue that clocks shall not be named solely by their connection IDs,
> which was a major problem before DT. Now that we have DT, I'm happier
> to reinstate the names, but I think we should just reinstate the names
> we had previously. That should be in the git history.
Good to know, that sounds fine to me.
>
> The down-side is those names are all in capitals - but they were named
> after the signal name(s) given in the Primecell documentation.
As long as we have standardised names I'm not too worried about which
case they happen to be in, and matching the documentation seems
sensible. The pl050 driver expects "KMIREFCLK" already, so it would be
in keeping with (as far as I can tell) the only Primecell driver
currently requesting a clock by name.
I'll prepare a v2 shortly.
Cheers,
Mark.
--
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: [RFC PATCH] [media]: of: move graph helpers from drivers/media/v4l2-core to drivers/of
From: Rob Herring @ 2014-02-11 13:56 UTC (permalink / raw)
To: Philipp Zabel
Cc: Russell King - ARM Linux, Mauro Carvalho Chehab, Grant Likely,
Rob Herring, Sylwester Nawrocki, Laurent Pinchart, Tomi Valkeinen,
Kyungmin Park, linux-kernel@vger.kernel.org,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
Philipp Zabel
In-Reply-To: <1392119105-25298-1-git-send-email-p.zabel@pengutronix.de>
On Tue, Feb 11, 2014 at 5:45 AM, Philipp Zabel <p.zabel@pengutronix.de> wrote:
> From: Philipp Zabel <philipp.zabel@gmail.com>
>
> This patch moves the parsing helpers used to parse connected graphs
> in the device tree, like the video interface bindings documented in
> Documentation/devicetree/bindings/media/video-interfaces.txt, from
> drivers/media/v4l2-core to drivers/of.
This is the opposite direction things have been moving...
> This allows to reuse the same parser code from outside the V4L2 framework,
> most importantly from display drivers. There have been patches that duplicate
> the code (and I am going to send one of my own), such as
> http://lists.freedesktop.org/archives/dri-devel/2013-August/043308.html
> and others that parse the same binding in a different way:
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg100761.html
>
> I think that all common video interface parsing helpers should be moved to a
> single place, outside of the specific subsystems, so that it can be reused
> by all drivers.
Perhaps that should be done rather than moving to drivers/of now and
then again to somewhere else.
> I moved v4l2_of_get_next_endpoint, v4l2_of_get_remote_port,
> and v4l2_of_get_remote_port_parent. They are renamed to
> of_graph_get_next_endpoint, of_graph_get_remote_port, and
> of_graph_get_remote_port_parent, respectively.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
> ---
> drivers/media/Kconfig | 1 +
> drivers/media/v4l2-core/v4l2-of.c | 117 ---------------------------------
> drivers/of/Kconfig | 3 +
> drivers/of/Makefile | 1 +
> drivers/of/of_graph.c | 133 ++++++++++++++++++++++++++++++++++++++
> include/linux/of_graph.h | 23 +++++++
> include/media/v4l2-of.h | 16 ++---
> 7 files changed, 167 insertions(+), 127 deletions(-)
> create mode 100644 drivers/of/of_graph.c
> create mode 100644 include/linux/of_graph.h
[snip]
> diff --git a/include/media/v4l2-of.h b/include/media/v4l2-of.h
> index 541cea4..404a493 100644
> --- a/include/media/v4l2-of.h
> +++ b/include/media/v4l2-of.h
> @@ -17,6 +17,7 @@
> #include <linux/list.h>
> #include <linux/types.h>
> #include <linux/errno.h>
> +#include <linux/of_graph.h>
>
> #include <media/v4l2-mediabus.h>
>
> @@ -72,11 +73,6 @@ struct v4l2_of_endpoint {
> #ifdef CONFIG_OF
> int v4l2_of_parse_endpoint(const struct device_node *node,
> struct v4l2_of_endpoint *endpoint);
> -struct device_node *v4l2_of_get_next_endpoint(const struct device_node *parent,
> - struct device_node *previous);
> -struct device_node *v4l2_of_get_remote_port_parent(
> - const struct device_node *node);
> -struct device_node *v4l2_of_get_remote_port(const struct device_node *node);
> #else /* CONFIG_OF */
>
> static inline int v4l2_of_parse_endpoint(const struct device_node *node,
> @@ -85,25 +81,25 @@ static inline int v4l2_of_parse_endpoint(const struct device_node *node,
> return -ENOSYS;
> }
>
> +#endif /* CONFIG_OF */
> +
> static inline struct device_node *v4l2_of_get_next_endpoint(
> const struct device_node *parent,
> struct device_node *previous)
> {
> - return NULL;
> + return of_graph_get_next_endpoint(parent, previous);
Won't this break for !OF?
Rob
^ permalink raw reply
* [PATCH] Add a README file for dtc and libfdt
From: Grant Likely @ 2014-02-11 13:56 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA,
david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+, jdl-CYoMK+44s/E,
devicetree-compiler-u79uwXL29TY76Z2rM5mHXA
Cc: Grant Likely
Add a README file to document the location of the mailing list, the home
page and state who the maintainers are.
Signed-off-by: Grant Likely <grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
README | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
create mode 100644 README
diff --git a/README b/README
new file mode 100644
index 000000000000..979974a1b3ad
--- /dev/null
+++ b/README
@@ -0,0 +1,20 @@
+The source tree contains the Device Tree Compiler (dtc) toolchain for
+working with device tree source and binary files and also libfdt, a
+utility library for reading and manipulating the binary format.
+
+DTC and LIBFDT are maintained by:
+
+David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
+Jon Loeliger <jdl-CYoMK+44s/E@public.gmane.org>
+
+Mailing list
+------------
+The following list is for discussion about dtc and libfdt implementation
+mailto:devicetree-compiler-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+
+Core device tree bindings are discussed on the devicetree-spec list:
+mailto:devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
+
+Home Page
+---------
+http://devicetree.org/Device_Tree_Compiler
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] ARM: dts: OMAP2+: Fix boot with multi_v7_defconfig
From: Roger Quadros @ 2014-02-11 13:53 UTC (permalink / raw)
To: tony
Cc: bcousson, balbi, nm, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, Roger Quadros, Hans de Goede
In-Reply-To: <1392055835-6494-1-git-send-email-rogerq@ti.com>
On 02/10/2014 08:10 PM, Roger Quadros wrote:
> The OMAP EHCI controller is not compatible with the EHCI
> platform HCD driver so don't claim that we are.
>
> This fixes boot on OMAP platforms with CONFIG_USB_EHCI_HCD_PLATFORM=y
> e.g. multi_v7_defconfig
>
> Reported-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Roger Quadros <rogerq@ti.com>
Please ignore this patch as Hans has agreed to do a more proper fix in
http://article.gmane.org/gmane.comp.hardware.netbook.arm.sunxi/7015
cheers,
-roger
> ---
> arch/arm/boot/dts/omap3.dtsi | 2 +-
> arch/arm/boot/dts/omap4.dtsi | 2 +-
> arch/arm/boot/dts/omap5.dtsi | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index a5fc83b..6b5dbf8 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -641,7 +641,7 @@
> };
>
> usbhsehci: ehci@48064800 {
> - compatible = "ti,ehci-omap", "usb-ehci";
> + compatible = "ti,ehci-omap";
> reg = <0x48064800 0x400>;
> interrupt-parent = <&intc>;
> interrupts = <77>;
> diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
> index d3f8a6e..f5d754b 100644
> --- a/arch/arm/boot/dts/omap4.dtsi
> +++ b/arch/arm/boot/dts/omap4.dtsi
> @@ -706,7 +706,7 @@
> };
>
> usbhsehci: ehci@4a064c00 {
> - compatible = "ti,ehci-omap", "usb-ehci";
> + compatible = "ti,ehci-omap";
> reg = <0x4a064c00 0x400>;
> interrupt-parent = <&gic>;
> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
> diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
> index a72813a..42fcffd 100644
> --- a/arch/arm/boot/dts/omap5.dtsi
> +++ b/arch/arm/boot/dts/omap5.dtsi
> @@ -784,7 +784,7 @@
> };
>
> usbhsehci: ehci@4a064c00 {
> - compatible = "ti,ehci-omap", "usb-ehci";
> + compatible = "ti,ehci-omap";
> reg = <0x4a064c00 0x400>;
> interrupt-parent = <&gic>;
> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
>
^ permalink raw reply
* Re: [PATCH v9 2/4] ehci-platform: Add support for clks and phy passed through devicetree
From: Roger Quadros @ 2014-02-11 13:42 UTC (permalink / raw)
To: Hans de Goede, Greg Kroah-Hartman
Cc: Alan Stern, Tony Prisk, linux-usb, Maxime Ripard,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
Menon, Nishanth, Kevin Hilman
In-Reply-To: <52F9F7B3.6080802-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On 02/11/2014 12:13 PM, Hans de Goede wrote:
> Hi,
>
> On 02/11/2014 11:00 AM, Roger Quadros wrote:
>> On 02/11/2014 11:31 AM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 02/11/2014 10:12 AM, Roger Quadros wrote:
>>>> Hi Hans,
>>>>
>>>> On 02/07/2014 05:36 PM, Hans de Goede wrote:
>>>>> Currently ehci-platform is only used in combination with devicetree when used
>>>>> with some Via socs. By extending it to (optionally) get clks and a phy from
>>>>> devicetree, and enabling / disabling those on power_on / off, it can be used
>>>>> more generically. Specifically after this commit it can be used for the
>>>>> ehci controller on Allwinner sunxi SoCs.
>>>>>
>>>>> Since ehci-platform is intended to handle any generic enough non pci ehci
>>>>> device, add a "usb-ehci" compatibility string.
>>>>>
>>>>> There already is a usb-ehci device-tree bindings document, update this
>>>>> with clks and phy bindings info.
>>>>>
>>>>> Although actually quite generic so far the via,vt8500 compatibilty string
>>>>> had its own bindings document. Somehow we even ended up with 2 of them. Since
>>>>> these provide no extra information over the generic usb-ehci documentation,
>>>>> this patch removes them.
>>>>>
>>>>> The ehci-ppc-of.c driver also claims the usb-ehci compatibility string,
>>>>> even though it mostly is ibm,usb-ehci-440epx specific. ehci-platform.c is
>>>>> not needed on ppc platforms, so add a !PPC_OF dependency to it to avoid
>>>>> 2 drivers claiming the same compatibility string getting build on ppc.
>>>>>
>>>>
>>>> This breaks all OMAP platforms on linux-next for the exact same reason. see [1].
>>>>
>>>> ./arch/arm/boot/dts/omap4.dtsi: compatible = "ti,ehci-omap", "usb-ehci";
>>>> ./arch/arm/boot/dts/omap3.dtsi: compatible = "ti,ehci-omap", "usb-ehci";
>>>> ./arch/arm/boot/dts/omap5.dtsi: compatible = "ti,ehci-omap", "usb-ehci";
>>>
>>> That should not be the case, the driver core should try to find a driver matching
>>> the compatibility string from left to right, or in other words from most specific
>>> to least specific. This is part of the whole devicetree design.
>>>
>>> So as long as the driver claiming "ti,ehci-omap" is available at probe time that
>>> one should get used and things should work fine. Now if ehci-platform is built-in
>>> and ehci-omap is a module, then I guess one could see the described breakage.
>>>
>>> If the driver is built-in and things are not working, then we will need to do some
>>> debugging as to why the left to right matching is not working as expected.
>>
>> Both ehci_platform and ehci_omap were built-in and still the ehci_platform driver got
>> probe preference. So it looks like the left to right compatible list priority probing
>> feature doesn't work.
>
> Oops, I guess nothing relies on it sofar. Well we could go and debug and fix this but...
>
I think we have a misunderstanding. The compatible list priority probing is only for the
platform identification compatible. I don't think it is meant to work with driver core yet.
http://lxr.free-electrons.com/source/Documentation/devicetree/usage-model.txt#L116
>>
>>>
>>> I must admit I'm not sure what happens if both are a module, the kernel direct
>>> module load will likely fail due to lack of a rootfs at that point, and then
>>> the module will later get loaded by udev I assume, at which point there are no
>>> loading ordering guarantees.
>>>
>>> The easiest solution to ensure that "ti,ehci-omap" is available at probe time
>>> (if enabled) seems to be to change USB_EHCI_HCD_OMAP to a boolean.
>>
>> That is a limitation I don't like to have for USB_EHCI_HCD_OMAP.
>
> I completely understand, thinking more about this I'm simply going to change the
> compatibility string for ohci- and ehci-platform to be "ohci-platform" resp.
> "ehci-platform". I know there are some people who don't like the -platform
> suffix, but though luck, as the above clearly shows using the generic "usb-ohci" /
> "usb-ehci" they were advocating for leads to a ton of issues, and we already
> have a precedent for ?hci-platform in the form of "xhci-platform".
+1
cheers,
-roger
^ permalink raw reply
* Re: [PATCH 4/7] spi: pl022: attempt to get sspclk by name
From: Mark Rutland @ 2014-02-11 13:39 UTC (permalink / raw)
To: Mark Brown
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, Pawel Moll,
Linus Walleij, Arnd Bergmann
In-Reply-To: <20140211120645.GH13533-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
On Tue, Feb 11, 2014 at 12:06:45PM +0000, Mark Brown wrote:
> On Tue, Feb 11, 2014 at 11:37:09AM +0000, Mark Rutland wrote:
>
> > - pl022->clk = devm_clk_get(&adev->dev, NULL);
> > + /*
> > + * For compatibility with old DTBs and platform data, fall back to the
> > + * first clock if there's not an explicitly named "sspclk" entry.
> > + */
> > + pl022->clk = devm_clk_get(&adev->dev, "sspclk");
> > + if (IS_ERR(pl022->clk))
> > + pl022->clk = devm_clk_get(&adev->dev, NULL);
> > +
>
> I'll just have a bit of a grumble here and point out that this sort of
> stuff always worries me with the convention of using nameless clocks -
> it causes hassle adding further clocks.
>
> In any case you didn't CC me on the cover letter or any of the non-SPI
> patches so I'm not sure what the dependencies are here (if there are
> any), does the series need to go in as one?
Apologies for missing you for the cover letter (you can find a copy in
the lakml archive [1]).
The SPI patches don't depend on the rest of the series, but given
Russell's comments on the cover [2] this will probably need a v2 anyway.
I'll ensure you're Cc'd.
Cheers,
Mark.
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/231572.html
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2014-February/231594.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Device tree meeting today
From: Grant Likely @ 2014-02-11 13:34 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Someone else needs to drive the device tree meeting today on
#devicetree. My internet connection will not stay up more than 5
minutes at a time. :-( Rob, can you take the lead?
For my part, I've talked to Stuart about the ePAPR spec and we're
discussing doing a new revision, possibly using the OASIS organization
to host it.
I've created the new mailing lists and sent out an announcement. I'll
send the list addresses to the BSD folks this afternoon.
g.
--
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
* [RFC PATCH 4/4] ARM: dts: imx6qdl: Add PU power-domain information to gpc node
From: Philipp Zabel @ 2014-02-11 13:27 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <1392125231-28387-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
The PGC that is part of GPC controls isolation and power sequencing of the
PU power domain. The power domain will be handled by the generic pm domain
framework and needs a phandle to the PU regulator to turn off power when
the domain is disabled.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 253d82c..595750d 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -598,9 +598,17 @@
};
gpc: gpc@020dc000 {
+ #address-cells = <1>;
+ #size-cells = <1>;
compatible = "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
interrupts = <0 89 0x04 0 90 0x04>;
+ pu-supply = <®_pu>;
+
+ pd_pu: power-domain@020dc260 {
+ compatible = "fsl,power-domain";
+ reg = <0x020dc260 0x10>;
+ };
};
gpr: iomuxc-gpr@020e0000 {
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH 3/4] ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp delay
From: Philipp Zabel @ 2014-02-11 13:27 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <1392125231-28387-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
The PU regulator is enabled during boot, but not necessarily always-on.
It can be disabled by the generic pm domain framework when the PU power
domain is shut down. The ramp delay of 150 us might be a bit conservative,
the value is taken from the Freescale kernel.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
arch/arm/boot/dts/imx6qdl.dtsi | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index fb28b2e..253d82c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -515,7 +515,8 @@
regulator-name = "vddpu";
regulator-min-microvolt = <725000>;
regulator-max-microvolt = <1450000>;
- regulator-always-on;
+ regulator-enable-ramp-delay = <150>;
+ regulator-boot-on;
anatop-reg-offset = <0x140>;
anatop-vol-bit-shift = <9>;
anatop-vol-bit-width = <5>;
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH 2/4] ARM: imx6: gpc: Add pm clock support to PU power domain
From: Philipp Zabel @ 2014-02-11 13:27 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <1392125231-28387-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Drivers still handle clocks themselves, we only enable pm clocks of the
GPU and VPU devices in the PU power domain temporarily during powerup
so that the reset machinery can work.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
arch/arm/mach-imx/gpc.c | 74 +++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 74 insertions(+)
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index c3ec2c5..e3f4492 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -18,6 +18,7 @@
#include <linux/of_address.h>
#include <linux/of_irq.h>
#include <linux/platform_device.h>
+#include <linux/pm_clock.h>
#include <linux/pm_domain.h>
#include <linux/regulator/consumer.h>
#include <linux/irqchip/arm-gic.h>
@@ -184,6 +185,7 @@ static int imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
{
+ struct pm_domain_data *pdd;
int ret;
u32 val;
int sw, sw2iso;
@@ -194,6 +196,10 @@ static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
return ret;
}
+ /* Enable PM clocks for all devices in the PU domain */
+ list_for_each_entry(pdd, &genpd->dev_list, list_node)
+ pm_clk_resume(pdd->dev);
+
/* Gate off PU domain when GPU/VPU when powered down */
writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
@@ -210,6 +216,10 @@ static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
/* Wait ISO + ISO2SW IPG clock cycles */
ndelay((sw + sw2iso) * 1000 / 66);
+ /* Disable PM clocks for all devices in the PU domain */
+ list_for_each_entry(pdd, &genpd->dev_list, list_node)
+ pm_clk_suspend(pdd->dev);
+
return 0;
}
@@ -219,6 +229,68 @@ static struct generic_pm_domain imx6q_pu_domain = {
.power_on = imx6q_pm_pu_power_on,
};
+int imx6q_pm_clk_add(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ const char *con_id;
+ struct clk *clk;
+ int i = 0;
+
+ /* Add and prepare named clocks */
+ while (!of_property_read_string_index(np, "clock-names", i, &con_id)) {
+ pm_clk_add(dev, con_id);
+ clk = of_clk_get(np, i);
+ if (!IS_ERR(clk)) {
+ clk_prepare(clk);
+ clk_put(clk);
+ }
+ i++;
+ }
+
+ /* If no named clocks are given, add and prepare unnamed clock */
+ if (i == 1 && of_find_property(dev->of_node, "clocks", NULL)) {
+ pm_clk_add(dev, NULL);
+ clk = of_clk_get(np, 0);
+ if (!IS_ERR(clk)) {
+ clk_prepare(clk);
+ clk_put(clk);
+ }
+ }
+
+ return 0;
+}
+
+int imx6q_pm_clk_remove(struct device *dev)
+{
+ struct device_node *np = dev->of_node;
+ const char *con_id;
+ struct clk *clk;
+ int i = 0;
+
+ /* Remove and unprepare named clocks */
+ while (!of_property_read_string_index(np, "clock-names", i, &con_id)) {
+ pm_clk_remove(dev, con_id);
+ clk = of_clk_get(np, i);
+ if (!IS_ERR(clk)) {
+ clk_unprepare(clk);
+ clk_put(clk);
+ }
+ i++;
+ }
+
+ /* If no named clocks are given, remove and unprepare unnamed clock */
+ if (i == 1 && of_find_property(dev->of_node, "clocks", NULL)) {
+ pm_clk_remove(dev, NULL);
+ clk = of_clk_get(np, 0);
+ if (!IS_ERR(clk)) {
+ clk_unprepare(clk);
+ clk_put(clk);
+ }
+ }
+
+ return 0;
+}
+
static int imx6q_pm_notifier_call(struct notifier_block *nb,
unsigned long event, void *data)
{
@@ -237,6 +309,7 @@ static int imx6q_pm_notifier_call(struct notifier_block *nb,
if (ret)
dev_err(dev, "failed to add to power domain: %d\n",
ret);
+ imx6q_pm_clk_add(dev);
break;
case BUS_NOTIFY_UNBOUND_DRIVER:
genpd = dev_to_genpd(dev);
@@ -246,6 +319,7 @@ static int imx6q_pm_notifier_call(struct notifier_block *nb,
if (ret)
dev_err(dev, "failed to remove from power domain: %d\n",
ret);
+ imx6q_pm_clk_remove(dev);
break;
}
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH 1/4] ARM: imx6: gpc: Add PU power domain for GPU/VPU
From: Philipp Zabel @ 2014-02-11 13:27 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
In-Reply-To: <1392125231-28387-1-git-send-email-p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
When generic pm domain support is enabled, the PGC can be used
to completely gate power to the PU power domain containing GPU3D,
GPU2D, and VPU cores.
This code triggers the PGC powerdown sequence to disable the GPU/VPU
isolation cells and gate power and then disables the PU regulator.
To reenable, the reverse powerup sequence is triggered after the PU
regulaotor is enabled again.
Signed-off-by: Philipp Zabel <p.zabel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
---
arch/arm/mach-imx/Kconfig | 2 +
arch/arm/mach-imx/gpc.c | 169 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 171 insertions(+)
diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
index 33567aa..3c58f2e 100644
--- a/arch/arm/mach-imx/Kconfig
+++ b/arch/arm/mach-imx/Kconfig
@@ -808,6 +808,7 @@ config SOC_IMX6Q
select PL310_ERRATA_727915 if CACHE_PL310
select PL310_ERRATA_769419 if CACHE_PL310
select PM_OPP if PM
+ select PM_GENERIC_DOMAINS if PM
help
This enables support for Freescale i.MX6 Quad processor.
@@ -827,6 +828,7 @@ config SOC_IMX6SL
select PL310_ERRATA_588369 if CACHE_PL310
select PL310_ERRATA_727915 if CACHE_PL310
select PL310_ERRATA_769419 if CACHE_PL310
+ select PM_GENERIC_DOMAINS if PM
help
This enables support for Freescale i.MX6 SoloLite processor.
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 586e017..c3ec2c5 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -10,19 +10,32 @@
* http://www.gnu.org/copyleft/gpl.html
*/
+#include <linux/clk.h>
+#include <linux/delay.h>
#include <linux/io.h>
#include <linux/irq.h>
#include <linux/of.h>
#include <linux/of_address.h>
#include <linux/of_irq.h>
+#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
+#include <linux/regulator/consumer.h>
#include <linux/irqchip/arm-gic.h>
#include "common.h"
+#include "hardware.h"
+#define GPC_CNTR 0x000
#define GPC_IMR1 0x008
+#define GPC_PGC_GPU_PDN 0x260
+#define GPC_PGC_GPU_PUPSCR 0x264
+#define GPC_PGC_GPU_PDNSCR 0x268
#define GPC_PGC_CPU_PDN 0x2a0
#define IMR_NUM 4
+#define GPU_VPU_PUP_REQ BIT(1)
+#define GPU_VPU_PDN_REQ BIT(0)
+
static void __iomem *gpc_base;
static u32 gpc_wake_irqs[IMR_NUM];
static u32 gpc_saved_imrs[IMR_NUM];
@@ -138,3 +151,159 @@ void __init imx_gpc_init(void)
gic_arch_extn.irq_unmask = imx_gpc_irq_unmask;
gic_arch_extn.irq_set_wake = imx_gpc_irq_set_wake;
}
+
+static struct regulator *pu_reg;
+
+static int imx6q_pm_pu_power_off(struct generic_pm_domain *genpd)
+{
+ u32 val;
+ int iso, iso2sw;
+
+ /* GPU3D, GPU2D, and VPU clocks should be disabled here */
+
+ /* Read ISO and ISO2SW power down delays */
+ val = readl_relaxed(gpc_base + GPC_PGC_GPU_PDNSCR);
+ iso = val & 0x3f;
+ iso2sw = (val >> 8) & 0x3f;
+
+ /* Gate off PU domain when GPU/VPU when powered down */
+ writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+ /* Request GPC to power down GPU/VPU */
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val |= GPU_VPU_PDN_REQ;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+
+ /* Wait ISO + ISO2SW IPG clock cycles */
+ ndelay((iso + iso2sw) * 1000 / 66);
+
+ regulator_disable(pu_reg);
+
+ return 0;
+}
+
+static int imx6q_pm_pu_power_on(struct generic_pm_domain *genpd)
+{
+ int ret;
+ u32 val;
+ int sw, sw2iso;
+
+ ret = regulator_enable(pu_reg);
+ if (ret) {
+ pr_err("%s: failed to enable regulator: %d\n", __func__, ret);
+ return ret;
+ }
+
+ /* Gate off PU domain when GPU/VPU when powered down */
+ writel_relaxed(0x1, gpc_base + GPC_PGC_GPU_PDN);
+
+ /* Read ISO and ISO2SW power down delays */
+ val = readl_relaxed(gpc_base + GPC_PGC_GPU_PUPSCR);
+ sw = val & 0x3f;
+ sw2iso = (val >> 8) & 0x3f;
+
+ /* Request GPC to power up GPU/VPU */
+ val = readl_relaxed(gpc_base + GPC_CNTR);
+ val |= GPU_VPU_PUP_REQ;
+ writel_relaxed(val, gpc_base + GPC_CNTR);
+
+ /* Wait ISO + ISO2SW IPG clock cycles */
+ ndelay((sw + sw2iso) * 1000 / 66);
+
+ return 0;
+}
+
+static struct generic_pm_domain imx6q_pu_domain = {
+ .name = "PU",
+ .power_off = imx6q_pm_pu_power_off,
+ .power_on = imx6q_pm_pu_power_on,
+};
+
+static int imx6q_pm_notifier_call(struct notifier_block *nb,
+ unsigned long event, void *data)
+{
+ struct generic_pm_domain *genpd;
+ struct device *dev = data;
+ struct device_node *np;
+ int ret;
+
+ switch (event) {
+ case BUS_NOTIFY_BIND_DRIVER:
+ np = of_parse_phandle(dev->of_node, "power-domain", 0);
+ if (!np)
+ return NOTIFY_DONE;
+
+ ret = pm_genpd_of_add_device(np, dev);
+ if (ret)
+ dev_err(dev, "failed to add to power domain: %d\n",
+ ret);
+ break;
+ case BUS_NOTIFY_UNBOUND_DRIVER:
+ genpd = dev_to_genpd(dev);
+ if (IS_ERR(genpd))
+ return NOTIFY_DONE;
+ ret = pm_genpd_remove_device(genpd, dev);
+ if (ret)
+ dev_err(dev, "failed to remove from power domain: %d\n",
+ ret);
+ break;
+ }
+
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block imx6q_platform_nb = {
+ .notifier_call = imx6q_pm_notifier_call,
+};
+
+static int imx_gpc_probe(struct platform_device *pdev)
+{
+ struct device_node *np;
+ int ret;
+
+ np = of_get_child_by_name(pdev->dev.of_node, "power-domain");
+ if (!np) {
+ dev_err(&pdev->dev, "missing power-domain node\n");
+ return -EINVAL;
+ }
+
+ pu_reg = devm_regulator_get(&pdev->dev, "pu");
+ if (IS_ERR(pu_reg)) {
+ ret = PTR_ERR(pu_reg);
+ dev_err(&pdev->dev, "failed to get pu regulator: %d\n", ret);
+ return ret;
+ }
+
+ /* The regulator is initially enabled */
+ ret = regulator_enable(pu_reg);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to enable pu regulator: %d\n", ret);
+ return ret;
+ }
+
+ imx6q_pu_domain.of_node = np;
+ pm_genpd_init(&imx6q_pu_domain, NULL, false);
+ bus_register_notifier(&platform_bus_type, &imx6q_platform_nb);
+
+ return 0;
+}
+
+static struct of_device_id imx_gpc_dt_ids[] = {
+ { .compatible = "fsl,imx6q-gpc" },
+ { }
+};
+
+static struct platform_driver imx_gpc_driver = {
+ .driver = {
+ .name = "imx-gpc",
+ .owner = THIS_MODULE,
+ .of_match_table = imx_gpc_dt_ids,
+ },
+ .probe = imx_gpc_probe,
+};
+
+static int __init imx_pgc_init(void)
+{
+ return platform_driver_register(&imx_gpc_driver);
+}
+subsys_initcall(imx_pgc_init);
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RFC PATCH 0/4] i.MX6 PU power domain support
From: Philipp Zabel @ 2014-02-11 13:27 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Philipp Zabel
The i.MX6Q can gate off the CPU and PU (GPU/VPU) power domains using the
Power Gating Controller (PGC) in the GPC register space. The CPU power
domain is already handled by wait state code, but the PU power domain can
be controlled using the generic power domain framework and power off the PU
supply regulator if all devices in the power domain are (runtime) suspended.
This patchset adds a GPC platform device initialized at subsys_initcall time
(after anatop regulators) that binds to the gpc device tree node and sets up
the PU power domain:
gpc: gpc@020dc000 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "fsl,imx6q-gpc";
reg = <0x020dc000 0x4000>;
interrupts = <0 89 0x04 0 90 0x04>;
pu-supply = <®_pu>;
pd_pu: power-domain@020dc260 {
compatible = "fsl,power-domain";
reg = <0x020dc260 0x10>;
};
};
It registers a platform bus notifier so that it can add GPU and VPU devices
to the power domain when they are bound. If finds devices to be added to the
power domain by scanning the device tree for nodes that contain a
power-domain = <&pd_pu>;
property.
For i.MX6QDL there is only one power domain, but on i.MX6SL I suspect the
DISP power domain could be handled using the same mechanism.
regards
Philipp
Philipp Zabel (4):
ARM: imx6: gpc: Add PU power domain for GPU/VPU
ARM: imx6: gpc: Add pm clock support to PU power domain
ARM: dts: imx6qdl: Allow disabling the PU regulator, add a enable ramp
delay
ARM: dts: imx6qdl: Add PU power-domain information to gpc node
arch/arm/boot/dts/imx6qdl.dtsi | 11 +-
arch/arm/mach-imx/Kconfig | 2 +
arch/arm/mach-imx/gpc.c | 243 +++++++++++++++++++++++++++++++++++++++++
3 files changed, 255 insertions(+), 1 deletion(-)
--
1.8.5.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: regression(ti platforms): next-20140210 (ehci?)
From: Nishanth Menon @ 2014-02-11 13:27 UTC (permalink / raw)
To: Kevin Hilman
Cc: Roger Quadros, linux-omap, linux-usb, Balbi, Felipe, linux-next,
devicetree@vger.kernel.org, tony@atomide.com
In-Reply-To: <7h38jq8nk9.fsf@paris.lan>
On 02/10/2014 07:07 PM, Kevin Hilman wrote:
> Nishanth Menon <nm@ti.com> writes:
>
>> On 02/10/2014 12:28 PM, Kevin Hilman wrote:
>>> Roger Quadros <rogerq@ti.com> writes:
>>>
>>>> +devicetree
>>>>
>>>> On 02/10/2014 05:59 PM, Nishanth Menon wrote:
>>>>> Hi,
>>>>>
>>>>> A quick note to report that I saw regression in today's next tag (logs
>>>>> indicate around EHCI) boot on various TI platforms:
>>>>>
>>>>> Note: crane and sdp2430 are not expected to pass with
>>>>> multi_v7_defconfig (note: omap2plus_defconfig boot seems to be sane
>>>>> but USB is disabled there)
>>>>>
>>>>> next-20140210-multi_v7_defconfig
>>>>> 1: am335x-evm: Boot PASS: http://slexy.org/raw/s2zYHdPb94
>>>>> 2: am335x-sk: Boot PASS: http://slexy.org/raw/s2UChLyzSE
>>>>> 3: am3517-evm: Boot FAIL: http://slexy.org/raw/s20Br9XLO1
>>>>> around ehci
>>>>>
>>>>> 4: am37x-evm: Boot FAIL: http://slexy.org/raw/s20mVz9Wc7
>>>>> around ehci
>>>>>
>>>>> 5: am43xx-epos: Boot PASS: http://slexy.org/raw/s2byveBYtT
>>>>> 6: BeagleBoard-XM: Boot FAIL: http://slexy.org/raw/s21sOgJNwK
>>>>> around ehci
>>>>>
>>>>> 7: BeagleBone-Black: Boot PASS: http://slexy.org/raw/s2ovVNAmO7
>>>>> 8: crane: No Image built - Missing platform support?:
>>>>> 9: dra7: Boot PASS: http://slexy.org/raw/s217qwaXsM
>>>>> 10: ldp: Boot FAIL: http://slexy.org/raw/s203IvjE23
>>>>> around ehci
>>>>>
>>>>> 11: PandaBoard-ES: Boot FAIL: http://slexy.org/raw/s2NvkRx2YJ
>>>>> around ehci
>>>>
>>>> I think the problem is that ehci-platform driver gets loaded instead of ehci-omap.
>>>>
>>>> In the DT node we have compatible ids for both. e.g. for omap4.dtsi
>>>>
>>>> usbhsehci: ehci@4a064c00 {
>>>> compatible = "ti,ehci-omap", "usb-ehci";
>>>> reg = <0x4a064c00 0x400>;
>>>> interrupt-parent = <&gic>;
>>>> interrupts = <GIC_SPI 77 IRQ_TYPE_LEVEL_HIGH>;
>>>> };
>>>>
>>>> Shouldn't ehci-omap driver be getting a higher priority than usb-ehci?
>>>>
>>>> A quick fix would be to eliminate "usb-ehci" from the DT node of all failing platforms.
>>>
>>> I can confirm that simply remvoing usb-ehci from omap[34].dtsi nodes
>>> fixed the problem for me on 3530/overo, 3730/beagle-xM and
>>> 4460/panda-es. But I don't think that's the right fix. First we have
>>> to figure out why ehci-omap stopped getting loaded first.
>>
>> Wont that depend on driver probe order? of_match_device is fairly
>> simple compatible walk through without looking at other drivers which
>> might also be compatible, but not yet probed?
>>
>> The issue started I think with the following patch getting merged:
>> ehci-platform: Add support for clks and phy passed through devicetree
>> some version of http://www.spinics.net/lists/linux-usb/msg101061.html
>> introduced { .compatible = "usb-ehci", },
>
> This is what I was getting at: an understanding of what caused the
> failue in the first place.
>
>> Now, in the build we have two drivers which dts claims compatibility
>> with, but only 1 driver actually works (drivers/usb/host/ehci-omap.c)
>> for the platform. Thinking that way, in fact, the current
>> compatibility even matches drivers/usb/host/ehci-ppc-of.c which
>> obviously wont work either.
>
> Right, so I agree that it makes sense to remove a compatible string
> where there is no compatability, but a couple other things should happen
> here.
>
> 1) changelog should describe why this compatible string is in the omap
> dtsi files in first place.
>
Agreed: I had commented the same on
https://patchwork.kernel.org/patch/3621811/
> 2) investigation into the patch that introduced this change to double
> check it's not introducing other breakage as well.
discussion is now on the relevant patch generating the break:
http://marc.info/?t=139178752000003&r=1&w=2
--
Regards,
Nishanth Menon
^ permalink raw reply
* Re: [PATCH] can: xilinx CAN controller support.
From: Michal Simek @ 2014-02-11 13:22 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Michal Simek, robh+dt@kernel.org, Arnd Bergmann,
Appana Durga Kedareswara Rao, wg@grandegger.com,
grant.likely@linaro.org, linux-can@vger.kernel.org,
netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <52FA1910.2060101@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 6218 bytes --]
On 02/11/2014 01:35 PM, Marc Kleine-Budde wrote:
> On 02/11/2014 12:45 PM, Michal Simek wrote:
>> Hi Marc,
>>
>> On 02/07/2014 10:37 AM, Marc Kleine-Budde wrote:
>>> On 02/07/2014 09:42 AM, Appana Durga Kedareswara Rao wrote:
>>>>>> ---
>>>>>> This patch is rebased on the 3.14 rc1 kernel.
>>>>>> ---
>>>>>> .../devicetree/bindings/net/can/xilinx_can.txt | 43 +
>>>>>> drivers/net/can/Kconfig | 8 +
>>>>>> drivers/net/can/Makefile | 1 +
>>>>>> drivers/net/can/xilinx_can.c | 1150 ++++++++++++++++++++
>>>>>> 4 files changed, 1202 insertions(+), 0 deletions(-) create mode
>>>>>> 100644 Documentation/devicetree/bindings/net/can/xilinx_can.txt
>>>>>> create mode 100644 drivers/net/can/xilinx_can.c
>>>>>>
>>>>>> diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt
>>>>>> b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..34f9643
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
>>>>>> @@ -0,0 +1,43 @@
>>>>>> +Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
>>>>>> +---------------------------------------------------------
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible : Should be "xlnx,zynq-can-1.00.a" for Zynq
>>>>> CAN
>>>>>> + controllers and "xlnx,axi-can-1.00.a" for Axi CAN
>>>>>> + controllers.
>>>>>> +- reg : Physical base address and size of the Axi CAN/Zynq
>>>>>> + CANPS registers map.
>>>>>> +- interrupts : Property with a value describing the interrupt
>>>>>> + number.
>>>>>> +- interrupt-parent : Must be core interrupt controller
>>>>>> +- clock-names : List of input clock names - "ref_clk",
>>>>> "aper_clk"
>>>>>> + (See clock bindings for details. Two clocks are
>>>>>> + required for Zynq CAN. For Axi CAN
>>>>>> + case it is one(ref_clk)).
>>>>>> +- clocks : Clock phandles (see clock bindings for details).
>>>>>> +- xlnx,can-tx-dpth : Can Tx fifo depth (Required for Axi CAN).
>>>>>> +- xlnx,can-rx-dpth : Can Rx fifo depth (Required for Axi CAN).
>>>>>> +
>>>>>> +
>>>>>> +Example:
>>>>>> +
>>>>>> +For Zynq CANPS Dts file:
>>>>>> + zynq_can_0: zynq-can@e0008000 {
>>>>>> + compatible = "xlnx,zynq-can-1.00.a";
>>>>>> + clocks = <&clkc 19>, <&clkc 36>;
>>>>>> + clock-names = "ref_clk", "aper_clk";
>>>>>> + reg = <0xe0008000 0x1000>;
>>>>>> + interrupts = <0 28 4>;
>>>>>> + interrupt-parent = <&intc>;
>>>>>
>>>>> Above xlnx,can-{rx,tx}-dpth is mentioned as required, but it's not in the
>>>>> Zynq example.
>>>>
>>>> One of the Difference b/w the AXI CAN and zynq CAN is in AXI CAN the fifo depth(tx,rx)
>>>> Is user configurable. But in case of ZYNQ CAN the fifo depth is fixed for tx and rx fifo's(64)
>>>> Xlnx,can-{rx,tx}-dpth is required only for AXI CAN case it is not required for zynq CAN.
>>>> That's why didn't putted that property in device tree.
>>>
>>> The device tree should be a hardware only description and should not
>>> hold any user configurable data. Please split your patch into two
>>> patches. The first one should add the driver with a fixed fifo size
>>> (e.g. 0x40) for the AXI, too. The second patch should make the fifo
>>> configurable via device tree.
>>
>> can-rx/tx-dpth is not user configurable data as you think.
>> This is FPGA where you can configure this parameter in design tools.
>> It means these 2 values just describe real hardware and user can't just change it
>> for different software behaviour.
>
> I see, thanks for the clarification. I had a short grep over the
> arm/boot/dts folder and it seems that fifo-depth is a more or less
> common property. I think it should be called {rx,tx}-fifo-depth. I'm
> unsure whether we need the xlnx or not.
We are using xlnx prefix for all generated properties that's why
Kedar just kept it there.
>> Also I don't think it is worth to create 2 patches for the same driver
>> where the first one is useless for axi can device. But if you think
>> that it is worth to do we can create 2 patches as you suggested.
>>
>> Also what we can do is to define that this property is required also
>> for zynq which is 0x40 and change code according too.
>
> Good idea, I think this would make the driver more uniform.
ok.
>>> If it's acceptable to describe the fifo usage by device tree, I'd like
>>> to make it a generic CAN driver option. But we have to look around, e.g.
>>> what the Ethernet driver use to configure their hardware.
>>
>> I think the real question is not if this is acceptable or not. It is just
>> reality that we can setup hardware fifo depth and driver has to reflect this
>> because without it driver just doesn't work for axi can.
>>
>> The only remaining question is if we should create generic DT binding
>> for fifo depth. Arnd, Rob: Any opinion about it?
>> Definitely will be worth to have one generic binding if this is generic feature.
>> But if this is just specific feature for us then current properties should
>> be fine.
>>
>> In general all these xlnx,XXX properties just reflect all configurable options
>> which you can setup in design tool which means that provide full hw description
>> with all variants and they are automatically generated from tools.
>>
>> Please let me know what you think.
>
> I like:
>
> rx-fifo-depth
> tx-fifo-depth
No problem with that. Let Kedar to fix it according this and he will send v2 with this.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/
Maintainer of Linux kernel - Xilinx Zynq ARM architecture
Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]
^ permalink raw reply
* New mailing lists
From: Grant Likely @ 2014-02-11 13:13 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: Rob Herring, Mark Rutland, Kumar Gala, Paweł Moll,
Ian Campbell, Yoder Stuart-B08248, David Gibson
Hi all,
As per the discussion two weeks ago[1], I've requested two new mailing
lists; devicetree-spec-u79uwXL29TY76Z2rM5mHXA@public.gmane.org and
devicetree-compiler-u79uwXL29TaiAVqoAR/hOA@public.gmane.org The lists were created to help
filter out the noise for specific device tree topics. The -compiler
list is for discussion specifically related to dtc and other tools.
The -spec list is for "core" binding discussions, so anything that
affects entire subsystems or the kinds of things that would make sense
to be added to ePAPR.
Here are the subscribe links:
http://vger.kernel.org/vger-lists.html#devicetree-compiler
http://vger.kernel.org/vger-lists.html#devicetree-spec
Archives for all devicetree lists can be found here:
http://gmane.org/find.php?list=devicetree
g.
[1] http://www.spinics.net/lists/devicetree/msg19209.html
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 12/14] Documentation: mfd/regulator: s2mps11: Document the "op_mode" bindings
From: Krzysztof Kozlowski @ 2014-02-11 13:03 UTC (permalink / raw)
To: Sangbeom Kim, Samuel Ortiz, Lee Jones, linux-kernel,
linux-samsung-soc
Cc: Kyungmin Park, Marek Szyprowski, Bartlomiej Zolnierkiewicz,
Krzysztof Kozlowski, Chanwoo Choi, Mark Brown, Liam Girdwood,
Tomasz Figa, devicetree, Rob Herring, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala
In-Reply-To: <1392123837-5517-1-git-send-email-k.kozlowski@samsung.com>
Document the "op_mode" properties parsed from DTS by s2mps11 driver.
S2MPS11/S2MPS14 regulators support different modes of operation:
- Always off;
- On/Off controlled by pin/GPIO (PWREN/LDOEN/EMMCEN);
- Always on;
This is very similar to S5M8767 regulator driver which also supports
opmodes (although S5M8767 have also low-power mode).
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
---
Documentation/devicetree/bindings/mfd/s2mps11.txt | 46 +++++++++++++++++++++
1 file changed, 46 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index f69bec294f02..ffad6bfe2ebf 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -54,6 +54,15 @@ BUCK[3, 4], and BUCK[7, 8, 10]
The regulator constraints inside the regulator nodes use the standard regulator
bindings which are documented elsewhere.
+On S2MPS14 chipset the driver additionally supports "op_mode" properties for
+each regulator.
+ - op_mode: describes the different operating modes of the regulators with
+ power mode change in SOC. The different possible values are,
+ 0 - always off mode
+ 1 - on in normal mode
+ 3 - suspend mode
+ (NOTE: value of 2 is reserved)
+
The following are the names of the regulators that the s2mps11 pmic block
supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
as per the datasheet of s2mps11.
@@ -112,3 +121,40 @@ Example:
};
};
};
+
+ s2mps14_pmic@66 {
+ compatible = "samsung,s2mps14-pmic";
+ reg = <0x66>;
+
+ s2m_osc: clocks {
+ compatible = "samsung,s2mps14-clk";
+ #clock-cells = 1;
+ clock-output-names = "xx", "", "zz";
+ };
+
+ regulators {
+ ldo1_reg: LDO1 {
+ regulator-name = "VAP_ALIVE_1.0V";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = "VAP_M1_1.2V";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ op_mode = <1>; /* Normal Mode */
+ };
+
+ buck1_reg: BUCK1 {
+ regulator-name = "VAP_MIF_1.0V";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ op_mode = <3>; /* Standby Mode */
+ };
+ };
+ };
--
1.7.9.5
^ permalink raw reply related
* [PATCH 10/14] Documentation: mfd: s2mps11: Document support for S2MPS14
From: Krzysztof Kozlowski @ 2014-02-11 13:03 UTC (permalink / raw)
To: Sangbeom Kim, Samuel Ortiz, Lee Jones, linux-kernel,
linux-samsung-soc
Cc: Kyungmin Park, Marek Szyprowski, Bartlomiej Zolnierkiewicz,
Krzysztof Kozlowski, Mark Brown, Liam Girdwood, Tomasz Figa,
devicetree, Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell,
Kumar Gala
In-Reply-To: <1392123837-5517-1-git-send-email-k.kozlowski@samsung.com>
Add bindings documentation for S2MPS14 device to the s2mps11 driver.
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Tomasz Figa <t.figa@samsung.com>
Cc: devicetree@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: Kumar Gala <galak@codeaurora.org>
---
Documentation/devicetree/bindings/mfd/s2mps11.txt | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 15ee89c3cc7b..f69bec294f02 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -1,5 +1,5 @@
-* Samsung S2MPS11 Voltage and Current Regulator
+* Samsung S2MPS11 and S2MPS14 Voltage and Current Regulator
The Samsung S2MPS11 is a multi-function device which includes voltage and
current regulators, RTC, charger controller and other sub-blocks. It is
@@ -7,7 +7,7 @@ interfaced to the host controller using an I2C interface. Each sub-block is
addressed by the host system using different I2C slave addresses.
Required properties:
-- compatible: Should be "samsung,s2mps11-pmic".
+- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic".
- reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
Optional properties:
@@ -59,10 +59,14 @@ supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
as per the datasheet of s2mps11.
- LDOn
- - valid values for n are 1 to 38
+ - valid values for n are:
+ - S2MPS11: 1 to 38
+ - S2MPS14: 1 to 25
- Example: LDO1, LD02, LDO28
- BUCKn
- - valid values for n are 1 to 10.
+ - valid values for n are:
+ - S2MPS11: 1 to 10
+ - S2MPS14: 1 to 5
- Example: BUCK1, BUCK2, BUCK9
Example:
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH v6 2/3] clocksource: keystone: add bindings for keystone timer
From: Daniel Lezcano @ 2014-02-11 12:58 UTC (permalink / raw)
To: Ivan Khoronzhuk, santosh.shilimkar-l0cyMroinI0,
rob-VoJi6FS/r0vR7s880joybQ, linux-lFZ/pmaqli7XmaaqVzeoHQ,
galak-sgV2jX0FEOL9JmXXK+q4OQ
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
tglx-hfZtesqFncYOwBW4kG4KsQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
grygorii.strashko-l0cyMroinI0, joshc-sgV2jX0FEOL9JmXXK+q4OQ
In-Reply-To: <1392027058-11680-3-git-send-email-ivan.khoronzhuk-l0cyMroinI0@public.gmane.org>
On 02/10/2014 11:10 AM, Ivan Khoronzhuk wrote:
> This patch provides bindings for the 64-bit timer in the KeyStone
> architecture devices. The timer can be configured as a general-purpose 64-bit
> timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
> timers, each half can operate in conjunction (chain mode) or independently
> (unchained mode) of each other.
>
> It is global timer is a free running up-counter and can generate interrupt
> when the counter reaches preset counter values.
>
> Documentation:
> http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Santosh Shilimkar <santosh.shilimkar-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk-l0cyMroinI0@public.gmane.org>
> ---
Applied to my tree for 3.15
Thanks !
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
--
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 v6 1/3] clocksource: timer-keystone: introduce clocksource driver for Keystone
From: Daniel Lezcano @ 2014-02-11 12:58 UTC (permalink / raw)
To: Ivan Khoronzhuk, santosh.shilimkar, rob, linux, galak
Cc: robh+dt, pawel.moll, mark.rutland, ijc+devicetree, tglx,
devicetree, linux-doc, linux-arm-kernel, linux-kernel,
grygorii.strashko, joshc
In-Reply-To: <1392027058-11680-2-git-send-email-ivan.khoronzhuk@ti.com>
On 02/10/2014 11:10 AM, Ivan Khoronzhuk wrote:
> Add broadcast clock-event device for the Keystone arch.
>
> The timer can be configured as a general-purpose 64-bit timer,
> dual general-purpose 32-bit timers. When configured as dual 32-bit
> timers, each half can operate in conjunction (chain mode) or
> independently (unchained mode) of each other.
>
> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org>
> Acked-by: Santosh shilimkar <santosh.shilimkar@ti.com>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@ti.com>
> ---
Applied to my tree for 3.15
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ 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