Re: [patch 2.6.17-rc4-omap-git] rtc-omap, rtc framework driver

[David Brownell <david-b@pacbell.net>]

On Tuesday 15 August 2006 10:25 am, Johnson, Steve-OMAP wrote:
> Hi Dave,
> 
> For OMAP2 and OMAP3, the RTC is in the Power Management companion chip
> (TWL92230 and TWL4030).
> 
> Where do you see an RTC on the web site for OMAP2420?  The only picture
> I see shows the RTC in the companion chip.

From www.omap.com, click the left hand option then the JavaScript omap2420
link to reach what I suspect is the same page you list (despite linewrap
manglage) and includes this graphic:

http://focus.ti.com/graphics/wtbu/blockdiagrams/l4_omap2420.gif

which is a GIF that shows an RTC on the omap2420 chip, in the block
labeled "Timers, Interrupt Controllers, RTC".  The product overview
link on that page gives a PDF document which agrees.  (Agreed that the
2420 gif shows another RTC, on the PM chip ... but not for 2430/3430.)

- Dave


> 
> http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=
> 6123&navigationId=11990&contentId=4671
> 
> Regards,
> 
> Steve
>  
> 
> > -----Original Message-----
> > From: linux-omap-open-source-bounces@linux.omap.com 
> > [mailto:linux-omap-open-source-bounces@linux.omap.com] On 
> > Behalf Of David Brownell
> > Sent: Tuesday, August 15, 2006 12:04 PM
> > To: linux-omap-open-source@linux.omap.com
> > Subject: [patch 2.6.17-rc4-omap-git] rtc-omap, rtc framework driver
> > 
> > Cleaning out my patch queue ... here's an "rtc class" driver. 
> >  Much more suitable for upstream merging than the previous 
> > version, even though that code has gotten much cleaner over time.
> > 
> > Could someone confirm that this RTC can't actually do system 
> > wakeups without external hardware support?  My documentation 
> > isn't at all clear on that issue.  There's certainly an 
> > external wakeup signal available, but text also says that the 
> > alarm irq should work the normal way ... but I don't see that 
> > happening.  It could easily be just a bug in 
> > enable_irq_wakeup(INT_RTC_ALARM) handling, which ISTR looked 
> > like a big NOP last I checked (for almost all IRQs).
> > 
> > Also, someone with an OMAP2 setup should confirm that the 
> > Kconfig is right, and this particular controller isn't 
> > provided on OMAP2.  That certainly matches the lack of RTC in 
> > the .../mach-omap2 directory, but the TI website says 2420 
> > (but not {2,3}430) has an RTC.  Maybe the OMAP 2420 support 
> > is just missing, and it's really the same RTC...
> > 
> > - Dave
> > 
> > 
> > This creates a new RTC-framework driver for the RTC/calendar 
> > module found in various OMAP chips, giving a more 
> > correct/standard replacement for the older 
> > drivers/char/omap-rtc.c driver.  Differences include:
> > 
> >  - much smaller/simpler, because it reuses shared infrastructure
> >  - the RTC name will normally be "rtc0" not "rtc"
> >  - the /dev node has a different major and minor numbers
> >  - RTC_ALM_SET handled as on PCs (alarm within 24 hours)
> >  - RTC_WKALM_SET handled as on PCs (alarm within this century)
> >  - epoch not changeable (why bother)
> >  - rtc alarm may optionally be a system wakeup event (board-specific)
> >  
> > If you use udev and statically link this, some init script 
> > can just create a symbolic link (rtc -> rtc0) so tools like 
> > "hwclock" will work as usual.
> > Or, updates to hwclock (and busybox) are available which 
> > teach it to use the /dev/rtc0 path as a backup, and to 
> > support "hwclock --file=/dev/rtc0". 
> > 
> > Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
> > 
> > ----
> > Presumably an upstream merge should remove the devices.c 
> > support for the older non-framework driver.
> > 
> >  arch/arm/mach-omap1/devices.c |    2 
> >  drivers/rtc/Kconfig           |    8 
> >  drivers/rtc/Makefile          |    1 
> >  drivers/rtc/rtc-omap.c        |  573 
> > ++++++++++++++++++++++++++++++++++++++++++
> >  4 files changed, 583 insertions(+), 1 deletion(-)
> > 
> > ... deletia ...