RE: [ECOS] Re: Possible deadlock in SPI driver for AT91 ARM target

["Svend Meyland Nicolaisen" <ecos at smn dot dk>]

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org 
> [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of 
> Jonathan Larmour
> Sent: 3. marts 2008 16:46
> To: Svend Meyland Nicolaisen
> Cc: ecos-discuss@ecos.sourceware.org
> Subject: [ECOS] Re: Possible deadlock in SPI driver for AT91 
> ARM target
> 
> Svend Meyland Nicolaisen wrote:
> > Hello
> > 
> > I am looking at the source, spi_at91.c, of the SPI driver 
> for the AT91 
> > ARM processor. In the function spi_at91_transfer the following code 
> > can be
> > found:
> > 
> > =====>
> >         cyg_drv_mutex_lock(&spi_bus->transfer_mx);
> >         {
> >             spi_bus->transfer_end = false;
> >     
> >             // Unmask the SPI int
> >             cyg_drv_interrupt_unmask(spi_bus->interrupt_number);
> >         
> >             // Wait for its completition
> >             cyg_drv_dsr_lock();
> >             {
> >                 while (!spi_bus->transfer_end)
> >                     cyg_drv_cond_wait(&spi_bus->transfer_cond);
> >             }
> >             cyg_drv_dsr_unlock();
> >         }    
> >         cyg_drv_mutex_unlock(&spi_bus->transfer_mx);
> > <=====
> > 
> > The transfer_cond condition is signalled in the DSR routine. Now if 
> > the DSR's are locked, how can the DSR routine be called to 
> signal the condition?
> > Am I missing something?
> 
> Yes ;-).
> 
> If a thread goes to sleep, the DSRs get unlocked again. When 
> the thread becomes runnable and is rescheduled, DSRs are 
> relocked. You could consider this to mean that the scheduler 
> lock is a per-thread property.
> 

Ahh, thank you for your answer. Might be a good point to add to the
documentation..... :-)

/Svend


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss