Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1301472 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-05 13:10 +0100
    Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-06 00:50 +0100
      Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-06 02:10 +0100
        Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-06 09:20 +0100
          Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-06 17:50 +0100
            Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-06 18:10 +0100
              Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-08 19:00 +0100
                Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-08 19:20 +0100
                  Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-08 19:40 +0100
                    Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-08 20:10 +0100
                      Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-08 20:40 +0100
                        Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-11 21:30 +0100
                          Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-12 01:10 +0100
                            Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-12 14:40 +0100
                              Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-12 22:30 +0100
                                Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-12 22:40 +0100
                                  Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-12 23:20 +0100
                                Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-13 11:30 +0100
                                  Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-13 16:00 +0100
                                    Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Grygorii Strashko <grygorii.strashko@ti.com> - 2016-01-13 16:20 +0100
                                      Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-13 17:50 +0100
                                        Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Grygorii Strashko <grygorii.strashko@ti.com> - 2016-01-13 18:20 +0100
                                          Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-13 18:40 +0100
                                            Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-13 19:10 +0100
                                              Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-13 19:30 +0100
                                        Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-13 18:30 +0100
                                          Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-13 19:10 +0100
                                            Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-13 19:40 +0100
                                              Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-13 19:50 +0100
                                                Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-13 20:10 +0100
                                                  Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Grygorii Strashko <grygorii.strashko@ti.com> - 2016-01-13 20:30 +0100
                                                  Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-13 20:50 +0100
                                                    Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <menon.nishanth@gmail.com> - 2016-01-13 23:40 +0100
                                                      Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Keerthy <a0393675@ti.com> - 2016-01-14 11:10 +0100
                                                        Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-14 18:50 +0100
                                                          Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-14 19:40 +0100
                                                            Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-15 15:40 +0100
                                                              Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-15 16:50 +0100
                                                                Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-15 18:20 +0100
                                                                Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-15 19:20 +0100
                                          Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-13 19:10 +0100
                                            Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-13 19:20 +0100
          Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and  charging of backup battery Tony Lindgren <tony@atomide.com> - 2016-01-06 17:50 +0100
      Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging of backup battery "H. Nikolaus Schaller" <hns@goldelico.com> - 2016-01-06 08:50 +0100
        Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Laxman Dewangan <ldewangan@nvidia.com> - 2016-01-06 09:30 +0100
          Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-06 15:40 +0100
            Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Rob Herring <robh+dt@kernel.org> - 2016-01-06 20:40 +0100
              Re: [PATCH 1/3] ARM: dts: omap5-board-common: enable rtc and charging  of backup battery Nishanth Menon <nm@ti.com> - 2016-01-06 21:00 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

* 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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

#1308698

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

#1308693

Am 13.01.2016 um 19:00 schrieb Tony Lindgren <tony@atomide.com>:

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

#1308727

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.

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

* 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

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

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

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 */
+		>;
+	};
+
 	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";

[toc] | [prev] | [next] | [standalone]

#1310162

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

[toc] | [prev] | [next] | [standalone]

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

* 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

[toc] | [prev] | [next] | [standalone]

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

* Tony Lindgren <tony@atomide.com> [160115 07:48]:
> * H. Nikolaus Schaller <hns@goldelico.com> [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@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 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@ti.com>. 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@vger.kernel.org # v4.4
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_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";

[toc] | [prev] | [next] | [standalone]

#1310349

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web