ARM: DRA7: hwmod: add entry for RTCSS

From: Lokesh Vutla <lokeshvutla@ti.com>

RTCSS on DRA7 provides a precise real-time clock.
Add hwmod entry for this IP.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
---
Applies to linux-next of 5th May.

 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |   41 +++++++++++++++++++++++++++++
 1 file changed, 41 insertions(+)

Hi Sekhar,

On Fri, 9 May 2014, Sekhar Nori wrote:

> From: Lokesh Vutla <lokeshvutla@ti.com>
> 
> RTCSS on DRA7 provides a precise real-time clock.
> Add hwmod entry for this IP.
> 
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>

Sorry for the delay on this patch.  Have been corresponding with TI to 
figure out what to do about DRA7xx/AM43xx patches.  I don't have boards or 
public documentation for these devices, so it's impossible for me to 
meaningfully review the patches.  Looks like boards and/or public docs 
won't be coming any time soon.

So for my part, here's what I'll need to merge any hwmod patches that
involve AM437x or DRA7xx:

1. A Reviewed-by: from one of the following folks (which should come from
a different person than who is submitting the patches):

Roger Quadros
Nishanth Menon
Rajendra Nayak
Kevin Hilman
Tony Lindgren

2. A Tested-by: from one of the following folks (who can be the same as 
the person who is the same as the person who is submitting the patches):

Nishanth Menon
Rajendra Nayak
Kevin Hilman 
Tony Lindgren


Once these are in place, I'd be happy to queue it for 3.16.



- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Fri, 13 Jun 2014, Paul Walmsley wrote:

> On Fri, 9 May 2014, Sekhar Nori wrote:
> 
> > From: Lokesh Vutla <lokeshvutla@ti.com>
> > 
> > RTCSS on DRA7 provides a precise real-time clock.
> > Add hwmod entry for this IP.
> > 
> > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> > Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> 
> Sorry for the delay on this patch.  Have been corresponding with TI to 
> figure out what to do about DRA7xx/AM43xx patches.  I don't have boards or 
> public documentation for these devices, so it's impossible for me to 
> meaningfully review the patches.  Looks like boards and/or public docs 
> won't be coming any time soon.
> 
> So for my part, here's what I'll need to merge any hwmod patches that
> involve AM437x or DRA7xx:
> 
> 1. A Reviewed-by: from one of the following folks (which should come from
> a different person than who is submitting the patches):
> 
> Roger Quadros
> Nishanth Menon
> Rajendra Nayak
> Kevin Hilman
> Tony Lindgren
> 
> 2. A Tested-by: from one of the following folks (who can be the same as 
> the person who is the same as the person who is submitting the patches):
> 
> Nishanth Menon
> Rajendra Nayak
> Kevin Hilman 
> Tony Lindgren
> 
> 
> Once these are in place, I'd be happy to queue it for 3.16.

I've tried to refine this a little bit.  More details here:

http://marc.info/?l=linux-omap&m=140280321814330&w=2

- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Friday 09 May 2014 06:07 PM, Sekhar Nori wrote:
> From: Lokesh Vutla <lokeshvutla@ti.com>
> 
> RTCSS on DRA7 provides a precise real-time clock.
> Add hwmod entry for this IP.
> 
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>

Reviewed-by: Rajendra Nayak <rnayak@ti.com>

> ---
> Applies to linux-next of 5th May.

Might need a repost with rebase on the latest mainline.

> 
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |   41 +++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 810c205..402ffc7 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1249,6 +1249,38 @@ static struct omap_hwmod dra7xx_qspi_hwmod = {
>  };
>  
>  /*
> + * 'rtcss' class
> + *
> + */
> +static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = {
> +	.sysc_offs	= 0x0078,
> +	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> +	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +			   SIDLE_SMART_WKUP),
> +	.sysc_fields	= &omap_hwmod_sysc_type3,
> +};
> +
> +static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
> +	.name	= "rtcss",
> +	.sysc	= &dra7xx_rtcss_sysc,
> +};
> +
> +/* rtcss */
> +static struct omap_hwmod dra7xx_rtcss_hwmod = {
> +	.name		= "rtcss",
> +	.class		= &dra7xx_rtcss_hwmod_class,
> +	.clkdm_name	= "rtc_clkdm",
> +	.main_clk	= "sys_32k_ck",
> +	.prcm = {
> +		.omap4 = {
> +			.clkctrl_offs = DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET,
> +			.context_offs = DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET,
> +			.modulemode   = MODULEMODE_SWCTRL,
> +		},
> +	},
> +};
> +
> +/*
>   * 'sata' class
>   *
>   */
> @@ -2354,6 +2386,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi = {
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> +/* l4_per3 -> rtcss */
> +static struct omap_hwmod_ocp_if dra7xx_l4_per3__rtcss = {
> +	.master		= &dra7xx_l4_per3_hwmod,
> +	.slave		= &dra7xx_rtcss_hwmod,
> +	.clk		= "l4_root_clk_div",
> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
>  static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = {
>  	{
>  		.name		= "sysc",
> @@ -2683,6 +2723,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
>  	&dra7xx_l4_cfg__mpu,
>  	&dra7xx_l4_cfg__ocp2scp1,
>  	&dra7xx_l3_main_1__qspi,
> +	&dra7xx_l4_per3__rtcss,
>  	&dra7xx_l4_cfg__sata,
>  	&dra7xx_l4_cfg__smartreflex_core,
>  	&dra7xx_l4_cfg__smartreflex_mpu,
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Thu, 3 Jul 2014, Rajendra Nayak wrote:

> On Friday 09 May 2014 06:07 PM, Sekhar Nori wrote:
> > From: Lokesh Vutla <lokeshvutla@ti.com>
> > 
> > RTCSS on DRA7 provides a precise real-time clock.
> > Add hwmod entry for this IP.
> > 
> > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> > Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> 
> Reviewed-by: Rajendra Nayak <rnayak@ti.com>
> 
> > ---
> > Applies to linux-next of 5th May.
> 
> Might need a repost with rebase on the latest mainline.

Will queue this as soon as someone sends a Tested-by: & a boot log for it.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

This series adds hwmod entry and dt node for RTC.

Tested on DRA7: logs can be seen here: http://hastebin.com/jaxogatuta.vhdl

Lokesh Vutla (2):
  ARM: DRA7: hwmod: Add data for RTC
  ARM: dts: DRA7: Add node for RTC

 arch/arm/boot/dts/dra7-evm.dts            |    1 +
 arch/arm/boot/dts/dra7.dtsi               |    9 +++++++
 arch/arm/mach-omap2/omap_hwmod_7xx_data.c |   41 +++++++++++++++++++++++++++++
 3 files changed, 51 insertions(+)

* Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
> Add node for RTC.
> And also making RTC regulator always-on, as RTC should be powered
> always.
> 
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> [nm@ti.com: update with rtc crossbar number]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> ---
> This patch depends on the crossbar dt patch series by Sricharan:
> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106910.html
> 
>  arch/arm/boot/dts/dra7-evm.dts |    1 +
>  arch/arm/boot/dts/dra7.dtsi    |    9 +++++++++
>  2 files changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
> index 4adc280..bca6d4a 100644
> --- a/arch/arm/boot/dts/dra7-evm.dts
> +++ b/arch/arm/boot/dts/dra7-evm.dts
> @@ -249,6 +249,7 @@
>  					regulator-min-microvolt = <1050000>;
>  					regulator-max-microvolt = <1050000>;
>  					regulator-boot-on;
> +					regulator-always-on;
>  				};
>  

Is this regulator really always on?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Tony,

On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
>> Add node for RTC.
>> And also making RTC regulator always-on, as RTC should be powered
>> always.
>>
>> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
>> [nm@ti.com: update with rtc crossbar number]
>> Signed-off-by: Nishanth Menon <nm@ti.com>
>> ---
>> This patch depends on the crossbar dt patch series by Sricharan:
>> https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106910.html
>>
>>   arch/arm/boot/dts/dra7-evm.dts |    1 +
>>   arch/arm/boot/dts/dra7.dtsi    |    9 +++++++++
>>   2 files changed, 10 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>> index 4adc280..bca6d4a 100644
>> --- a/arch/arm/boot/dts/dra7-evm.dts
>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>> @@ -249,6 +249,7 @@
>>   					regulator-min-microvolt = <1050000>;
>>   					regulator-max-microvolt = <1050000>;
>>   					regulator-boot-on;
>> +					regulator-always-on;
>>   				};
>>   
> Is this regulator really always on?

This feeds on to RTC which is a free running clock. So i guess always on 
is justified no?

>
> Regards,
>
> Tony

Regards,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

* Keerthy <a0393675@ti.com> [140709 02:36]:
> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
> >* Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
> >>--- a/arch/arm/boot/dts/dra7-evm.dts
> >>+++ b/arch/arm/boot/dts/dra7-evm.dts
> >>@@ -249,6 +249,7 @@
> >>  					regulator-min-microvolt = <1050000>;
> >>  					regulator-max-microvolt = <1050000>;
> >>  					regulator-boot-on;
> >>+					regulator-always-on;
> >>  				};
> >Is this regulator really always on?
> 
> This feeds on to RTC which is a free running clock. So i guess always on is
> justified no?

Well the dts entries should describe the hardware. If the
regulator can be enabled and disabled, we should not claim it's
always on.

Also adding temporary dts entries just causes more churn on the
dts files which is a PITA for everybody.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
> * Keerthy <a0393675@ti.com> [140709 02:36]:
>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
>>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>>> @@ -249,6 +249,7 @@
>>>>   					regulator-min-microvolt = <1050000>;
>>>>   					regulator-max-microvolt = <1050000>;
>>>>   					regulator-boot-on;
>>>> +					regulator-always-on;
>>>>   				};
>>> Is this regulator really always on?
>> This feeds on to RTC which is a free running clock. So i guess always on is
>> justified no?
> Well the dts entries should describe the hardware. If the
> regulator can be enabled and disabled, we should not claim it's
> always on.

 From the PMIC perspective every regulator can be enabled and
disabled. From a Board perspective there are some which need
to be always on. For Ex: SMPS123 which feeds on to the MPU.

I guess RTC also needs the supply to be on as long as we want
the clock to be ticking.

> Also adding temporary dts entries just causes more churn on the
> dts files which is a PITA for everybody.
>
> Regards,
>
> Tony

Regards,
Keerthy
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

* Keerthy <a0393675@ti.com> [140709 03:39]:
> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
> >* Keerthy <a0393675@ti.com> [140709 02:36]:
> >>On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
> >>>* Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
> >>>>--- a/arch/arm/boot/dts/dra7-evm.dts
> >>>>+++ b/arch/arm/boot/dts/dra7-evm.dts
> >>>>@@ -249,6 +249,7 @@
> >>>>  					regulator-min-microvolt = <1050000>;
> >>>>  					regulator-max-microvolt = <1050000>;
> >>>>  					regulator-boot-on;
> >>>>+					regulator-always-on;
> >>>>  				};
> >>>Is this regulator really always on?
> >>This feeds on to RTC which is a free running clock. So i guess always on is
> >>justified no?
> >Well the dts entries should describe the hardware. If the
> >regulator can be enabled and disabled, we should not claim it's
> >always on.
> 
> From the PMIC perspective every regulator can be enabled and
> disabled. From a Board perspective there are some which need
> to be always on. For Ex: SMPS123 which feeds on to the MPU.

Right, and we already have regulator-boot-on for those. Or are
you seeing some issue with that?

> I guess RTC also needs the supply to be on as long as we want
> the clock to be ticking.

Sure, but if somebody wants shut it off regulator-boot-on is
better from driver point of view.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote:
> * Keerthy <a0393675@ti.com> [140709 03:39]:
>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
>>> * Keerthy <a0393675@ti.com> [140709 02:36]:
>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>>>>> @@ -249,6 +249,7 @@
>>>>>>   					regulator-min-microvolt = <1050000>;
>>>>>>   					regulator-max-microvolt = <1050000>;
>>>>>>   					regulator-boot-on;
>>>>>> +					regulator-always-on;
>>>>>>   				};
>>>>> Is this regulator really always on?
>>>> This feeds on to RTC which is a free running clock. So i guess always on is
>>>> justified no?
>>> Well the dts entries should describe the hardware. If the
>>> regulator can be enabled and disabled, we should not claim it's
>>> always on.
>>  From the PMIC perspective every regulator can be enabled and
>> disabled. From a Board perspective there are some which need
>> to be always on. For Ex: SMPS123 which feeds on to the MPU.
> Right, and we already have regulator-boot-on for those. Or are
> you seeing some issue with that?
regulator-boot-on describes that at boot a particular regulator is on.
It does not guarantee that it will be on for the rest of the time. The
regulator framework can go ahead and disable it if no one has requested
for it. In case of RTC we do not want that to happen.

>
>> I guess RTC also needs the supply to be on as long as we want
>> the clock to be ticking.
> Sure, but if somebody wants shut it off regulator-boot-on is
> better from driver point of view.
>
> Regards,
>
> Tony

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

* Keerthy <a0393675@ti.com> [140709 03:59]:
> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote:
> >* Keerthy <a0393675@ti.com> [140709 03:39]:
> >>On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
> >>>* Keerthy <a0393675@ti.com> [140709 02:36]:
> >>>>On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
> >>>>>* Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
> >>>>>>--- a/arch/arm/boot/dts/dra7-evm.dts
> >>>>>>+++ b/arch/arm/boot/dts/dra7-evm.dts
> >>>>>>@@ -249,6 +249,7 @@
> >>>>>>  					regulator-min-microvolt = <1050000>;
> >>>>>>  					regulator-max-microvolt = <1050000>;
> >>>>>>  					regulator-boot-on;
> >>>>>>+					regulator-always-on;
> >>>>>>  				};
> >>>>>Is this regulator really always on?
> >>>>This feeds on to RTC which is a free running clock. So i guess always on is
> >>>>justified no?
> >>>Well the dts entries should describe the hardware. If the
> >>>regulator can be enabled and disabled, we should not claim it's
> >>>always on.
> >> From the PMIC perspective every regulator can be enabled and
> >>disabled. From a Board perspective there are some which need
> >>to be always on. For Ex: SMPS123 which feeds on to the MPU.
> >Right, and we already have regulator-boot-on for those. Or are
> >you seeing some issue with that?
> regulator-boot-on describes that at boot a particular regulator is on.
> It does not guarantee that it will be on for the rest of the time. The
> regulator framework can go ahead and disable it if no one has requested
> for it. In case of RTC we do not want that to happen.

That's a bug in the RTC driver then. The driver should request a
regulator if it's specified.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote:
> * Keerthy <a0393675@ti.com> [140709 03:59]:
>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote:
>>> * Keerthy <a0393675@ti.com> [140709 03:39]:
>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]:
>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>> @@ -249,6 +249,7 @@
>>>>>>>>   					regulator-min-microvolt = <1050000>;
>>>>>>>>   					regulator-max-microvolt = <1050000>;
>>>>>>>>   					regulator-boot-on;
>>>>>>>> +					regulator-always-on;
>>>>>>>>   				};
>>>>>>> Is this regulator really always on?
>>>>>> This feeds on to RTC which is a free running clock. So i guess always on is
>>>>>> justified no?
>>>>> Well the dts entries should describe the hardware. If the
>>>>> regulator can be enabled and disabled, we should not claim it's
>>>>> always on.
>>>>  From the PMIC perspective every regulator can be enabled and
>>>> disabled. From a Board perspective there are some which need
>>>> to be always on. For Ex: SMPS123 which feeds on to the MPU.
>>> Right, and we already have regulator-boot-on for those. Or are
>>> you seeing some issue with that?
>> regulator-boot-on describes that at boot a particular regulator is on.
>> It does not guarantee that it will be on for the rest of the time. The
>> regulator framework can go ahead and disable it if no one has requested
>> for it. In case of RTC we do not want that to happen.
> That's a bug in the RTC driver then. The driver should request a
> regulator if it's specified.

Okay.

>
> Regards,
>
> Tony

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Tony,
On Wednesday 09 July 2014 04:36 PM, Keerthy wrote:
> On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote:
>> * Keerthy <a0393675@ti.com> [140709 03:59]:
>>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote:
>>>> * Keerthy <a0393675@ti.com> [140709 03:39]:
>>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
>>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]:
>>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
>>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
>>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>>> @@ -249,6 +249,7 @@
>>>>>>>>>                       regulator-min-microvolt = <1050000>;
>>>>>>>>>                       regulator-max-microvolt = <1050000>;
>>>>>>>>>                       regulator-boot-on;
>>>>>>>>> +                    regulator-always-on;
>>>>>>>>>                   };
>>>>>>>> Is this regulator really always on?
>>>>>>> This feeds on to RTC which is a free running clock. So i guess always on is
>>>>>>> justified no?
>>>>>> Well the dts entries should describe the hardware. If the
>>>>>> regulator can be enabled and disabled, we should not claim it's
>>>>>> always on.
>>>>>  From the PMIC perspective every regulator can be enabled and
>>>>> disabled. From a Board perspective there are some which need
>>>>> to be always on. For Ex: SMPS123 which feeds on to the MPU.
>>>> Right, and we already have regulator-boot-on for those. Or are
>>>> you seeing some issue with that?
>>> regulator-boot-on describes that at boot a particular regulator is on.
>>> It does not guarantee that it will be on for the rest of the time. The
>>> regulator framework can go ahead and disable it if no one has requested
>>> for it. In case of RTC we do not want that to happen.
>> That's a bug in the RTC driver then. The driver should request a
>> regulator if it's specified.

In my experiments I observed that when RTC regulator is switched off and switched on, there is an abort while
accessing RTC registers.
After discussing with hardware team, it is confirmed that this LDO9 regulator powering RTC cannot be turned off when
SoC is active and expected to be always on.

Thanks and regards,
Lokesh

> 
> Okay.
> 
>>
>> Regards,
>>
>> Tony
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

* Lokesh Vutla <lokeshvutla@ti.com> [140714 07:47]:
> Hi Tony,
> On Wednesday 09 July 2014 04:36 PM, Keerthy wrote:
> > On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote:
> >> * Keerthy <a0393675@ti.com> [140709 03:59]:
> >>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote:
> >>>> * Keerthy <a0393675@ti.com> [140709 03:39]:
> >>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
> >>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]:
> >>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
> >>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
> >>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts
> >>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
> >>>>>>>>> @@ -249,6 +249,7 @@
> >>>>>>>>>                       regulator-min-microvolt = <1050000>;
> >>>>>>>>>                       regulator-max-microvolt = <1050000>;
> >>>>>>>>>                       regulator-boot-on;
> >>>>>>>>> +                    regulator-always-on;
> >>>>>>>>>                   };
> >>>>>>>> Is this regulator really always on?
> >>>>>>> This feeds on to RTC which is a free running clock. So i guess always on is
> >>>>>>> justified no?
> >>>>>> Well the dts entries should describe the hardware. If the
> >>>>>> regulator can be enabled and disabled, we should not claim it's
> >>>>>> always on.
> >>>>>  From the PMIC perspective every regulator can be enabled and
> >>>>> disabled. From a Board perspective there are some which need
> >>>>> to be always on. For Ex: SMPS123 which feeds on to the MPU.
> >>>> Right, and we already have regulator-boot-on for those. Or are
> >>>> you seeing some issue with that?
> >>> regulator-boot-on describes that at boot a particular regulator is on.
> >>> It does not guarantee that it will be on for the rest of the time. The
> >>> regulator framework can go ahead and disable it if no one has requested
> >>> for it. In case of RTC we do not want that to happen.
> >> That's a bug in the RTC driver then. The driver should request a
> >> regulator if it's specified.
> 
> In my experiments I observed that when RTC regulator is switched
> off and switched on, there is an abort while accessing RTC registers.

Right, then you know you have the right regulator :)

> After discussing with hardware team, it is confirmed that this
> LDO9 regulator powering RTC cannot be turned off when
> SoC is active and expected to be always on.

Hmm but sounds like you already proved it can be idled? So
the regulator really should be managed by the driver?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Monday 14 July 2014 08:15 PM, Lokesh Vutla wrote:
> Hi Tony,
> On Wednesday 09 July 2014 04:36 PM, Keerthy wrote:
>> On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote:
>>> * Keerthy <a0393675@ti.com> [140709 03:59]:
>>>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote:
>>>>> * Keerthy <a0393675@ti.com> [140709 03:39]:
>>>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
>>>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]:
>>>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
>>>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
>>>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>>>> @@ -249,6 +249,7 @@
>>>>>>>>>>                        regulator-min-microvolt = <1050000>;
>>>>>>>>>>                        regulator-max-microvolt = <1050000>;
>>>>>>>>>>                        regulator-boot-on;
>>>>>>>>>> +                    regulator-always-on;
>>>>>>>>>>                    };
>>>>>>>>> Is this regulator really always on?
>>>>>>>> This feeds on to RTC which is a free running clock. So i guess always on is
>>>>>>>> justified no?
>>>>>>> Well the dts entries should describe the hardware. If the
>>>>>>> regulator can be enabled and disabled, we should not claim it's
>>>>>>> always on.
>>>>>>   From the PMIC perspective every regulator can be enabled and
>>>>>> disabled. From a Board perspective there are some which need
>>>>>> to be always on. For Ex: SMPS123 which feeds on to the MPU.
>>>>> Right, and we already have regulator-boot-on for those. Or are
>>>>> you seeing some issue with that?
>>>> regulator-boot-on describes that at boot a particular regulator is on.
>>>> It does not guarantee that it will be on for the rest of the time. The
>>>> regulator framework can go ahead and disable it if no one has requested
>>>> for it. In case of RTC we do not want that to happen.
>>> That's a bug in the RTC driver then. The driver should request a
>>> regulator if it's specified.
> In my experiments I observed that when RTC regulator is switched off and switched on, there is an abort while
> accessing RTC registers.
> After discussing with hardware team, it is confirmed that this LDO9 regulator powering RTC cannot be turned off when
> SoC is active and expected to be always on.
As confirmed by the PMIC hardware team this regulator should be an always-on
regulator.

Acked-by: Keerthy <j-keerthy@ti.com>
>
> Thanks and regards,
> Lokesh
>
>> Okay.
>>
>>> Regards,
>>>
>>> Tony

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Monday 14 July 2014 09:53 PM, Tony Lindgren wrote:
> * Lokesh Vutla <lokeshvutla@ti.com> [140714 07:47]:
>> Hi Tony,
>> On Wednesday 09 July 2014 04:36 PM, Keerthy wrote:
>>> On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote:
>>>> * Keerthy <a0393675@ti.com> [140709 03:59]:
>>>>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote:
>>>>>> * Keerthy <a0393675@ti.com> [140709 03:39]:
>>>>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
>>>>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]:
>>>>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
>>>>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
>>>>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>>>>> @@ -249,6 +249,7 @@
>>>>>>>>>>>                        regulator-min-microvolt = <1050000>;
>>>>>>>>>>>                        regulator-max-microvolt = <1050000>;
>>>>>>>>>>>                        regulator-boot-on;
>>>>>>>>>>> +                    regulator-always-on;
>>>>>>>>>>>                    };
>>>>>>>>>> Is this regulator really always on?
>>>>>>>>> This feeds on to RTC which is a free running clock. So i guess always on is
>>>>>>>>> justified no?
>>>>>>>> Well the dts entries should describe the hardware. If the
>>>>>>>> regulator can be enabled and disabled, we should not claim it's
>>>>>>>> always on.
>>>>>>>   From the PMIC perspective every regulator can be enabled and
>>>>>>> disabled. From a Board perspective there are some which need
>>>>>>> to be always on. For Ex: SMPS123 which feeds on to the MPU.
>>>>>> Right, and we already have regulator-boot-on for those. Or are
>>>>>> you seeing some issue with that?
>>>>> regulator-boot-on describes that at boot a particular regulator is on.
>>>>> It does not guarantee that it will be on for the rest of the time. The
>>>>> regulator framework can go ahead and disable it if no one has requested
>>>>> for it. In case of RTC we do not want that to happen.
>>>> That's a bug in the RTC driver then. The driver should request a
>>>> regulator if it's specified.
>> In my experiments I observed that when RTC regulator is switched
>> off and switched on, there is an abort while accessing RTC registers.
> Right, then you know you have the right regulator :)
>
>> After discussing with hardware team, it is confirmed that this
>> LDO9 regulator powering RTC cannot be turned off when
>> SoC is active and expected to be always on.
> Hmm but sounds like you already proved it can be idled? So
> the regulator really should be managed by the driver?

Tony,

Lokesh and i tried disabling the ldo9 regulator and then re-enabling it
post boot via driver as well as through I2C tools. Once we disable and 
re-enable
we see that we can not access the RTC related registers any further.
So we checked with the hardware team and they confirmed that it should
never be disabled.

Regards,
Keerthy
> Regards,
>
> Tony

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Tony,
On Monday 14 July 2014 09:53 PM, Tony Lindgren wrote:
> * Lokesh Vutla <lokeshvutla@ti.com> [140714 07:47]:
>> Hi Tony,
>> On Wednesday 09 July 2014 04:36 PM, Keerthy wrote:
>>> On Wednesday 09 July 2014 04:30 PM, Tony Lindgren wrote:
>>>> * Keerthy <a0393675@ti.com> [140709 03:59]:
>>>>> On Wednesday 09 July 2014 04:20 PM, Tony Lindgren wrote:
>>>>>> * Keerthy <a0393675@ti.com> [140709 03:39]:
>>>>>>> On Wednesday 09 July 2014 03:39 PM, Tony Lindgren wrote:
>>>>>>>> * Keerthy <a0393675@ti.com> [140709 02:36]:
>>>>>>>>> On Wednesday 09 July 2014 02:42 PM, Tony Lindgren wrote:
>>>>>>>>>> * Lokesh Vutla <lokeshvutla@ti.com> [140709 01:37]:
>>>>>>>>>>> --- a/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>>>>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>>>>>>>>>>> @@ -249,6 +249,7 @@
>>>>>>>>>>>                       regulator-min-microvolt = <1050000>;
>>>>>>>>>>>                       regulator-max-microvolt = <1050000>;
>>>>>>>>>>>                       regulator-boot-on;
>>>>>>>>>>> +                    regulator-always-on;
>>>>>>>>>>>                   };
>>>>>>>>>> Is this regulator really always on?
>>>>>>>>> This feeds on to RTC which is a free running clock. So i guess always on is
>>>>>>>>> justified no?
>>>>>>>> Well the dts entries should describe the hardware. If the
>>>>>>>> regulator can be enabled and disabled, we should not claim it's
>>>>>>>> always on.
>>>>>>>  From the PMIC perspective every regulator can be enabled and
>>>>>>> disabled. From a Board perspective there are some which need
>>>>>>> to be always on. For Ex: SMPS123 which feeds on to the MPU.
>>>>>> Right, and we already have regulator-boot-on for those. Or are
>>>>>> you seeing some issue with that?
>>>>> regulator-boot-on describes that at boot a particular regulator is on.
>>>>> It does not guarantee that it will be on for the rest of the time. The
>>>>> regulator framework can go ahead and disable it if no one has requested
>>>>> for it. In case of RTC we do not want that to happen.
>>>> That's a bug in the RTC driver then. The driver should request a
>>>> regulator if it's specified.
>>
>> In my experiments I observed that when RTC regulator is switched
>> off and switched on, there is an abort while accessing RTC registers.
> 
> Right, then you know you have the right regulator :)
Once we switch it off it is expected, but then if it is *switched on* it is expected that we should be able to access
registers. Here there is an abort accessing these registers. 
> 
>> After discussing with hardware team, it is confirmed that this
>> LDO9 regulator powering RTC cannot be turned off when
>> SoC is active and expected to be always on.
> 
> Hmm but sounds like you already proved it can be idled? So
> the regulator really should be managed by the driver?
Actually I adapted the driver to support a power regulator. Then I observed that if rtc is loaded as  a module
there is an abort(  which is happening because the regulator is disabled once and re-enabled). So when we checked
with the hardware team, they confirmed that ldo9 should not be disabled. 

Thanks and regards,
Lokesh
> 
> Regards,
> 
> Tony
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

* Lokesh Vutla <lokeshvutla@ti.com> [140714 21:09]:
> On Monday 14 July 2014 09:53 PM, Tony Lindgren wrote:
> > * Lokesh Vutla <lokeshvutla@ti.com> [140714 07:47]:
> >>
> >> In my experiments I observed that when RTC regulator is switched
> >> off and switched on, there is an abort while accessing RTC registers.
> > 
> > Right, then you know you have the right regulator :)
>
> Once we switch it off it is expected, but then if it is *switched on*
> it is expected that we should be able to access registers. Here there
> is an abort accessing these registers. 

Most likely you need to also reconfigure the registers or
re-enable the clock or reset it at the interconnect too.

> >> After discussing with hardware team, it is confirmed that this
> >> LDO9 regulator powering RTC cannot be turned off when
> >> SoC is active and expected to be always on.
> > 
> > Hmm but sounds like you already proved it can be idled? So
> > the regulator really should be managed by the driver?
>
> Actually I adapted the driver to support a power regulator.
> Then I observed that if rtc is loaded as  a module there is
> an abort(  which is happening because the regulator is disabled
> once and re-enabled). So when we checked with the hardware team,
> they confirmed that ldo9 should not be disabled. 

Hmm so how is it enabled initially then?

To me it sounds like very standard stuff to reinitialize
a driver for any omap device when waking from suspend or
returning from off-idle. If the RTC device cannot be reset,
idled and re-initialized properly, there's something wrong
with the RTC driver, clocks, regulators, or hwmod data for
that device.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Hi Paul,
On Wednesday 09 July 2014 02:05 PM, Lokesh Vutla wrote:
> Add hwmod data for RTC
> 
> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> Reviewed-by: Rajendra Nayak <rnayak@ti.com>
Can you take this patch. I have submitted logs also.

Thanks and regards,
Lokesh
> ---
> Changes since V1:
> Rebased on top of linux-next 20140708.
> 
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c |   41 +++++++++++++++++++++++++++++
>  1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 20b4398..d8032b9 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -1249,6 +1249,38 @@ static struct omap_hwmod dra7xx_qspi_hwmod = {
>  };
>  
>  /*
> + * 'rtcss' class
> + *
> + */
> +static struct omap_hwmod_class_sysconfig dra7xx_rtcss_sysc = {
> +	.sysc_offs	= 0x0078,
> +	.sysc_flags	= SYSC_HAS_SIDLEMODE,
> +	.idlemodes	= (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> +			   SIDLE_SMART_WKUP),
> +	.sysc_fields	= &omap_hwmod_sysc_type3,
> +};
> +
> +static struct omap_hwmod_class dra7xx_rtcss_hwmod_class = {
> +	.name	= "rtcss",
> +	.sysc	= &dra7xx_rtcss_sysc,
> +};
> +
> +/* rtcss */
> +static struct omap_hwmod dra7xx_rtcss_hwmod = {
> +	.name		= "rtcss",
> +	.class		= &dra7xx_rtcss_hwmod_class,
> +	.clkdm_name	= "rtc_clkdm",
> +	.main_clk	= "sys_32k_ck",
> +	.prcm = {
> +		.omap4 = {
> +			.clkctrl_offs = DRA7XX_CM_RTC_RTCSS_CLKCTRL_OFFSET,
> +			.context_offs = DRA7XX_RM_RTC_RTCSS_CONTEXT_OFFSET,
> +			.modulemode   = MODULEMODE_SWCTRL,
> +		},
> +	},
> +};
> +
> +/*
>   * 'sata' class
>   *
>   */
> @@ -2344,6 +2376,14 @@ static struct omap_hwmod_ocp_if dra7xx_l3_main_1__qspi = {
>  	.user		= OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> +/* l4_per3 -> rtcss */
> +static struct omap_hwmod_ocp_if dra7xx_l4_per3__rtcss = {
> +	.master		= &dra7xx_l4_per3_hwmod,
> +	.slave		= &dra7xx_rtcss_hwmod,
> +	.clk		= "l4_root_clk_div",
> +	.user		= OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
>  static struct omap_hwmod_addr_space dra7xx_sata_addrs[] = {
>  	{
>  		.name		= "sysc",
> @@ -2673,6 +2713,7 @@ static struct omap_hwmod_ocp_if *dra7xx_hwmod_ocp_ifs[] __initdata = {
>  	&dra7xx_l4_cfg__mpu,
>  	&dra7xx_l4_cfg__ocp2scp1,
>  	&dra7xx_l3_main_1__qspi,
> +	&dra7xx_l4_per3__rtcss,
>  	&dra7xx_l4_cfg__sata,
>  	&dra7xx_l4_cfg__smartreflex_core,
>  	&dra7xx_l4_cfg__smartreflex_mpu,
> 

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Tue, 22 Jul 2014, Lokesh Vutla wrote:

> Hi Paul,
> On Wednesday 09 July 2014 02:05 PM, Lokesh Vutla wrote:
> > Add hwmod data for RTC
> > 
> > Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
> > Signed-off-by: Sekhar Nori <nsekhar@ti.com>
> > Reviewed-by: Rajendra Nayak <rnayak@ti.com>
> Can you take this patch. I have submitted logs also.

Thanks, queued for 3.17.  And thanks for running rtctest in your testlog - 
that's helpful and gives some extra confidence.


- Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html