* Re: Linux-3.14-rc2: Order of serial node compatibles in DTS files.
From: Kevin Hao @ 2014-02-12 10:31 UTC (permalink / raw)
To: Sebastian Hesselbarth
Cc: Stephen N Chivers, Chris Proctor, Arnd Bergmann, devicetree,
Scott Wood, linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ
In-Reply-To: <52FB3108.3000202-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2551 bytes --]
On Wed, Feb 12, 2014 at 09:30:00AM +0100, Sebastian Hesselbarth wrote:
> On 02/12/2014 06:28 AM, Kevin Hao wrote:
> >On Wed, Feb 12, 2014 at 10:21:58AM +1000, Stephen N Chivers wrote:
> >>But, the Interrupt Controller (MPIC)
> >>goes AWOL and it is down hill from there.
> >>
> >>The MPIC is specified in the DTS as:
> >>
> >> mpic: pic@40000 {
> >> interrupt-controller;
> >> #address-cells = <0>;
> >> #interrupt-cells = <2>;
> >> reg = <0x40000 0x40000>;
> >> compatible = "chrp,open-pic";
> >> device_type = "open-pic";
> >> big-endian;
> >> };
> >>
> >>The board support file has the standard mechanism for allocating
> >>the PIC:
> >>
> >> struct mpic *mpic;
> >>
> >> mpic = mpic_alloc(NULL, 0, 0, 0, 256, " OpenPIC ");
> >> BUG_ON(mpic == NULL);
> >>
> >> mpic_init(mpic);
> >>
> >>I checked for damage in applying the patch and it has applied
> >>correctly.
> >
> >How about the following fix?
> >
> >diff --git a/drivers/of/base.c b/drivers/of/base.c
> >index ff85450d5683..ca91984d3c4b 100644
> >--- a/drivers/of/base.c
> >+++ b/drivers/of/base.c
> >@@ -730,32 +730,40 @@ out:
> > }
> > EXPORT_SYMBOL(of_find_node_with_property);
> >
> >+static int of_match_type_name(const struct device_node *node,
> >+ const struct of_device_id *m)
>
> I am fine with having a sub-function here, but it should rather be
> named of_match_type_or_name.
OK.
>
> >+{
> >+ int match = 1;
> >+
> >+ if (m->name[0])
> >+ match &= node->name && !strcmp(m->name, node->name);
> >+
> >+ if (m->type[0])
> >+ match &= node->type && !strcmp(m->type, node->type);
> >+
> >+ return match;
> >+}
> [...]
> >+ /* Check against matches without compatible string */
> >+ m = matches;
> >+ while (!m->compatible[0] && (m->name[0] || m->type[0])) {
>
> We shouldn't check for anything else than the sentinel here.
> Although I guess yours will not quit early as mine did but that
> way we don't have to worry about it.
Yes, this is still buggy. I will change something like this:
m = matches;
/* Check against matches without compatible string */
while (m->name[0] || m->type[0] || m->compatible[0]) {
if (m->compatible[0]) {
m++;
continue;
}
match = of_match_type_name(node, m);
if (match)
return m;
m++;
}
Thanks,
Kevin
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 4/4] ARM: dts: imx6qdl: Add PU power-domain information to gpc node
From: Philipp Zabel @ 2014-02-12 10:20 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140212072510.GI31484-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
Am Mittwoch, den 12.02.2014, 15:25 +0800 schrieb Shawn Guo:
> On Tue, Feb 11, 2014 at 02:27:11PM +0100, Philipp Zabel wrote:
> > 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>;
> > + };
>
> It's time to have a binding doc for gpc/pgc?
Yes, I'll add one for the next version.
> And I'm not sure
> "fsl,power-domain" is a good compatible as it's so generic.
fsl,imx6q-power-domain ?
Currently there is no need for a compatible property at all, since this
node is just used as a phandle target.
Even the 0x260 register offset is hardcoded in the driver, but this
might change when imx6sl support is added.
regards
Philipp
--
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 v7 12/12] usb: omap: dts: Update DT binding example usage
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: balbi, nm, khilman, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, linux-usb, Roger Quadros, Alan Stern
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
Remove non-compatible id from examples.
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Documentation/devicetree/bindings/usb/ehci-omap.txt | 2 +-
Documentation/devicetree/bindings/usb/ohci-omap3.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt b/Documentation/devicetree/bindings/usb/ehci-omap.txt
index 485a9a1..3dc231c 100644
--- a/Documentation/devicetree/bindings/usb/ehci-omap.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-omap.txt
@@ -21,7 +21,7 @@ Documentation/devicetree/bindings/mfd/omap-usb-host.txt
Example for OMAP4:
usbhsehci: ehci@4a064c00 {
- compatible = "ti,ehci-omap", "usb-ehci";
+ compatible = "ti,ehci-omap";
reg = <0x4a064c00 0x400>;
interrupts = <0 77 0x4>;
};
diff --git a/Documentation/devicetree/bindings/usb/ohci-omap3.txt b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
index 14ab428..ce8c47cff 100644
--- a/Documentation/devicetree/bindings/usb/ohci-omap3.txt
+++ b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
@@ -9,7 +9,7 @@ Required properties:
Example for OMAP4:
usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupts = <0 76 0x4>;
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 11/12] ARM: dts: OMAP2+: Get rid of incompatible ids for USB host nodes
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: balbi, nm, khilman, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, linux-usb, Roger Quadros, Alan Stern
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
The OMAP EHCI and OHCI controllers are not compatible with drivers
other than "ti,ehci-omap" and "ti,ohci-omap3" respectively, so get
rid of the incompatible ids.
CC: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 4 ++--
arch/arm/boot/dts/omap4.dtsi | 4 ++--
arch/arm/boot/dts/omap5.dtsi | 4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index a5fc83b..8e7de9e 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -634,14 +634,14 @@
ranges;
usbhsohci: ohci@48064400 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x48064400 0x400>;
interrupt-parent = <&intc>;
interrupts = <76>;
};
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 39a05ce..ff1b057 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -705,14 +705,14 @@
"refclk_60m_ext_p2";
usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
};
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 d4dae48..f65aa65 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -783,14 +783,14 @@
"refclk_60m_ext_p2";
usbhsohci: ohci@4a064800 {
- compatible = "ti,ohci-omap3", "usb-ohci";
+ compatible = "ti,ohci-omap3";
reg = <0x4a064800 0x400>;
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
};
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>;
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 10/12] ARM: OMAP2+: Remove legacy_init_ehci_clk()
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: balbi, nm, khilman, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, linux-usb, Roger Quadros
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
The necessary clock phandle for the EHCI clock is now provided
via device tree so we no longer need this legacy method.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/mach-omap2/pdata-quirks.c | 16 ----------------
1 file changed, 16 deletions(-)
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 3d5b24d..f1ecd86 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -31,20 +31,6 @@ struct pdata_init {
struct of_dev_auxdata omap_auxdata_lookup[];
static struct twl4030_gpio_platform_data twl_gpio_auxdata;
-/*
- * Create alias for USB host PHY clock.
- * Remove this when clock phandle can be provided via DT
- */
-static void __init __used legacy_init_ehci_clk(char *clkname)
-{
- int ret;
-
- ret = clk_add_alias("main_clk", NULL, clkname, NULL);
- if (ret)
- pr_err("%s:Failed to add main_clk alias to %s :%d\n",
- __func__, clkname, ret);
-}
-
#if IS_ENABLED(CONFIG_WL12XX)
static struct wl12xx_platform_data wl12xx __initdata;
@@ -182,7 +168,6 @@ static void __init omap4_sdp_legacy_init(void)
static void __init omap4_panda_legacy_init(void)
{
omap4_panda_display_init_of();
- legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
#endif
@@ -190,7 +175,6 @@ static void __init omap4_panda_legacy_init(void)
#ifdef CONFIG_SOC_OMAP5
static void __init omap5_uevm_legacy_init(void)
{
- legacy_init_ehci_clk("auxclk1_ck");
}
#endif
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 09/12] ARM: dts: omap5-uevm: Provide USB PHY clock
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony-4v6yS6AI5VpBDgjK7y7TUQ, bcousson-rdvid1DuHRBWk0Htik3J/w,
lee.jones-QSEj5FYQhm4dnm+yROfE0A
Cc: balbi-l0cyMroinI0, nm-l0cyMroinI0, khilman-QSEj5FYQhm4dnm+yROfE0A,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Roger Quadros
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq-l0cyMroinI0@public.gmane.org>
The HS USB 2 PHY gets its clock from AUXCLK1. Provide this
information.
Signed-off-by: Roger Quadros <rogerq-l0cyMroinI0@public.gmane.org>
---
arch/arm/boot/dts/omap5-uevm.dts | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 002fa70..3b99ec2 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -31,12 +31,8 @@
hsusb2_phy: hsusb2_phy {
compatible = "usb-nop-xceiv";
reset-gpios = <&gpio3 16 GPIO_ACTIVE_LOW>; /* gpio3_80 HUB_NRESET */
- /**
- * FIXME
- * Put the right clock phandle here when available
- * clocks = <&auxclk1>;
- * clock-names = "main_clk";
- */
+ clocks = <&auxclk1_ck>;
+ clock-names = "main_clk";
clock-frequency = <19200000>;
};
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* [PATCH v7 08/12] ARM: dts: omap4-panda: Provide USB PHY clock
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: balbi, nm, khilman, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, linux-usb, Roger Quadros
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
The USB PHY gets its clock from AUXCLK3. Provide this
information.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 8 ++------
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05..50b72966 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -83,12 +83,8 @@
compatible = "usb-nop-xceiv";
reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>; /* gpio_62 */
vcc-supply = <&hsusb1_power>;
- /**
- * FIXME:
- * put the right clock phandle here when available
- * clocks = <&auxclk3>;
- * clock-names = "main_clk";
- */
+ clocks = <&auxclk3_ck>;
+ clock-names = "main_clk";
clock-frequency = <19200000>;
};
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 07/12] ARM: dts: omap5: Update omap-usb-host node
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: balbi, nm, khilman, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, linux-usb, Roger Quadros
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/omap5.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index a72813a..d4dae48 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -775,6 +775,12 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ clocks = <&l3init_60m_fclk>,
+ <&xclk60mhsp1_ck>,
+ <&xclk60mhsp2_ck>;
+ clock-names = "refclk_60m_int",
+ "refclk_60m_ext_p1",
+ "refclk_60m_ext_p2";
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 06/12] ARM: dts: omap4: Update omap-usb-host node
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: balbi, nm, khilman, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, linux-usb, Roger Quadros
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
The omap-usb-host driver expects a certain name for internal
and external reference clocks. Provide these clocks.
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index d3f8a6e..39a05ce 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -697,6 +697,12 @@
#address-cells = <1>;
#size-cells = <1>;
ranges;
+ clocks = <&init_60m_fclk>,
+ <&xclk60mhsp1_ck>,
+ <&xclk60mhsp2_ck>;
+ clock-names = "refclk_60m_int",
+ "refclk_60m_ext_p1",
+ "refclk_60m_ext_p2";
usbhsohci: ohci@4a064800 {
compatible = "ti,ohci-omap3", "usb-ohci";
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 05/12] mfd: omap-usb-tll: Update DT clock binding information
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: nm, devicetree, khilman, Samuel Ortiz, linux-usb, linux-kernel,
balbi, linux-omap, linux-arm-kernel, Roger Quadros
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
The omap-usb-tll driver needs one clock for each TLL channel.
Add this information to the DT binding document.
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
Documentation/devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
index 62fe697..c58d704 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -7,6 +7,16 @@ Required properties:
- interrupts : should contain the TLL module's interrupt
- ti,hwmod : must contain "usb_tll_hs"
+Optional properties:
+
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+ clock-names.
+
+- clock-names: should include:
+ * "usb_tll_hs_usb_ch0_clk" - USB TLL channel 0 clock
+ * "usb_tll_hs_usb_ch1_clk" - USB TLL channel 1 clock
+ * "usb_tll_hs_usb_ch2_clk" - USB TLL channel 2 clock
+
Example:
usbhstll: usbhstll@4a062000 {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 04/12] mfd: omap-usb-host: Update DT clock binding information
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: balbi, nm, khilman, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, linux-usb, Roger Quadros, Samuel Ortiz
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
The omap-usb-host driver expects certained named clocks.
Add this information to the DT binding document.
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
.../devicetree/bindings/mfd/omap-usb-host.txt | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
index b381fa6..4721b2d 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -32,6 +32,29 @@ Optional properties:
- single-ulpi-bypass: Must be present if the controller contains a single
ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+ clock-names.
+
+- clock-names: should include:
+ For OMAP3
+ * "usbhost_120m_fck" - 120MHz Functional clock.
+
+ For OMAP4+
+ * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux
+ * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux.
+ * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux
+ * "utmi_p1_gfclk" - Port 1 UTMI clock mux.
+ * "utmi_p2_gfclk" - Port 2 UTMI clock mux.
+ * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate.
+ * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate.
+ * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate.
+ * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate.
+ * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate.
+ * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate.
+ * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate.
+ * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate.
+ * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate.
+
Required properties if child node exists:
- #address-cells: Must be 1
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 03/12] mfd: omap-usb-host: Use clock names as per function for reference clocks
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: nm, devicetree, khilman, Samuel Ortiz, linux-usb, linux-kernel,
balbi, linux-omap, linux-arm-kernel, Roger Quadros
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
Use a meaningful name for the reference clocks so that it indicates the function.
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/mfd/omap-usb-host.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 60a3bed..ce620a8 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -714,21 +714,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
+ omap->xclk60mhsp1_ck = devm_clk_get(dev, "refclk_60m_ext_p1");
if (IS_ERR(omap->xclk60mhsp1_ck)) {
ret = PTR_ERR(omap->xclk60mhsp1_ck);
dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
goto err_mem;
}
- omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck");
+ omap->xclk60mhsp2_ck = devm_clk_get(dev, "refclk_60m_ext_p2");
if (IS_ERR(omap->xclk60mhsp2_ck)) {
ret = PTR_ERR(omap->xclk60mhsp2_ck);
dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
goto err_mem;
}
- omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk");
+ omap->init_60m_fclk = devm_clk_get(dev, "refclk_60m_int");
if (IS_ERR(omap->init_60m_fclk)) {
ret = PTR_ERR(omap->init_60m_fclk);
dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 02/12] mfd: omap-usb-host: Get clocks based on hardware revision
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: nm, devicetree, khilman, Samuel Ortiz, linux-usb, linux-kernel,
balbi, linux-omap, linux-arm-kernel, Roger Quadros
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
Not all revisions have all the clocks so get the necessary clocks
based on hardware revision.
This should avoid un-necessary clk_get failure messages that were
observed earlier.
Be more strict and always fail on clk_get() error.
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
---
drivers/mfd/omap-usb-host.c | 92 +++++++++++++++++++++++++++++++--------------
1 file changed, 64 insertions(+), 28 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 0c3c9a0..60a3bed 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -665,22 +665,41 @@ static int usbhs_omap_probe(struct platform_device *pdev)
goto err_mem;
}
- need_logic_fck = false;
+ /* Set all clocks as invalid to begin with */
+ omap->ehci_logic_fck = omap->init_60m_fclk = ERR_PTR(-ENODEV);
+ omap->utmi_p1_gfclk = omap->utmi_p2_gfclk = ERR_PTR(-ENODEV);
+ omap->xclk60mhsp1_ck = omap->xclk60mhsp2_ck = ERR_PTR(-ENODEV);
+
for (i = 0; i < omap->nports; i++) {
- if (is_ehci_phy_mode(i) || is_ehci_tll_mode(i) ||
- is_ehci_hsic_mode(i))
- need_logic_fck |= true;
+ omap->utmi_clk[i] = ERR_PTR(-ENODEV);
+ omap->hsic480m_clk[i] = ERR_PTR(-ENODEV);
+ omap->hsic60m_clk[i] = ERR_PTR(-ENODEV);
}
- omap->ehci_logic_fck = ERR_PTR(-EINVAL);
- if (need_logic_fck) {
- omap->ehci_logic_fck = devm_clk_get(dev, "ehci_logic_fck");
- if (IS_ERR(omap->ehci_logic_fck)) {
- ret = PTR_ERR(omap->ehci_logic_fck);
- dev_dbg(dev, "ehci_logic_fck failed:%d\n", ret);
+ /* for OMAP3 i.e. USBHS REV1 */
+ if (omap->usbhs_rev == OMAP_USBHS_REV1) {
+ need_logic_fck = false;
+ for (i = 0; i < omap->nports; i++) {
+ if (is_ehci_phy_mode(pdata->port_mode[i]) ||
+ is_ehci_tll_mode(pdata->port_mode[i]) ||
+ is_ehci_hsic_mode(pdata->port_mode[i]))
+
+ need_logic_fck |= true;
+ }
+
+ if (need_logic_fck) {
+ omap->ehci_logic_fck = clk_get(dev, "usbhost_120m_fck");
+ if (IS_ERR(omap->ehci_logic_fck)) {
+ ret = PTR_ERR(omap->ehci_logic_fck);
+ dev_err(dev, "usbhost_120m_fck failed:%d\n",
+ ret);
+ goto err_mem;
+ }
}
+ goto initialize;
}
+ /* for OMAP4+ i.e. USBHS REV2+ */
omap->utmi_p1_gfclk = devm_clk_get(dev, "utmi_p1_gfclk");
if (IS_ERR(omap->utmi_p1_gfclk)) {
ret = PTR_ERR(omap->utmi_p1_gfclk);
@@ -728,54 +747,71 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* them
*/
omap->utmi_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap->utmi_clk[i]))
- dev_dbg(dev, "Failed to get clock : %s : %ld\n",
- clkname, PTR_ERR(omap->utmi_clk[i]));
+ if (IS_ERR(omap->utmi_clk[i])) {
+ ret = PTR_ERR(omap->utmi_clk[i]);
+ dev_err(dev, "Failed to get clock : %s : %d\n",
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic480m_p%d_clk", i + 1);
omap->hsic480m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap->hsic480m_clk[i]))
- dev_dbg(dev, "Failed to get clock : %s : %ld\n",
- clkname, PTR_ERR(omap->hsic480m_clk[i]));
+ if (IS_ERR(omap->hsic480m_clk[i])) {
+ ret = PTR_ERR(omap->hsic480m_clk[i]);
+ dev_err(dev, "Failed to get clock : %s : %d\n",
+ clkname, ret);
+ goto err_mem;
+ }
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic60m_p%d_clk", i + 1);
omap->hsic60m_clk[i] = devm_clk_get(dev, clkname);
- if (IS_ERR(omap->hsic60m_clk[i]))
- dev_dbg(dev, "Failed to get clock : %s : %ld\n",
- clkname, PTR_ERR(omap->hsic60m_clk[i]));
+ if (IS_ERR(omap->hsic60m_clk[i])) {
+ ret = PTR_ERR(omap->hsic60m_clk[i]);
+ dev_err(dev, "Failed to get clock : %s : %d\n",
+ clkname, ret);
+ goto err_mem;
+ }
}
if (is_ehci_phy_mode(pdata->port_mode[0])) {
- /* for OMAP3, clk_set_parent fails */
ret = clk_set_parent(omap->utmi_p1_gfclk,
omap->xclk60mhsp1_ck);
- if (ret != 0)
- dev_dbg(dev, "xclk60mhsp1_ck set parent failed: %d\n",
+ if (ret != 0) {
+ dev_err(dev, "xclk60mhsp1_ck set parent failed: %d\n",
ret);
+ goto err_mem;
+ }
} else if (is_ehci_tll_mode(pdata->port_mode[0])) {
ret = clk_set_parent(omap->utmi_p1_gfclk,
omap->init_60m_fclk);
- if (ret != 0)
- dev_dbg(dev, "P0 init_60m_fclk set parent failed: %d\n",
+ if (ret != 0) {
+ dev_err(dev, "P0 init_60m_fclk set parent failed: %d\n",
ret);
+ goto err_mem;
+ }
}
if (is_ehci_phy_mode(pdata->port_mode[1])) {
ret = clk_set_parent(omap->utmi_p2_gfclk,
omap->xclk60mhsp2_ck);
- if (ret != 0)
- dev_dbg(dev, "xclk60mhsp2_ck set parent failed: %d\n",
+ if (ret != 0) {
+ dev_err(dev, "xclk60mhsp2_ck set parent failed: %d\n",
ret);
+ goto err_mem;
+ }
} else if (is_ehci_tll_mode(pdata->port_mode[1])) {
ret = clk_set_parent(omap->utmi_p2_gfclk,
omap->init_60m_fclk);
- if (ret != 0)
- dev_dbg(dev, "P1 init_60m_fclk set parent failed: %d\n",
+ if (ret != 0) {
+ dev_err(dev, "P1 init_60m_fclk set parent failed: %d\n",
ret);
+ goto err_mem;
+ }
}
+initialize:
omap_usbhs_init(dev);
if (dev->of_node) {
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 01/12] mfd: omap-usb-host: Use resource managed clk_get()
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: balbi, nm, khilman, linux-omap, linux-arm-kernel, linux-kernel,
devicetree, linux-usb, Roger Quadros, Samuel Ortiz
In-Reply-To: <1392200333-28397-1-git-send-email-rogerq@ti.com>
Use devm_clk_get() instead of clk_get().
CC: Lee Jones <lee.jones@linaro.org>
CC: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
drivers/mfd/omap-usb-host.c | 81 +++++++++------------------------------------
1 file changed, 16 insertions(+), 65 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 90b630c..0c3c9a0 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -674,46 +674,46 @@ static int usbhs_omap_probe(struct platform_device *pdev)
omap->ehci_logic_fck = ERR_PTR(-EINVAL);
if (need_logic_fck) {
- omap->ehci_logic_fck = clk_get(dev, "ehci_logic_fck");
+ omap->ehci_logic_fck = devm_clk_get(dev, "ehci_logic_fck");
if (IS_ERR(omap->ehci_logic_fck)) {
ret = PTR_ERR(omap->ehci_logic_fck);
dev_dbg(dev, "ehci_logic_fck failed:%d\n", ret);
}
}
- omap->utmi_p1_gfclk = clk_get(dev, "utmi_p1_gfclk");
+ omap->utmi_p1_gfclk = devm_clk_get(dev, "utmi_p1_gfclk");
if (IS_ERR(omap->utmi_p1_gfclk)) {
ret = PTR_ERR(omap->utmi_p1_gfclk);
dev_err(dev, "utmi_p1_gfclk failed error:%d\n", ret);
- goto err_p1_gfclk;
+ goto err_mem;
}
- omap->utmi_p2_gfclk = clk_get(dev, "utmi_p2_gfclk");
+ omap->utmi_p2_gfclk = devm_clk_get(dev, "utmi_p2_gfclk");
if (IS_ERR(omap->utmi_p2_gfclk)) {
ret = PTR_ERR(omap->utmi_p2_gfclk);
dev_err(dev, "utmi_p2_gfclk failed error:%d\n", ret);
- goto err_p2_gfclk;
+ goto err_mem;
}
- omap->xclk60mhsp1_ck = clk_get(dev, "xclk60mhsp1_ck");
+ omap->xclk60mhsp1_ck = devm_clk_get(dev, "xclk60mhsp1_ck");
if (IS_ERR(omap->xclk60mhsp1_ck)) {
ret = PTR_ERR(omap->xclk60mhsp1_ck);
dev_err(dev, "xclk60mhsp1_ck failed error:%d\n", ret);
- goto err_xclk60mhsp1;
+ goto err_mem;
}
- omap->xclk60mhsp2_ck = clk_get(dev, "xclk60mhsp2_ck");
+ omap->xclk60mhsp2_ck = devm_clk_get(dev, "xclk60mhsp2_ck");
if (IS_ERR(omap->xclk60mhsp2_ck)) {
ret = PTR_ERR(omap->xclk60mhsp2_ck);
dev_err(dev, "xclk60mhsp2_ck failed error:%d\n", ret);
- goto err_xclk60mhsp2;
+ goto err_mem;
}
- omap->init_60m_fclk = clk_get(dev, "init_60m_fclk");
+ omap->init_60m_fclk = devm_clk_get(dev, "init_60m_fclk");
if (IS_ERR(omap->init_60m_fclk)) {
ret = PTR_ERR(omap->init_60m_fclk);
dev_err(dev, "init_60m_fclk failed error:%d\n", ret);
- goto err_init60m;
+ goto err_mem;
}
for (i = 0; i < omap->nports; i++) {
@@ -727,21 +727,21 @@ static int usbhs_omap_probe(struct platform_device *pdev)
* platforms have all clocks and we can function without
* them
*/
- omap->utmi_clk[i] = clk_get(dev, clkname);
+ omap->utmi_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap->utmi_clk[i]))
dev_dbg(dev, "Failed to get clock : %s : %ld\n",
clkname, PTR_ERR(omap->utmi_clk[i]));
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic480m_p%d_clk", i + 1);
- omap->hsic480m_clk[i] = clk_get(dev, clkname);
+ omap->hsic480m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap->hsic480m_clk[i]))
dev_dbg(dev, "Failed to get clock : %s : %ld\n",
clkname, PTR_ERR(omap->hsic480m_clk[i]));
snprintf(clkname, sizeof(clkname),
"usb_host_hs_hsic60m_p%d_clk", i + 1);
- omap->hsic60m_clk[i] = clk_get(dev, clkname);
+ omap->hsic60m_clk[i] = devm_clk_get(dev, clkname);
if (IS_ERR(omap->hsic60m_clk[i]))
dev_dbg(dev, "Failed to get clock : %s : %ld\n",
clkname, PTR_ERR(omap->hsic60m_clk[i]));
@@ -784,7 +784,7 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, "Failed to create DT children: %d\n", ret);
- goto err_alloc;
+ goto err_mem;
}
} else {
@@ -792,40 +792,12 @@ static int usbhs_omap_probe(struct platform_device *pdev)
if (ret) {
dev_err(dev, "omap_usbhs_alloc_children failed: %d\n",
ret);
- goto err_alloc;
+ goto err_mem;
}
}
return 0;
-err_alloc:
- for (i = 0; i < omap->nports; i++) {
- if (!IS_ERR(omap->utmi_clk[i]))
- clk_put(omap->utmi_clk[i]);
- if (!IS_ERR(omap->hsic60m_clk[i]))
- clk_put(omap->hsic60m_clk[i]);
- if (!IS_ERR(omap->hsic480m_clk[i]))
- clk_put(omap->hsic480m_clk[i]);
- }
-
- clk_put(omap->init_60m_fclk);
-
-err_init60m:
- clk_put(omap->xclk60mhsp2_ck);
-
-err_xclk60mhsp2:
- clk_put(omap->xclk60mhsp1_ck);
-
-err_xclk60mhsp1:
- clk_put(omap->utmi_p2_gfclk);
-
-err_p2_gfclk:
- clk_put(omap->utmi_p1_gfclk);
-
-err_p1_gfclk:
- if (!IS_ERR(omap->ehci_logic_fck))
- clk_put(omap->ehci_logic_fck);
-
err_mem:
pm_runtime_disable(dev);
@@ -847,27 +819,6 @@ static int usbhs_omap_remove_child(struct device *dev, void *data)
*/
static int usbhs_omap_remove(struct platform_device *pdev)
{
- struct usbhs_hcd_omap *omap = platform_get_drvdata(pdev);
- int i;
-
- for (i = 0; i < omap->nports; i++) {
- if (!IS_ERR(omap->utmi_clk[i]))
- clk_put(omap->utmi_clk[i]);
- if (!IS_ERR(omap->hsic60m_clk[i]))
- clk_put(omap->hsic60m_clk[i]);
- if (!IS_ERR(omap->hsic480m_clk[i]))
- clk_put(omap->hsic480m_clk[i]);
- }
-
- clk_put(omap->init_60m_fclk);
- clk_put(omap->utmi_p1_gfclk);
- clk_put(omap->utmi_p2_gfclk);
- clk_put(omap->xclk60mhsp2_ck);
- clk_put(omap->xclk60mhsp1_ck);
-
- if (!IS_ERR(omap->ehci_logic_fck))
- clk_put(omap->ehci_logic_fck);
-
pm_runtime_disable(&pdev->dev);
/* remove children */
--
1.8.3.2
^ permalink raw reply related
* [PATCH v7 00/12] USB Host support for OMAP5 uEVM
From: Roger Quadros @ 2014-02-12 10:18 UTC (permalink / raw)
To: tony, bcousson, lee.jones
Cc: nm, devicetree, khilman, linux-usb, linux-kernel, balbi,
linux-omap, linux-arm-kernel, Roger Quadros
Hi Benoit, Tony & Lee,
This patchset brings up USB Host ports and Ethernet port on
the OMAP5 uEVM board. Please queue these for -next.
Tested on:
- OMAP5 uEVM
- Pandaboard ES Rev. B1
- Beagleboard-XM Rev C2
- Beagleboard Rev C4.
Changelog:
v7:
- Rebased on 3.14-rc2
- Removed incompatible ids from DT files and examples
v6:
- Initialized clocks to -ENODEV and split patch 3.
v5:
- Expose all clocks in the DT binding document for mfd:omap-usb-host
and mfd:omap-usb-tll
v4:
- Updated DT binding document for clock binding
v3:
- Rebased on top of 3.13-rc7
cheers,
-roger
--
Roger Quadros (12):
mfd: omap-usb-host: Use resource managed clk_get()
mfd: omap-usb-host: Get clocks based on hardware revision
mfd: omap-usb-host: Use clock names as per function for reference
clocks
mfd: omap-usb-host: Update DT clock binding information
mfd: omap-usb-tll: Update DT clock binding information
ARM: dts: omap4: Update omap-usb-host node
ARM: dts: omap5: Update omap-usb-host node
ARM: dts: omap4-panda: Provide USB PHY clock
ARM: dts: omap5-uevm: Provide USB PHY clock
ARM: OMAP2+: Remove legacy_init_ehci_clk()
ARM: dts: OMAP2+: Get rid of incompatible ids for USB host nodes
usb: omap: dts: Update DT binding example usage
.../devicetree/bindings/mfd/omap-usb-host.txt | 23 +++
.../devicetree/bindings/mfd/omap-usb-tll.txt | 10 ++
.../devicetree/bindings/usb/ehci-omap.txt | 2 +-
.../devicetree/bindings/usb/ohci-omap3.txt | 2 +-
arch/arm/boot/dts/omap3.dtsi | 4 +-
arch/arm/boot/dts/omap4-panda-common.dtsi | 8 +-
arch/arm/boot/dts/omap4.dtsi | 10 +-
arch/arm/boot/dts/omap5-uevm.dts | 8 +-
arch/arm/boot/dts/omap5.dtsi | 10 +-
arch/arm/mach-omap2/pdata-quirks.c | 16 --
drivers/mfd/omap-usb-host.c | 171 ++++++++++-----------
11 files changed, 136 insertions(+), 128 deletions(-)
--
1.8.3.2
^ permalink raw reply
* Re: [RFC PATCH 1/4] ARM: imx6: gpc: Add PU power domain for GPU/VPU
From: Philipp Zabel @ 2014-02-12 10:13 UTC (permalink / raw)
To: Shawn Guo
Cc: Rob Herring, Mark Rutland, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140212071731.GH31484-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
Hi Shawn,
thanks you for the comments.
Am Mittwoch, den 12.02.2014, 15:17 +0800 schrieb Shawn Guo:
> > +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 */
>
> The comment should be dropped?
Ok.
[...]
> > +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);
>
> That means the PU power domain will be always on when neither GPU nor
> VPU is enabled?
You are right, if there is no device in the power domain, it will never
be disabled by the genpd framework. Disabling the domain by default
should help:
> > + 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);
diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
index 65e0f2c..2fc4ea1 100644
--- a/arch/arm/mach-imx/gpc.c
+++ b/arch/arm/mach-imx/gpc.c
@@ -356,7 +356,8 @@ static int imx_gpc_probe(struct platform_device
*pdev)
}
imx6q_pu_domain.of_node = np;
- pm_genpd_init(&imx6q_pu_domain, NULL, false);
+ imx6q_pm_pu_power_off(&imx6q_pu_domain);
+ pm_genpd_init(&imx6q_pu_domain, NULL, true);
bus_register_notifier(&platform_bus_type, &imx6q_platform_nb);
return 0;
> > +
> > + 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
> >
regards
Philipp
--
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
* Re: [PATCH v2 4/4] video: mmp: add device tree support
From: Tomi Valkeinen @ 2014-02-12 10:11 UTC (permalink / raw)
To: Zhou Zhu
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Jean-Christophe Plagniol-Villard, Haojian Zhuang, Sascha Hauer,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chao Xie, Guoqing Li
In-Reply-To: <52F998B7.7060203-eYqpPyKDWXRBDgjK7y7TUQ@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4349 bytes --]
On 11/02/14 05:27, Zhou Zhu wrote:
> On 02/10/2014 08:43 PM, Tomi Valkeinen wrote:
>> How is the panel linked to all this? The nodes above do not refer to the
>> panel.
> We are making panel refer to path, so when panel dev probe, it could
> register to related path.
> The reason we not link from path to panel is our customer sometimes
> asked us to use same image pack (include dts) for different panel types
> in product. We could only add all these panels in dts and detect panel
> dynamically when boot. So moving panel out and making path not link to
> panel but panel link to path would be more straight forward.
Ok.
>>
>>> + ...
>>> + marvell,path = <&path1>;
>>> + ...
>>> +};
>>
>> It's a bit difficult to say much about this, as I have no knowledge
>> about mmp.
>>
>> But I don't quite understand what the pxa988-fb is. Is that some kind of
>> virtual device, only used to set up fbdev side? And pxa988-disp is the
>> actual hardware device?
>>
>> If so, I don't really think pxa988-fb should exist in the DT data at
>> all, as it's not a hardware device.
> Yes, fb is a virtual device for fbdev side.
> In our platforms we may use more than one fb for different paths/output
> panel or multi overlays on same path for composition. So we need to
> configure fb settings like which path/overlay/dmafetch it connected to
> for one or more fbdev.
> Besides, some more configures like yres_virtual size or fixed fb mem
> reserved rather than allocated which depends on platforms are also
> needed although these features are not upstreamed yet.
> So we put fb as a dt node here for these configures.
Ok.
The device tree data should reflect the hardware. Not the software. So
when thinking what kind of DT data you should have, you should forget
the drivers, and just think on HW terms.
You might want to have a look at CDF (Common Display Framework)
discussions on linux-fbdev list, and the "[PATCHv3 00/41] OMAPDSS: DT
support v3" series I've posted (mostly the .dts parts).
It sounds to me that you'd benefit greatly from the CDF, and even if CDF
is not yet merged (and will probably still take time), I'd very much
recommend trying to create your DT data in such a manner that it would
be in the same direction as what is currently suggested for CDF (or in
the OMAPDSS series).
>> Why isn't there just one node for pxa988-disp, which would contain all
>> the above information?
> We have moved out fb/panel from path due to several reasons:
> 1. To simplify the node. If moved these nodes in, it might be:
> disp {
> ...
> path1 {
> ...
> panel-xxx {
> }
> panel-yyy {
> }
> ...
> fb0 {
> }
> fb1 {
> }
> }
> path2 {
> ...
> panel-zzz {
> }
> fb3 {
> }
> }
> }
> Also due to child node type might be different, we could even not
> directly check child of node. The code would be complex.
> 2. the path of node would be too long and not so common.
> e.g. the panel node in dts would be /soc/axi/disp/path1/panel-xxx, and
> in sysfs, node would be /sys/devices/platform/soc/axi/path1/panel-xxx.
> It would be complex and not compatible for platforms when our
> bootloader/user app doing some operations to these nodes.
> If we moved them out, we could move fb/panel out of soc directory so the
> node would be /panel-xxx or /fb1 and simpler and compatible.
I suggest to first think only about the DT data, and create it
correctly. After that you could think how to create compatibility code
in the driver side, so that the legacy sysfs paths are still usable.
The thing with DT data is that it's quite difficult to make big changes
to it later, without writing possibly complex compatibility
functionality. So in my opinion it's worth it to spend a good deal of
time thinking about good DT bindings from the start.
That said, if the driver and hardware in question is for some old SoC,
that's not going to be used on new boards, and the driver is not going
to be used in any future boards, it might be simpler to just make simple
bindings that work for the known set of boards and displays, and be done
with it.
I don't know if that's the case here or not.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply
* [PATCH V2 2/2] ARM: imx: add speed grading check for i.mx6 soc
From: Anson Huang @ 2014-02-12 9:57 UTC (permalink / raw)
To: shawn.guo-QSEj5FYQhm4dnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1392199023-29880-1-git-send-email-b20788-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
The fuse map of speed_grading[1:0] defines the max speed
of ARM, see below the definition:
2b'11: 1200000000Hz;
2b'10: 996000000Hz;
2b'01: 852000000Hz; -- i.MX6Q Only, exclusive with 996MHz.
2b'00: 792000000Hz;
Need to remove all illegal setpoints according to fuse
map.
Signed-off-by: Anson Huang <b20788-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
arch/arm/mach-imx/mach-imx6q.c | 26 +++++++++++++++++++++++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
index d131499..1e12685 100644
--- a/arch/arm/mach-imx/mach-imx6q.c
+++ b/arch/arm/mach-imx/mach-imx6q.c
@@ -253,8 +253,10 @@ static void __init imx6q_init_machine(void)
#define OCOTP_CFG3 0x440
#define OCOTP_CFG3_SPEED_SHIFT 16
#define OCOTP_CFG3_SPEED_1P2GHZ 0x3
+#define OCOTP_CFG3_SPEED_996MHZ 0x2
+#define OCOTP_CFG3_SPEED_852MHZ 0x1
-static void __init imx6q_opp_check_1p2ghz(struct device *cpu_dev)
+static void __init imx6q_opp_check_speed_grading(struct device *cpu_dev)
{
struct device_node *np;
void __iomem *base;
@@ -272,11 +274,29 @@ static void __init imx6q_opp_check_1p2ghz(struct device *cpu_dev)
goto put_node;
}
+ /*
+ * SPEED_GRADING[1:0] defines the max speed of ARM:
+ * 2b'11: 1200000000Hz;
+ * 2b'10: 996000000Hz;
+ * 2b'01: 852000000Hz; -- i.MX6Q Only, exclusive with 996MHz.
+ * 2b'00: 792000000Hz;
+ * We need to set the max speed of ARM according to fuse map.
+ */
val = readl_relaxed(base + OCOTP_CFG3);
val >>= OCOTP_CFG3_SPEED_SHIFT;
- if ((val & 0x3) != OCOTP_CFG3_SPEED_1P2GHZ)
+ val &= 0x3;
+
+ if (val != OCOTP_CFG3_SPEED_1P2GHZ)
if (dev_pm_opp_disable(cpu_dev, 1200000000))
pr_warn("failed to disable 1.2 GHz OPP\n");
+ if (val < OCOTP_CFG3_SPEED_996MHZ)
+ if (dev_pm_opp_disable(cpu_dev, 996000000))
+ pr_warn("failed to disable 996 MHz OPP\n");
+ if (cpu_is_imx6q()) {
+ if (val != OCOTP_CFG3_SPEED_852MHZ)
+ if (dev_pm_opp_disable(cpu_dev, 852000000))
+ pr_warn("failed to disable 852 MHz OPP\n");
+ }
put_node:
of_node_put(np);
@@ -302,7 +322,7 @@ static void __init imx6q_opp_init(void)
goto put_node;
}
- imx6q_opp_check_1p2ghz(cpu_dev);
+ imx6q_opp_check_speed_grading(cpu_dev);
put_node:
of_node_put(np);
--
1.7.9.5
--
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
* [PATCH V2 1/2] ARM: dts: imx6q: add 852MHz setpoint for CPU freq
From: Anson Huang @ 2014-02-12 9:57 UTC (permalink / raw)
To: shawn.guo-QSEj5FYQhm4dnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
According to datasheet, i.MX6Q has setpoint of 852MHz
which is exclusive with 996MHz, the fuse map of speed_grading
defines the max speed of ARM, here we add this 852MHz
setpoint opp info, kernel will check the speed_grading
fuse and remove all illegal setpoints.
Signed-off-by: Anson Huang <b20788-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
---
arch/arm/boot/dts/imx6q.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index 422d169..fadf498 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -30,6 +30,7 @@
/* kHz uV */
1200000 1275000
996000 1250000
+ 852000 1250000
792000 1150000
396000 975000
>;
@@ -37,6 +38,7 @@
/* ARM kHz SOC-PU uV */
1200000 1275000
996000 1250000
+ 852000 1250000
792000 1175000
396000 1175000
>;
--
1.7.9.5
--
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
* Re: [PATCH] ARM: dts: imx6qdl-sabresd: Do not place regulator nodes under simple-bus
From: Mark Rutland @ 2014-02-12 9:54 UTC (permalink / raw)
To: Shawn Guo
Cc: Fabio Estevam,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Fabio Estevam
In-Reply-To: <20140212092227.GA24834-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
On Wed, Feb 12, 2014 at 09:22:30AM +0000, Shawn Guo wrote:
> On Tue, Feb 11, 2014 at 10:31:18PM -0200, Fabio Estevam wrote:
> > From: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> >
> > According to Documentation/devicetree/bindings/regulator/regulator.txt
> > regulator nodes should not be placed under 'simple-bus'.
>
> I failed to read that statement from the binding doc. Can you quote the
> doc specifically on that statement?
The statement is slightly wrong. Rather, regulators are not required to
be on a simple bus.
In this particular case the simple-bus is being used incorrectly. I
describe some of this in the link Fabio provided immediately below, and
I have further comments specific to this case.
>
> >
> > Mark Rutland also explains about it at:
> > http://www.spinics.net/lists/linux-usb/msg101497.html
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> > ---
> > Shawn,
> >
> > I can convert other dts files if you are fine with this approach.
>
> I take it as an unnecessary churn, unless I see the consensus from most
> of DT maintainers and arm-soc folks that we should make this change.
> And see comment below ...
My concern is that the simple-bus is being used in a nonsensical way,
with a meaningless address space and reg values on children. While this
currently works it is not correct, and it's not even necessary. I would
like to limit the misuse of these constructs so as to prevent others
from making the same mistakes.
>
> >
> > arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 51 ++++++++++++++--------------------
> > 1 file changed, 21 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > index 0d816d3..d7df5b2 100644
> > --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > @@ -18,38 +18,29 @@
> > reg = <0x10000000 0x40000000>;
> > };
> >
> > - regulators {
> > - compatible = "simple-bus";
> > - #address-cells = <1>;
> > - #size-cells = <0>;
> > -
> > - reg_usb_otg_vbus: regulator@0 {
> > - compatible = "regulator-fixed";
> > - reg = <0>;
> > - regulator-name = "usb_otg_vbus";
> > - regulator-min-microvolt = <5000000>;
> > - regulator-max-microvolt = <5000000>;
> > - gpio = <&gpio3 22 0>;
> > - enable-active-high;
> > - };
> > + reg_usb_otg_vbus: regulator@0 {
>
> nodename@num should only be used for nodes that have 'reg' property.
> Why are you dropping 'reg' property here? Right, it does not compile if
> you do not drop it. You can take it as a reason of why I endorse
> simple-bus regulators container.
I don't think the logical jump from "it does not compile" to "I endorse
simple-bus regulators container" makes any sense. They're two separate
issues.
The unit-addresses and reg values can be dropped. They are not in the
regulator-fixed binding, and were never necessary. All that's necessary
is a unique name, and unit-addresses (which required a reg) were misused
to provide uniqueness. With that fixed, this will compile.
The question to ask is what address space does the simple-bus represent?
The regulators never defined one in their binding, and the simple-bus is
missing a _required_ ranges property, so it's not in the MMIO space of
the parent. Yet somehow it has a single address cell and no size cells.
This is _clearly_ not a simple-bus. Either it needs to map to the parent
address space in some way (which would mean dropping the reg values and
unit addresses as they would be clearly wrong), or it needs to be
replaced by something that isn't a simple-bus. For the latter case that
would mean you couldn't have MMIO regulators in the same container as
fixed regulators, which would be a bit useless.
As far as I can see, a regulator container node is pointless. It
describes no topological information yet pretends to.
Mark.
>
> Shawn
>
> > + compatible = "regulator-fixed";
> > + regulator-name = "usb_otg_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + gpio = <&gpio3 22 0>;
> > + enable-active-high;
> > + };
> >
> > - reg_usb_h1_vbus: regulator@1 {
> > - compatible = "regulator-fixed";
> > - reg = <1>;
> > - regulator-name = "usb_h1_vbus";
> > - regulator-min-microvolt = <5000000>;
> > - regulator-max-microvolt = <5000000>;
> > - gpio = <&gpio1 29 0>;
> > - enable-active-high;
> > - };
> > + reg_usb_h1_vbus: regulator@1 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "usb_h1_vbus";
> > + regulator-min-microvolt = <5000000>;
> > + regulator-max-microvolt = <5000000>;
> > + gpio = <&gpio1 29 0>;
> > + enable-active-high;
> > + };
> >
> > - reg_audio: regulator@2 {
> > - compatible = "regulator-fixed";
> > - reg = <2>;
> > - regulator-name = "wm8962-supply";
> > - gpio = <&gpio4 10 0>;
> > - enable-active-high;
> > - };
> > + reg_audio: regulator@2 {
> > + compatible = "regulator-fixed";
> > + regulator-name = "wm8962-supply";
> > + gpio = <&gpio4 10 0>;
> > + enable-active-high;
> > };
> >
> > gpio-keys {
> > --
> > 1.8.1.2
> >
>
>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 1/2] usb: dwc3: core: continue probing if usb phy library returns -ENODEV/-ENXIO
From: Kishon Vijay Abraham I @ 2014-02-12 9:46 UTC (permalink / raw)
To: Heikki Krogerus, Felipe Balbi
Cc: george.cherian, rogerq, devicetree, linux-doc, linux-kernel,
linux-omap, linux-arm-kernel, linux-usb
In-Reply-To: <20140129144659.GA22152@xps8300>
On Wednesday 29 January 2014 08:17 PM, Heikki Krogerus wrote:
> Hi,
>
> On Tue, Jan 28, 2014 at 10:30:36AM -0600, Felipe Balbi wrote:
>> On Tue, Jan 28, 2014 at 05:32:30PM +0200, Heikki Krogerus wrote:
>>> On Mon, Jan 27, 2014 at 10:05:20AM -0600, Felipe Balbi wrote:
>>> For the controller drivers the PHYs are just a resource like any
>>> other. The controller drivers can't have any responsibility of
>>> them. They should not care if PHY drivers are available for them or
>>> not, or even if the PHY framework is available or not.
>>
>> huh? If memory isn't available you don't continue probing, right ? If
>> your IORESOURCE_MEM is missing, you also don't continue probing, if your
>> IRQ line is missing, you bail too. Those are also nothing but resources
>> to the driver, what you're asking here is to treat PHY as a _different_
>> resource; which might be fine, but we need to make sure we don't
>> continue probing when a PHY is missing in a platform that certainly
>> needs a PHY.
>
> Yes, true. In my head I was comparing the PHY only to resources like
> gpios, clocks, dma channels, etc. that are often optional to the
> drivers.
>
>>>>>> But I really want to see the argument against using no-op. As far as I
>>>>>> could see, everybody needs a PHY driver one way or another, some
>>>>>> platforms just haven't sent any PHY driver upstream and have their own
>>>>>> hacked up solution to avoid using the PHY layer.
>>>>>
>>>>> Not true in our case. Platforms using Intel's SoCs and chip sets may
>>>>> or may not have controllable USB PHY. Quite often they don't. The
>>>>> Baytrails have usually ULPI PHY for USB2, but that does not mean they
>>>>> provide any vendor specific functions or any need for a driver in any
>>>>> case.
>>>>
>>>> that's different from what I heard.
>>>
>>> I don't know where you got that impression, but it's not true. The
>>> Baytrail SoCs for example don't have internal USB PHYs, which means
>>> the manufacturers using it can select what they want. So we have
>>> boards where PHY driver(s) is needed and boards where it isn't.
>>
>> alright, that explains it ;-) So you have external USB2 and USB3 PHYs ?
>> You have an external PIPE3 interface ? That's quite an achievement,
>> kudos to your HW designers. Getting timing closure on PIPE3 is a
>> difficult task.
>
> No, only the USB2 PHY is external. I'm giving you wrong information,
> I'm sorry about that. Need to concentrate on what I'm writing.
>
> <snip>
>
>>> This is really good to get. We have some projects where we are dealing
>>> with more embedded environments, like IVI, where the kernel should be
>>> stripped of everything useless. Since the PHYs are autonomous, we
>>> should be able to disable the PHY libraries/frameworks.
>>
>> hmmm, in that case it's a lot easier to treat. We can use
>> ERR_PTR(-ENXIO) as an indication that the framework is disabled, or
>> something like that.
>>
>> The difficult is really reliably supporting e.g. OMAP5 (which won't work
>> without a PHY) and your BayTrail with autonomous PHYs. What can we use
>> as an indication ?
>
> OMAP has it's own glue driver, so shouldn't it depend on the PHY
> layer?
right, but the PHY is connected to the dwc3 core and not to the glue.
>
>> I mean, I need to know that a particular platform depends on a PHY
>> driver before I decide to return -EPROBE_DEFER or just assume the PHY
>> isn't needed ;-)
>
> I don't think dwc3 (core) should care about that. The PHY layer needs
> to tell us that. If the PHY driver that the platform depends is not
> available yet, the PHY layer returns -EPROBE_DEFER and dwc3 ends up
> returning -EPROBE_DEFER.
I don't think the PHY layer can 'reliably' tell if PHY driver is available or
not. Consider when the phy_provider_register fails, there is no way to know if
PHY driver is available or not. There are a few cases where PHY layer returns
-EPROBE_DEFER but none of them can tell for sure that PHY driver is either
available and failed or not available at all. It would be best for us to leave
that to the platforms if we want to be sure if the platform needs a PHY or not.
Thanks
Kishon
^ permalink raw reply
* RE: [PATCH 2/2] ARM: imx: add speed grading check for i.mx6 soc
From: Anson.Huang-KZfg59tc24xl57MIdRCFDg @ 2014-02-12 9:44 UTC (permalink / raw)
To: Shawn Guo
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <20140212093926.GB24834-rvtDTF3kK1ictlrPMvKcciBecyulp+rMXqFh9Ls21Oc@public.gmane.org>
Right, will improve it in V2, thanks.
Best Regards.
Anson Huang
Freescale Semiconductor Shanghai
Tel:021-28937058
>-----Original Message-----
>From: Shawn Guo [mailto:shawn.guo-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org]
>Sent: Wednesday, February 12, 2014 5:39 PM
>To: Huang Yongcai-B20788
>Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org; devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-arm-
>kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>Subject: Re: [PATCH 2/2] ARM: imx: add speed grading check for i.mx6 soc
>
>On Wed, Feb 12, 2014 at 03:56:17PM +0800, Anson Huang wrote:
>> The fuse map of speed_grading[1:0] defines the max speed of ARM, see
>> below the definition:
>>
>> 2b'11: 1200000000Hz;
>> 2b'10: 996000000Hz;
>> 2b'01: 852000000Hz; -- i.MX6Q Only, exclusive with 996MHz.
>> 2b'00: 792000000Hz;
>>
>> Need to remove all illegal setpoints according to fuse map.
>>
>> Signed-off-by: Anson Huang <b20788-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
>> ---
>> arch/arm/mach-imx/mach-imx6q.c | 22 ++++++++++++++++++++--
>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/mach-imx/mach-imx6q.c
>> b/arch/arm/mach-imx/mach-imx6q.c index f9cbbf9..ad9da1f 100644
>> --- a/arch/arm/mach-imx/mach-imx6q.c
>> +++ b/arch/arm/mach-imx/mach-imx6q.c
>> @@ -219,8 +219,10 @@ static void __init imx6q_init_machine(void)
>> #define OCOTP_CFG3 0x440
>> #define OCOTP_CFG3_SPEED_SHIFT 16
>> #define OCOTP_CFG3_SPEED_1P2GHZ 0x3
>> +#define OCOTP_CFG3_SPEED_996MHZ 0x2
>> +#define OCOTP_CFG3_SPEED_852MHZ 0x1
>>
>> -static void __init imx6q_opp_check_1p2ghz(struct device *cpu_dev)
>> +static void __init imx6q_opp_check_speed_grading(struct device
>> +*cpu_dev)
>> {
>> struct device_node *np;
>> void __iomem *base;
>> @@ -238,11 +240,27 @@ static void __init imx6q_opp_check_1p2ghz(struct
>device *cpu_dev)
>> goto put_node;
>> }
>>
>> + /*
>> + * SPEED_GRADING[1:0] defines the max speed of ARM:
>> + * 2b'11: 1200000000Hz;
>> + * 2b'10: 996000000Hz;
>> + * 2b'01: 852000000Hz; -- i.MX6Q Only, exclusive with 996MHz.
>> + * 2b'00: 792000000Hz;
>> + * We need to set the max speed of ARM according to fuse map.
>> + */
>> val = readl_relaxed(base + OCOTP_CFG3);
>> val >>= OCOTP_CFG3_SPEED_SHIFT;
>
> val &= 0x3;
>
>Then you do not need to do it in every if-clause below.
>
>> if ((val & 0x3) != OCOTP_CFG3_SPEED_1P2GHZ)
>> if (dev_pm_opp_disable(cpu_dev, 1200000000))
>> pr_warn("failed to disable 1.2 GHz OPP\n");
>> + if ((val & 0x3) < OCOTP_CFG3_SPEED_996MHZ)
>> + if (dev_pm_opp_disable(cpu_dev, 996000000))
>> + pr_warn("failed to disable 996 MHz OPP\n");
>> + if (cpu_is_imx6q()) {
>> + if ((val & 0x3) != OCOTP_CFG3_SPEED_852MHZ)
>
> if (cpu_is_imx6q() && val != OCOTP_CFG3_SPEED_852MHZ)
>
>Shawn
>
>> + if (dev_pm_opp_disable(cpu_dev, 852000000))
>> + pr_warn("failed to disable 852 MHz OPP\n");
>> + }
>>
>> put_node:
>> of_node_put(np);
>> @@ -268,7 +286,7 @@ static void __init imx6q_opp_init(void)
>> goto put_node;
>> }
>>
>> - imx6q_opp_check_1p2ghz(cpu_dev);
>> + imx6q_opp_check_speed_grading(cpu_dev);
>>
>> put_node:
>> of_node_put(np);
>> --
>> 1.7.9.5
>>
>>
--
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 2/2] ARM: imx: add speed grading check for i.mx6 soc
From: Shawn Guo @ 2014-02-12 9:39 UTC (permalink / raw)
To: Anson Huang
Cc: kernel-bIcnvbaLZ9MEGnE8C9+IrQ, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1392191777-15703-2-git-send-email-b20788-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
On Wed, Feb 12, 2014 at 03:56:17PM +0800, Anson Huang wrote:
> The fuse map of speed_grading[1:0] defines the max speed
> of ARM, see below the definition:
>
> 2b'11: 1200000000Hz;
> 2b'10: 996000000Hz;
> 2b'01: 852000000Hz; -- i.MX6Q Only, exclusive with 996MHz.
> 2b'00: 792000000Hz;
>
> Need to remove all illegal setpoints according to fuse
> map.
>
> Signed-off-by: Anson Huang <b20788-KZfg59tc24xl57MIdRCFDg@public.gmane.org>
> ---
> arch/arm/mach-imx/mach-imx6q.c | 22 ++++++++++++++++++++--
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index f9cbbf9..ad9da1f 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -219,8 +219,10 @@ static void __init imx6q_init_machine(void)
> #define OCOTP_CFG3 0x440
> #define OCOTP_CFG3_SPEED_SHIFT 16
> #define OCOTP_CFG3_SPEED_1P2GHZ 0x3
> +#define OCOTP_CFG3_SPEED_996MHZ 0x2
> +#define OCOTP_CFG3_SPEED_852MHZ 0x1
>
> -static void __init imx6q_opp_check_1p2ghz(struct device *cpu_dev)
> +static void __init imx6q_opp_check_speed_grading(struct device *cpu_dev)
> {
> struct device_node *np;
> void __iomem *base;
> @@ -238,11 +240,27 @@ static void __init imx6q_opp_check_1p2ghz(struct device *cpu_dev)
> goto put_node;
> }
>
> + /*
> + * SPEED_GRADING[1:0] defines the max speed of ARM:
> + * 2b'11: 1200000000Hz;
> + * 2b'10: 996000000Hz;
> + * 2b'01: 852000000Hz; -- i.MX6Q Only, exclusive with 996MHz.
> + * 2b'00: 792000000Hz;
> + * We need to set the max speed of ARM according to fuse map.
> + */
> val = readl_relaxed(base + OCOTP_CFG3);
> val >>= OCOTP_CFG3_SPEED_SHIFT;
val &= 0x3;
Then you do not need to do it in every if-clause below.
> if ((val & 0x3) != OCOTP_CFG3_SPEED_1P2GHZ)
> if (dev_pm_opp_disable(cpu_dev, 1200000000))
> pr_warn("failed to disable 1.2 GHz OPP\n");
> + if ((val & 0x3) < OCOTP_CFG3_SPEED_996MHZ)
> + if (dev_pm_opp_disable(cpu_dev, 996000000))
> + pr_warn("failed to disable 996 MHz OPP\n");
> + if (cpu_is_imx6q()) {
> + if ((val & 0x3) != OCOTP_CFG3_SPEED_852MHZ)
if (cpu_is_imx6q() && val != OCOTP_CFG3_SPEED_852MHZ)
Shawn
> + if (dev_pm_opp_disable(cpu_dev, 852000000))
> + pr_warn("failed to disable 852 MHz OPP\n");
> + }
>
> put_node:
> of_node_put(np);
> @@ -268,7 +286,7 @@ static void __init imx6q_opp_init(void)
> goto put_node;
> }
>
> - imx6q_opp_check_1p2ghz(cpu_dev);
> + imx6q_opp_check_speed_grading(cpu_dev);
>
> put_node:
> of_node_put(np);
> --
> 1.7.9.5
>
>
--
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/3] Documentation: mfd: Add binding document for S2MPA01
From: Sachin Kamat @ 2014-02-12 9:32 UTC (permalink / raw)
To: LKML
Cc: devicetree@vger.kernel.org, Mark Rutland, Sangbeom Kim, Lee Jones,
Sachin Kamat, Rob Herring
In-Reply-To: <1389266554-23463-3-git-send-email-sachin.kamat@linaro.org>
On 9 January 2014 16:52, Sachin Kamat <sachin.kamat@linaro.org> wrote:
> Added initial binding documentation for S2MPA01 MFD.
>
> Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
> ---
> * Re-organised as suggested by Mark Rutland.
> ---
> Documentation/devicetree/bindings/mfd/s2mpa01.txt | 86 +++++++++++++++++++++
> 1 file changed, 86 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/s2mpa01.txt
>
> diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> new file mode 100644
> index 000000000000..70879b92b24b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
> @@ -0,0 +1,86 @@
> +
> +* Samsung S2MPA01 Voltage and Current Regulator
> +
> +The Samsung S2MPA01 is a multi-function device which includes high
> +efficiency buck converters including Dual-Phase buck converter, various LDOs,
> +and an RTC. It is 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,s2mpa01-pmic".
> +- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66.
> +
> +Optional properties:
> +- interrupt-parent: Specifies the phandle of the interrupt controller to which
> + the interrupts from s2mpa01 are delivered to.
> +- interrupts: Interrupt specifier for interrupt source (connected to SoC).
> +
> +Optional nodes:
> +- regulators: The regulators of s2mpa01 that have to be instantiated should be
> + included in a sub-node named 'regulators'. Regulator nodes and constraints
> + included in this sub-node use the standard regulator bindings which are
> + documented elsewhere.
> +
> +Properties for BUCK regulator nodes:
> + regulator-ramp-delay for BUCKs = [6250/12500(default)/25000/50000] uV/us
> +
> + BUCK[1/2/3/4] supports disabling ramp delay on hardware, so explictly
> + regulator-ramp-delay = <0> can be used for them to disable ramp delay.
> + In the absence of the regulator-ramp-delay property, the default ramp
> + delay will be used.
> +
> + NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set
> + for a particular group of BUCKs. So provide same regulator-ramp-delay<value>.
> + Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6],
> + BUCK[2, 4], and BUCK[8, 9, 10]
> +
> +The following are the names of the regulators that the s2mpa01 PMIC block
> +supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
> +as per the datasheet of s2mpa01.
> +
> + - LDOn
> + - valid values for n are 1 to 26
> + - Example: LDO1, LD02, LDO26
> + - BUCKn
> + - valid values for n are 1 to 10.
> + - Example: BUCK1, BUCK2, BUCK9
> +
> +Example:
> +
> + s2mpa01_pmic@66 {
> + compatible = "samsung,s2mpa01-pmic";
> + reg = <0x66>;
> +
> + regulators {
> + ldo1_reg: LDO1 {
> + regulator-name = "VDD_ALIVE";
> + regulator-min-microvolt = <1000000>;
> + regulator-max-microvolt = <1000000>;
> + };
> +
> + ldo2_reg: LDO2 {
> + regulator-name = "VDDQ_MMC2";
> + regulator-min-microvolt = <2800000>;
> + regulator-max-microvolt = <2800000>;
> + regulator-always-on;
> + };
> +
> + buck1_reg: BUCK1 {
> + regulator-name = "vdd_mif";
> + regulator-min-microvolt = <950000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + buck2_reg: BUCK2 {
> + regulator-name = "vdd_arm";
> + regulator-min-microvolt = <950000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-ramp-delay = <50000>;
> + };
> + };
> + };
> --
> 1.7.9.5
>
Can I please have an ack from the DT maintainers so that this series
can be picked by Lee.
--
With warm regards,
Sachin
^ permalink raw reply
* Re: [PATCH] ARM: dts: qcom: Add RNG device tree node
From: Stanimir Varbanov @ 2014-02-12 9:28 UTC (permalink / raw)
To: Stephen Boyd
Cc: devicetree, linux-arm-kernel, linux-arm-msm, Kumar Gala,
Mark Rutland, Rob Herring, Pawel Moll, Ian Campbell, David Brown
In-Reply-To: <20140208033740.GD10784@codeaurora.org>
Hi, Stephen
On 02/08/2014 05:37 AM, Stephen Boyd wrote:
> On 02/07, Stanimir Varbanov wrote:
>> Add the necessary DT node to probe the rng driver on
>> msm8974 platforms.
>>
>
> Looks good. We should add it to msm8960-cdp and enable the driver
> in the defconfig as well.
Sure, I can prepare a patch. Unfortunately I haven't msm8960 CDP to test it.
>
>> Signed-off-by: Stanimir Varbanov <svarbanov@mm-sol.com>
>
> Acked-by: Stephen Boyd <sboyd@codeaurora.org>
>
Thanks!
regards,
Stan
^ 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