[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Sanjeev Premi]

The current selection of the GPTIMER on was result of
a hardware issue in early versions of the Beagleboards
(Ax and B1 thru B4). [1] [2]

Its been long since the hardware issue has been fixed.
This patch uses GPTIMER 1 for all newer board revisions
incl. Beagleboard XM.

 [1] http://thread.gmane.org/gmane.comp.hardware.beagleboard.general/91
 [2] Errata #7 at http://elinux.org/BeagleBoard#Errata

Signed-off-by: Sanjeev Premi <premi@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
---

  * The patch has been boot tested with Beagleboard-XM.
    Verified that GPTIMER1 is indeed being used.

  * Browsing through the code, it appears that similar
    change could be applied for these boards:
     - devkit8000
     - omap3stalker
     - omap3touchbook
    However, I don't have access to any of these;
    or information on their revisions.
    I can update this patch based on confirmations.

 arch/arm/mach-omap2/board-omap3beagle.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 4b113b2..edc1596 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -509,7 +509,10 @@ static void __init omap3_beagle_init_irq(void)
 {
 	omap_init_irq();
 #ifdef CONFIG_OMAP_32K_TIMER
-	omap2_gp_clockevent_set_gptimer(12);
+	if (omap3_beagle_version == OMAP3BEAGLE_BOARD_AXBX)
+		omap2_gp_clockevent_set_gptimer(12);
+	else
+		omap2_gp_clockevent_set_gptimer(1);
 #endif
 }
 
-- 
1.7.2.2

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Premi, Sanjeev]

> -----Original Message-----
> From: Premi, Sanjeev 
> Sent: Friday, June 24, 2011 9:54 PM
> To: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Cc: Premi, Sanjeev; Paul Walmsley
> Subject: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[sp] I do notice a typo in subject.
     Will fix in next rev with any other comments - if any.

> 
> The current selection of the GPTIMER on was result of
> a hardware issue in early versions of the Beagleboards
> (Ax and B1 thru B4). [1] [2]
> 
> Its been long since the hardware issue has been fixed.
> This patch uses GPTIMER 1 for all newer board revisions
> incl. Beagleboard XM.
> 
>  [1] 
> http://thread.gmane.org/gmane.comp.hardware.beagleboard.general/91
>  [2] Errata #7 at http://elinux.org/BeagleBoard#Errata
> 
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>

Few lines from top of boot log on Beagleboard XM:

[    0.000000] Linux version 3.0.0-rc3-14001-gba7aaf5-dirty (premi at mylinux) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #18 SMP Fri Jun 24 20:40:30 IST 2011
[    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
[    0.000000] Machine: OMAP3 Beagle Board
[    0.000000] Reserving 12582912 bytes SDRAM for VRAM
[    0.000000] Memory policy: ECC disabled, Data cache writeback
[    0.000000] OMAP3630 ES1.2 (l2cache iva sgx neon isp 192mhz_clk )
[    0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x10000
[    0.000000] Clocking rate (Crystal/Core/MPU): 26.0/400/600 MHz
[    0.000000] Reprogramming SDRC clock to 400000000 Hz
[    0.000000] dpll3_m2_clk rate change failed: -22
[    0.000000] PERCPU: Embedded 7 pages/cpu @c0bdd000 s5504 r8192 d14976 u32768
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 61952
[    0.000000] Kernel command line: console=ttyO2,115200n8 vram=12M omapfb.mode=dvi:1024x768MR-16 at 60 omapdss.def_disp=dvi root=/dev/ram0 rw initrd=0x81600000,24M earlyprintk=serial,ttyO0,115200
[    0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
[    0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[    0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[    0.000000] Memory: 244MB = 244MB total
[    0.000000] Memory: 212904k/212904k available, 49240k reserved, 0K highmem
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
[    0.000000]     DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
[    0.000000]     vmalloc : 0xd0800000 - 0xf8000000   ( 632 MB)
[    0.000000]     lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
[    0.000000]     modules : 0xbf000000 - 0xc0000000   (  16 MB)
[    0.000000]       .init : 0xc0008000 - 0xc003e000   ( 216 kB)
[    0.000000]       .text : 0xc003e000 - 0xc04330f0   (4053 kB)
[    0.000000]       .data : 0xc0434000 - 0xc048aaf0   ( 347 kB)
[    0.000000] Hierarchical RCU 00000 (revision 4.0) with 96 interrupts
[    0.000000] Total of 96 interrupts on 1 active controller
[    0.000000] OMAP clockevent source: GPTIMER1 at 32768 Hz
[    0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
[    0.000000] Console: colour dummy device 80x30
[    0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[    0.000000] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.000000] ... MAX_LOCK_DEPTH:          48
[    0.000000] ... MAX_LOCKDEP_KEYS:        8191
[    0.000000] ... CLASSHASH_SIZE:          4096
[    0.000000] ... MAX_LOCKDEP_ENTRIES:     16384
[    0.000000] ... MAX_LOCKDEP_CHAINS:      32768
[    0.000000] ... CHAINHASH_SIZE:          16384
[    0.000000]  memory used by lock dependency info: 3695 kB
[    0.000000]  per task-struct memory footprint: 1152 bytes
[    0.000823] Calibrating delay loop... 597.64 BogoMIPS (lpj=2334720)
[    0.093780] pid_max: default: 32768 minimum: 301
[    0.094329] Security Framework initialized
[    0.094635] Mount-cache hash table entries: 512
[    0.098175] CPU: Testing write buffer coherency: ok
[    0.101074] Brought up 1 CPUs
[    0.101104] SMP: Total of 1 processors activated (597.64 BogoMIPS).

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Koen Kooi]

Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende geschreven:

> The current selection of the GPTIMER on was result of
> a hardware issue in early versions of the Beagleboards
> (Ax and B1 thru B4). [1] [2]
> 
> Its been long since the hardware issue has been fixed.
> This patch uses GPTIMER 1 for all newer board revisions
> incl. Beagleboard XM.

What's the reason for switching away from gptimer12? Nothing in your patch or changelog says why.

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org 
> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Koen Kooi
> Sent: Saturday, June 25, 2011 1:47 PM
> To: linux-omap at vger.kernel.org List
> Cc: linux-arm-kernel; Paul Walmsley
> Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
> 
> 
> Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende geschreven:
> 
> > The current selection of the GPTIMER on was result of
> > a hardware issue in early versions of the Beagleboards
> > (Ax and B1 thru B4). [1] [2]
> > 
> > Its been long since the hardware issue has been fixed.
> > This patch uses GPTIMER 1 for all newer board revisions
> > incl. Beagleboard XM.

[sp] I didn't include a reason - because the problem may not
     be reproducible on the public trees.

     During tests performed in internal development trees, the
     BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
     range. While there was no such inconsistency on OMAP3EVM.

     After few days of debug GPTIMER12 came to be only difference.
     Tracing GPTIMER12 in the spec proved quite a challenge; the
     as timer is not included in the TRM and corresponding interrupt
     is marked reserved. Paul (in cc:) obviously had access to
     documents that we don't.

     This patch is merely trying to bring parity in use of GPTIMER
     across OMAP3 boards (AND use documented IP) - taking note of
     many Beagleboards where current code is necessary.

~sanjeev

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Koen Kooi]

Op 25 jun 2011, om 20:51 heeft Premi, Sanjeev het volgende geschreven:

>> -----Original Message-----
>> From: linux-omap-owner at vger.kernel.org 
>> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Koen Kooi
>> Sent: Saturday, June 25, 2011 1:47 PM
>> To: linux-omap at vger.kernel.org List
>> Cc: linux-arm-kernel; Paul Walmsley
>> Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
>> 
>> 
>> Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende geschreven:
>> 
>>> The current selection of the GPTIMER on was result of
>>> a hardware issue in early versions of the Beagleboards
>>> (Ax and B1 thru B4). [1] [2]
>>> 
>>> Its been long since the hardware issue has been fixed.
>>> This patch uses GPTIMER 1 for all newer board revisions
>>> incl. Beagleboard XM.
> 
> [sp] I didn't include a reason - because the problem may not
>     be reproducible on the public trees.
> 
>     During tests performed in internal development trees, the
>     BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
>     range. While there was no such inconsistency on OMAP3EVM.
> 
>     After few days of debug GPTIMER12 came to be only difference.
>     Tracing GPTIMER12 in the spec proved quite a challenge; the
>     as timer is not included in the TRM and corresponding interrupt
>     is marked reserved. Paul (in cc:) obviously had access to
>     documents that we don't.
> 
>     This patch is merely trying to bring parity in use of GPTIMER
>     across OMAP3 boards (AND use documented IP) - taking note of
>     many Beagleboards where current code is necessary.

I get a value of 1010 ?10 bogoMIPS consistently with .39 + dvfs patches. Having said that, this patch does seem to be an improvement, but has it actually been tested on real beagleboard hardware with a recent kernel? Especially on the boards affected by the capacitor issue on the external clock.

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Premi, Sanjeev]

> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org 
> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Koen Kooi
> Sent: Sunday, June 26, 2011 1:41 AM
> To: linux-omap at vger.kernel.org List
> Cc: linux-arm-kernel; Paul Walmsley
> Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
> 
> 
> Op 25 jun 2011, om 20:51 heeft Premi, Sanjeev het volgende geschreven:
> 
> >> -----Original Message-----
> >> From: linux-omap-owner at vger.kernel.org 
> >> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Koen Kooi
> >> Sent: Saturday, June 25, 2011 1:47 PM
> >> To: linux-omap at vger.kernel.org List
> >> Cc: linux-arm-kernel; Paul Walmsley
> >> Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
> >> 
> >> 
> >> Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende 
> geschreven:
> >> 
> >>> The current selection of the GPTIMER on was result of
> >>> a hardware issue in early versions of the Beagleboards
> >>> (Ax and B1 thru B4). [1] [2]
> >>> 
> >>> Its been long since the hardware issue has been fixed.
> >>> This patch uses GPTIMER 1 for all newer board revisions
> >>> incl. Beagleboard XM.
> > 
> > [sp] I didn't include a reason - because the problem may not
> >     be reproducible on the public trees.
> > 
> >     During tests performed in internal development trees, the
> >     BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
> >     range. While there was no such inconsistency on OMAP3EVM.
> > 
> >     After few days of debug GPTIMER12 came to be only difference.
> >     Tracing GPTIMER12 in the spec proved quite a challenge; the
> >     as timer is not included in the TRM and corresponding interrupt
> >     is marked reserved. Paul (in cc:) obviously had access to
> >     documents that we don't.
> > 
> >     This patch is merely trying to bring parity in use of GPTIMER
> >     across OMAP3 boards (AND use documented IP) - taking note of
> >     many Beagleboards where current code is necessary.
> 
> I get a value of 1010 ?10 bogoMIPS consistently with .39 + 
> dvfs patches. Having said that, this patch does seem to be an 
> improvement, but has it actually been tested on real 
> beagleboard hardware with a recent kernel?

[sp] It was tested on BeagleXM RevB on top of linux-omap master - as
     on day of submitting th patch.

> Especially on the 
> boards affected by the capacitor issue on the external clock.--

[sp] The patch relies on the check for board revision to continue using
     GPTIMER12 on affected boards - which I am assuming to be right.

     I don't have access to any of these versions, trying to find some
     early users. Hope someone on the list with Ax/Bx version can share
     the result...

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

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Jonathan Cameron]

On 06/25/11 21:10, Koen Kooi wrote:
> 
> Op 25 jun 2011, om 20:51 heeft Premi, Sanjeev het volgende geschreven:
> 
>>> -----Original Message-----
>>> From: linux-omap-owner at vger.kernel.org 
>>> [mailto:linux-omap-owner at vger.kernel.org] On Behalf Of Koen Kooi
>>> Sent: Saturday, June 25, 2011 1:47 PM
>>> To: linux-omap at vger.kernel.org List
>>> Cc: linux-arm-kernel; Paul Walmsley
>>> Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
>>>
>>>
>>> Op 24 jun 2011, om 18:23 heeft Sanjeev Premi het volgende geschreven:
>>>
>>>> The current selection of the GPTIMER on was result of
>>>> a hardware issue in early versions of the Beagleboards
>>>> (Ax and B1 thru B4). [1] [2]
>>>>
>>>> Its been long since the hardware issue has been fixed.
>>>> This patch uses GPTIMER 1 for all newer board revisions
>>>> incl. Beagleboard XM.
>>
>> [sp] I didn't include a reason - because the problem may not
>>     be reproducible on the public trees.
>>
>>     During tests performed in internal development trees, the
>>     BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
>>     range. While there was no such inconsistency on OMAP3EVM.
>>
>>     After few days of debug GPTIMER12 came to be only difference.
>>     Tracing GPTIMER12 in the spec proved quite a challenge; the
>>     as timer is not included in the TRM and corresponding interrupt
>>     is marked reserved. Paul (in cc:) obviously had access to
>>     documents that we don't.
>>
>>     This patch is merely trying to bring parity in use of GPTIMER
>>     across OMAP3 boards (AND use documented IP) - taking note of
>>     many Beagleboards where current code is necessary.
> 

> I get a value of 1010 ?10 bogoMIPS consistently with .39 + dvfs
> patches. Having said that, this patch does seem to be an improvement,
> but has it actually been tested on real beagleboard hardware with a
> recent kernel? Especially on the boards affected by the capacitor
> issue on the external clock.--
Hi Koen,

Probably obvious to anyone else here, but which dvfs patches?

I've only recently acquired an xm and hence wasn't following these threads.
Don't suppose you could point me to a tree with them in or the relevant
thread?

Cheers,

Jonathan

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Paul Walmsley]

On Sun, 26 Jun 2011, Premi, Sanjeev wrote:

> [sp] I didn't include a reason - because the problem may not
>      be reproducible on the public trees.
> 
>      During tests performed in internal development trees, the
>      BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
>      range. While there was no such inconsistency on OMAP3EVM.

There are some other reasons to avoid GPTIMER12 when possible, which you 
should probably put in the patch description.  The most important, in my 
view, is that the clock source for GPTIMER12 is much less frequency-stable 
than the clock sources for GPTIMER1.  So using GPTIMER12 can result in 
major time skew over a fairly short interval.

I've been meaning to send a patch like this for some time, so I'm happy to 
see this fixed.


- Paul

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Premi, Sanjeev]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com] 
> Sent: Sunday, June 26, 2011 4:17 AM
> To: Koen Kooi; Premi, Sanjeev
> Cc: linux-omap at vger.kernel.org List; linux-arm-kernel
> Subject: RE: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
> 
> On Sun, 26 Jun 2011, Premi, Sanjeev wrote:
> 
> > [sp] I didn't include a reason - because the problem may not
> >      be reproducible on the public trees.
> > 
> >      During tests performed in internal development trees, the
> >      BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
> >      range. While there was no such inconsistency on OMAP3EVM.
> 
> There are some other reasons to avoid GPTIMER12 when 
> possible, which you 
> should probably put in the patch description.  The most 
> important, in my 
> view, is that the clock source for GPTIMER12 is much less 
> frequency-stable 
> than the clock sources for GPTIMER1.  So using GPTIMER12 can 
> result in 
> major time skew over a fairly short interval.

[sp] Thanks for details. I will include in next rev.

> 
> I've been meaning to send a patch like this for some time, so 
> I'm happy to 
> see this fixed.
> 
> 
> - Paul
> 

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [110625 15:42]:
> On Sun, 26 Jun 2011, Premi, Sanjeev wrote:
> 
> > [sp] I didn't include a reason - because the problem may not
> >      be reproducible on the public trees.
> > 
> >      During tests performed in internal development trees, the
> >      BogoMIPS calculations @ 1GHz wouldn't go beyond "830-850"
> >      range. While there was no such inconsistency on OMAP3EVM.
> 
> There are some other reasons to avoid GPTIMER12 when possible, which you 
> should probably put in the patch description.  The most important, in my 
> view, is that the clock source for GPTIMER12 is much less frequency-stable 
> than the clock sources for GPTIMER1.  So using GPTIMER12 can result in 
> major time skew over a fairly short interval.
> 
> I've been meaning to send a patch like this for some time, so I'm happy to 
> see this fixed.

This fix will cause bad dependency issues with sys_timer.

This patch has a dependency to omap3_beagle_init_rev, which depends on
the mux framework and gpio framework. Not cool for init_early. We just
want to initialize sys_timer early without any complicated dependencies.

The best way to fix this is to set a separate machine ID for the properly
working beagle boards like xm, then just set the .timer entry to omap3_timer
for working beagle boards and omap3_secure_timer for non-working beagle
boards. The rest of the board-*.c file can be shared.

The above assumes the patches in devel-timer branch where we no longer
have the non-standard timer interface, but use the sys_timer entries
instead like we should.

Regards,

Tony

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Paul Walmsley]

On Mon, 27 Jun 2011, Tony Lindgren wrote:

> This fix will cause bad dependency issues with sys_timer.
> 
> This patch has a dependency to omap3_beagle_init_rev, which depends on
> the mux framework and gpio framework. Not cool for init_early. We just
> want to initialize sys_timer early without any complicated dependencies.
> 
> The best way to fix this is to set a separate machine ID for the properly
> working beagle boards like xm, then just set the .timer entry to omap3_timer
> for working beagle boards and omap3_secure_timer for non-working beagle
> boards. The rest of the board-*.c file can be shared.

Sanjeev, want to take care of this?  Machine ID update info is in 
linux/arch/arm/tools/mach-types.  

This strategy will unfortunately involve patching bootloaders.  But if the 
default is to use GPT12, it should work out okay.

Hopefully we won't have to do the same thing for the other Beagle-derived 
boards, Devkit8000, Touchbook, etc. etc.  Then again, I suppose this will 
eventually just be another property passed in via DT, with a single 
machine ID.

> The above assumes the patches in devel-timer branch where we no longer
> have the non-standard timer interface, but use the sys_timer entries
> instead like we should.


- Paul

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Premi, Sanjeev]

> -----Original Message-----
> From: Paul Walmsley [mailto:paul at pwsan.com] 
> Sent: Monday, June 27, 2011 9:00 PM
> To: Premi, Sanjeev; Tony Lindgren
> Cc: Koen Kooi; linux-omap at vger.kernel.org List; linux-arm-kernel
> Subject: Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents
> 
> On Mon, 27 Jun 2011, Tony Lindgren wrote:
> 
> > This fix will cause bad dependency issues with sys_timer.
> > 
> > This patch has a dependency to omap3_beagle_init_rev, which 
> depends on
> > the mux framework and gpio framework. Not cool for 
> init_early. We just
> > want to initialize sys_timer early without any complicated 
> dependencies.
> > 
> > The best way to fix this is to set a separate machine ID 
> for the properly
> > working beagle boards like xm, then just set the .timer 
> entry to omap3_timer
> > for working beagle boards and omap3_secure_timer for 
> non-working beagle
> > boards. The rest of the board-*.c file can be shared.
> 
> Sanjeev, want to take care of this?  Machine ID update info is in 
> linux/arch/arm/tools/mach-types.  
> 
> This strategy will unfortunately involve patching 
> bootloaders.  But if the 
> default is to use GPT12, it should work out okay.

[sp] Just sent another query to Tony on this specific issue.
     But, if different mach-type is the way forward, then
     I will take it forward.

> 
> Hopefully we won't have to do the same thing for the other 
> Beagle-derived 
> boards, Devkit8000, Touchbook, etc. etc.  Then again, I 
> suppose this will 
> eventually just be another property passed in via DT, with a single 
> machine ID.

[sp] Can you look at my query to Tony? Will that be an acceptable
     workaround until DT. Going to two machine IDs and then unifying
     back again could cause confusion - esp. during transition times.

~sanjeev

> 
> > The above assumes the patches in devel-timer branch where 
> we no longer
> > have the non-standard timer interface, but use the sys_timer entries
> > instead like we should.
> 
> 
> - Paul
> 

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Paul Walmsley]

On Mon, 27 Jun 2011, Premi, Sanjeev wrote:

> [sp] Can you look at my query to Tony? Will that be an acceptable
>      workaround until DT. Going to two machine IDs and then unifying
>      back again could cause confusion - esp. during transition times.

It's up to Tony, he's the maintainer...


- Paul

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Tony Lindgren]

* Paul Walmsley <paul@pwsan.com> [110627 09:50]:
> On Mon, 27 Jun 2011, Premi, Sanjeev wrote:
> 
> > [sp] Can you look at my query to Tony? Will that be an acceptable
> >      workaround until DT. Going to two machine IDs and then unifying
> >      back again could cause confusion - esp. during transition times.
> 
> It's up to Tony, he's the maintainer...

For the record, replied something to the other thread about system_rev
and cmdline options.

Tony

[PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

[Paul Walmsley]

On Fri, 24 Jun 2011, Sanjeev Premi wrote:

> The current selection of the GPTIMER on was result of
> a hardware issue in early versions of the Beagleboards
> (Ax and B1 thru B4). [1] [2]
> 
> Its been long since the hardware issue has been fixed.
> This patch uses GPTIMER 1 for all newer board revisions
> incl. Beagleboard XM.
> 
>  [1] http://thread.gmane.org/gmane.comp.hardware.beagleboard.general/91
>  [2] Errata #7 at http://elinux.org/BeagleBoard#Errata
> 
> Signed-off-by: Sanjeev Premi <premi@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>

Reviewed-by: Paul Walmsley <paul@pwsan.com>

>   * Browsing through the code, it appears that similar
>     change could be applied for these boards:
>      - devkit8000
>      - omap3stalker
>      - omap3touchbook
>     However, I don't have access to any of these;
>     or information on their revisions.
>     I can update this patch based on confirmations.

You might want to send an E-mail to the people who are listed as authors 
in git for these boards.  Otherwise they will probably miss it in the 
onslaught of mailing list traffic.  Unless the PCB designs are based on 
A or B revisions of the BeagleBoard, it should be safe for them to switch 
to GPTIMER1.


- Paul