All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Nicolas BLANCHARD" <n.blanchard@domain.hid>
To: xenomai-help, xenomai@xenomai.org,
Subject: [Xenomai-help] [RTDM] IRQ lock problem ?
Date: Thu, 19 Apr 2007 11:49:06 +0200	[thread overview]
Message-ID: <s62756bc.018@domain.hid> (raw)

[-- Attachment #1: Type: text/plain, Size: 2546 bytes --]

Hi,
 
I've write an rtdm driver and i have a problem.
I use ioctl (rt_dev_ioctl) to read and write data (RTC time) on cmos. 
(I know it could better to use _rt_dev_read or rt_dev_write 
 but it was my first rtdm driver, and i' think that it's not the cause
of my problem).
 
My user application (Native xenomai task) use this rt_dev_ioctl each
100 ms to read data on cmos.
But, sometime (each 3 or 4 days), i read bad values.
 
this is the code to read the cmos (call in an rt_dev_ioctl) : 
 
//---------------------------------------------------------------------------------------------
static unsigned char get_cmos_time(struct rtc146818drv_context *ctx,
           struct rtc_time *rtc_tm)
{
 unsigned char uip;
 rtdm_lockctx_t  lock_ctx;
 
 rtdm_lock_get_irqsave(&ctx->lock, lock_ctx); 
 
 uip = (CMOS_READ(RTC_FREQ_SELECT) & RTC_UIP);
 
 if(uip == 0)
 {
      rtc_tm->tm_year = CMOS_READ(RTC_YEAR);
      rtc_tm->tm_mon = CMOS_READ(RTC_MONTH);
      rtc_tm->tm_mday = CMOS_READ(RTC_DAY_OF_MONTH);
      rtc_tm->tm_hour = CMOS_READ(RTC_HOURS);
      rtc_tm->tm_min = CMOS_READ(RTC_MINUTES);
      rtc_tm->tm_sec = CMOS_READ(RTC_SECONDS);
      rtc_tm->tm_wday = CMOS_READ(RTC_DAY_OF_WEEK);
}
rtc_tm->tm_yday = 0;
rtc_tm->tm_isdst = 0;

rtdm_lock_put_irqrestore(&ctx->lock, lock_ctx); 
 
return uip;
}
//---------------------------------------------------------------------------------------------
 
Data are read on MC146818A chipset, documentaton of this chipset
explain that an update cycle is execute
once per second and during this update  RTC_values or not fully
available.
So, we test the uip,when uip==0 the update cycle is not in progress and
will not be for at least 244 us (for all time bases).
 
So to be sure that in thoses 244 us i've time to execute my code, i've
disable the premption with rtdm_lock_get_irqsave.
But sometime, like if the update cycle begin in the midle of my code, i
read bad value (value 165 exactly).
 
For example i read this bad time : 
"19/04/07 11:165:165 day 165" (like if i've been prempt after
CMOS_READ(RTC_HOURS) instructions).
or
"19//04/165 165:165:165 day 165" (like if i've been prempt after
CMOS_READ(RTC_MONTH) instructions).
 
We use the same hardware with other system (RTLinux), with same test on
uip bit and we have no problem ( problem isn't on the chipset .. ).
 
So Is my rtdm_lock_get_irqsave and restore use correct ?
Is it sure that my critical section is protected from any premption
with this lock ?
 
i use xenomai 2.3, hal 1.6-03, linux 2.6.19-2.
 
Thanks for your help!
 
 
 

[-- Attachment #2: HTML --]
[-- Type: text/html, Size: 3956 bytes --]

             reply	other threads:[~2007-04-19  9:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-19  9:49 Nicolas BLANCHARD [this message]
2007-04-19 11:55 ` [Xenomai-help] [RTDM] IRQ lock problem ? Jan Kiszka
  -- strict thread matches above, loose matches on Subject: below --
2007-04-19 14:03 Nicolas BLANCHARD

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=s62756bc.018@domain.hid \
    --to=n.blanchard@domain.hid \
    --cc=xenomai@xenomai.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.