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

[Jonathan Larmour <jifl at eCosCentric dot com>]

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.

Jifl
-- 
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine

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