Skip to contentSkip to conversation

rtc-twl: catch22 in 2.6.37 and 2.6.38 when clock was never set

PATCH New Alexander Holler 3 participants 12 messages Apr 4, 2011 – Jun 9, 2011

Subsystems (3)
Arm (32-bit) Arm sub-architectures OMAP2+ support
lore
Share & tools
lore

Alexander Holler

author
#0 lore raw

Hello,

it just happened here that the rechargeable backup battery for the RTC on a TPS65950 run out off power, because of some days while the device wasn't powered.

Afterwards I couldn't read or set the clock with hwclock using a kernel 2.6.37.n or 2.6.38.n.

I don't have a fix, but I think I've analyzed the problem and can offer a (bad) workaround.

What happens is the following:

When trying to read or set the clock with hwclock, the driver (rtc-twl) starts an alarm, but the irq for the alarm will never get called. The result is that a select in hwclock times out (for both operations, read or set).

Because I had this clock running before, I've got the idea to try one of those old OMAP-kernels (2.6.32-angstrom) using the same userland. And with that kernel I could set the clock.
Using 2.6.37 or 2.6.38 afterwards, hwclock did function again, both read an set are working.

So it looks like there is a catch22 in kernels >=2.6.37 (I haven't tested .33-.36):

When the clock was never set, the alarm(-irq) doesn't work, so hwclock doesn't work, so one can't set the clock.

Regards,

Alexander Holler

author
#1 lore raw

Hello,

Am 04.04.2011 16:29, schrieb Alexander Holler:

Quoted 23 lines

it just happened here that the rechargeable backup battery for the RTC on a TPS65950 run out off power, because of some days while the device wasn't powered.

Afterwards I couldn't read or set the clock with hwclock using a kernel 2.6.37.n or 2.6.38.n.

I don't have a fix, but I think I've analyzed the problem and can offer a (bad) workaround.

What happens is the following:

When trying to read or set the clock with hwclock, the driver (rtc-twl) starts an alarm, but the irq for the alarm will never get called. The result is that a select in hwclock times out (for both operations, read or set).

Because I had this clock running before, I've got the idea to try one of those old OMAP-kernels (2.6.32-angstrom) using the same userland. And with that kernel I could set the clock.
Using 2.6.37 or 2.6.38 afterwards, hwclock did function again, both read an set are working.

Quoted 5 lines

So it looks like there is a catch22 in kernels >=2.6.37 (I haven't tested .33-.36):

When the clock was never set, the alarm(-irq) doesn't work, so hwclock doesn't work, so one can't set the clock.

It turns out that the missing/wrong initialization of the msecure line is the problem which disabled setting the clock. After doing that through a quick hack, I could set the clock.

I'm using a BeagleBoard C4, but I can't find any msecure initialization for other boards too.

What happened with those patches? E.g. those:

http://www.mail-archive.com/[email protected]/msg16125.html

Regards,

Alexander

author
#2 lore raw

PATCH 1/1 arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Signed-off-by Alexander Holler <[email protected]>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +3 -0
index 46d814a..ebe3a7e 100644
@@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
 	usb_ehci_init(&ehci_pdata);
 	omap3beagle_flash_init();
 
+	/* Ensure msecure is mux'd to be able to set the RTC. */
+	omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
 	/* Ensure SDRC pins are mux'd for self-refresh */
 	omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
 	omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 1 line
1.7.3.4
maintainer
#3 lore raw

PATCH 1/1 arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Quoted 4 lines · Alexander Holler

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Adding this into fixes.

Tony

Quoted 26 lines
Signed-off-by Alexander Holler <[email protected]>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +3 -0
index 46d814a..ebe3a7e 100644
@@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
 	usb_ehci_init(&ehci_pdata);
 	omap3beagle_flash_init();
 
+	/* Ensure msecure is mux'd to be able to set the RTC. */
+	omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
 	/* Ensure SDRC pins are mux'd for self-refresh */
 	omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
 	omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 6 lines
1.7.3.4

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

PATCH 1/1 arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Am 31.05.2011 12:29, schrieb Tony Lindgren:

Quoted 23 lines · Alexander Holler
Quoted 4 lines

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Adding this into fixes.

Tony

Quoted 13 lines
Signed-off-by Alexander Holler<[email protected]>
---
  arch/arm/mach-omap2/board-omap3beagle.c |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 46d814a..ebe3a7e 100644
@@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
  	usb_ehci_init(&ehci_pdata);
  	omap3beagle_flash_init();
Quoted 9 lines
Quoted 9 lines
arch/arm/mach-omap2/board-omap3beagle.c +3 -1
+	/* Ensure msecure is mux'd to be able to set the RTC. */
+	omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
  	/* Ensure SDRC pins are mux'd for self-refresh */
  	omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
  	omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
--

1.7.3.4

I've later switched to the following patch which muxes msecure as GPIO (the drm-mode isn't explained in the TRM) and also exports the GPIO, so root could easily switch it to prevent modifications on the RTC.

(Warning, either my clipboard or the version of Thunderbird I'm currently using replaces the tabs with spaces in the pasted patch and I'm currently too lazy to search a workaround).

---
  arch/arm/mach-omap2/board-omap3beagle.c |    6 ++++++
  1 files changed, 6 insertions(+), 0 deletions(-)
(quoted diff) +0 -0

b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..24b4417 100644

arch/arm/mach-omap2/board-omap3beagle.c +6 -0
@@ -673,6 +673,12 @@ static void __init omap3_beagle_init(void)
         usbhs_init(&usbhs_bdata);
         omap3beagle_flash_init();
 
+       /* Ensure msecure is high to be able to set the RTC. */
+       omap_mux_init_signal("gpio_22", OMAP_PIN_OFF_OUTPUT_HIGH);
+       gpio_request(22, "msecure");
+       gpio_direction_output(22, true);
+       gpio_export(22, false);
+
         /* Ensure SDRC pins are mux'd for self-refresh */
         omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
         omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 5 lines
1.7.3.4

Regards,

Alexander Holler
#5 lore raw

PATCH 1/1 arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Quoted 47 lines · Alexander Holler

Am 31.05.2011 12:29, schrieb Tony Lindgren:

Quoted 23 lines · Alexander Holler
Quoted 4 lines

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Adding this into fixes.

Tony

Quoted 13 lines
Signed-off-by Alexander Holler<[email protected]>
---
  arch/arm/mach-omap2/board-omap3beagle.c |    3 +++
  1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 46d814a..ebe3a7e 100644
@@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
      usb_ehci_init(&ehci_pdata);
      omap3beagle_flash_init();
Quoted 9 lines
Quoted 9 lines
arch/arm/mach-omap2/board-omap3beagle.c +3 -0
+    /* Ensure msecure is mux'd to be able to set the RTC. */
+    omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
      /* Ensure SDRC pins are mux'd for self-refresh */
      omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
      omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 1 line
1.7.3.4

I've later switched to the following patch which muxes msecure as GPIO (the drm-mode isn't explained in the TRM) and also exports the GPIO, so root could easily switch it to prevent modifications on the RTC.

(Warning, either my clipboard or the version of Thunderbird I'm currently using replaces the tabs with spaces in the pasted patch and I'm currently too lazy to search a workaround).

---
 arch/arm/mach-omap2/board-omap3beagle.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 33007fd..24b4417 100644

arch/arm/mach-omap2/board-omap3beagle.c static void __init omap3_beagle_init(void) · line 679

Quoted 7 lines
arch/arm/mach-omap2/board-omap3beagle.c +4 -0
@@ -673,6 +673,12 @@ static void __init omap3_beagle_init(void)
        usbhs_init(&usbhs_bdata);
        omap3beagle_flash_init();
 
+       /* Ensure msecure is high to be able to set the RTC. */
+       omap_mux_init_signal("gpio_22", OMAP_PIN_OFF_OUTPUT_HIGH);
+       gpio_request(22, "msecure");
+       gpio_direction_output(22, true);

Can this be gpio_request_one() instead, please? Also, it will be nice to make a define for the magic 22.

Quoted 5 lines
arch/arm/mach-omap2/board-omap3beagle.c +2 -0
+       gpio_export(22, false);
+
        /* Ensure SDRC pins are mux'd for self-refresh */
        omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
        omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 2 lines
Regards,
Igor.
author
#6 lore raw

PATCH 1/1 arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Am 07.06.2011 11:50, schrieb Igor Grinberg:

Quoted 52 lines · Alexander Holler
Quoted 51 lines

Am 31.05.2011 12:29, schrieb Tony Lindgren:

Quoted 23 lines · Alexander Holler
Quoted 4 lines

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Adding this into fixes.

Tony

Quoted 13 lines
Signed-off-by Alexander Holler<[email protected]>
---
   arch/arm/mach-omap2/board-omap3beagle.c |    3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 46d814a..ebe3a7e 100644
@@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
       usb_ehci_init(&ehci_pdata);
       omap3beagle_flash_init();
Quoted 9 lines
Quoted 9 lines
arch/arm/mach-omap2/board-omap3beagle.c +3 -1
+    /* Ensure msecure is mux'd to be able to set the RTC. */
+    omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
       /* Ensure SDRC pins are mux'd for self-refresh */
       omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
       omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
--

1.7.3.4

I've later switched to the following patch which muxes msecure as GPIO (the drm-mode isn't explained in the TRM) and also exports the GPIO, so root could easily switch it to prevent modifications on the RTC.

(Warning, either my clipboard or the version of Thunderbird I'm currently using replaces the tabs with spaces in the pasted patch and I'm currently too lazy to search a workaround).

---
  arch/arm/mach-omap2/board-omap3beagle.c |    6 ++++++
  1 files changed, 6 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 33007fd..24b4417 100644
@@ -673,6 +673,12 @@ static void __init omap3_beagle_init(void)
         usbhs_init(&usbhs_bdata);
         omap3beagle_flash_init();
Quoted 7 lines

arch/arm/mach-omap2/board-omap3beagle.c static void __init omap3_beagle_init(void) · line 679

Quoted 4 lines
arch/arm/mach-omap2/board-omap3beagle.c +4 -0
+       /* Ensure msecure is high to be able to set the RTC. */
+       omap_mux_init_signal("gpio_22", OMAP_PIN_OFF_OUTPUT_HIGH);
+       gpio_request(22, "msecure");
+       gpio_direction_output(22, true);

Can this be gpio_request_one() instead, please? Also, it will be nice to make a define for the magic 22.

You need the "gpio_22" in the mux_init, so using a define would imho introduce a potential source for an error, at least when the define would not be anywhere near the "gpio_22" and someone would forget change the string too, when he changes the define. So I don't think a define adds much value there.

Quoted 7 lines

arch/arm/mach-omap2/board-omap3beagle.c static void __init omap3_beagle_init(void) · line 684

Quoted 6 lines
arch/arm/mach-omap2/board-omap3beagle.c +2 -0
+       gpio_export(22, false);
+
         /* Ensure SDRC pins are mux'd for self-refresh */
         omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
         omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);

Regards,

Alexander

#7 lore raw

PATCH 1/1 arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Quoted 61 lines · Alexander Holler

Am 07.06.2011 11:50, schrieb Igor Grinberg:

Quoted 52 lines · Alexander Holler
Quoted 51 lines

Am 31.05.2011 12:29, schrieb Tony Lindgren:

Quoted 23 lines · Alexander Holler
Quoted 4 lines

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Adding this into fixes.

Tony

Quoted 13 lines
Signed-off-by Alexander Holler<[email protected]>
---
   arch/arm/mach-omap2/board-omap3beagle.c |    3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 46d814a..ebe3a7e 100644
@@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
       usb_ehci_init(&ehci_pdata);
       omap3beagle_flash_init();
Quoted 9 lines
Quoted 9 lines
arch/arm/mach-omap2/board-omap3beagle.c +3 -0
+    /* Ensure msecure is mux'd to be able to set the RTC. */
+    omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
       /* Ensure SDRC pins are mux'd for self-refresh */
       omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
       omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 1 line
1.7.3.4

I've later switched to the following patch which muxes msecure as GPIO (the drm-mode isn't explained in the TRM) and also exports the GPIO, so root could easily switch it to prevent modifications on the RTC.

(Warning, either my clipboard or the version of Thunderbird I'm currently using replaces the tabs with spaces in the pasted patch and I'm currently too lazy to search a workaround).

---
  arch/arm/mach-omap2/board-omap3beagle.c |    6 ++++++
  1 files changed, 6 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 33007fd..24b4417 100644
@@ -673,6 +673,12 @@ static void __init omap3_beagle_init(void)
         usbhs_init(&usbhs_bdata);
         omap3beagle_flash_init();
Quoted 7 lines

arch/arm/mach-omap2/board-omap3beagle.c static void __init omap3_beagle_init(void) · line 679

Quoted 4 lines
arch/arm/mach-omap2/board-omap3beagle.c +4 -0
+       /* Ensure msecure is high to be able to set the RTC. */
+       omap_mux_init_signal("gpio_22", OMAP_PIN_OFF_OUTPUT_HIGH);
+       gpio_request(22, "msecure");
+       gpio_direction_output(22, true);

Can this be gpio_request_one() instead, please? Also, it will be nice to make a define for the magic 22.

Quoted 1 line

You need the "gpio_22" in the mux_init, so using a define would imho introduce a potential source for an error, at least when the define would not be anywhere near the "gpio_22" and someone would forget change the string too, when he changes the define. So I don't think a define adds much value there.

Why not leave "sys_drm_msecure" for mux_init, or does it make troubles on XM?

What about gpio_request_one()? To conform with the rest of the file and mach-omap2/*.

Signature · 2 lines
Regards,
Igor.
author
#8 lore raw

PATCH 1/1 arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Quoted 63 lines · Igor Grinberg
Quoted 61 lines · Alexander Holler

Am 07.06.2011 11:50, schrieb Igor Grinberg:

Quoted 59 lines · Alexander Holler
Quoted 48 lines

Am 31.05.2011 12:29, schrieb Tony Lindgren:

Quoted 23 lines · Alexander Holler
Quoted 4 lines

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Adding this into fixes.

Tony

Quoted 13 lines
Signed-off-by Alexander Holler<[email protected]>
---
   arch/arm/mach-omap2/board-omap3beagle.c |    3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 46d814a..ebe3a7e 100644
@@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
       usb_ehci_init(&ehci_pdata);
       omap3beagle_flash_init();
Quoted 9 lines
Quoted 9 lines
arch/arm/mach-omap2/board-omap3beagle.c +3 -0
+    /* Ensure msecure is mux'd to be able to set the RTC. */
+    omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
       /* Ensure SDRC pins are mux'd for self-refresh */
       omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
       omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 1 line
1.7.3.4

I've later switched to the following patch which muxes msecure as GPIO (the drm-mode isn't explained in the TRM) and also exports the GPIO, so root could easily switch it to prevent modifications on the RTC.

(Warning, either my clipboard or the version of Thunderbird I'm currently using replaces the tabs with spaces in the pasted patch and I'm currently too lazy to search a workaround).

---
  arch/arm/mach-omap2/board-omap3beagle.c |    6 ++++++
  1 files changed, 6 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 33007fd..24b4417 100644

arch/arm/mach-omap2/board-omap3beagle.c static void __init omap3_beagle_init(void) · line 679

Quoted 7 lines
arch/arm/mach-omap2/board-omap3beagle.c +4 -0
@@ -673,6 +673,12 @@ static void __init omap3_beagle_init(void)
         usbhs_init(&usbhs_bdata);
         omap3beagle_flash_init();
 
+       /* Ensure msecure is high to be able to set the RTC. */
+       omap_mux_init_signal("gpio_22", OMAP_PIN_OFF_OUTPUT_HIGH);
+       gpio_request(22, "msecure");
+       gpio_direction_output(22, true);

Can this be gpio_request_one() instead, please? Also, it will be nice to make a define for the magic 22.

Quoted 3 lines
Quoted 1 line

You need the "gpio_22" in the mux_init, so using a define would imho introduce a potential source for an error, at least when the define would not be anywhere near the "gpio_22" and someone would forget change the string too, when he changes the define. So I don't think a define adds much value there.

Why not leave "sys_drm_msecure" for mux_init, or does it make troubles on XM?

There is nothing wrong with the small patch which uses sys_drm_msecure. It's short and does everything which is needed to use the RTC. I've posted the solution with the use of the GPIO-mode only as an alternative because the drm-mode isn't explained in the TRM (I assume one has to sign a NDA to get more informations on that).
So it is not obvious what my first patch does. Using sys_drm_msecure works because it seems to be always off, at least on the BeagleBoards. The additional functionality in my second patch to turn off possible modifications on the RTC through switching the GPIO is most likely just an educational feature, I don't think someone will ever use that. I don't have any preferences which solution will end in the kernel, I just wanted to offer the second one too.

Quoted 1 line

What about gpio_request_one()? To conform with the rest of the file and mach-omap2/*.

Below is an updated version. The gpio_export() might be removed too.

Regards,

Alexander

From: Alexander Holler <[email protected]>
Date: Thu, 19 May 2011 11:42:05 +0200
Subject: [PATCH v3] arm: omap3: beagle: Ensure msecure is mux'd and high to be able to set the RTC

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Signed-off-by Alexander Holler <[email protected]>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
(quoted diff) +0 -0

b/arch/arm/mach-omap2/board-omap3beagle.c
index 33007fd..4c9e26e 100644

arch/arm/mach-omap2/board-omap3beagle.c +5 -0
@@ -673,6 +673,11 @@ static void __init omap3_beagle_init(void)
 	usbhs_init(&usbhs_bdata);
 	omap3beagle_flash_init();
 
+	/* Ensure msecure is high to be able to set the RTC. */
+	omap_mux_init_signal("gpio_22", OMAP_PIN_OFF_OUTPUT_HIGH);
+	gpio_request_one(22, GPIOF_OUT_INIT_HIGH, "msecure");
+	gpio_export(22, false);
+
 	/* Ensure SDRC pins are mux'd for self-refresh */
 	omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
 	omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 1 line
1.7.3.4
#9 lore raw

PATCH 1/1 arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Quoted 61 lines · Alexander Holler
Quoted 52 lines · Igor Grinberg
Quoted 51 lines · Alexander Holler

Am 07.06.2011 11:50, schrieb Igor Grinberg:

Quoted 50 lines · Alexander Holler
Quoted 49 lines

Am 31.05.2011 12:29, schrieb Tony Lindgren:

Quoted 22 lines · Alexander Holler
Quoted 4 lines

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Adding this into fixes.

Tony

Quoted 13 lines
Signed-off-by Alexander Holler<[email protected]>
---
   arch/arm/mach-omap2/board-omap3beagle.c |    3 +++
   1 files changed, 3 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 46d814a..ebe3a7e 100644
@@ -628,6 +628,9 @@ static void __init omap3_beagle_init(void)
       usb_ehci_init(&ehci_pdata);
       omap3beagle_flash_init();
Quoted 9 lines
Quoted 9 lines
arch/arm/mach-omap2/board-omap3beagle.c +3 -0
+    /* Ensure msecure is mux'd to be able to set the RTC. */
+    omap_mux_init_signal("sys_drm_msecure", OMAP_PIN_OFF_OUTPUT_HIGH);
+
       /* Ensure SDRC pins are mux'd for self-refresh */
       omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
       omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 1 line
1.7.3.4

I've later switched to the following patch which muxes msecure as GPIO (the drm-mode isn't explained in the TRM) and also exports the GPIO, so root could easily switch it to prevent modifications on the RTC.

(Warning, either my clipboard or the version of Thunderbird I'm currently using replaces the tabs with spaces in the pasted patch and I'm currently too lazy to search a workaround).

---
  arch/arm/mach-omap2/board-omap3beagle.c |    6 ++++++
  1 files changed, 6 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +0 -0
index 33007fd..24b4417 100644
@@ -673,6 +673,12 @@ static void __init omap3_beagle_init(void)
         usbhs_init(&usbhs_bdata);
         omap3beagle_flash_init();
Quoted 8 lines
Quoted 7 lines
Quoted 6 lines

arch/arm/mach-omap2/board-omap3beagle.c static void __init omap3_beagle_init(void)

Quoted 4 lines
arch/arm/mach-omap2/board-omap3beagle.c +4 -0
+       /* Ensure msecure is high to be able to set the RTC. */
+       omap_mux_init_signal("gpio_22", OMAP_PIN_OFF_OUTPUT_HIGH);
+       gpio_request(22, "msecure");
+       gpio_direction_output(22, true);

Can this be gpio_request_one() instead, please? Also, it will be nice to make a define for the magic 22.

You need the "gpio_22" in the mux_init, so using a define would imho introduce a potential source for an error, at least when the define would not be anywhere near the "gpio_22" and someone would forget change the string too, when he changes the define. So I don't think a define adds much value there.

Why not leave "sys_drm_msecure" for mux_init, or does it make troubles on XM?

Quoted 12 lines

There is nothing wrong with the small patch which uses sys_drm_msecure. It's short and does everything which is needed to use the RTC. I've posted the solution with the use of the GPIO-mode only as an alternative because the drm-mode isn't explained in the TRM (I assume one has to sign a NDA to get more informations on that).
So it is not obvious what my first patch does. Using sys_drm_msecure works because it seems to be always off, at least on the BeagleBoards. The additional functionality in my second patch to turn off possible modifications on the RTC through switching the GPIO is most likely just an educational feature, I don't think someone will ever use that. I don't have any preferences which solution will end in the kernel, I just wanted to offer the second one too.

I see. Is the new patch version somehow provides better functionality? You configure the gpio for output, this means that the pin is actually driven and not just relies on internal pullup (which can vary from chip to chip). I know nothing about that msecure stuff, but may be it is better to drive the pin, then just configuring the mux (enabling internal pullup)...

Quoted 2 lines
Quoted 1 line

What about gpio_request_one()? To conform with the rest of the file and mach-omap2/*.

Below is an updated version. The gpio_export() might be removed too.

The original patch version is already in Linus' tree, so this one will not apply as it is. If you decide it is better then the original one, then it must be rebased. Otherwise, looks OK.

Quoted 37 lines

Regards,

Alexander

From: Alexander Holler <[email protected]>
Date: Thu, 19 May 2011 11:42:05 +0200
Subject: [PATCH v3] arm: omap3: beagle: Ensure msecure is mux'd and high to be able to set the RTC

Without msecure beeing high it isn't possible to set (or start) the RTC.

Tested with a BeagleBoard C4.

Signed-off-by Alexander Holler <[email protected]>
---
 arch/arm/mach-omap2/board-omap3beagle.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)
arch/arm/mach-omap2/board-omap3beagle.c +5 -0
index 33007fd..4c9e26e 100644
@@ -673,6 +673,11 @@ static void __init omap3_beagle_init(void)
 	usbhs_init(&usbhs_bdata);
 	omap3beagle_flash_init();
 
+	/* Ensure msecure is high to be able to set the RTC. */
+	omap_mux_init_signal("gpio_22", OMAP_PIN_OFF_OUTPUT_HIGH);
+	gpio_request_one(22, GPIOF_OUT_INIT_HIGH, "msecure");
+	gpio_export(22, false);
+
 	/* Ensure SDRC pins are mux'd for self-refresh */
 	omap_mux_init_signal("sdrc_cke0", OMAP_PIN_OUTPUT);
 	omap_mux_init_signal("sdrc_cke1", OMAP_PIN_OUTPUT);
Signature · 2 lines
Regards,
Igor.
author
#10 lore raw

PATCH 1/1 arm: omap3: beagle: Ensure msecure is mux'd to be able to set the RTC

Hello,

Am 09.06.2011 09:40, schrieb Igor Grinberg:

Quoted 7 lines · Alexander Holler

I see. Is the new patch version somehow provides better functionality? You configure the gpio for output, this means that the pin is actually driven and not just relies on internal pullup (which can vary from chip to chip). I know nothing about that msecure stuff, but may be it is better to drive the pin, then just configuring the mux (enabling internal pullup)...

Just using the internal pullup was enough with my BeagleBoard C4.

Quoted 5 lines
Quoted 1 line

Below is an updated version. The gpio_export() might be removed too.

The original patch version is already in Linus' tree, so this one will not apply as it is. If you decide it is better then the original one, then it must be rebased. Otherwise, looks OK.

I'm fine with either version, so no new patch is necessary. ;)

Regards,

Alexander

maintainer
#11 lore raw
In reply to Alexander Holler
Quoted 37 lines · Alexander Holler

Hello,

Am 04.04.2011 16:29, schrieb Alexander Holler:

Quoted 23 lines

it just happened here that the rechargeable backup battery for the RTC on a TPS65950 run out off power, because of some days while the device wasn't powered.

Afterwards I couldn't read or set the clock with hwclock using a kernel 2.6.37.n or 2.6.38.n.

I don't have a fix, but I think I've analyzed the problem and can offer a (bad) workaround.

What happens is the following:

When trying to read or set the clock with hwclock, the driver (rtc-twl) starts an alarm, but the irq for the alarm will never get called. The result is that a select in hwclock times out (for both operations, read or set).

Because I had this clock running before, I've got the idea to try one of those old OMAP-kernels (2.6.32-angstrom) using the same userland. And with that kernel I could set the clock.
Using 2.6.37 or 2.6.38 afterwards, hwclock did function again, both read an set are working.

Quoted 5 lines

So it looks like there is a catch22 in kernels >=2.6.37 (I haven't tested .33-.36):

When the clock was never set, the alarm(-irq) doesn't work, so hwclock doesn't work, so one can't set the clock.

It turns out that the missing/wrong initialization of the msecure line is the problem which disabled setting the clock. After doing that through a quick hack, I could set the clock.

Quoted 6 lines

I'm using a BeagleBoard C4, but I can't find any msecure initialization for other boards too.

What happened with those patches? E.g. those:

http://www.mail-archive.com/[email protected]/msg16125.html

Looks like these need reposting. Maybe worth doing generic omap RTC init code though?

Tony