> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Jonathan Larmour > Sent: 3. marts 2008 16:46 > To: Svend Meyland Nicolaisen > Cc: [email protected] > 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
