This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
RE: I2C driver DSR locking
- From: Daniel Helgason <danielh at telus dot net>
- To: eCos Discuss <ecos-discuss at ecos dot sourceware dot org>
- Date: Tue, 03 Apr 2007 21:41:44 -0700
- Subject: RE: [ECOS] I2C driver DSR locking
- References: <005d01c77636$fc351fc0$8d7ba8c0@PAULD>
On Tue, 2007-04-03 at 14:28 -0700, Paul D. DeRocco wrote:
> > From: Rob Duncan
> >
> > Can someone explain to me how this code fragment from
> > i2c_mcf52xx.c is supposed to work? extra->i2c_lock is a
> > mutex to control access to the
> > extra->i2c_wait condition variable which is used to signal that the
> > extra->i2c_completed flag should be re-examined. However
> > i2c_completed
> > extra->is set true and the condition variable is
> > signaled by the DSR, which won't be able to run because the
> > DSR lock has been taken. Isn't this liable to hang the
> > system? It looks to me that locking the DSR is exactly what
> > you don't want to do.
> >
> > cyg_drv_mutex_lock(&(extra->i2c_lock));
> > cyg_drv_dsr_lock();
> > while (! extra->i2c_completed) {
> > cyg_drv_cond_wait(&(extra->i2c_wait));
> > }
> > cyg_drv_dsr_unlock();
> > cyg_drv_mutex_unlock(&(extra->i2c_lock));
>
> cyg_drv_cond_wait releases and reacquires the DSR lock, just like it
> releases and reacquires the mutex. This allows the routine to coexist not
> only with other threads, but with the DSR. You see the same pattern in most
> drivers.
> ...
Paul!
Do you (or anyone reading this list) know if this is true for any case
where a thread blocks after taking the scheduler lock? Or is this just
special for cyg_drv_cond_wait() function?
--
+---------------------------------------------
| Daniel Helgason <danielh@telus.net>
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss