[PATCH v2 0/6] ARM: AM4372: Enable RTC

[PATCH v2 0/6] ARM: AM4372: Enable RTC

[Keerthy]

The series brings multiple fixes needed to get rtc ticking
on am437x-gp-evm.

This is tested on top of omap-for-v4.3/dt-v2 branch. Boot tested on
AM437X-GP-EVM also tested rtc ticking via sysfs nodes. 

The series is on top of this patch:
http://comments.gmane.org/gmane.linux.drivers.devicetree/131026

Keerthy (6):
  ARM: dts: AM43XX: Add clk_32k_rtc node
  rtc: omap: Add external clock enabling support
  ARM: AM43xx: Introduce a separate soc_is function for am438x series of
    SoCs
  ARM: dts: am43x-epos-evm: Add the am438 compatible string
  ARM: AM43XX: HWMOD: Add rtc hwmod
  ARM: dts: AM437X-GP-EVM: Enable rtc

Changes in v2:

  * Couple of patches already pulled in.
  * Removed dt ext-clk-src and made use of clocks property to determine
    presence of external clock source.

 .../devicetree/bindings/arm/omap/omap.txt          |  3 +++
 arch/arm/boot/dts/am4372.dtsi                      |  2 ++
 arch/arm/boot/dts/am437x-gp-evm.dts                |  4 +++
 arch/arm/boot/dts/am43x-epos-evm.dts               |  2 +-
 arch/arm/boot/dts/am43xx-clocks.dtsi               |  6 +++++
 arch/arm/mach-omap2/board-generic.c                |  1 +
 arch/arm/mach-omap2/id.c                           |  2 ++
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c         | 16 ++++++++++--
 arch/arm/mach-omap2/soc.h                          |  7 +++--
 drivers/rtc/rtc-omap.c                             | 30 ++++++++++++++++++++++
 10 files changed, 68 insertions(+), 5 deletions(-)

-- 
1.9.1

--
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

[PATCH v2 1/6] ARM: dts: AM43XX: Add clk_32k_rtc node

[Keerthy]

Add the clk_32k_rtc this is the external clock source
for the rtc.

Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/am43xx-clocks.dtsi | 6 ++++++
 drivers/clk/ti/clk-43xx.c            | 1 +
 2 files changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/am43xx-clocks.dtsi b/arch/arm/boot/dts/am43xx-clocks.dtsi
index d0c0dfa..31f1d96 100644
--- a/arch/arm/boot/dts/am43xx-clocks.dtsi
+++ b/arch/arm/boot/dts/am43xx-clocks.dtsi
@@ -159,6 +159,12 @@
 		clock-frequency = <32768>;
 	};
 
+	clk_32k_rtc: clk_32k_rtc {
+		#clock-cells = <0>;
+		compatible = "fixed-clock";
+		clock-frequency = <32768>;
+	};
+
 	clk_rc32k_ck: clk_rc32k_ck {
 		#clock-cells = <0>;
 		compatible = "fixed-clock";
diff --git a/drivers/clk/ti/clk-43xx.c b/drivers/clk/ti/clk-43xx.c
index 3795fce..af393c2 100644
--- a/drivers/clk/ti/clk-43xx.c
+++ b/drivers/clk/ti/clk-43xx.c
@@ -22,6 +22,7 @@
 static struct ti_dt_clk am43xx_clks[] = {
 	DT_CLK(NULL, "clk_32768_ck", "clk_32768_ck"),
 	DT_CLK(NULL, "clk_rc32k_ck", "clk_rc32k_ck"),
+	DT_CLK(NULL, "clk_32k_rtc", "clk_32k_rtc"),
 	DT_CLK(NULL, "virt_19200000_ck", "virt_19200000_ck"),
 	DT_CLK(NULL, "virt_24000000_ck", "virt_24000000_ck"),
 	DT_CLK(NULL, "virt_25000000_ck", "virt_25000000_ck"),
-- 
1.9.1

--
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

[PATCH v2 2/6] rtc: omap: Add external clock enabling support

[Keerthy]

Switch to external clock source during suspend and switch back
to internal source on resume. This helps rtc ticking across suspend.

Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/am4372.dtsi |  2 ++
 drivers/rtc/rtc-omap.c        | 31 +++++++++++++++++++++++++++++++
 2 files changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index d99b2ee..756819f 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -336,6 +336,8 @@
 			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH
 				      GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
 			ti,hwmods = "rtc";
+			clocks = <&clk_32768_ck>, <&clk_32k_rtc>;
+			clock-names = "int-clk", "ext-clk";
 			status = "disabled";
 		};
 
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 8b6355f..cfc8558 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -25,6 +25,7 @@
 #include <linux/of_device.h>
 #include <linux/pm_runtime.h>
 #include <linux/io.h>
+#include <linux/clk.h>
 
 /*
  * The OMAP RTC is a year/month/day/hours/minutes/seconds BCD clock
@@ -107,6 +108,7 @@
 
 /* OMAP_RTC_OSC_REG bit fields: */
 #define OMAP_RTC_OSC_32KCLK_EN		BIT(6)
+#define OMAP_RTC_OSC_SEL_32KCLK_SRC	BIT(3)
 
 /* OMAP_RTC_IRQWAKEEN bit fields: */
 #define OMAP_RTC_IRQWAKEEN_ALARM_WAKEEN	BIT(1)
@@ -136,6 +138,7 @@ struct omap_rtc {
 	int irq_timer;
 	u8 interrupts_reg;
 	bool is_pmic_controller;
+	bool has_ext_clk;
 	const struct omap_rtc_device_type *type;
 };
 
@@ -525,6 +528,7 @@ static int omap_rtc_probe(struct platform_device *pdev)
 {
 	struct omap_rtc	*rtc;
 	struct resource	*res;
+	struct clk *ext_clk;
 	u8 reg, mask, new_ctrl;
 	const struct platform_device_id *id_entry;
 	const struct of_device_id *of_id;
@@ -553,6 +557,10 @@ static int omap_rtc_probe(struct platform_device *pdev)
 	if (rtc->irq_alarm <= 0)
 		return -ENOENT;
 
+	ext_clk = devm_clk_get(&pdev->dev, "ext-clk");
+	if (!IS_ERR(ext_clk))
+		rtc->has_ext_clk = true;
+
 	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 	rtc->base = devm_ioremap_resource(&pdev->dev, res);
 	if (IS_ERR(rtc->base))
@@ -698,6 +706,7 @@ static int __exit omap_rtc_remove(struct platform_device *pdev)
 static int omap_rtc_suspend(struct device *dev)
 {
 	struct omap_rtc *rtc = dev_get_drvdata(dev);
+	u8 reg;
 
 	rtc->interrupts_reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
 
@@ -711,6 +720,18 @@ static int omap_rtc_suspend(struct device *dev)
 		enable_irq_wake(rtc->irq_alarm);
 	else
 		rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
+
+	/*
+	 * If we have the luxury of external clock then
+	 * Switch to external clock so we can keep ticking
+	 * acorss suspend
+	 */
+	if (rtc->has_ext_clk) {
+		reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
+		rtc_write(rtc, OMAP_RTC_OSC_REG, reg |
+			  OMAP_RTC_OSC_SEL_32KCLK_SRC);
+	}
+
 	rtc->type->lock(rtc);
 
 	/* Disable the clock/module */
@@ -722,6 +743,7 @@ static int omap_rtc_suspend(struct device *dev)
 static int omap_rtc_resume(struct device *dev)
 {
 	struct omap_rtc *rtc = dev_get_drvdata(dev);
+	u8 reg;
 
 	/* Enable the clock/module so that we can access the registers */
 	pm_runtime_get_sync(dev);
@@ -731,6 +753,15 @@ static int omap_rtc_resume(struct device *dev)
 		disable_irq_wake(rtc->irq_alarm);
 	else
 		rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, rtc->interrupts_reg);
+	/*
+	 * Switch back to internal source
+	 */
+	if (rtc->has_ext_clk) {
+		reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
+		reg &= ~OMAP_RTC_OSC_SEL_32KCLK_SRC;
+		rtc_write(rtc, OMAP_RTC_OSC_REG, reg);
+	}
+
 	rtc->type->lock(rtc);
 
 	return 0;
-- 
1.9.1

--
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

Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support

[Alexandre Belloni]

Hi,

This seems better but:

On 10/08/2015 at 14:58:22 +0530, Keerthy wrote :
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index d99b2ee..756819f 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -336,6 +336,8 @@
>  			interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH
>  				      GIC_SPI 76 IRQ_TYPE_LEVEL_HIGH>;
>  			ti,hwmods = "rtc";
> +			clocks = <&clk_32768_ck>, <&clk_32k_rtc>;
> +			clock-names = "int-clk", "ext-clk";
>  			status = "disabled";
>  		};
>  

This change has to be part of another patch.

> @@ -698,6 +706,7 @@ static int __exit omap_rtc_remove(struct platform_device *pdev)
>  static int omap_rtc_suspend(struct device *dev)
>  {
>  	struct omap_rtc *rtc = dev_get_drvdata(dev);
> +	u8 reg;
>  
>  	rtc->interrupts_reg = rtc_read(rtc, OMAP_RTC_INTERRUPTS_REG);
>  
> @@ -711,6 +720,18 @@ static int omap_rtc_suspend(struct device *dev)
>  		enable_irq_wake(rtc->irq_alarm);
>  	else
>  		rtc_write(rtc, OMAP_RTC_INTERRUPTS_REG, 0);
> +
> +	/*
> +	 * If we have the luxury of external clock then
> +	 * Switch to external clock so we can keep ticking
> +	 * acorss suspend
> +	 */
> +	if (rtc->has_ext_clk) {
> +		reg = rtc_read(rtc, OMAP_RTC_OSC_REG);
> +		rtc_write(rtc, OMAP_RTC_OSC_REG, reg |
> +			  OMAP_RTC_OSC_SEL_32KCLK_SRC);
> +	}
> +

You should probably prepare/enable the clock before switching to it. I
know it doesn't matter right now but that may not be the case on other
boards.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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

Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support

[Paul Walmsley]

On Mon, 10 Aug 2015, Keerthy wrote:

> Switch to external clock source during suspend and switch back
> to internal source on resume. This helps rtc ticking across suspend.

Doesn't this type of dynamic switching make it likely that ticks will be 
lost?

If the external, optional source is present, isn't it best just to use the 
external source 100% of the time?


- Paul
--
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

Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support

[Keerthy]

On Wednesday 12 August 2015 07:57 PM, Paul Walmsley wrote:
> On Mon, 10 Aug 2015, Keerthy wrote:
>
>> Switch to external clock source during suspend and switch back
>> to internal source on resume. This helps rtc ticking across suspend.
>
> Doesn't this type of dynamic switching make it likely that ticks will be
> lost?
>
> If the external, optional source is present, isn't it best just to use the
> external source 100% of the time?


Paul,

The intent here is to switch to a higher precision clock which is the 
internal clock when available.

Alexandre,

Is dynamic switching preferred over sticking  to external clock always 
if present?

Regards,
Keerthy
>
>
> - Paul
>
--
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

Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support

[Alexandre Belloni]

Hi,

On 13/08/2015 at 00:38:50 +0530, Keerthy wrote :
> The intent here is to switch to a higher precision clock which is the
> internal clock when available.
> 
> Alexandre,
> 
> Is dynamic switching preferred over sticking  to external clock always if
> present?
> 

I'd say that I don't really care. I'd say the best would be to make a
decision based on clock-accuracy but maybe that is an information you
don't have yet. Anyway, this could be added at a later date.

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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

Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support

[Paul Walmsley]

Hi guys

On Wed, 12 Aug 2015, Alexandre Belloni wrote:

> On 13/08/2015 at 00:38:50 +0530, Keerthy wrote :
> > The intent here is to switch to a higher precision clock which is the
> > internal clock when available.
> > 
> > Alexandre,
> > 
> > Is dynamic switching preferred over sticking  to external clock always if
> > present?
> 
> I'd say that I don't really care. I'd say the best would be to make a
> decision based on clock-accuracy but maybe that is an information you
> don't have yet. Anyway, this could be added at a later date.

Either the clock mux logic is glitchless, in which case the RTC is likely 
to lose at least 31 microseconds per switch; or it's not glitchless, in 
which case it's unsafe to switch the RTC clock source while the clock 
isn't gated.  Keerthy, before submitting this patch for merging, I'd 
suggest consulting your hardware folks to figure out which case it is.


- Paul
--
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

Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support

[Keerthy]

On Friday 14 August 2015 01:47 AM, Paul Walmsley wrote:
> Hi guys
>
> On Wed, 12 Aug 2015, Alexandre Belloni wrote:
>
>> On 13/08/2015 at 00:38:50 +0530, Keerthy wrote :
>>> The intent here is to switch to a higher precision clock which is the
>>> internal clock when available.
>>>
>>> Alexandre,
>>>
>>> Is dynamic switching preferred over sticking  to external clock always if
>>> present?
>>
>> I'd say that I don't really care. I'd say the best would be to make a
>> decision based on clock-accuracy but maybe that is an information you
>> don't have yet. Anyway, this could be added at a later date.
>
> Either the clock mux logic is glitchless, in which case the RTC is likely
> to lose at least 31 microseconds per switch; or it's not glitchless, in
> which case it's unsafe to switch the RTC clock source while the clock
> isn't gated.  Keerthy, before submitting this patch for merging, I'd
> suggest consulting your hardware folks to figure out which case it is.

Paul,

Thanks. Yes so i am doing the static way first. Keeping external clock 
always if available. Switching dynamically can be done later with more 
clarifications.

Thanks,
Keerthy

>
>
> - Paul
>
--
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

Re: [PATCH v2 2/6] rtc: omap: Add external clock enabling support

[Alexandre Belloni]

On 13/08/2015 at 20:17:23 +0000, Paul Walmsley wrote :
> > I'd say that I don't really care. I'd say the best would be to make a
> > decision based on clock-accuracy but maybe that is an information you
> > don't have yet. Anyway, this could be added at a later date.
> 
> Either the clock mux logic is glitchless, in which case the RTC is likely 
> to lose at least 31 microseconds per switch; or it's not glitchless, in 
> which case it's unsafe to switch the RTC clock source while the clock 
> isn't gated.  Keerthy, before submitting this patch for merging, I'd 
> suggest consulting your hardware folks to figure out which case it is.
> 

Don't take me wrong, your point is perfectly valid. I was just saying
that I didn't care what was done in the driver. Obviously, this has to
match what is best from a hardware point of view. But since we agreed on
the DT bindings, I'd say that we can still adjust the driver later.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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

[PATCH v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

[Keerthy]

EPOS evms are fitted with a separate family of am43xx SoCs and are named
am438x series. Adding a separate soc_is function to identify that
particular series of SoCs. This can be done to avoid unnecessarily
registering hwmods like rtc when not needed on EPOS evms.

Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
---
 Documentation/devicetree/bindings/arm/omap/omap.txt | 3 +++
 arch/arm/mach-omap2/board-generic.c                 | 1 +
 arch/arm/mach-omap2/id.c                            | 2 ++
 arch/arm/mach-omap2/soc.h                           | 7 +++++--
 4 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 9f4e513..4269c13 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -100,6 +100,9 @@ SoCs:
 - AM4372
   compatible = "ti,am4372", "ti,am43"
 
+- AM438x
+  compatible = "ti,am438x", "ti,am43"
+
 Boards:
 
 - OMAP3 BeagleBoard : Low cost community board
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 34ff14b..3d70d6a 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -266,6 +266,7 @@ MACHINE_END
 #ifdef CONFIG_SOC_AM43XX
 static const char *const am43_boards_compat[] __initconst = {
 	"ti,am4372",
+	"ti,am438x",
 	"ti,am43",
 	NULL,
 };
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index e3f713f..1bab9f5 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -228,6 +228,8 @@ static void __init omap3_cpuinfo(void)
 		cpu_name =  "AM335X";
 	} else if (soc_is_am437x()) {
 		cpu_name =  "AM437x";
+	} else if (soc_is_am438x()) {
+		cpu_name =  "AM438X";
 	} else if (cpu_is_ti814x()) {
 		cpu_name = "TI814X";
 	} else if (omap3_has_iva() && omap3_has_sgx()) {
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index f97654d..feb27fd 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -238,6 +238,7 @@ IS_AM_SUBCLASS(437x, 0x437)
 #define soc_is_am335x()			0
 #define soc_is_am43xx()			0
 #define soc_is_am437x()			0
+#define soc_is_am438x()			0
 #define cpu_is_omap44xx()		0
 #define cpu_is_omap443x()		0
 #define cpu_is_omap446x()		0
@@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
 #ifdef	CONFIG_SOC_AM43XX
 # undef soc_is_am43xx
 # undef soc_is_am437x
-# define soc_is_am43xx()		is_am43xx()
-# define soc_is_am437x()		is_am437x()
+# undef soc_is_am438x
+# define soc_is_am43xx()		of_machine_is_compatible("ti,am43")
+# define soc_is_am437x()		of_machine_is_compatible("ti,am4372")
+# define soc_is_am438x()		of_machine_is_compatible("ti,am438x")
 #endif
 
 # if defined(CONFIG_ARCH_OMAP4)
-- 
1.9.1

--
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

Re: [PATCH v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

[Tony Lindgren]

* Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [150810 02:31]:
> @@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
>  #ifdef	CONFIG_SOC_AM43XX
>  # undef soc_is_am43xx
>  # undef soc_is_am437x
> -# define soc_is_am43xx()		is_am43xx()
> -# define soc_is_am437x()		is_am437x()
> +# undef soc_is_am438x
> +# define soc_is_am43xx()		of_machine_is_compatible("ti,am43")
> +# define soc_is_am437x()		of_machine_is_compatible("ti,am4372")
> +# define soc_is_am438x()		of_machine_is_compatible("ti,am438x")
>  #endif

Hmm didn't I already comment on this change? I don't want to do it
for one SoC. Please add the SoC detection the old way for am43xx,
then do another series that changes all the DT only SoCs to use
of_machine_is_compatible() after it's been properly tested so now
regressions are caused for the early init code.

Regards,

Tony
--
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

Re: [PATCH v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

[Keerthy]

On Tuesday 11 August 2015 06:25 PM, Tony Lindgren wrote:
> * Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [150810 02:31]:
>> @@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
>>   #ifdef	CONFIG_SOC_AM43XX
>>   # undef soc_is_am43xx
>>   # undef soc_is_am437x
>> -# define soc_is_am43xx()		is_am43xx()
>> -# define soc_is_am437x()		is_am437x()
>> +# undef soc_is_am438x
>> +# define soc_is_am43xx()		of_machine_is_compatible("ti,am43")
>> +# define soc_is_am437x()		of_machine_is_compatible("ti,am4372")
>> +# define soc_is_am438x()		of_machine_is_compatible("ti,am438x")
>>   #endif
>
> Hmm didn't I already comment on this change? I don't want to do it
> for one SoC. Please add the SoC detection the old way for am43xx,
> then do another series that changes all the DT only SoCs to use
> of_machine_is_compatible() after it's been properly tested so now
> regressions are caused for the early init code.

Okay. I misinterpreted your earlier comment. Thanks for clarifying.
I will re-do.

>
> Regards,
>
> Tony
>
--
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

Re: [PATCH v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

[Tony Lindgren]

* Keerthy <a0393675-l0cyMroinI0@public.gmane.org> [150811 10:57]:
> 
> 
> On Tuesday 11 August 2015 06:25 PM, Tony Lindgren wrote:
> >* Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [150810 02:31]:
> >>@@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
> >>  #ifdef	CONFIG_SOC_AM43XX
> >>  # undef soc_is_am43xx
> >>  # undef soc_is_am437x
> >>-# define soc_is_am43xx()		is_am43xx()
> >>-# define soc_is_am437x()		is_am437x()
> >>+# undef soc_is_am438x
> >>+# define soc_is_am43xx()		of_machine_is_compatible("ti,am43")
> >>+# define soc_is_am437x()		of_machine_is_compatible("ti,am4372")
> >>+# define soc_is_am438x()		of_machine_is_compatible("ti,am438x")
> >>  #endif
> >
> >Hmm didn't I already comment on this change? I don't want to do it
> >for one SoC. Please add the SoC detection the old way for am43xx,
> >then do another series that changes all the DT only SoCs to use
> >of_machine_is_compatible() after it's been properly tested so now
> >regressions are caused for the early init code.
> 
> Okay. I misinterpreted your earlier comment. Thanks for clarifying.
> I will re-do.

Actually, can you please do the following patches first while at it:

1.  Change dra7 SoC detection to intialize soc_name and soc_rev
    registers based on the of_machine_is_compatible so we don't
    do pointless string comparisons with the current code

2. Add am437x detection the same way

3. Change all the existing DT only SoCs to do the same (this
   can be done in a separate series)

That should allow us to drop most of the SoC detection code.

Regards,

Tony
--
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

Re: [PATCH v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

[Keerthy]

On Wednesday 12 August 2015 02:07 PM, Tony Lindgren wrote:
> * Keerthy <a0393675-l0cyMroinI0@public.gmane.org> [150811 10:57]:
>>
>>
>> On Tuesday 11 August 2015 06:25 PM, Tony Lindgren wrote:
>>> * Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [150810 02:31]:
>>>> @@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
>>>>   #ifdef	CONFIG_SOC_AM43XX
>>>>   # undef soc_is_am43xx
>>>>   # undef soc_is_am437x
>>>> -# define soc_is_am43xx()		is_am43xx()
>>>> -# define soc_is_am437x()		is_am437x()
>>>> +# undef soc_is_am438x
>>>> +# define soc_is_am43xx()		of_machine_is_compatible("ti,am43")
>>>> +# define soc_is_am437x()		of_machine_is_compatible("ti,am4372")
>>>> +# define soc_is_am438x()		of_machine_is_compatible("ti,am438x")
>>>>   #endif
>>>
>>> Hmm didn't I already comment on this change? I don't want to do it
>>> for one SoC. Please add the SoC detection the old way for am43xx,
>>> then do another series that changes all the DT only SoCs to use
>>> of_machine_is_compatible() after it's been properly tested so now
>>> regressions are caused for the early init code.
>>
>> Okay. I misinterpreted your earlier comment. Thanks for clarifying.
>> I will re-do.
>
> Actually, can you please do the following patches first while at it:
>
> 1.  Change dra7 SoC detection to intialize soc_name and soc_rev
>      registers based on the of_machine_is_compatible so we don't
>      do pointless string comparisons with the current code
>
> 2. Add am437x detection the same way
>
> 3. Change all the existing DT only SoCs to do the same (this
>     can be done in a separate series)
>
> That should allow us to drop most of the SoC detection code.

Alright. I will post only the clock dts patch and the driver patches for 
now.

I will work on 1,2 and 3 in order.

Thanks Tony for your feedback.

-Keerthy
>
> Regards,
>
> Tony
>
--
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

Re: [PATCH v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

[Keerthy]

On Wednesday 12 August 2015 02:07 PM, Tony Lindgren wrote:
> * Keerthy <a0393675-l0cyMroinI0@public.gmane.org> [150811 10:57]:
>>
>>
>> On Tuesday 11 August 2015 06:25 PM, Tony Lindgren wrote:
>>> * Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [150810 02:31]:
>>>> @@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
>>>>   #ifdef	CONFIG_SOC_AM43XX
>>>>   # undef soc_is_am43xx
>>>>   # undef soc_is_am437x
>>>> -# define soc_is_am43xx()		is_am43xx()
>>>> -# define soc_is_am437x()		is_am437x()
>>>> +# undef soc_is_am438x
>>>> +# define soc_is_am43xx()		of_machine_is_compatible("ti,am43")
>>>> +# define soc_is_am437x()		of_machine_is_compatible("ti,am4372")
>>>> +# define soc_is_am438x()		of_machine_is_compatible("ti,am438x")
>>>>   #endif
>>>
>>> Hmm didn't I already comment on this change? I don't want to do it
>>> for one SoC. Please add the SoC detection the old way for am43xx,
>>> then do another series that changes all the DT only SoCs to use
>>> of_machine_is_compatible() after it's been properly tested so now
>>> regressions are caused for the early init code.
>>
>> Okay. I misinterpreted your earlier comment. Thanks for clarifying.
>> I will re-do.
>
> Actually, can you please do the following patches first while at it:
>
> 1.  Change dra7 SoC detection to intialize soc_name and soc_rev
>      registers based on the of_machine_is_compatible so we don't
>      do pointless string comparisons with the current code

Tony,

just another confirmation. So the intent here is to directly do
of_machine_is_compatible checks instead if soc_is_dra* and try to remove 
soc_is calls from mach-omap2 code right?

-Keerthy
>
> 2. Add am437x detection the same way
>
> 3. Change all the existing DT only SoCs to do the same (this
>     can be done in a separate series)
>
> That should allow us to drop most of the SoC detection code.
>
> Regards,
>
> Tony
>
--
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

Re: [PATCH v2 3/6] ARM: AM43xx: Introduce a separate soc_is function for am438x series of SoCs

[Tony Lindgren]

* Keerthy <a0393675-l0cyMroinI0@public.gmane.org> [150813 02:08]:
> 
> 
> On Wednesday 12 August 2015 02:07 PM, Tony Lindgren wrote:
> >* Keerthy <a0393675-l0cyMroinI0@public.gmane.org> [150811 10:57]:
> >>
> >>
> >>On Tuesday 11 August 2015 06:25 PM, Tony Lindgren wrote:
> >>>* Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org> [150810 02:31]:
> >>>>@@ -371,8 +372,10 @@ IS_OMAP_TYPE(3430, 0x3430)
> >>>>  #ifdef	CONFIG_SOC_AM43XX
> >>>>  # undef soc_is_am43xx
> >>>>  # undef soc_is_am437x
> >>>>-# define soc_is_am43xx()		is_am43xx()
> >>>>-# define soc_is_am437x()		is_am437x()
> >>>>+# undef soc_is_am438x
> >>>>+# define soc_is_am43xx()		of_machine_is_compatible("ti,am43")
> >>>>+# define soc_is_am437x()		of_machine_is_compatible("ti,am4372")
> >>>>+# define soc_is_am438x()		of_machine_is_compatible("ti,am438x")
> >>>>  #endif
> >>>
> >>>Hmm didn't I already comment on this change? I don't want to do it
> >>>for one SoC. Please add the SoC detection the old way for am43xx,
> >>>then do another series that changes all the DT only SoCs to use
> >>>of_machine_is_compatible() after it's been properly tested so now
> >>>regressions are caused for the early init code.
> >>
> >>Okay. I misinterpreted your earlier comment. Thanks for clarifying.
> >>I will re-do.
> >
> >Actually, can you please do the following patches first while at it:
> >
> >1.  Change dra7 SoC detection to intialize soc_name and soc_rev
> >     registers based on the of_machine_is_compatible so we don't
> >     do pointless string comparisons with the current code
> 
> just another confirmation. So the intent here is to directly do
> of_machine_is_compatible checks instead if soc_is_dra* and try to remove
> soc_is calls from mach-omap2 code right?

Only do of_machine_is_compatible check once to initialize
the necessary variables for soc_is_* to use. 

Rgarads,

Tony
--
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

[PATCH v2 4/6] ARM: dts: am43x-epos-evm: Add the am438 compatible string

[Keerthy]

The SoCs on am43x-epos-evm are named am438x.
Hence add the compatiblity string and remove the am4372 string.

Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/am43x-epos-evm.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts b/arch/arm/boot/dts/am43x-epos-evm.dts
index 86c2dfb..7e473c2 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -18,7 +18,7 @@
 
 / {
 	model = "TI AM43x EPOS EVM";
-	compatible = "ti,am43x-epos-evm","ti,am4372","ti,am43";
+	compatible = "ti,am43x-epos-evm","ti,am438x","ti,am43";
 
 	aliases {
 		display0 = &lcd0;
-- 
1.9.1

--
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

[PATCH v2 5/6] ARM: AM43XX: HWMOD: Add rtc hwmod

[Keerthy]

The patch adds rtc hwmod. This is present on gp and sk evm and not on
epos evm. Hence adding it selectively using a seprate list.

Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
---
 arch/arm/mach-omap2/omap_hwmod_43xx_data.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
index 215d5ef..a0850b9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_43xx_data.c
@@ -21,7 +21,7 @@
 #include "prcm43xx.h"
 #include "omap_hwmod_common_data.h"
 #include "hdq1w.h"
-
+#include "soc.h"
 
 /* IP blocks */
 static struct omap_hwmod am43xx_emif_hwmod = {
@@ -1020,9 +1020,21 @@ static struct omap_hwmod_ocp_if *am43xx_hwmod_ocp_ifs[] __initdata = {
 	NULL,
 };
 
+static struct omap_hwmod_ocp_if *am43xx_rtc_hwmod_ocp_ifs[] __initdata = {
+	&am33xx_l4_wkup__rtc,
+	NULL,
+};
+
 int __init am43xx_hwmod_init(void)
 {
+	int ret;
+
 	omap_hwmod_am43xx_reg();
 	omap_hwmod_init();
-	return omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+	ret = omap_hwmod_register_links(am43xx_hwmod_ocp_ifs);
+
+	if (!soc_is_am438x())
+		ret = omap_hwmod_register_links(am43xx_rtc_hwmod_ocp_ifs);
+
+	return ret;
 }
-- 
1.9.1

--
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

Re: [PATCH v2 5/6] ARM: AM43XX: HWMOD: Add rtc hwmod

[Paul Walmsley]

On Mon, 10 Aug 2015, Keerthy wrote:

> The patch adds rtc hwmod. This is present on gp and sk evm and not on
> epos evm. Hence adding it selectively using a seprate list.
> 
> Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>

So just to confirm, the RTC IP block has been physically removed or 
permanently disabled on these new AM438x chips?  So the registers are no 
longer accessible by the MPU?

Is there a TRM available for these chips?


- Paul
--
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

Re: [PATCH v2 5/6] ARM: AM43XX: HWMOD: Add rtc hwmod

[Tero Kristo]

On 08/12/2015 05:39 PM, Paul Walmsley wrote:
> On Mon, 10 Aug 2015, Keerthy wrote:
>
>> The patch adds rtc hwmod. This is present on gp and sk evm and not on
>> epos evm. Hence adding it selectively using a seprate list.
>>
>> Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
>
> So just to confirm, the RTC IP block has been physically removed or
> permanently disabled on these new AM438x chips?  So the registers are no
> longer accessible by the MPU?
>
> Is there a TRM available for these chips?

No public TRM available, as the SoC mostly contains secure environment 
support on them.

The RTC module is physically present on the SoC, but it is permanently 
disabled. A secure RTC is used instead on these devices, where needed.

-Tero

>
>
> - Paul
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.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

[PATCH v2 6/6] ARM: dts: AM437X-GP-EVM: Enable rtc

[Keerthy]

Enables rtc. RTC can be used to wake up system from suspend
when used with external clock source.

Signed-off-by: Keerthy <j-keerthy-l0cyMroinI0@public.gmane.org>
---
 arch/arm/boot/dts/am437x-gp-evm.dts | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts b/arch/arm/boot/dts/am437x-gp-evm.dts
index 215775d..1c897be 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -941,3 +941,7 @@
 	tx-num-evt = <32>;
 	rx-num-evt = <32>;
 };
+
+&rtc {
+	status = "okay";
+};
-- 
1.9.1

--
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