[PATCH 0/3] Enable twl603x-GPADC for some OMAP4/OMAP5 boards and Palmas-RTC for OMAP5

[PATCH 0/3] Enable twl603x-GPADC for some OMAP4/OMAP5 boards and Palmas-RTC for OMAP5

[H. Nikolaus Schaller]

This patch series adds DT nodes for:

twl6030-gpadc for omap4 based boards (Pandaboard ES)
twl6037-gpadc for omap5 based boards (OMAP5 EVM)
twl6037-rtc for omap5 based boards (OMAP5 EVM)


H. Nikolaus Schaller (3):
  ARM: dts: omap5-board-common: enable rtc and charging of backup
    battery
  ARM: dts: omap5-board-common: enable iio gpadc for Palmas
  ARM: dts: twl6030: add gpadc

 arch/arm/boot/dts/omap5-board-common.dtsi | 18 ++++++++++++++++++
 arch/arm/boot/dts/twl6030.dtsi            |  6 ++++++
 2 files changed, 24 insertions(+)

-- 
2.5.1

[PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

tested on OMP5432 EVM

Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
---
 arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
index 5cf76a1..30c0d3b 100644
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -358,6 +358,14 @@
 			#clock-cells = <0>;
 		};
 
+		rtc {
+			compatible = "ti,palmas-rtc";
+			interrupt-parent = <&palmas>;
+			interrupts = <8 IRQ_TYPE_NONE>;
+			ti,backup-battery-chargeable;
+			ti,backup-battery-charge-high-current;
+		};
+
 		palmas_pmic {
 			compatible = "ti,palmas-pmic";
 			interrupt-parent = <&palmas>;
-- 
2.5.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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
> tested on OMP5432 EVM
> 
> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
> ---
>  arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
> index 5cf76a1..30c0d3b 100644
> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> @@ -358,6 +358,14 @@
>  			#clock-cells = <0>;
>  		};
>  
> +		rtc {
> +			compatible = "ti,palmas-rtc";
> +			interrupt-parent = <&palmas>;
> +			interrupts = <8 IRQ_TYPE_NONE>;

IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
it had none, there'd be no interrupt, right?

> +			ti,backup-battery-chargeable;
> +			ti,backup-battery-charge-high-current;
> +		};
> +
>  		palmas_pmic {
>  			compatible = "ti,palmas-pmic";
>  			interrupt-parent = <&palmas>;
> 


-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> [160105 15:40]:
> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
> > tested on OMP5432 EVM
> > 
> > Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
> > ---
> >  arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
> > index 5cf76a1..30c0d3b 100644
> > --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> > +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> > @@ -358,6 +358,14 @@
> >  			#clock-cells = <0>;
> >  		};
> >  
> > +		rtc {
> > +			compatible = "ti,palmas-rtc";
> > +			interrupt-parent = <&palmas>;
> > +			interrupts = <8 IRQ_TYPE_NONE>;
> 
> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
> it had none, there'd be no interrupt, right?

Also I'm not seeing just zeroes coming from RTC after typing hwclock
on omap5-uevm. It's working on x15 though.

Nikolaus, is hwclock command working for you on omap5-uevm?

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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi Tony,

Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony@atomide.com>:

> * Nishanth Menon <nm@ti.com> [160105 15:40]:
>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>> tested on OMP5432 EVM
>>> 
>>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>>> ---
>>> arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++
>>> 1 file changed, 8 insertions(+)
>>> 
>>> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
>>> index 5cf76a1..30c0d3b 100644
>>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>>> @@ -358,6 +358,14 @@
>>> 			#clock-cells = <0>;
>>> 		};
>>> 
>>> +		rtc {
>>> +			compatible = "ti,palmas-rtc";
>>> +			interrupt-parent = <&palmas>;
>>> +			interrupts = <8 IRQ_TYPE_NONE>;
>> 
>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>> it had none, there'd be no interrupt, right?
> 
> Also I'm not seeing just zeroes coming from RTC after typing hwclock
> on omap5-uevm. It's working on x15 though.
> 
> Nikolaus, is hwclock command working for you on omap5-uevm?

Well, yes and no. It appears it *was* working when tested last time
(we sometimes have months of delay for submitting patches upstream).

I have found an SD image with 4.3-rc6 with this patch in the dtb and
there it works. With 4.4-rc8 it does not work. hwclock command hangs for
10 seconds (I guess some timeout).

I have checked the dtb and in both cases it is interrupts = <8 0>;

xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts
0000000: 0000 0008 0000 0000

So I think something has changed in the rtc driver or somewhere else.

BR,
Nikolaus

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

Hi,

* H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [160106 00:12]:
> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> > 
> > Also I'm not seeing just zeroes coming from RTC after typing hwclock
> > on omap5-uevm. It's working on x15 though.
> > 
> > Nikolaus, is hwclock command working for you on omap5-uevm?
> 
> Well, yes and no. It appears it *was* working when tested last time
> (we sometimes have months of delay for submitting patches upstream).
> 
> I have found an SD image with 4.3-rc6 with this patch in the dtb and
> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
> 10 seconds (I guess some timeout).
> 
> I have checked the dtb and in both cases it is interrupts = <8 0>;
> 
> xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts
> 0000000: 0000 0008 0000 0000
> 
> So I think something has changed in the rtc driver or somewhere else.

I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
RTC, and I still don't have hwclock working with RTC.

It seems you have some additional patches there that make it work?

I guess it could also be a bootloader change if it's a different
SD image that works for you.

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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi Tony,

Am 06.01.2016 um 17:41 schrieb Tony Lindgren <tony@atomide.com>:

> Hi,
> 
> * H. Nikolaus Schaller <hns@goldelico.com> [160106 00:12]:
>> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony@atomide.com>:
>>> 
>>> Also I'm not seeing just zeroes coming from RTC after typing hwclock
>>> on omap5-uevm. It's working on x15 though.
>>> 
>>> Nikolaus, is hwclock command working for you on omap5-uevm?
>> 
>> Well, yes and no. It appears it *was* working when tested last time
>> (we sometimes have months of delay for submitting patches upstream).
>> 
>> I have found an SD image with 4.3-rc6 with this patch in the dtb and
>> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
>> 10 seconds (I guess some timeout).
>> 
>> I have checked the dtb and in both cases it is interrupts = <8 0>;
>> 
>> xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts
>> 0000000: 0000 0008 0000 0000
>> 
>> So I think something has changed in the rtc driver or somewhere else.
> 
> I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
> RTC, and I still don't have hwclock working with RTC.
> 
> It seems you have some additional patches there that make it work?

Hm. Not that I am aware of. We just did add the rtc nodes but did not
touch palmas drivers (except adding the gpadc of this patch series).

> 
> I guess it could also be a bootloader change if it's a different
> SD image that works for you.

Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from
source. I will try to find out if it makes a difference.

BR,
Nikolaus

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [160106 08:48]:
> Hi Tony,
> 
> Am 06.01.2016 um 17:41 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> 
> > Hi,
> > 
> > * H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [160106 00:12]:
> >> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> >>> 
> >>> Also I'm not seeing just zeroes coming from RTC after typing hwclock
> >>> on omap5-uevm. It's working on x15 though.
> >>> 
> >>> Nikolaus, is hwclock command working for you on omap5-uevm?
> >> 
> >> Well, yes and no. It appears it *was* working when tested last time
> >> (we sometimes have months of delay for submitting patches upstream).
> >> 
> >> I have found an SD image with 4.3-rc6 with this patch in the dtb and
> >> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
> >> 10 seconds (I guess some timeout).
> >> 
> >> I have checked the dtb and in both cases it is interrupts = <8 0>;
> >> 
> >> xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts
> >> 0000000: 0000 0008 0000 0000
> >> 
> >> So I think something has changed in the rtc driver or somewhere else.
> > 
> > I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
> > RTC, and I still don't have hwclock working with RTC.
> > 
> > It seems you have some additional patches there that make it work?
> 
> Hm. Not that I am aware of. We just did add the rtc nodes but did not
> touch palmas drivers (except adding the gpadc of this patch series).

OK

> > I guess it could also be a bootloader change if it's a different
> > SD image that works for you.
> 
> Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from
> source. I will try to find out if it makes a difference.

OK. It could be also some .config change with something built-in?

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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Tony,
it is strange. It now works under unknown conditions - without any obvoius change.

Am 06.01.2016 um 18:09 schrieb Tony Lindgren <tony@atomide.com>:

> * H. Nikolaus Schaller <hns@goldelico.com> [160106 08:48]:
>> Hi Tony,
>> 
>> Am 06.01.2016 um 17:41 schrieb Tony Lindgren <tony@atomide.com>:
>> 
>>> Hi,
>>> 
>>> * H. Nikolaus Schaller <hns@goldelico.com> [160106 00:12]:
>>>> Am 06.01.2016 um 02:00 schrieb Tony Lindgren <tony@atomide.com>:
>>>>> 
>>>>> Also I'm not seeing just zeroes coming from RTC after typing hwclock
>>>>> on omap5-uevm. It's working on x15 though.
>>>>> 
>>>>> Nikolaus, is hwclock command working for you on omap5-uevm?
>>>> 
>>>> Well, yes and no. It appears it *was* working when tested last time
>>>> (we sometimes have months of delay for submitting patches upstream).
>>>> 
>>>> I have found an SD image with 4.3-rc6 with this patch in the dtb and
>>>> there it works. With 4.4-rc8 it does not work. hwclock command hangs for
>>>> 10 seconds (I guess some timeout).
>>>> 
>>>> I have checked the dtb and in both cases it is interrupts = <8 0>;
>>>> 
>>>> xxd /sys/firmware/devicetree/base/ocp/i2c@48070000/palmas@48/rtc/interrupts
>>>> 0000000: 0000 0008 0000 0000
>>>> 
>>>> So I think something has changed in the rtc driver or somewhere else.
>>> 
>>> I just gave it a try on v4.3-rc6 with omap5-uevm.dts patched for
>>> RTC, and I still don't have hwclock working with RTC.
>>> 
>>> It seems you have some additional patches there that make it work?
>> 
>> Hm. Not that I am aware of. We just did add the rtc nodes but did not
>> touch palmas drivers (except adding the gpadc of this patch series).
> 
> OK
> 
>>> I guess it could also be a bootloader change if it's a different
>>> SD image that works for you.
>> 
>> Yes, it is using a 2 years old U-Boot instead 2015.10 compiled from
>> source. I will try to find out if it makes a difference.
> 
> OK. It could be also some .config change with something built-in?

I have compared /proc/config.gz from both systems and /sys/firmware/fdt
with no significant and obvious change.

Then I booted the 4.4-rc8 again and this time it worked.

To verify, I have checked out linux-next this morning, cherry-picked this palmas
rtc patch, compiled with omap2plus defconfig, and used the omap5-uevm.dtb. And
hwclock works after doing a modprobe rtc_palmas.

Then I did the same with official v4.4-rc8 and hwclock hangs. And now our
4.4-rc8 production kernel hangs again as well. Even if I use the
DTB from the 4.3 kernel.

So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in
linux-next and unrelated to this DT patch.

But I have no hint or idea what it is.

BR,
Nikolaus

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [160108 09:50]:
> Tony,
> it is strange. It now works under unknown conditions - without any obvoius change.
> 
> Am 06.01.2016 um 18:09 schrieb Tony Lindgren <tony@atomide.com>:
> > 
> > OK. It could be also some .config change with something built-in?
> 
> I have compared /proc/config.gz from both systems and /sys/firmware/fdt
> with no significant and obvious change.
> 
> Then I booted the 4.4-rc8 again and this time it worked.
> 
> To verify, I have checked out linux-next this morning, cherry-picked this palmas
> rtc patch, compiled with omap2plus defconfig, and used the omap5-uevm.dtb. And
> hwclock works after doing a modprobe rtc_palmas.

Weird. No luck here with current linux next or anything.

> Then I did the same with official v4.4-rc8 and hwclock hangs. And now our
> 4.4-rc8 production kernel hangs again as well. Even if I use the
> DTB from the 4.3 kernel.

I'm not seeing the RTC second increase in u-boot either, this
should show it:

# i2c md 0x48 0x100

Of course the rtc may not be enabled in u-boot unlike for x15.

> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in
> linux-next and unrelated to this DT patch.
> 
> But I have no hint or idea what it is.

Or something hangs the RTC? And the back-up battery has to drain to
reset the RTC somehow?

Regards,

Tony

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:

> * H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [160108 09:50]:
>> Tony,
>> it is strange. It now works under unknown conditions - without any obvoius change.
>> 
>> Am 06.01.2016 um 18:09 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
>>> 
>>> OK. It could be also some .config change with something built-in?
>> 
>> I have compared /proc/config.gz from both systems and /sys/firmware/fdt
>> with no significant and obvious change.
>> 
>> Then I booted the 4.4-rc8 again and this time it worked.
>> 
>> To verify, I have checked out linux-next this morning, cherry-picked this palmas
>> rtc patch, compiled with omap2plus defconfig, and used the omap5-uevm.dtb. And
>> hwclock works after doing a modprobe rtc_palmas.
> 
> Weird. No luck here with current linux next or anything.
> 
>> Then I did the same with official v4.4-rc8 and hwclock hangs. And now our
>> 4.4-rc8 production kernel hangs again as well. Even if I use the
>> DTB from the 4.3 kernel.
> 
> I'm not seeing the RTC second increase in u-boot either, this
> should show it:
> 
> # i2c md 0x48 0x100
> 
> Of course the rtc may not be enabled in u-boot unlike for x15.
> 
>> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in
>> linux-next and unrelated to this DT patch.
>> 
>> But I have no hint or idea what it is.
> 
> Or something hangs the RTC? And the back-up battery has to drain to
> reset the RTC somehow?

Indeed it could be something like this. I already suspected that it depends
on boot order of some components.

But you get the /dev/rtc and /sys/class/rtc nodes? This is what this patch
should enable (and not fix potential driver issues).

BR,
Nikolaus

--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [160108 10:33]:
> Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony@atomide.com>:
> > * H. Nikolaus Schaller <hns@goldelico.com> [160108 09:50]:
> > 
> >> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in
> >> linux-next and unrelated to this DT patch.
> >> 
> >> But I have no hint or idea what it is.
> > 
> > Or something hangs the RTC? And the back-up battery has to drain to
> > reset the RTC somehow?
> 
> Indeed it could be something like this. I already suspected that it depends
> on boot order of some components.
> 
> But you get the /dev/rtc and /sys/class/rtc nodes? This is what this patch
> should enable (and not fix potential driver issues).

Yes no problems with $subject patch. It's just the we also need
to figure out why RTC does not work :)

Regards,

Tony

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Am 08.01.2016 um 20:04 schrieb Tony Lindgren <tony@atomide.com>:

> * H. Nikolaus Schaller <hns@goldelico.com> [160108 10:33]:
>> Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony@atomide.com>:
>>> * H. Nikolaus Schaller <hns@goldelico.com> [160108 09:50]:
>>> 
>>>> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in
>>>> linux-next and unrelated to this DT patch.
>>>> 
>>>> But I have no hint or idea what it is.
>>> 
>>> Or something hangs the RTC? And the back-up battery has to drain to
>>> reset the RTC somehow?
>> 
>> Indeed it could be something like this. I already suspected that it depends
>> on boot order of some components.
>> 
>> But you get the /dev/rtc and /sys/class/rtc nodes? This is what this patch
>> should enable (and not fix potential driver issues).
> 
> Yes no problems with $subject patch. It's just the we also need
> to figure out why RTC does not work :)

Yes indeed. I can not focus on that at the moment but as soon as we have
the new Pyra handheld devices (with OMAP5+Palmas) running, there will
be more developers to look at it.

BR,
Nikolaus

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [160108 11:32]:
> 
> Am 08.01.2016 um 20:04 schrieb Tony Lindgren <tony@atomide.com>:
> 
> > * H. Nikolaus Schaller <hns@goldelico.com> [160108 10:33]:
> >> Am 08.01.2016 um 19:15 schrieb Tony Lindgren <tony@atomide.com>:
> >>> * H. Nikolaus Schaller <hns@goldelico.com> [160108 09:50]:
> >>> 
> >>>> So I think it is something which is unstable in 4.4-rc8 that is (probably) fixed in
> >>>> linux-next and unrelated to this DT patch.
> >>>> 
> >>>> But I have no hint or idea what it is.
> >>> 
> >>> Or something hangs the RTC? And the back-up battery has to drain to
> >>> reset the RTC somehow?
> >> 
> >> Indeed it could be something like this. I already suspected that it depends
> >> on boot order of some components.
> >> 
> >> But you get the /dev/rtc and /sys/class/rtc nodes? This is what this patch
> >> should enable (and not fix potential driver issues).
> > 
> > Yes no problems with $subject patch. It's just the we also need
> > to figure out why RTC does not work :)
> 
> Yes indeed. I can not focus on that at the moment but as soon as we have
> the new Pyra handheld devices (with OMAP5+Palmas) running, there will
> be more developers to look at it.

OK so the issue is that the twl msecure pin should be high to enable
the RTC registers. We used to have that code with platform_data, but
no longer have it with device tree based booting. I'll send a patch
for that.

Curiously setting jumper j5 on beagle-x15 that controls what used to
be the msecure and now is powerhold, does the opposite.. The
device boots automatically but RTC is stopped?

Regards,

Tony

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [160111 12:27]:
> 
> OK so the issue is that the twl msecure pin should be high to enable
> the RTC registers. We used to have that code with platform_data, but
> no longer have it with device tree based booting. I'll send a patch
> for that.
> 
> Curiously setting jumper j5 on beagle-x15 that controls what used to
> be the msecure and now is powerhold, does the opposite.. The
> device boots automatically but RTC is stopped?

And here's a fix the issue for omap5. Beagle-x15 needs to be
investigated more.

Care to test it with your RTC enabling patch?

Regards,

Tony

8< ---------------
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Date: Mon, 11 Jan 2016 14:35:24 -0800
Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes

The palmas PMIC has some control lines that need to be muxed properly
for things to work. The sys_nirq pin is used for interrupts, and msecure
pin is used for enabling writes to some PMIC registers.

Without these pins configured properly things can fail in mysterious
ways. For example, we can't update the RTC registers on palmas PMIC
unless the msecure pin is configured. And this is probably the reason
why we had RTC missing from the omap5 dts file.

According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)"
swps052f.pdf, mux mode 1 is for sys_drm_msecure so there's no need to
configure it as a GPIO pin.

Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -213,6 +213,12 @@
 		>;
 	};
 
+	palmas_msecure_pins: palmas_msecure_pins {
+		pinctrl-single,pins = <
+			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */
+		>;
+	};
+
 	usbhost_pins: pinmux_usbhost_pins {
 		pinctrl-single,pins = <
 			0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
@@ -278,6 +284,12 @@
 			&usbhost_wkup_pins
 	>;
 
+	palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins {
+		pinctrl-single,pins = <
+			OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */
+		>;
+	};
+
 	usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
 		pinctrl-single,pins = <
 			0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */
@@ -345,6 +357,8 @@
 		interrupt-controller;
 		#interrupt-cells = <2>;
 		ti,system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>;
 
 		extcon_usb3: palmas_usb {
 			compatible = "ti,palmas-usb-vid";
--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi Tony,

Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:

> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [160111 12:27]:
>> 
>> OK so the issue is that the twl msecure pin should be high to enable
>> the RTC registers. We used to have that code with platform_data, but
>> no longer have it with device tree based booting. I'll send a patch
>> for that.
>> 
>> Curiously setting jumper j5 on beagle-x15 that controls what used to
>> be the msecure and now is powerhold, does the opposite.. The
>> device boots automatically but RTC is stopped?
> 
> And here's a fix the issue for omap5. Beagle-x15 needs to be
> investigated more.
> 
> Care to test it with your RTC enabling patch?

yes, I will test asap.

Reminds me on some issues we did have with msecure and twl4030 rtc some years ago.

BR,
Nikolaus

> 
> Regards,
> 
> Tony
> 
> 8< ---------------
> From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> Date: Mon, 11 Jan 2016 14:35:24 -0800
> Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes
> 
> The palmas PMIC has some control lines that need to be muxed properly
> for things to work. The sys_nirq pin is used for interrupts, and msecure
> pin is used for enabling writes to some PMIC registers.
> 
> Without these pins configured properly things can fail in mysterious
> ways. For example, we can't update the RTC registers on palmas PMIC
> unless the msecure pin is configured. And this is probably the reason
> why we had RTC missing from the omap5 dts file.
> 
> According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)"
> swps052f.pdf, mux mode 1 is for sys_drm_msecure so there's no need to
> configure it as a GPIO pin.
> 
> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
> 
> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> @@ -213,6 +213,12 @@
> 		>;
> 	};
> 
> +	palmas_msecure_pins: palmas_msecure_pins {
> +		pinctrl-single,pins = <
> +			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */
> +		>;
> +	};
> +
> 	usbhost_pins: pinmux_usbhost_pins {
> 		pinctrl-single,pins = <
> 			0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
> @@ -278,6 +284,12 @@
> 			&usbhost_wkup_pins
> 	>;
> 
> +	palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins {
> +		pinctrl-single,pins = <
> +			OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */
> +		>;
> +	};
> +
> 	usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
> 		pinctrl-single,pins = <
> 			0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */
> @@ -345,6 +357,8 @@
> 		interrupt-controller;
> 		#interrupt-cells = <2>;
> 		ti,system-power-controller;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>;
> 
> 		extcon_usb3: palmas_usb {
> 			compatible = "ti,palmas-usb-vid";

--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi Tony,

Am 12.01.2016 um 14:30 schrieb H. Nikolaus Schaller <hns@goldelico.com>:

> Hi Tony,
> 
> Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony@atomide.com>:
> 
>> * Tony Lindgren <tony@atomide.com> [160111 12:27]:
>>> 
>>> OK so the issue is that the twl msecure pin should be high to enable
>>> the RTC registers. We used to have that code with platform_data, but
>>> no longer have it with device tree based booting. I'll send a patch
>>> for that.
>>> 
>>> Curiously setting jumper j5 on beagle-x15 that controls what used to
>>> be the msecure and now is powerhold, does the opposite.. The
>>> device boots automatically but RTC is stopped?
>> 
>> And here's a fix the issue for omap5. Beagle-x15 needs to be
>> investigated more.
>> 
>> Care to test it with your RTC enabling patch?
> 
> yes, I will test asap.
> 
> Reminds me on some issues we did have with msecure and twl4030 rtc some years ago.

Ok, works for me on OMAP5432EVM.

Thanks for spotting the issue.

> 
> BR,
> Nikolaus
> 
>> 
>> Regards,
>> 
>> Tony
>> 
>> 8< ---------------
>> From: Tony Lindgren <tony@atomide.com>
>> Date: Mon, 11 Jan 2016 14:35:24 -0800
>> Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes
>> 
>> The palmas PMIC has some control lines that need to be muxed properly
>> for things to work. The sys_nirq pin is used for interrupts, and msecure
>> pin is used for enabling writes to some PMIC registers.
>> 
>> Without these pins configured properly things can fail in mysterious
>> ways. For example, we can't update the RTC registers on palmas PMIC
>> unless the msecure pin is configured. And this is probably the reason
>> why we had RTC missing from the omap5 dts file.
>> 
>> According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)"
>> swps052f.pdf, mux mode 1 is for sys_drm_msecure so there's no need to
>> configure it as a GPIO pin.
>> 
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>> 
>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>> @@ -213,6 +213,12 @@
>> 		>;
>> 	};
>> 
>> +	palmas_msecure_pins: palmas_msecure_pins {
>> +		pinctrl-single,pins = <
>> +			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */
>> +		>;
>> +	};
>> +
>> 	usbhost_pins: pinmux_usbhost_pins {
>> 		pinctrl-single,pins = <
>> 			0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
>> @@ -278,6 +284,12 @@
>> 			&usbhost_wkup_pins
>> 	>;
>> 
>> +	palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins {
>> +		pinctrl-single,pins = <
>> +			OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */
>> +		>;
>> +	};
>> +
>> 	usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
>> 		pinctrl-single,pins = <
>> 			0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */
>> @@ -345,6 +357,8 @@
>> 		interrupt-controller;
>> 		#interrupt-cells = <2>;
>> 		ti,system-power-controller;
>> +		pinctrl-names = "default";
>> +		pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>;
>> 
>> 		extcon_usb3: palmas_usb {
>> 			compatible = "ti,palmas-usb-vid";
> 

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/12/2016 03:27 PM, H. Nikolaus Schaller wrote:
> Hi Tony,
> 
> Am 12.01.2016 um 14:30 schrieb H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>:
> 
>> Hi Tony,
>>
>> Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
>>
>>> * Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [160111 12:27]:
>>>>
>>>> OK so the issue is that the twl msecure pin should be high to enable
>>>> the RTC registers. We used to have that code with platform_data, but
>>>> no longer have it with device tree based booting. I'll send a patch
>>>> for that.
>>>>
>>>> Curiously setting jumper j5 on beagle-x15 that controls what used to
>>>> be the msecure and now is powerhold, does the opposite.. The
>>>> device boots automatically but RTC is stopped?
>>>
>>> And here's a fix the issue for omap5. Beagle-x15 needs to be
>>> investigated more.
>>>
>>> Care to test it with your RTC enabling patch?
>>
>> yes, I will test asap.
>>
>> Reminds me on some issues we did have with msecure and twl4030 rtc some years ago.
> 
> Ok, works for me on OMAP5432EVM.
> 
> Thanks for spotting the issue.
> 


http://pastebin.ubuntu.com/14480852/
Works for me as well ( https://patchwork.kernel.org/patch/7954341/ +
http://pastebin.ubuntu.com/14480852/)



-- 
Regards,
Nishanth Menon
--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> [160112 13:38]:
> On 01/12/2016 03:27 PM, H. Nikolaus Schaller wrote:
> >> Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:
> >>> Care to test it with your RTC enabling patch?
> >>
> >> yes, I will test asap.
> >>
> >> Reminds me on some issues we did have with msecure and twl4030 rtc some years ago.
> > 
> > Ok, works for me on OMAP5432EVM.
> > 
> > Thanks for spotting the issue.

OK thanks.

> http://pastebin.ubuntu.com/14480852/
> Works for me as well ( https://patchwork.kernel.org/patch/7954341/ +
> http://pastebin.ubuntu.com/14480852/)

OK thanks for testing, will apply both to omap-for-v4.5/fixes to get RTC
working on omap5.

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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi Tony,

Am 12.01.2016 um 22:27 schrieb H. Nikolaus Schaller <hns@goldelico.com>:

> Hi Tony,
> 
> Am 12.01.2016 um 14:30 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> 
>> Hi Tony,
>> 
>> Am 12.01.2016 um 01:09 schrieb Tony Lindgren <tony@atomide.com>:
>> 
>>> * Tony Lindgren <tony@atomide.com> [160111 12:27]:
>>>> 
>>>> OK so the issue is that the twl msecure pin should be high to enable
>>>> the RTC registers. We used to have that code with platform_data, but
>>>> no longer have it with device tree based booting. I'll send a patch
>>>> for that.
>>>> 
>>>> Curiously setting jumper j5 on beagle-x15 that controls what used to
>>>> be the msecure and now is powerhold, does the opposite.. The
>>>> device boots automatically but RTC is stopped?
>>> 
>>> And here's a fix the issue for omap5. Beagle-x15 needs to be
>>> investigated more.
>>> 
>>> Care to test it with your RTC enabling patch?
>> 
>> yes, I will test asap.
>> 
>> Reminds me on some issues we did have with msecure and twl4030 rtc some years ago.
> 
> Ok, works for me on OMAP5432EVM.

Yes, it works, but I didn't look into the code yet.

> 
> Thanks for spotting the issue.
> 
>> 
>> BR,
>> Nikolaus
>> 
>>> 
>>> Regards,
>>> 
>>> Tony
>>> 
>>> 8< ---------------
>>> From: Tony Lindgren <tony@atomide.com>
>>> Date: Mon, 11 Jan 2016 14:35:24 -0800
>>> Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes
>>> 
>>> The palmas PMIC has some control lines that need to be muxed properly
>>> for things to work. The sys_nirq pin is used for interrupts, and msecure
>>> pin is used for enabling writes to some PMIC registers.
>>> 
>>> Without these pins configured properly things can fail in mysterious
>>> ways. For example, we can't update the RTC registers on palmas PMIC
>>> unless the msecure pin is configured. And this is probably the reason
>>> why we had RTC missing from the omap5 dts file.
>>> 
>>> According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)"
>>> swps052f.pdf, mux mode 1 is for sys_drm_msecure so there's no need to
>>> configure it as a GPIO pin.
>>> 
>>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>> 
>>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>>> @@ -213,6 +213,12 @@
>>> 		>;
>>> 	};
>>> 
>>> +	palmas_msecure_pins: palmas_msecure_pins {
>>> +		pinctrl-single,pins = <
>>> +			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */

I wonder now what MODE1 is.

In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved".

Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15?

And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software).

This one

>>> 		OMAP5_IOPAD(0x180, PIN_INPUT _PULLUP | MUX_MODE6) /* gpio8_234 used for sys_drm_msecure */


works for me on the OMAP5 EVM as well.

BR,
Nikolaus

>>> +		>;
>>> +	};
>>> +
>>> 	usbhost_pins: pinmux_usbhost_pins {
>>> 		pinctrl-single,pins = <
>>> 			0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
>>> @@ -278,6 +284,12 @@
>>> 			&usbhost_wkup_pins
>>> 	>;
>>> 
>>> +	palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins {
>>> +		pinctrl-single,pins = <
>>> +			OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */
>>> +		>;
>>> +	};
>>> +
>>> 	usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
>>> 		pinctrl-single,pins = <
>>> 			0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */
>>> @@ -345,6 +357,8 @@
>>> 		interrupt-controller;
>>> 		#interrupt-cells = <2>;
>>> 		ti,system-power-controller;
>>> +		pinctrl-names = "default";
>>> +		pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>;
>>> 
>>> 		extcon_usb3: palmas_usb {
>>> 			compatible = "ti,palmas-usb-vid";
>> 
> 

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote:
[...]

>>>>
>>>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>>>
>>>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>>>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>>>> @@ -213,6 +213,12 @@
>>>> 		>;
>>>> 	};
>>>>
>>>> +	palmas_msecure_pins: palmas_msecure_pins {
>>>> +		pinctrl-single,pins = <
>>>> +			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */
> 
> I wonder now what MODE1 is.
> 
> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved".
> 
> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15?
> 
> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software).


Good catch. This one is interesting. If my memory serves me right,
MSECURE signal from SoC is triggered in secure mode (trustzone) - the
requirement was that certain PMIC modifications should only be done in
secure mode for certain product applications. What this means is that
certain functions of the PMIC will be unavailable when the SoC is
running in "untrusted" mode.

Instead, the usual mode of operation is to set it up as GPIO (as Nikolas
pointed below) and either use GPIO HOG or default weak pull to keep it
in the required state.

I think it is better to set it as GPIO than as DRM_MSECURE.

This is probably also the reason why this mode is NOT in public TRM -
all security related topics are probably in the NDA only secure TRM
addendum.


I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we
are not doing any HS OMAP5 at least in public domain :) ).

> 
> This one
> 
>>>> 		OMAP5_IOPAD(0x180, PIN_INPUT _PULLUP | MUX_MODE6) /* gpio8_234 used for sys_drm_msecure */
> 
> 
> works for me on the OMAP5 EVM as well.
> 

[...]


-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Grygorii Strashko]

On 01/13/2016 04:55 PM, Nishanth Menon wrote:
> On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote:
> [...]
> 
>>>>>
>>>>> Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
>>>>>
>>>>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>>>>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>>>>> @@ -213,6 +213,12 @@
>>>>> 		>;
>>>>> 	};
>>>>>
>>>>> +	palmas_msecure_pins: palmas_msecure_pins {
>>>>> +		pinctrl-single,pins = <
>>>>> +			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE1) /* gpio8_234.sys_drm_msecure */
>>
>> I wonder now what MODE1 is.
>>
>> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved".
>>
>> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15?
>>
>> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software).
> 
> 
> Good catch. This one is interesting. If my memory serves me right,
> MSECURE signal from SoC is triggered in secure mode (trustzone) - the
> requirement was that certain PMIC modifications should only be done in
> secure mode for certain product applications. What this means is that
> certain functions of the PMIC will be unavailable when the SoC is
> running in "untrusted" mode.
> 
> Instead, the usual mode of operation is to set it up as GPIO (as Nikolas
> pointed below) and either use GPIO HOG or default weak pull to keep it
> in the required state.
> 
> I think it is better to set it as GPIO than as DRM_MSECURE.
> 
> This is probably also the reason why this mode is NOT in public TRM -
> all security related topics are probably in the NDA only secure TRM
> addendum.
> 
> 
> I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we
> are not doing any HS OMAP5 at least in public domain :) ).

Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi)
and, again if i remember correctly, someone reported that sys_drm_msecure might have different values
on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality
was always modeled using GPIO.
 

-- 
regards,
-grygorii
--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Grygorii Strashko <grygorii.strashko@ti.com> [160113 07:15]:
> On 01/13/2016 04:55 PM, Nishanth Menon wrote:
> > On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote:
> >>
> >> I wonder now what MODE1 is.
> >>
> >> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved".
> >>
> >> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15?

The 5430 data manual I listed in the commit states mode 1 is for
msecure. It is unlikely it got changed for 5432 as the mux registers
tend to stay the same for most part across a SoC generation with just
devices being enabled or disabled.

For beagle-x15, the msecure is now called "powerhold" and seems to
have some additional or different functionality in the PMIC. So
that's a separate issue from this one.

> >> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software).
> > 
> > Good catch. This one is interesting. If my memory serves me right,
> > MSECURE signal from SoC is triggered in secure mode (trustzone) - the
> > requirement was that certain PMIC modifications should only be done in
> > secure mode for certain product applications. What this means is that
> > certain functions of the PMIC will be unavailable when the SoC is
> > running in "untrusted" mode.
> > 
> > Instead, the usual mode of operation is to set it up as GPIO (as Nikolas
> > pointed below) and either use GPIO HOG or default weak pull to keep it
> > in the required state.
> > 
> > I think it is better to set it as GPIO than as DRM_MSECURE.

Well we do have the data manual saying it's the msecure pin, and
we are muxing it to msecure for omap4 in twl6030_omap4.dtsi. And a
TI commit has used msecure mode for GP omap5 evm at least here:

https://gitlab.com/ubuntu-omap/u-boot-omap5/commit/dcc5279ffe880e874abb4d7f95302a34ab4968ca

I've added Keerthy to Cc, maybe he knows how this should be handled
in the long run?

So if we start changing things to GPIO mode, we really need some
further explanations and neeed to handle the GPIO pin properly in
the TWL driver. And it should be done in a separate patch for all
of the TWL SoCs.

> > This is probably also the reason why this mode is NOT in public TRM -
> > all security related topics are probably in the NDA only secure TRM
> > addendum.

Right, probably the msecure pin has been set reserved in the public TRM
because of whatever NDA reasons there might be to not allow writes to RTC.

> > I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we
> > are not doing any HS OMAP5 at least in public domain :) ).
> 
> Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi)
> and, again if i remember correctly, someone reported that sys_drm_msecure might have different values
> on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality
> was always modeled using GPIO.

Care to dig up some more information on that?

I don't have anything against adding GPIO handling to the TWL driver
so it can be optionally specified. But that's clearly a separate patch
and should be done by somebody who knows more about the issue and has
a test case needing the GPIO logic for this pin.

Regards,

Tony

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Grygorii Strashko]

On 01/13/2016 06:48 PM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@ti.com> [160113 07:15]:
>> On 01/13/2016 04:55 PM, Nishanth Menon wrote:
>>> On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote:
>>>>
>>>> I wonder now what MODE1 is.
>>>>
>>>> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved".
>>>>
>>>> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15?
> 
> The 5430 data manual I listed in the commit states mode 1 is for
> msecure. It is unlikely it got changed for 5432 as the mux registers
> tend to stay the same for most part across a SoC generation with just
> devices being enabled or disabled.
> 
> For beagle-x15, the msecure is now called "powerhold" and seems to
> have some additional or different functionality in the PMIC. So
> that's a separate issue from this one.
> 
>>>> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software).
>>>http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a7a516be9338eabc9a7682e7433fa34d86c1f208
>>> Good catch. This one is interesting. If my memory serves me right,
>>> MSECURE signal from SoC is triggered in secure mode (trustzone) - the
>>> requirement was that certain PMIC modifications should only be done in
>>> secure mode for certain product applications. What this means is that
>>> certain functions of the PMIC will be unavailable when the SoC is
>>> running in "untrusted" mode.
>>>
>>> Instead, the usual mode of operation is to set it up as GPIO (as Nikolas
>>> pointed below) and either use GPIO HOG or default weak pull to keep it
>>> in the required state.
>>>
>>> I think it is better to set it as GPIO than as DRM_MSECURE.
> 
> Well we do have the data manual saying it's the msecure pin, and
> we are muxing it to msecure for omap4 in twl6030_omap4.dtsi. And a
> TI commit has used msecure mode for GP omap5 evm at least here:
> 
> https://gitlab.com/ubuntu-omap/u-boot-omap5/commit/dcc5279ffe880e874abb4d7f95302a34ab4968ca
> 
> I've added Keerthy to Cc, maybe he knows how this should be handled
> in the long run?
> 
> So if we start changing things to GPIO mode, we really need some
> further explanations and neeed to handle the GPIO pin properly in
> the TWL driver. And it should be done in a separate patch for all
> of the TWL SoCs.
> 
>>> This is probably also the reason why this mode is NOT in public TRM -
>>> all security related topics are probably in the NDA only secure TRM
>>> addendum.
> 
> Right, probably the msecure pin has been set reserved in the public TRM
> because of whatever NDA reasons there might be to not allow writes to RTC.
> 
>>> I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we
>>> are not doing any HS OMAP5 at least in public domain :) ).
>>
>> Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi)
>> and, again if i remember correctly, someone reported that sys_drm_msecure might have different values
>> on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality
>> was always modeled using GPIO.
> 
> Care to dig up some more information on that?

i can't find this report, sry - as i remember there was difference
between some OMAP4 HS and GP SoCs. 

But links on commits for old 3.4 kernel below:
http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a7a516be9338eabc9a7682e7433fa34d86c1f208
http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=262669aebf4af4044a25e8292f0e27986e18445a

> 
> I don't have anything against adding GPIO handling to the TWL driver
> so it can be optionally specified. But that's clearly a separate patch
> and should be done by somebody who knows more about the issue and has
> a test case needing the GPIO logic for this pin.
> 


-- 
regards,
-grygorii

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/13/2016 11:12 AM, Grygorii Strashko wrote:
> On 01/13/2016 06:48 PM, Tony Lindgren wrote:

[...]

>> Care to dig up some more information on that?
> 
> i can't find this report, sry - as i remember there was difference
> between some OMAP4 HS and GP SoCs. 
> 
> But links on commits for old 3.4 kernel below:
> http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a7a516be9338eabc9a7682e7433fa34d86c1f208
> http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=262669aebf4af4044a25e8292f0e27986e18445a
> 
>>
>> I don't have anything against adding GPIO handling to the TWL driver
>> so it can be optionally specified. But that's clearly a separate patch
>> and should be done by somebody who knows more about the issue and has
>> a test case needing the GPIO logic for this pin.
>>
> 
> 
if it helps in anyways
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170707.html


-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Am 13.01.2016 um 18:38 schrieb Nishanth Menon <nm@ti.com>:

> On 01/13/2016 11:12 AM, Grygorii Strashko wrote:
>> On 01/13/2016 06:48 PM, Tony Lindgren wrote:
> 
> [...]
> 
>>> Care to dig up some more information on that?
>> 
>> i can't find this report, sry - as i remember there was difference
>> between some OMAP4 HS and GP SoCs. 
>> 
>> But links on commits for old 3.4 kernel below:
>> http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=a7a516be9338eabc9a7682e7433fa34d86c1f208
>> http://omapzoom.org/?p=kernel/omap.git;a=commitdiff;h=262669aebf4af4044a25e8292f0e27986e18445a
>> 
>>> 
>>> I don't have anything against adding GPIO handling to the TWL driver
>>> so it can be optionally specified. But that's clearly a separate patch
>>> and should be done by somebody who knows more about the issue and has
>>> a test case needing the GPIO logic for this pin.
>>> 
>> 
>> 
> if it helps in anyways
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/170707.html

>> Yes, the TRM has some mode bits marked as reserved, but that doesn't
>> mean they don't work.  It just means the documentation is squirreled
>> away in the secure TRM addendum.

Ok, now I understand why the "reserved" MUX_MODE1 could still be correct
for OMAP5. And that I just have a "squirreled away" version of the TRM which
made me wonder what is going on.

>From this discussion I read that for X15 there is a different PMIC
(Palmas derived, but not a twl6037) so that it needs something different.

So my proposal would be to keep the MUX_MODE1 (because it works
on OMAP5+TWL6037) as proposed by Tony. Maybe after adding a comment
that MUX_MODE1 is a weakly documented feature.

And the X15 board can "patch" it after using the omap5-board-common.dtsi
to whatever it needs to fix it.

BR,
Nikolaus

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/13/2016 12:00 PM, H. Nikolaus Schaller wrote:
[...]
> And the X15 board can "patch" it after using the omap5-board-common.dtsi
> to whatever it needs to fix it.
> 

There is nothing to patch on X15[1]. there is no MSECURE pin on X15.
there are three RTCs on X15: MCP, TPS and DRA7-RTC. TPS has no use for
RTC, in fact has no capability of having a backup battery - which pretty
much (at least IMHO) removes real world use of TPS as a RTC in a
non-networked world.. but anyways, lets keep X15 and uevm seperate -
they dont share much in this context.

[1]
https://github.com/beagleboard/beagleboard-x15/blob/master/BeagleBoard-X15_RevA2.pdf

-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/13/2016 10:48 AM, Tony Lindgren wrote:
> * Grygorii Strashko <grygorii.strashko@ti.com> [160113 07:15]:
>> On 01/13/2016 04:55 PM, Nishanth Menon wrote:
>>> On 01/13/2016 04:25 AM, H. Nikolaus Schaller wrote:
>>>>
>>>> I wonder now what MODE1 is.
>>>>
>>>> In my OMAP5 TRM (Version "Y" - may be too old) the MODE1 is tagged as "reserved".
>>>>
>>>> Maybe "reserved" happens to output a "1" on OMAP5 and a "0" on the X15?
> 
> The 5430 data manual I listed in the commit states mode 1 is for
> msecure. It is unlikely it got changed for 5432 as the mux registers
> tend to stay the same for most part across a SoC generation with just
> devices being enabled or disabled.

Again - it depends on NDA or non-NDA version of the TRM being refered to.

> 
> For beagle-x15, the msecure is now called "powerhold" and seems to
> have some additional or different functionality in the PMIC. So
> that's a separate issue from this one.

powerhold is NOT the same as msecure. the PMICs for X15 and O5, though
they share the same pedigree, are NOT the same. there are distinct
changes done in both PMIC definition, functionality and markets being
targeted by the PMIC.

> 
>>>> And as far as I am aware there is no "driver" for some MSECURE module (but I don't know the details of MSECURE control by software).
>>>
>>> Good catch. This one is interesting. If my memory serves me right,
>>> MSECURE signal from SoC is triggered in secure mode (trustzone) - the
>>> requirement was that certain PMIC modifications should only be done in
>>> secure mode for certain product applications. What this means is that
>>> certain functions of the PMIC will be unavailable when the SoC is
>>> running in "untrusted" mode.
>>>
>>> Instead, the usual mode of operation is to set it up as GPIO (as Nikolas
>>> pointed below) and either use GPIO HOG or default weak pull to keep it
>>> in the required state.
>>>
>>> I think it is better to set it as GPIO than as DRM_MSECURE.
> 
> Well we do have the data manual saying it's the msecure pin, and
> we are muxing it to msecure for omap4 in twl6030_omap4.dtsi. And a
> TI commit has used msecure mode for GP omap5 evm at least here:
> 
> https://gitlab.com/ubuntu-omap/u-boot-omap5/commit/dcc5279ffe880e874abb4d7f95302a34ab4968ca

We used to have High security devices previously (before those got
scrapped).

> 
> I've added Keerthy to Cc, maybe he knows how this should be handled
> in the long run?
> 
> So if we start changing things to GPIO mode, we really need some
> further explanations and neeed to handle the GPIO pin properly in
> the TWL driver. And it should be done in a separate patch for all
> of the TWL SoCs.

That does not make sense to me. The original intent of MSECURE is to use
PMIC control (in specific certain usecases - which are no longer
relevant) in trustzone or equivalent secure processor modes. when such a
mode is not planned on being used, you just tell PMIC that it is always
in secure mode. In fact, there was discussion internally that MSECURE
should never even have been connected to SoC if the SoC was GP SoC - but
ofcourse, the want to have a consistent reference schematics for evms
(since EVMs have HS/Non-HS parts) trumped such talk.

trying to split this up into further steps adds 0 additional
functionality - what is the pmic driver supposed to do with the GPIO even?

in *real* HS product devices, in fact, the register space is really
firewalled out


> 
>>> This is probably also the reason why this mode is NOT in public TRM -
>>> all security related topics are probably in the NDA only secure TRM
>>> addendum.
> 
> Right, probably the msecure pin has been set reserved in the public TRM
> because of whatever NDA reasons there might be to not allow writes to RTC.
> 

Unfortunately, the norm inside TI, anything that remotely sounds
"secure" gets wrapped up in NDA and triple signed blah blah.. I cant
explain the rationale for why such a definition came on RTC.


>>> I'd suggest setting up a GPIO hog and a mux to GPIO for board-common (we
>>> are not doing any HS OMAP5 at least in public domain :) ).
>>
>> Yeah. As I remember the same issue was with OMAP4 (twl6030_omap4.dtsi)
>> and, again if i remember correctly, someone reported that sys_drm_msecure might have different values
>> on different SoCs. Also I'd like to note that on Old non-DT kernel such functionality
>> was always modeled using GPIO.
> 
> Care to dig up some more information on that?


The last TI product kernel tree that seriously focussed on OMAP5/OMAP4
was
http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4
things changed definitions (in terms of descope) since then.. but
anyways.. thought I'd just pitch it out here.

sevm: - this board got scrapped
http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5evm.c;h=bd8d71d75cc3da921856bb2004230e4cd6505328;hb=refs/heads/p-linux-omap-3.4#l1097

omap5-panda is the omap5uevm/evm now:
http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816

> 
> I don't have anything against adding GPIO handling to the TWL driver
> so it can be optionally specified. But that's clearly a separate patch

TWL/TPS driver will need no change in the proposal I made with "gpio
hog" mechanism (Documentation/devicetree/bindings/gpio/gpio.txt -
gpio-hog property) - just a dt change for the right configuration.


> and should be done by somebody who knows more about the issue and has
> a test case needing the GPIO logic for this pin.
> 

Since my explanation does not seem to suffice, alright - we can wait for
the right person, then.


-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [160113 09:30]:
> On 01/13/2016 10:48 AM, Tony Lindgren wrote:
> > 
> > So if we start changing things to GPIO mode, we really need some
> > further explanations and neeed to handle the GPIO pin properly in
> > the TWL driver. And it should be done in a separate patch for all
> > of the TWL SoCs.
> 
> That does not make sense to me. The original intent of MSECURE is to use
> PMIC control (in specific certain usecases - which are no longer
> relevant) in trustzone or equivalent secure processor modes. when such a
> mode is not planned on being used, you just tell PMIC that it is always
> in secure mode. In fact, there was discussion internally that MSECURE
> should never even have been connected to SoC if the SoC was GP SoC - but
> ofcourse, the want to have a consistent reference schematics for evms
> (since EVMs have HS/Non-HS parts) trumped such talk.
> 
> trying to split this up into further steps adds 0 additional
> functionality - what is the pmic driver supposed to do with the GPIO even?
> 
> in *real* HS product devices, in fact, the register space is really
> firewalled out

Right, OK here we are finally getting some answers to the "why" part :)

And I also have few more "why" question in mind. If this change from
msecure to GPIO muxing is so important.

Why it was never fixed in the mainline kernel for omap4 and omap5 and
it was just sitting in various TI trees?

And it sounds like any kind of muxing on HS devices here for this
pin will oops the device?

> The last TI product kernel tree that seriously focussed on OMAP5/OMAP4
> was
> http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4
> things changed definitions (in terms of descope) since then.. but
> anyways.. thought I'd just pitch it out here.
> 
> sevm: - this board got scrapped
> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5evm.c;h=bd8d71d75cc3da921856bb2004230e4cd6505328;hb=refs/heads/p-linux-omap-3.4#l1097
> 
> omap5-panda is the omap5uevm/evm now:
> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816

OK

> > I don't have anything against adding GPIO handling to the TWL driver
> > so it can be optionally specified. But that's clearly a separate patch
> 
> TWL/TPS driver will need no change in the proposal I made with "gpio
> hog" mechanism (Documentation/devicetree/bindings/gpio/gpio.txt -
> gpio-hog property) - just a dt change for the right configuration.

OK. So are we sure the TWL driver will never have to toggle this pin?

Again, that's another "why" that I have no clue about and that is not
documented anywhere.

> > and should be done by somebody who knows more about the issue and has
> > a test case needing the GPIO logic for this pin.
> 
> Since my explanation does not seem to suffice, alright - we can wait for
> the right person, then.

Sorry don't take it personally. I'm just trying to make sense of the
"why do we need to do this change?" part. Especially if I need to make
the change and write the commit log.

Regards,

Tony

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Am 13.01.2016 um 19:00 schrieb Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>:

> * Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> [160113 09:30]:
>> On 01/13/2016 10:48 AM, Tony Lindgren wrote:
>>> 
>>> So if we start changing things to GPIO mode, we really need some
>>> further explanations and neeed to handle the GPIO pin properly in
>>> the TWL driver. And it should be done in a separate patch for all
>>> of the TWL SoCs.
>> 
>> That does not make sense to me. The original intent of MSECURE is to use
>> PMIC control (in specific certain usecases - which are no longer
>> relevant) in trustzone or equivalent secure processor modes. when such a
>> mode is not planned on being used, you just tell PMIC that it is always
>> in secure mode. In fact, there was discussion internally that MSECURE
>> should never even have been connected to SoC if the SoC was GP SoC - but
>> ofcourse, the want to have a consistent reference schematics for evms
>> (since EVMs have HS/Non-HS parts) trumped such talk.
>> 
>> trying to split this up into further steps adds 0 additional
>> functionality - what is the pmic driver supposed to do with the GPIO even?
>> 
>> in *real* HS product devices, in fact, the register space is really
>> firewalled out
> 
> Right, OK here we are finally getting some answers to the "why" part :)
> 
> And I also have few more "why" question in mind. If this change from
> msecure to GPIO muxing is so important.
> 
> Why it was never fixed in the mainline kernel for omap4 and omap5 and
> it was just sitting in various TI trees?
> 
> And it sounds like any kind of muxing on HS devices here for this
> pin will oops the device?
> 
>> The last TI product kernel tree that seriously focussed on OMAP5/OMAP4
>> was
>> http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4
>> things changed definitions (in terms of descope) since then.. but
>> anyways.. thought I'd just pitch it out here.
>> 
>> sevm: - this board got scrapped
>> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5evm.c;h=bd8d71d75cc3da921856bb2004230e4cd6505328;hb=refs/heads/p-linux-omap-3.4#l1097
>> 
>> omap5-panda is the omap5uevm/evm now:
>> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816
> 
> OK
> 
>>> I don't have anything against adding GPIO handling to the TWL driver
>>> so it can be optionally specified. But that's clearly a separate patch
>> 
>> TWL/TPS driver will need no change in the proposal I made with "gpio
>> hog" mechanism (Documentation/devicetree/bindings/gpio/gpio.txt -
>> gpio-hog property) - just a dt change for the right configuration.
> 
> OK. So are we sure the TWL driver will never have to toggle this pin?

After studying the Palmas TRM it appears that this pin just should be "high"
to be able to write to RTC and some scratchpad register. If the Palmas OTP
is programmed to use gpio7 as msecure input.

Since the scratchpad is not used we can permanently enable msecure. Which
means that we must somehow get the driving output to be "1".

This can be either done by
* a gpio with pull-up - switched to input mode as I proposed, or
* a real gpio output which is actively set to value 1 in u-boot or kernel driver, or
* the not well documented feature of MUX_MODE1 (OMAP5), other MUX_MODEs for OMAP3/4.

For my application we do not need to change the msecure state. We just need
to be able to write the rtc. And since the gpio7 of the Palmas is connected to
gpio8_234 of the OMAP5 we just have to initialize it properly once.

BR,
Nikolaus

--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote:
[...]

>> OK. So are we sure the TWL driver will never have to toggle this pin?
> 
> After studying the Palmas TRM it appears that this pin just should be "high"
> to be able to write to RTC and some scratchpad register. If the Palmas OTP
> is programmed to use gpio7 as msecure input.

Thanks for digging it up. we dont use the scratchpad, but in some cases
where SoC cold reset is involved, those registers may store additional
information.

> 
> Since the scratchpad is not used we can permanently enable msecure. Which
> means that we must somehow get the driving output to be "1".
> 
> This can be either done by
> * a gpio with pull-up - switched to input mode as I proposed, or

I think you intended to suggest to do a mux to gpio with just pinmux
pull? The internal pull on padconf is very weak - for typical needs like
these, it is rather suggested to stick with real GPIO drive to prevent
conditions like noise interference(for example).


-- 
Regards,
Nishanth Menon
--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Am 13.01.2016 um 19:31 schrieb Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>:

> On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote:
> [...]
> 
>>> OK. So are we sure the TWL driver will never have to toggle this pin?
>> 
>> After studying the Palmas TRM it appears that this pin just should be "high"
>> to be able to write to RTC and some scratchpad register. If the Palmas OTP
>> is programmed to use gpio7 as msecure input.
> 
> Thanks for digging it up. we dont use the scratchpad, but in some cases
> where SoC cold reset is involved, those registers may store additional
> information.

I remember a similar thing from omap3-twl4030 where the boot source is stored
so that a warm reboot searches there. But I don#t know if the OMPAP5 Boot ROM
is using that.

> 
>> 
>> Since the scratchpad is not used we can permanently enable msecure. Which
>> means that we must somehow get the driving output to be "1".
>> 
>> This can be either done by
>> * a gpio with pull-up - switched to input mode as I proposed, or
> 
> I think you intended to suggest to do a mux to gpio with just pinmux
> pull?

Yes.

> The internal pull on padconf is very weak
> - for typical needs like
> these, it is rather suggested to stick with real GPIO drive to prevent
> conditions like noise interference(for example).


well, on OMAP5 pull up/down are astonishingly strong :)
100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic.
So a noise source must be coupled by an impedance in the 1 kOhm range.
This is quite rare. So I would not worry about that.

But if there is MUX_MODE1 for this purpose that works equally well, we
should use it instead of a gpin+pullup.

BR,
Nikolaus--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/13/2016 12:44 PM, H. Nikolaus Schaller wrote:
> 
> Am 13.01.2016 um 19:31 schrieb Nishanth Menon <nm@ti.com>:
> 
>> On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote:
>> [...]
>>
>>>> OK. So are we sure the TWL driver will never have to toggle this pin?
>>>
>>> After studying the Palmas TRM it appears that this pin just should be "high"
>>> to be able to write to RTC and some scratchpad register. If the Palmas OTP
>>> is programmed to use gpio7 as msecure input.
>>
>> Thanks for digging it up. we dont use the scratchpad, but in some cases
>> where SoC cold reset is involved, those registers may store additional
>> information.
> 
> I remember a similar thing from omap3-twl4030 where the boot source is stored
> so that a warm reboot searches there. But I don#t know if the OMPAP5 Boot ROM
> is using that.
> 

I believe that nonsense of OMAP ROM accessing PMIC stopped with OMAP3. I
dont believe OMAP4 or any later generation processors does any PMIC
access anymore - they instead make assumptions about specific voltage
levels they will work on (So called OPP_BOOT) instead of assuming
specific PMIC they will work with..

>>> Since the scratchpad is not used we can permanently enable msecure. Which
>>> means that we must somehow get the driving output to be "1".
>>>
>>> This can be either done by
>>> * a gpio with pull-up - switched to input mode as I proposed, or
>>
>> I think you intended to suggest to do a mux to gpio with just pinmux
>> pull?
> 
> Yes.
> 
>> The internal pull on padconf is very weak
>> - for typical needs like
>> these, it is rather suggested to stick with real GPIO drive to prevent
>> conditions like noise interference(for example).
> 
> 
> well, on OMAP5 pull up/down are astonishingly strong :)
> 100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic.
> So a noise source must be coupled by an impedance in the 1 kOhm range.
> This is quite rare. So I would not worry about that.
> 

Interesting. I did not know that, and have'nt dug at people to confirm
that either :).

An internal feedback I got some time back on AM57 (not OMAP5) - context
was that we were discussing if an external pull up resistor was needed
for a GPIO button:
"Internal pull-ups are relatively weak (ranging to 100kOhm or higher)
and are good for avoiding higher leakage due to floating input level,
and may not be sufficient for valid logic 1/0 depending on what else is
connected on the board.  If a signal must absolutely be pulled to a
valid logic 1 or 0 for system functionality, then an external pull
should be used."

Anyways... will let Tony decide where he wants to go on this..

-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Grygorii Strashko]

On 01/13/2016 09:05 PM, Nishanth Menon wrote:
> On 01/13/2016 12:44 PM, H. Nikolaus Schaller wrote:
>>
>> Am 13.01.2016 um 19:31 schrieb Nishanth Menon <nm@ti.com>:
>>
>>> On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote:
>>> [...]
>>>
>>>>> OK. So are we sure the TWL driver will never have to toggle this pin?
>>>>
>>>> After studying the Palmas TRM it appears that this pin just should be "high"
>>>> to be able to write to RTC and some scratchpad register. If the Palmas OTP
>>>> is programmed to use gpio7 as msecure input.
>>>
>>> Thanks for digging it up. we dont use the scratchpad, but in some cases
>>> where SoC cold reset is involved, those registers may store additional
>>> information.
>>
>> I remember a similar thing from omap3-twl4030 where the boot source is stored
>> so that a warm reboot searches there. But I don#t know if the OMPAP5 Boot ROM
>> is using that.
>>
> 
> I believe that nonsense of OMAP ROM accessing PMIC stopped with OMAP3. I
> dont believe OMAP4 or any later generation processors does any PMIC
> access anymore - they instead make assumptions about specific voltage
> levels they will work on (So called OPP_BOOT) instead of assuming
> specific PMIC they will work with..
> 
>>>> Since the scratchpad is not used we can permanently enable msecure. Which
>>>> means that we must somehow get the driving output to be "1".
>>>>
>>>> This can be either done by
>>>> * a gpio with pull-up - switched to input mode as I proposed, or
>>>
>>> I think you intended to suggest to do a mux to gpio with just pinmux
>>> pull?
>>
>> Yes.
>>
>>> The internal pull on padconf is very weak
>>> - for typical needs like
>>> these, it is rather suggested to stick with real GPIO drive to prevent
>>> conditions like noise interference(for example).
>>
>>
>> well, on OMAP5 pull up/down are astonishingly strong :)
>> 100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic.
>> So a noise source must be coupled by an impedance in the 1 kOhm range.
>> This is quite rare. So I would not worry about that.
>>
> 
> Interesting. I did not know that, and have'nt dug at people to confirm
> that either :).
> 
> An internal feedback I got some time back on AM57 (not OMAP5) - context
> was that we were discussing if an external pull up resistor was needed
> for a GPIO button:
> "Internal pull-ups are relatively weak (ranging to 100kOhm or higher)
> and are good for avoiding higher leakage due to floating input level,
> and may not be sufficient for valid logic 1/0 depending on what else is
> connected on the board.  If a signal must absolutely be pulled to a
> valid logic 1 or 0 for system functionality, then an external pull
> should be used."

MUX_MODE1(secure modes) is not working well as i mentioned. 

Here I agree with Nishanth -  "gpio hog" mechanism looks like
the best solution now, because of:
- it exist now :P. At the moment when omap4/5 were fixed the pinmux
solution was the simplest and fastest one, with not too many alternatives.
- explicit gpio hog definition in DT will help other developer (and
what is more important HW designers) to better understand that this gpio
can be used as generic GPIO (at minimum without HW modification).  

-- 
regards,
-grygorii

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Nishanth Menon <nm@ti.com> [160113 11:06]:
> On 01/13/2016 12:44 PM, H. Nikolaus Schaller wrote:
> > 
> > Am 13.01.2016 um 19:31 schrieb Nishanth Menon <nm@ti.com>:
> > 
> >> On 01/13/2016 12:08 PM, H. Nikolaus Schaller wrote:
> >>> Since the scratchpad is not used we can permanently enable msecure. Which
> >>> means that we must somehow get the driving output to be "1".
> >>>
> >>> This can be either done by
> >>> * a gpio with pull-up - switched to input mode as I proposed, or
> >>
> >> I think you intended to suggest to do a mux to gpio with just pinmux
> >> pull?
> > 
> > Yes.
> > 
> >> The internal pull on padconf is very weak
> >> - for typical needs like
> >> these, it is rather suggested to stick with real GPIO drive to prevent
> >> conditions like noise interference(for example).
> > 
> > 
> > well, on OMAP5 pull up/down are astonishingly strong :)
> > 100-250µA. Which translated roughly to 7 .. 18 kOhm @ 1.8V logic.
> > So a noise source must be coupled by an impedance in the 1 kOhm range.
> > This is quite rare. So I would not worry about that.
> > 
> 
> Interesting. I did not know that, and have'nt dug at people to confirm
> that either :).
> 
> An internal feedback I got some time back on AM57 (not OMAP5) - context
> was that we were discussing if an external pull up resistor was needed
> for a GPIO button:
> "Internal pull-ups are relatively weak (ranging to 100kOhm or higher)
> and are good for avoiding higher leakage due to floating input level,
> and may not be sufficient for valid logic 1/0 depending on what else is
> connected on the board.  If a signal must absolutely be pulled to a
> valid logic 1 or 0 for system functionality, then an external pull
> should be used."
> 
> Anyways... will let Tony decide where he wants to go on this..

Eek now we have at least three options! Time for online vote:

1. Use msecure pinmux and let whatever mystery software control
   the pin completely out of our control like we've been doing with
   the mainline kernel for years.

2. Set up the msecure pin as GPIO output high unconditionally.
   This is what the TI android kernel tree seems to be doing.

3. New suggestion to use the SoC internal pull to keep the msecure
   pin high. This might be a little bit more power friendly than
   option #2 or #3.

Maybe option #3 would save a little bit more power compared to
options 1 and 2?

Anyways, considering what's been discussed, after the minimal RTC fix
we could also add code to allow the TWL driver optionally configure the
GPIO. This way the TWL driver could also check the GPIO state in case
some out-of-our-control mystery software goes tweak the msecure pin
state. Or the RTC driver could just check that the bits really change
after= writing them. Then we would at least know things are not working
right for the TWL related RTC drivers.

Regards,

Tony

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/13/2016 01:40 PM, Tony Lindgren wrote:

> Anyways, considering what's been discussed, after the minimal RTC fix
> we could also add code to allow the TWL driver optionally configure the
> GPIO. This way the TWL driver could also check the GPIO state in case
> some out-of-our-control mystery software goes tweak the msecure pin
> state.

I dont even know how that will work:
If you are using MSECURE as it is intended to be, then you'd mux it to
msecure, which means that GPIO read is just a waste of time - you dont
even mux it to external world. Now, some SoCs like DRA7 has input lines
always connected. even assuming this is for such a case:
a) when you are running linux, you are already in nonsecure - it needs
no read of MSECURE GPIO to figure that out.
b)  when you are in secure world, Linux wont be running either.

Reading from GPIO is just misguided in my opinion. firewalls are not
reconfigured, and muxes are usually done a single time.

 Or the RTC driver could just check that the bits really change
> after= writing them. Then we would at least know things are not working
> right for the TWL related RTC drivers.

that is reasonable to check, but just a overhead - anyways, just
isolated to palmas-rtc.. fail reason maynot always be issues with
MSECURE mux.. it could be very well be 32k clk fail etc.. but yeah -
that might give a hint that there is an issue..

-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Keerthy]

On Thursday 14 January 2016 04:02 AM, Nishanth Menon wrote:
> On 01/13/2016 01:40 PM, Tony Lindgren wrote:
>
>> Anyways, considering what's been discussed, after the minimal RTC fix
>> we could also add code to allow the TWL driver optionally configure the
>> GPIO. This way the TWL driver could also check the GPIO state in case
>> some out-of-our-control mystery software goes tweak the msecure pin
>> state.
>
> I dont even know how that will work:
> If you are using MSECURE as it is intended to be, then you'd mux it to
> msecure, which means that GPIO read is just a waste of time - you dont
> even mux it to external world. Now, some SoCs like DRA7 has input lines
> always connected. even assuming this is for such a case:
> a) when you are running linux, you are already in nonsecure - it needs
> no read of MSECURE GPIO to figure that out.
> b)  when you are in secure world, Linux wont be running either.
>
> Reading from GPIO is just misguided in my opinion. firewalls are not
> reconfigured, and muxes are usually done a single time.
>
>   Or the RTC driver could just check that the bits really change
>> after= writing them. Then we would at least know things are not working
>> right for the TWL related RTC drivers.
>
> that is reasonable to check, but just a overhead - anyways, just
> isolated to palmas-rtc.. fail reason maynot always be issues with
> MSECURE mux.. it could be very well be 32k clk fail etc.. but yeah -
> that might give a hint that there is an issue..
>

IIRC without configuring the mux mode of gpio234 to msecure mode we were 
unable to write to the rtc registers. Hence configured it one time at boot.

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/14/2016 04:01 AM, Keerthy wrote:
> 
> 
> On Thursday 14 January 2016 04:02 AM, Nishanth Menon wrote:
>> On 01/13/2016 01:40 PM, Tony Lindgren wrote:
>>
>>> Anyways, considering what's been discussed, after the minimal RTC fix
>>> we could also add code to allow the TWL driver optionally configure the
>>> GPIO. This way the TWL driver could also check the GPIO state in case
>>> some out-of-our-control mystery software goes tweak the msecure pin
>>> state.
>>
>> I dont even know how that will work:
>> If you are using MSECURE as it is intended to be, then you'd mux it to
>> msecure, which means that GPIO read is just a waste of time - you dont
>> even mux it to external world. Now, some SoCs like DRA7 has input lines
>> always connected. even assuming this is for such a case:
>> a) when you are running linux, you are already in nonsecure - it needs
>> no read of MSECURE GPIO to figure that out.
>> b)  when you are in secure world, Linux wont be running either.
>>
>> Reading from GPIO is just misguided in my opinion. firewalls are not
>> reconfigured, and muxes are usually done a single time.
>>
>>   Or the RTC driver could just check that the bits really change
>>> after= writing them. Then we would at least know things are not working
>>> right for the TWL related RTC drivers.
>>
>> that is reasonable to check, but just a overhead - anyways, just
>> isolated to palmas-rtc.. fail reason maynot always be issues with
>> MSECURE mux.. it could be very well be 32k clk fail etc.. but yeah -
>> that might give a hint that there is an issue..
>>
> 
> IIRC without configuring the mux mode of gpio234 to msecure mode we were 
> unable to write to the rtc registers. Hence configured it one time at boot.
> 
Looks like you missed the code section that shows that the u-boot
configuration was overridden by kernel as GPIO for the very same reason.!

http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816

-- 
Regards,
Nishanth Menon
--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> [160114 09:40]:
> On 01/14/2016 04:01 AM, Keerthy wrote:
> > 
> > IIRC without configuring the mux mode of gpio234 to msecure mode we were 
> > unable to write to the rtc registers. Hence configured it one time at boot.
> > 
> Looks like you missed the code section that shows that the u-boot
> configuration was overridden by kernel as GPIO for the very same reason.!
> 
> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816

OK so let's use the GPIO hog for the msecure pin then. Here's an
updated patch, please retest that hwclock -w works properly with
the RTC patch in this thread.

Regards,

Tony

8<--------------------
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Date: Mon, 11 Jan 2016 14:35:24 -0800
Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes

The palmas PMIC has two control lines that need to be muxed properly
for things to work. The sys_nirq pin is used for interrupts, and msecure
pin is used for enabling writes to some PMIC registers.

Without these pins configured properly things can fail in mysterious
ways. For example, we can't update the RTC registers on palmas PMIC
unless the msecure pin is configured. And this is probably the reason
why we had RTC missing from the omap5 dts file.

According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)"
swps052f.pdf, mux mode 1 is for sys_drm_msecure so there's no need to
configure it as a GPIO pin.

However, it seems there are some reliability issues using the msecure
mux mode. The TI trees configure the msecure pin as GPIO out high
instead.

As the PMIC only cares that the msecure line is high to allow access
to the RTC registers, let's use a GPIO hog as suggested by Nishanth
Menon <nm-l0cyMroinI0@public.gmane.org>. Also the use of the internal pull was considered
but supposedly that may not be capable of driving the line in a noisy
environment.

If we ever see high security omap5 products in the mainline tree,
those need to skip the msecure pin muxing and ignore setting the GPIO
hog. Chances are the related pin mux registers are locked in that case
and the msecure pin is managed by whatever software may be running in
the ARM TrustZone.

Who knows what the original intention of the msecure pin was. Maybe
it was supposed to prevent the system time to be set back for some
game demo modes to time out? Anyways, it seems that later PMICs like
tps659037 have recycled this pin for "powerhold" and devices like
beagle-x15 do not need changes to the msecure pin configuration.

To avoid further confusion with TWL variant PMICs, beagle-x15 does
not have a back-up battery for RTC palmas. Instead the mcp79410 RTC
is used with rtc-ds1307 driver. There is a "powerhold" jumper j5
holes near the palmas PMIC, and shorting it seems to power up
beagle-x15 automatically. It is unknown if it also has other side
effects to the beagle-x15 power up sequence.

Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -130,6 +130,16 @@
 	};
 };
 
+&gpio8 {
+	/* TI trees use GPIO instead of msecure, see also muxing */
+	p234 {
+		gpio-hog;
+		gpios = <10 GPIO_ACTIVE_HIGH>;
+		output-high;
+		line-name = "gpio8_234/msecure";
+	};
+};
+
 &omap5_pmx_core {
 	pinctrl-names = "default";
 	pinctrl-0 = <
@@ -213,6 +223,13 @@
 		>;
 	};
 
+	/* TI trees use GPIO mode; msecure mode does not work reliably? */
+	palmas_msecure_pins: palmas_msecure_pins {
+		pinctrl-single,pins = <
+			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE7) /* gpio8_234 */
+		>;
+	};
+
 	usbhost_pins: pinmux_usbhost_pins {
 		pinctrl-single,pins = <
 			0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
@@ -278,6 +295,12 @@
 			&usbhost_wkup_pins
 	>;
 
+	palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins {
+		pinctrl-single,pins = <
+			OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */
+		>;
+	};
+
 	usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
 		pinctrl-single,pins = <
 			0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */
@@ -345,6 +368,8 @@
 		interrupt-controller;
 		#interrupt-cells = <2>;
 		ti,system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>;
 
 		extcon_usb3: palmas_usb {
 			compatible = "ti,palmas-usb-vid";
--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Am 14.01.2016 um 19:35 schrieb Tony Lindgren <tony@atomide.com>:

> * Nishanth Menon <nm@ti.com> [160114 09:40]:
>> On 01/14/2016 04:01 AM, Keerthy wrote:
>>> 
>>> IIRC without configuring the mux mode of gpio234 to msecure mode we were 
>>> unable to write to the rtc registers. Hence configured it one time at boot.
>>> 
>> Looks like you missed the code section that shows that the u-boot
>> configuration was overridden by kernel as GPIO for the very same reason.!
>> 
>> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816
> 
> OK so let's use the GPIO hog for the msecure pin then.
> Here's an
> updated patch, please retest that hwclock -w works properly with
> the RTC patch in this thread.

I tried and it works.

But then I found that you did set MUX_MODE7. Which is safe-mode.

And in safe-mode the gpio8_234/msecure ball should be "L".

Then I experimented a little and it appears that you can remove
the gpio-hog entry:

root@letux:~# devmem2 0x4A002980
/dev/mem opened.
Memory mapped at address 0xb6f48000.
Value at address 0x4A002980 (0xb6f48980): 0x1080006
root@letux:~# hwclock
Fri Jan 15 13:32:52 2016  -0.726651 seconds
root@letux:~# 

Or even mux the gpio to PIN_INPUT_PULLDOWN | MUX_MODE6:

root@letux:~# devmem2 0x4A002980
/dev/mem opened.
Memory mapped at address 0xb6f35000.
Value at address 0x4A002980 (0xb6f35980): 0x108010E
root@letux:~# hwclock
Fri Jan 15 14:30:05 2016  -1.155714 seconds
root@letux:~# 

So I now wonder if the twl6037 variant on the OMAP5432EVM really has
the gpio7 enabled as msecure input (there is some mention of OTP variants
in the Palmas docs I have, but I don't have the one of the exact chip variant used
on the EVM).

If it were disabled by OTP (and then I assume it is automatically write-unprotected),
then we would simply have a useless connection from gpio8_234 to Palmas...

So the outcome might depend on the Palmas chip version that is used on any
board that includes the omap5-board-common.dtsi.

And the main difference between hwclock not-working and working on the omap5evm
should be the nirq1 part of your patch!

Please can someone else confirm that hwclock works without any init for
the msecure line and that I did not have a false positive by some other reason?

BR,
Nikolaus

> 
> Regards,
> 
> Tony
> 
> 8<--------------------
> From: Tony Lindgren <tony@atomide.com>
> Date: Mon, 11 Jan 2016 14:35:24 -0800
> Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes
> 
> The palmas PMIC has two control lines that need to be muxed properly
> for things to work. The sys_nirq pin is used for interrupts, and msecure
> pin is used for enabling writes to some PMIC registers.
> 
> Without these pins configured properly things can fail in mysterious
> ways. For example, we can't update the RTC registers on palmas PMIC
> unless the msecure pin is configured. And this is probably the reason
> why we had RTC missing from the omap5 dts file.
> 
> According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)"
> swps052f.pdf, mux mode 1 is for sys_drm_msecure so there's no need to
> configure it as a GPIO pin.
> 
> However, it seems there are some reliability issues using the msecure
> mux mode. The TI trees configure the msecure pin as GPIO out high
> instead.
> 
> As the PMIC only cares that the msecure line is high to allow access
> to the RTC registers, let's use a GPIO hog as suggested by Nishanth
> Menon <nm@ti.com>. Also the use of the internal pull was considered
> but supposedly that may not be capable of driving the line in a noisy
> environment.
> 
> If we ever see high security omap5 products in the mainline tree,
> those need to skip the msecure pin muxing and ignore setting the GPIO
> hog. Chances are the related pin mux registers are locked in that case
> and the msecure pin is managed by whatever software may be running in
> the ARM TrustZone.
> 
> Who knows what the original intention of the msecure pin was. Maybe
> it was supposed to prevent the system time to be set back for some
> game demo modes to time out? Anyways, it seems that later PMICs like
> tps659037 have recycled this pin for "powerhold" and devices like
> beagle-x15 do not need changes to the msecure pin configuration.
> 
> To avoid further confusion with TWL variant PMICs, beagle-x15 does
> not have a back-up battery for RTC palmas. Instead the mcp79410 RTC
> is used with rtc-ds1307 driver. There is a "powerhold" jumper j5
> holes near the palmas PMIC, and shorting it seems to power up
> beagle-x15 automatically. It is unknown if it also has other side
> effects to the beagle-x15 power up sequence.
> 
> Signed-off-by: Tony Lindgren <tony@atomide.com>
> 
> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
> @@ -130,6 +130,16 @@
> 	};
> };
> 
> +&gpio8 {
> +	/* TI trees use GPIO instead of msecure, see also muxing */
> +	p234 {
> +		gpio-hog;
> +		gpios = <10 GPIO_ACTIVE_HIGH>;
> +		output-high;
> +		line-name = "gpio8_234/msecure";
> +	};
> +};
> +
> &omap5_pmx_core {
> 	pinctrl-names = "default";
> 	pinctrl-0 = <
> @@ -213,6 +223,13 @@
> 		>;
> 	};
> 
> +	/* TI trees use GPIO mode; msecure mode does not work reliably? */
> +	palmas_msecure_pins: palmas_msecure_pins {
> +		pinctrl-single,pins = <
> +			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE7) /* gpio8_234 */

s/MUX_MODE7/MUX_MODE0/

or

s/MUX_MODE7/MUX_MODE6/

> +		>;
> +	};
> +
> 	usbhost_pins: pinmux_usbhost_pins {
> 		pinctrl-single,pins = <
> 			0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
> @@ -278,6 +295,12 @@
> 			&usbhost_wkup_pins
> 	>;
> 
> +	palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins {
> +		pinctrl-single,pins = <
> +			OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */
> +		>;
> +	};
> +
> 	usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
> 		pinctrl-single,pins = <
> 			0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */
> @@ -345,6 +368,8 @@
> 		interrupt-controller;
> 		#interrupt-cells = <2>;
> 		ti,system-power-controller;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>;
> 
> 		extcon_usb3: palmas_usb {
> 			compatible = "ti,palmas-usb-vid";

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* H. Nikolaus Schaller <hns@goldelico.com> [160115 06:34]:
> Am 14.01.2016 um 19:35 schrieb Tony Lindgren <tony@atomide.com>:
> > updated patch, please retest that hwclock -w works properly with
> > the RTC patch in this thread.
> 
> I tried and it works.
> 
> But then I found that you did set MUX_MODE7. Which is safe-mode.

Oops, that's a typo, sorry!

> And in safe-mode the gpio8_234/msecure ball should be "L".
> 
> Then I experimented a little and it appears that you can remove
> the gpio-hog entry:
> 
> root@letux:~# devmem2 0x4A002980
> /dev/mem opened.
> Memory mapped at address 0xb6f48000.
> Value at address 0x4A002980 (0xb6f48980): 0x1080006
> root@letux:~# hwclock
> Fri Jan 15 13:32:52 2016  -0.726651 seconds
> root@letux:~# 
> 
> Or even mux the gpio to PIN_INPUT_PULLDOWN | MUX_MODE6:

Hmm interesting. Have to test here too. FYI, it might be also worth
draining the back-up battery with a small resistor while testing
to make sure there's no initial state in the PMIC.

> root@letux:~# devmem2 0x4A002980
> /dev/mem opened.
> Memory mapped at address 0xb6f35000.
> Value at address 0x4A002980 (0xb6f35980): 0x108010E
> root@letux:~# hwclock
> Fri Jan 15 14:30:05 2016  -1.155714 seconds
> root@letux:~# 
> 
> So I now wonder if the twl6037 variant on the OMAP5432EVM really has
> the gpio7 enabled as msecure input (there is some mention of OTP variants
> in the Palmas docs I have, but I don't have the one of the exact chip variant used
> on the EVM).
>
> If it were disabled by OTP (and then I assume it is automatically write-unprotected),
> then we would simply have a useless connection from gpio8_234 to Palmas...
> 
> So the outcome might depend on the Palmas chip version that is used on any
> board that includes the omap5-board-common.dtsi.

Could be different version yeah.

> And the main difference between hwclock not-working and working on the omap5evm
> should be the nirq1 part of your patch!

OK so best to go back to square one with the testing with just the nirq1
change.

> Please can someone else confirm that hwclock works without any init for
> the msecure line and that I did not have a false positive by some other reason?

Just to be sure.. Have you tested with hwclock -w and made sure it
changes the time? Otherwise you may have started the RTC with some
earlier kernel and it still keeps on ticking so the read test is
not enough.

Regards,

Tony

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Tony Lindgren]

* Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> [160115 07:48]:
> * H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org> [160115 06:34]:
> > I tried and it works.
> > 
> > But then I found that you did set MUX_MODE7. Which is safe-mode.
> 
> Oops, that's a typo, sorry!
> 
> > And in safe-mode the gpio8_234/msecure ball should be "L".
> > 
> > Then I experimented a little and it appears that you can remove
> > the gpio-hog entry:
> > 
> > root@letux:~# devmem2 0x4A002980
> > /dev/mem opened.
> > Memory mapped at address 0xb6f48000.
> > Value at address 0x4A002980 (0xb6f48980): 0x1080006
> > root@letux:~# hwclock
> > Fri Jan 15 13:32:52 2016  -0.726651 seconds
> > root@letux:~# 
> > 
> > Or even mux the gpio to PIN_INPUT_PULLDOWN | MUX_MODE6:
> 
> Hmm interesting. Have to test here too. FYI, it might be also worth
> draining the back-up battery with a small resistor while testing
> to make sure there's no initial state in the PMIC.

Looks like the bootloader has mux mode 0x118 here for me. That does
not work for hwclock -w. Also commenting out the GPIO hog makes the
hwclock -w stop working for me. So looks like I need both the mux
and GPIO hog for hwclock -w to work.

I've also retested the patch I sent yesterday with MUX_MODE7 typo,
and hwclock -w does not work with that one. I must have fat fingered
that somehow yesterday and not retested. I have not retested the
msecure muxing but presumably that alone works too still for me.

> > So the outcome might depend on the Palmas chip version that is used on any
> > board that includes the omap5-board-common.dtsi.
> 
> Could be different version yeah.

This could be still the case though. Or you did not test with
hwclock -w? Or there's some persistent state in the PMIC that
is only cleared after draining the back-up battery.

Anyways, updated patch below with the mux mode fixed. I also updated
the comments a bit.

Regards,

Tony

8< ---------------------
From: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>
Date: Mon, 11 Jan 2016 14:35:24 -0800
Subject: [PATCH] ARM: dts: Fix omap5 PMIC control lines for RTC writes

The palmas PMIC has two control lines that need to be muxed properly
for things to work. The sys_nirq pin is used for interrupts, and msecure
pin is used for enabling writes to some PMIC registers.

Without these pins configured properly things can fail in mysterious
ways. For example, we can't update the RTC registers on palmas PMIC
unless the msecure pin is configured. And this is probably the reason
why we had RTC missing from the omap5 dts file.

According to "OMAP5430 ES2.0 Data Manual [Public] VErsion A (Rev. F)"
swps052f.pdf, mux mode 1 is for sys_drm_msecure so in theory there's
should be no need to configure it as a GPIO pin.

However, it seems there are some reliability issues using the msecure
mux mode. And the TI trees configure the msecure pin as GPIO out high
instead.

As the PMIC only cares that the msecure line is high to allow access
to the RTC registers, let's use a GPIO hog as suggested by Nishanth
Menon <nm-l0cyMroinI0@public.gmane.org>. Also the use of the internal pull was considered
but supposedly that may not be capable of keeping the line high in
a noisy environment.

If we ever see high security omap5 products in the mainline tree,
those need to skip the msecure pin muxing and ignore setting the GPIO
hog. Chances are the related pin mux registers are locked in that case
and the msecure pin is managed by whatever software may be running in
the ARM TrustZone.

Who knows what the original intention of the msecure pin was. Maybe
it was supposed to prevent the system time to be set back for some
game demo modes to time out? Anyways, it seems that later PMICs like
tps659037 have recycled this pin for "powerhold" and devices like
beagle-x15 do not need changes to the msecure pin configuration.

To avoid further confusion with TWL variant PMICs, beagle-x15 does
not have a back-up battery for RTC palmas. Instead the mcp79410 RTC
is used with rtc-ds1307 driver. There is a "powerhold" jumper j5
holes near the palmas PMIC, and shorting it seems to power up
beagle-x15 automatically. It is unknown if it also has other side
effects to the beagle-x15 power up sequence.

Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org # v4.4
Signed-off-by: Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>

--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -130,6 +130,16 @@
 	};
 };
 
+&gpio8 {
+	/* TI trees use GPIO instead of msecure, see also muxing */
+	p234 {
+		gpio-hog;
+		gpios = <10 GPIO_ACTIVE_HIGH>;
+		output-high;
+		line-name = "gpio8_234/msecure";
+	};
+};
+
 &omap5_pmx_core {
 	pinctrl-names = "default";
 	pinctrl-0 = <
@@ -213,6 +223,13 @@
 		>;
 	};
 
+	/* TI trees use GPIO mode; msecure mode does not work reliably? */
+	palmas_msecure_pins: palmas_msecure_pins {
+		pinctrl-single,pins = <
+			OMAP5_IOPAD(0x180, PIN_OUTPUT | MUX_MODE6) /* gpio8_234 */
+		>;
+	};
+
 	usbhost_pins: pinmux_usbhost_pins {
 		pinctrl-single,pins = <
 			0x84 (PIN_INPUT | MUX_MODE0) /* usbb2_hsic_strobe */
@@ -278,6 +295,12 @@
 			&usbhost_wkup_pins
 	>;
 
+	palmas_sys_nirq_pins: pinmux_palmas_sys_nirq_pins {
+		pinctrl-single,pins = <
+			OMAP5_IOPAD(0x068, PIN_INPUT_PULLUP | MUX_MODE0) /* sys_nirq1 */
+		>;
+	};
+
 	usbhost_wkup_pins: pinmux_usbhost_wkup_pins {
 		pinctrl-single,pins = <
 			0x1A (PIN_OUTPUT | MUX_MODE0) /* fref_clk1_out, USB hub clk */
@@ -345,6 +368,8 @@
 		interrupt-controller;
 		#interrupt-cells = <2>;
 		ti,system-power-controller;
+		pinctrl-names = "default";
+		pinctrl-0 = <&palmas_sys_nirq_pins &palmas_msecure_pins>;
 
 		extcon_usb3: palmas_usb {
 			compatible = "ti,palmas-usb-vid";
--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi,

Am 15.01.2016 um 16:47 schrieb Tony Lindgren <tony@atomide.com>:

> * H. Nikolaus Schaller <hns@goldelico.com> [160115 06:34]:
>> Am 14.01.2016 um 19:35 schrieb Tony Lindgren <tony@atomide.com>:
>>> updated patch, please retest that hwclock -w works properly with
>>> the RTC patch in this thread.
>> 
>> I tried and it works.
>> 
>> But then I found that you did set MUX_MODE7. Which is safe-mode.
> 
> Oops, that's a typo, sorry!
> 
>> And in safe-mode the gpio8_234/msecure ball should be "L".
>> 
>> Then I experimented a little and it appears that you can remove
>> the gpio-hog entry:
>> 
>> root@letux:~# devmem2 0x4A002980
>> /dev/mem opened.
>> Memory mapped at address 0xb6f48000.
>> Value at address 0x4A002980 (0xb6f48980): 0x1080006
>> root@letux:~# hwclock
>> Fri Jan 15 13:32:52 2016  -0.726651 seconds
>> root@letux:~# 
>> 
>> Or even mux the gpio to PIN_INPUT_PULLDOWN | MUX_MODE6:
> 
> Hmm interesting. Have to test here too. FYI, it might be also worth
> draining the back-up battery with a small resistor while testing
> to make sure there's no initial state in the PMIC.
> 
>> root@letux:~# devmem2 0x4A002980
>> /dev/mem opened.
>> Memory mapped at address 0xb6f35000.
>> Value at address 0x4A002980 (0xb6f35980): 0x108010E
>> root@letux:~# hwclock
>> Fri Jan 15 14:30:05 2016  -1.155714 seconds
>> root@letux:~# 
>> 
>> So I now wonder if the twl6037 variant on the OMAP5432EVM really has
>> the gpio7 enabled as msecure input (there is some mention of OTP variants
>> in the Palmas docs I have, but I don't have the one of the exact chip variant used
>> on the EVM).
>> 
>> If it were disabled by OTP (and then I assume it is automatically write-unprotected),
>> then we would simply have a useless connection from gpio8_234 to Palmas...
>> 
>> So the outcome might depend on the Palmas chip version that is used on any
>> board that includes the omap5-board-common.dtsi.
> 
> Could be different version yeah.
> 
>> And the main difference between hwclock not-working and working on the omap5evm
>> should be the nirq1 part of your patch!
> 
> OK so best to go back to square one with the testing with just the nirq1
> change.
> 
>> Please can someone else confirm that hwclock works without any init for
>> the msecure line and that I did not have a false positive by some other reason?
> 
> Just to be sure.. Have you tested with hwclock -w and made sure it
> changes the time? Otherwise you may have started the RTC with some
> earlier kernel and it still keeps on ticking so the read test is
> not enough.

You were right (and I as well to doubt my first results). And I also didn't
take ntpd in account.

Now:

root@letux:~# hwclock
Fri Jan 15 16:53:19 2016  -0.699173 seconds
root@letux:~# hwclock --set --date="2011-08-14 16:45:05"
root@letux:~# hwclock
Fri Jan 15 16:54:08 2016  -0.451544 seconds
root@letux:~# devmem2 0x4A002980 w 0x108010E
/dev/mem opened.
Memory mapped at address 0xb6f58000.
Value at address 0x4A002980 (0xb6f58980): 0x108010E
Written 0x108010E; readback 0x108010E
root@letux:~# hwclock --set --date="2011-08-14 16:45:05"
root@letux:~# hwclock
Fri Jan 15 16:55:18 2016  -0.555951 seconds
root@letux:~# devmem2 0x4A002980 w 0x108011E
/dev/mem opened.
Memory mapped at address 0xb6f7e000.
Value at address 0x4A002980 (0xb6f7e980): 0x108010E
Written 0x108011E; readback 0x108011E
root@letux:~# hwclock --set --date="2011-08-14 16:45:05"
root@letux:~# hwclock
Sun Aug 14 16:45:10 2011  -0.813317 seconds
root@letux:~# ^C
root@letux:~# 

So the pull-up in gpin-mode6 must be enable to *write* the RTC, i.e.
the msecure pin must indeed be pulled up (or hogged to "1").

It also works with gpio-hog + PIN_OUTPUT | MUX_MODE6.

This means:
* nirq1 is needed so that we don't have the timeout (on read/write)
* gpio-hog is needed on MODE6 or MODE0 to be able to really write (and not be silently ignored)

Thanks and BR,
Nikolaus

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Matthijs van Duin]

On 13 January 2016 at 19:18, Nishanth Menon <nm@ti.com> wrote:
> As you already see it is ridiculously round about way of protecting RTC
> time.. but anyways, for what ever reason, that was mandatory function to
> support on certain product lines.

Having secure date/time is probably necessary for some digital rights
management schemes; e.g. you rent a movie for limited time, but it may
not always be acceptable to require working internet connectivity to
be able to hit the play button hence the need to rely on a secure RTC.

There wouldn't even be an SMC for setting the RTC, probably it would
synchronize when the secure-world shizzle contacts the Big Server
O'Secrety Bits. :P

Protecting pinmux through the L4 firewall sounds hilarious: the whole
ctrl_core module (0x4a002000 - 0x4a002fff) is a single firewall
region. All permitted access to it by linux would have to be
redirected to an SMC or similar.

On 13 January 2016 at 20:05, Nishanth Menon <nm@ti.com> wrote:
> An internal feedback I got some time back on AM57 (not OMAP5) - context
> was that we were discussing if an external pull up resistor was needed
> for a GPIO button:
> "Internal pull-ups are relatively weak (ranging to 100kOhm or higher)

Unlike the OMAP5, AM57xx uses 1.8V/3.3V drivers for its generic IOs,
which have to do magic to not get fried by such high voltages.
Crappier specs result, especially for pulling up to 3.3V:
1.8V mode, pull-down current while pin is held high: 50-210 uA
3.3V mode, pull-down current while pin is held high: 40-200 uA
1.8V mode, pull-up current while pin is held low: 60-200 uA
3.3V mode, pull-up current while pin is held low: 10-290 uA

Note the worst-case equivalent pull-up resistance in 3.3V mode is 330
kOhm, eleven times higher than in 1.8V mode.

Matthijs

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/13/2016 12:00 PM, Tony Lindgren wrote:
> * Nishanth Menon <nm@ti.com> [160113 09:30]:
>> On 01/13/2016 10:48 AM, Tony Lindgren wrote:
>>>
>>> So if we start changing things to GPIO mode, we really need some
>>> further explanations and neeed to handle the GPIO pin properly in
>>> the TWL driver. And it should be done in a separate patch for all
>>> of the TWL SoCs.
>>
>> That does not make sense to me. The original intent of MSECURE is to use
>> PMIC control (in specific certain usecases - which are no longer
>> relevant) in trustzone or equivalent secure processor modes. when such a
>> mode is not planned on being used, you just tell PMIC that it is always
>> in secure mode. In fact, there was discussion internally that MSECURE
>> should never even have been connected to SoC if the SoC was GP SoC - but
>> ofcourse, the want to have a consistent reference schematics for evms
>> (since EVMs have HS/Non-HS parts) trumped such talk.
>>
>> trying to split this up into further steps adds 0 additional
>> functionality - what is the pmic driver supposed to do with the GPIO even?
>>
>> in *real* HS product devices, in fact, the register space is really
>> firewalled out
> 
> Right, OK here we are finally getting some answers to the "why" part :)
> 
> And I also have few more "why" question in mind. If this change from
> msecure to GPIO muxing is so important.
> 
> Why it was never fixed in the mainline kernel for omap4 and omap5 and
> it was just sitting in various TI trees?
> 
> And it sounds like any kind of muxing on HS devices here for this
> pin will oops the device?
> 

It depends on what the secure firewall does - unfortunately HS devices
are basically lego blocks that way. In the original usecase where
specific function like MSECURE was desired, the 4k chunk for padconf
registers would be firewalled away and only setup for access from
trustzone or a specific "trusted" processor like IPU M3/DSP.

>> The last TI product kernel tree that seriously focussed on OMAP5/OMAP4
>> was
>> http://git.omapzoom.org/?p=kernel/omap.git;a=shortlog;h=refs/heads/p-linux-omap-3.4
>> things changed definitions (in terms of descope) since then.. but
>> anyways.. thought I'd just pitch it out here.
>>
>> sevm: - this board got scrapped
>> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5evm.c;h=bd8d71d75cc3da921856bb2004230e4cd6505328;hb=refs/heads/p-linux-omap-3.4#l1097
>>
>> omap5-panda is the omap5uevm/evm now:
>> http://git.omapzoom.org/?p=kernel/omap.git;a=blob;f=arch/arm/mach-omap2/board-omap5panda.c;h=6113bc0e04625a1bd794b3f169581c67ad3b42ff;hb=refs/heads/p-linux-omap-3.4#l816
> 
> OK
> 
>>> I don't have anything against adding GPIO handling to the TWL driver
>>> so it can be optionally specified. But that's clearly a separate patch
>>
>> TWL/TPS driver will need no change in the proposal I made with "gpio
>> hog" mechanism (Documentation/devicetree/bindings/gpio/gpio.txt -
>> gpio-hog property) - just a dt change for the right configuration.
> 
> OK. So are we sure the TWL driver will never have to toggle this pin?
> 
> Again, that's another "why" that I have no clue about and that is not
> documented anywhere.
> 

It is not necessary for the functions we just described -MSECURE
function by itself is not something to be controlled by "non secure"
software (which is probably weird to us, but that is what security team
folks call HLOS like Linux). I dont recollect any recent product that
actually uses MSECURE the way we originally defined it. For the sake of
debate, Lets take a theoretical case where such a function might be
desired: in such a case, "non-secure" software should generate an SMC
service call into secure world for "setting RTC time"; When ARM enters
trustzone mode, MSECURE will be auto asserted by SoC. the secure
firmware will then have an I2C driver that will send a RTC set time
register access for the RTC time to be set.


In the above definition, we should not even have an TWL RTC driver,
instead a custom TWL-SMC-RTC driver will need to be written that will
access RTC on TWL/TPS over SMC calls to secure service. infact, if DSP
was desired for the "secure access", then a DSP-RPROC-RTC driver will
have to be written. The "generic definition" then became "MSECURE" and
was envisaged to protect further stuff eventually beyond RTC(I dont
recollect more than RTC unfortunately). In all such cases, you'd not use
MSECURE in GPIO mode - that will just defeat it's original purpose.
Instead you'd set it up as MSECURE in  secure boot software(even before
HLOS starts), then firewall the region off from access by non-secure
software, finally write a shim driver to send non-secure requests to the
secure world - which will determine who of the actors can actually do
which actions..

As you already see it is ridiculously round about way of protecting RTC
time.. but anyways, for what ever reason, that was mandatory function to
support on certain product lines.


I hope this helps.

>>> and should be done by somebody who knows more about the issue and has
>>> a test case needing the GPIO logic for this pin.
>>
>> Since my explanation does not seem to suffice, alright - we can wait for
>> the right person, then.
> 
> Sorry don't take it personally. I'm just trying to make sense of the
> "why do we need to do this change?" part. Especially if I need to make
> the change and write the commit log.

Not a problem, just trying to share what I can given that not all
thought process and background work that takes place inside TI is either
"logical" or in many cases fails to reach public documentation :( .

-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[H. Nikolaus Schaller]

Hi,

Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm@ti.com>:

> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>> tested on OMP5432 EVM
>> 
>> Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com>
>> ---
>> arch/arm/boot/dts/omap5-board-common.dtsi | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>> 
>> diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
>> index 5cf76a1..30c0d3b 100644
>> --- a/arch/arm/boot/dts/omap5-board-common.dtsi
>> +++ b/arch/arm/boot/dts/omap5-board-common.dtsi
>> @@ -358,6 +358,14 @@
>> 			#clock-cells = <0>;
>> 		};
>> 
>> +		rtc {
>> +			compatible = "ti,palmas-rtc";
>> +			interrupt-parent = <&palmas>;
>> +			interrupts = <8 IRQ_TYPE_NONE>;
> 
> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
> it had none, there'd be no interrupt, right?

Well, it just translates IRQ_TYPE_NONE through

Linux/include/dt-bindings/interrupt-controller/irq.h

to 

interrupts = <8 0>;

which is given as an example in

Documentation//devicetree/bindings/rtc/rtc-palmas.txt

Since I don't know anything about the rtc driver beyond the bindings documentation I assume it is correct...
I have added Laxman Dewangan because he introduced this interrupts = <8 0>;

> 
>> +			ti,backup-battery-chargeable;
>> +			ti,backup-battery-charge-high-current;
>> +		};
>> +
>> 		palmas_pmic {
>> 			compatible = "ti,palmas-pmic";
>> 			interrupt-parent = <&palmas>;
>> 
> 
> 
> -- 
> Regards,
> Nishanth Menon


BR,
Nikolaus

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Laxman Dewangan]

On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
> Hi,
>
> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>:
>
>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>> +		rtc {
>>> +			compatible = "ti,palmas-rtc";
>>> +			interrupt-parent = <&palmas>;
>>> +			interrupts = <8 IRQ_TYPE_NONE>;
>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>> it had none, there'd be no interrupt, right?
> Well, it just translates IRQ_TYPE_NONE through
>
> Linux/include/dt-bindings/interrupt-controller/irq.h
>
> to
>
> interrupts = <8 0>;
>
> which is given as an example in
>
> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>
> Since I don't know anything about the rtc driver beyond the bindings documentation I assume it is correct...
> I have added Laxman Dewangan because he introduced this interrupts = <8 0>;
>

As this is for palmas interrupt controller, it does not use the second 
field for interrupt from RTC.
So there is no really any polarity. It can be set to 0.

The second argument will be used for GPIOs mainly. However, support need 
to be added on GPIO driver for rising/falling configuration.




--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
> 
> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>> Hi,
>>
>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm@ti.com>:
>>
>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>>> +        rtc {
>>>> +            compatible = "ti,palmas-rtc";
>>>> +            interrupt-parent = <&palmas>;
>>>> +            interrupts = <8 IRQ_TYPE_NONE>;
>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>>> it had none, there'd be no interrupt, right?
>> Well, it just translates IRQ_TYPE_NONE through
>>
>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>
>> to
>>
>> interrupts = <8 0>;
>>
>> which is given as an example in
>>
>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>
>> Since I don't know anything about the rtc driver beyond the bindings
>> documentation I assume it is correct...
>> I have added Laxman Dewangan because he introduced this interrupts =
>> <8 0>;
>>
> 
> As this is for palmas interrupt controller, it does not use the second
> field for interrupt from RTC.
> So there is no really any polarity. It can be set to 0.
> 
> The second argument will be used for GPIOs mainly. However, support need
> to be added on GPIO driver for rising/falling configuration.


Device tree represents the hardware - not to reflect how the driver
works. if the driver is wrong, fix it. the interrupt polarity needs to
be described in DT. based on palmas like designs, you should probably
use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
the SoC as it reaches Secondary interrupt handlers(SIH) registers.

-- 
Regards,
Nishanth Menon

Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Rob Herring]

On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> wrote:
> On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
>>
>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>>> Hi,
>>>
>>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>:
>>>
>>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>>>> +        rtc {
>>>>> +            compatible = "ti,palmas-rtc";
>>>>> +            interrupt-parent = <&palmas>;
>>>>> +            interrupts = <8 IRQ_TYPE_NONE>;
>>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>>>> it had none, there'd be no interrupt, right?
>>> Well, it just translates IRQ_TYPE_NONE through
>>>
>>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>>
>>> to
>>>
>>> interrupts = <8 0>;
>>>
>>> which is given as an example in
>>>
>>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>>
>>> Since I don't know anything about the rtc driver beyond the bindings
>>> documentation I assume it is correct...
>>> I have added Laxman Dewangan because he introduced this interrupts =
>>> <8 0>;
>>>
>>
>> As this is for palmas interrupt controller, it does not use the second
>> field for interrupt from RTC.
>> So there is no really any polarity. It can be set to 0.
>>
>> The second argument will be used for GPIOs mainly. However, support need
>> to be added on GPIO driver for rising/falling configuration.
>
>
> Device tree represents the hardware - not to reflect how the driver
> works. if the driver is wrong, fix it. the interrupt polarity needs to
> be described in DT. based on palmas like designs, you should probably
> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
> the SoC as it reaches Secondary interrupt handlers(SIH) registers.

If the trigger type is not programmable, then not setting the trigger
type in the DT is fine. Internal connections are often not documented.

Rob
--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Nishanth Menon]

On 01/06/2016 01:34 PM, Rob Herring wrote:
> On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon <nm-l0cyMroinI0@public.gmane.org> wrote:
>> On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
>>>
>>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>>>> Hi,
>>>>
>>>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm-l0cyMroinI0@public.gmane.org>:
>>>>
>>>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>>>>> +        rtc {
>>>>>> +            compatible = "ti,palmas-rtc";
>>>>>> +            interrupt-parent = <&palmas>;
>>>>>> +            interrupts = <8 IRQ_TYPE_NONE>;
>>>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>>>>> it had none, there'd be no interrupt, right?
>>>> Well, it just translates IRQ_TYPE_NONE through
>>>>
>>>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>>>
>>>> to
>>>>
>>>> interrupts = <8 0>;
>>>>
>>>> which is given as an example in
>>>>
>>>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>>>
>>>> Since I don't know anything about the rtc driver beyond the bindings
>>>> documentation I assume it is correct...
>>>> I have added Laxman Dewangan because he introduced this interrupts =
>>>> <8 0>;
>>>>
>>>
>>> As this is for palmas interrupt controller, it does not use the second
>>> field for interrupt from RTC.
>>> So there is no really any polarity. It can be set to 0.
>>>
>>> The second argument will be used for GPIOs mainly. However, support need
>>> to be added on GPIO driver for rising/falling configuration.
>>
>>
>> Device tree represents the hardware - not to reflect how the driver
>> works. if the driver is wrong, fix it. the interrupt polarity needs to
>> be described in DT. based on palmas like designs, you should probably
>> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
>> the SoC as it reaches Secondary interrupt handlers(SIH) registers.
> 
> If the trigger type is not programmable, then not setting the trigger
> type in the DT is fine. Internal connections are often not documented.
> 

Weird, that is not what I got feedback when I send
https://patchwork.ozlabs.org/patch/381125/

If this is the new norm, I retract my objection.


-- 
Regards,
Nishanth Menon
--
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 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery

[Rob Herring]

On Wed, Jan 6, 2016 at 1:53 PM, Nishanth Menon <nm@ti.com> wrote:
> On 01/06/2016 01:34 PM, Rob Herring wrote:
>> On Wed, Jan 6, 2016 at 8:36 AM, Nishanth Menon <nm@ti.com> wrote:
>>> On 01/06/2016 02:13 AM, Laxman Dewangan wrote:
>>>>
>>>> On Wednesday 06 January 2016 01:12 PM, H. Nikolaus Schaller wrote:
>>>>> Hi,
>>>>>
>>>>> Am 06.01.2016 um 00:40 schrieb Nishanth Menon <nm@ti.com>:
>>>>>
>>>>>> On 01/05/2016 06:01 AM, H. Nikolaus Schaller wrote:
>>>>>>> +        rtc {
>>>>>>> +            compatible = "ti,palmas-rtc";
>>>>>>> +            interrupt-parent = <&palmas>;
>>>>>>> +            interrupts = <8 IRQ_TYPE_NONE>;
>>>>>> IRQ_TYPE_NONE is not correct here -> it should have some polarity - if
>>>>>> it had none, there'd be no interrupt, right?
>>>>> Well, it just translates IRQ_TYPE_NONE through
>>>>>
>>>>> Linux/include/dt-bindings/interrupt-controller/irq.h
>>>>>
>>>>> to
>>>>>
>>>>> interrupts = <8 0>;
>>>>>
>>>>> which is given as an example in
>>>>>
>>>>> Documentation//devicetree/bindings/rtc/rtc-palmas.txt
>>>>>
>>>>> Since I don't know anything about the rtc driver beyond the bindings
>>>>> documentation I assume it is correct...
>>>>> I have added Laxman Dewangan because he introduced this interrupts =
>>>>> <8 0>;
>>>>>
>>>>
>>>> As this is for palmas interrupt controller, it does not use the second
>>>> field for interrupt from RTC.
>>>> So there is no really any polarity. It can be set to 0.
>>>>
>>>> The second argument will be used for GPIOs mainly. However, support need
>>>> to be added on GPIO driver for rising/falling configuration.
>>>
>>>
>>> Device tree represents the hardware - not to reflect how the driver
>>> works. if the driver is wrong, fix it. the interrupt polarity needs to
>>> be described in DT. based on palmas like designs, you should probably
>>> use IRQ_TYPE_EDGE_FALLING because that is the default signaling inside
>>> the SoC as it reaches Secondary interrupt handlers(SIH) registers.
>>
>> If the trigger type is not programmable, then not setting the trigger
>> type in the DT is fine. Internal connections are often not documented.
>>
>
> Weird, that is not what I got feedback when I send
> https://patchwork.ozlabs.org/patch/381125/
>
> If this is the new norm, I retract my objection.

I'm not saying that necessarily makes sense here. Given the above, you do know the polarity.

To put it another way, if the trigger type doesn't matter, why do you have a second cell?

Rob

[PATCH 2/3] ARM: dts: omap5-board-common: enable iio gpadc for Palmas

[H. Nikolaus Schaller]

tested on OMP5432 EVM

Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
---
 arch/arm/boot/dts/omap5-board-common.dtsi | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-board-common.dtsi b/arch/arm/boot/dts/omap5-board-common.dtsi
index 30c0d3b..56429ce 100644
--- a/arch/arm/boot/dts/omap5-board-common.dtsi
+++ b/arch/arm/boot/dts/omap5-board-common.dtsi
@@ -366,6 +366,16 @@
 			ti,backup-battery-charge-high-current;
 		};
 
+		gpadc {
+			compatible = "ti,palmas-gpadc";
+			interrupts = <18 0
+				      16 0
+				      17 0>;
+			#io-channel-cells = <1>;
+			ti,channel0-current-microamp = <5>;
+			ti,channel3-current-microamp = <10>;
+		};
+
 		palmas_pmic {
 			compatible = "ti,palmas-pmic";
 			interrupt-parent = <&palmas>;
-- 
2.5.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 3/3] ARM: dts: twl6030: add gpadc

[H. Nikolaus Schaller]

tested on Pandaboard ES.

Signed-off-by: H. Nikolaus Schaller <hns-xXXSsgcRVICgSpxsJD1C4w@public.gmane.org>
---
 arch/arm/boot/dts/twl6030.dtsi | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/twl6030.dtsi b/arch/arm/boot/dts/twl6030.dtsi
index 55eb35f..98e444d 100644
--- a/arch/arm/boot/dts/twl6030.dtsi
+++ b/arch/arm/boot/dts/twl6030.dtsi
@@ -99,4 +99,10 @@
 		compatible = "ti,twl6030-pwmled";
 		#pwm-cells = <2>;
 	};
+
+	adc {
+		compatible = "ti,twl6030-gpadc";
+		interrupts = <3>;
+		#io-channel-cells = <1>;
+	};
 };
-- 
2.5.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