Re: [PATCH v2] ARM: pl330: Fix a race condition

[Javi Merino <javi.merino@arm.com>]

On 28/11/11 08:23, Boojin Kim wrote:
> Javi Merino wrote:
> 
>>> On Samsung's Exynos4 platform, while testing audio playback with i2s
>>> interface, the above change causes the playback to freeze. The
>>> _thrd_active(thrd) call always returns '1' and hence _start(thrd) is
>>> not getting called.
>>
>> If _thrd_active(thrd) returns '1', that means there is an active
>> transfer still running or, if it has finished, you haven't called
>> pl330_update() to acknowledge that.  pl330_update() calls _start() as
>> soon as it can.
>>
>> drivers/dma/pl330.c registers the irq handler in pl330_probe(), so
>> when
>> the transaction finishes, pl330_update() should clear it and call
>> _start().  If there is any outstanding transaction, it should start
>> straight away. If there isn't, it would mark the channel as free, so
>> _thrd_active() should return '0'.  If _thrd_active() is still '1', then
>> something has gone wrong in the way.
>>
>> Does this shed some light?
>>
> 
> Your patch makes the memcpy operation on dmatest.c and net DMA be frozen too
> as well as Samsung audio playback.

Is the IRQ correctly registered in drivers/dma/pl330.c:pl330_probe()?
Do you get interrupts when the transfer finish?

The only way I can think of that
ee3f615819404a9438b2dd01b7a39f276d2737f2 can break break something is
that you aren't calling pl330_update() at all.

> With our patch, common DMA memcpy sequence may be changed.

Which one is "our patch"?  I'm sorry, I'm not subscribed to any of the
lists so I may have missed something.

Cheers,
Javi