dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <deathsimple@vodafone.de>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics
Date: Fri, 01 Jun 2012 12:44:33 +0200	[thread overview]
Message-ID: <4FC89D11.4030703@vodafone.de> (raw)
In-Reply-To: <1338532249.25194.308.camel@thor.local>

On 01.06.2012 08:30, Michel Dänzer wrote:
> On Fre, 2012-06-01 at 08:19 +0200, Michel Dänzer wrote:
>> I think this might introduce a race condition:
>>
>> Thread 0 Thread 1
>> -------- --------
>> atomic_inc_return() returns 1
>> spin_lock_irqsave()
>> atomic_dec_and_test()
>> radeon_irq_set()
>>
>> =>  the interrupt won't be enabled.
> Hrmm, I messed up the formatting there, let me try one more time:
>
> Thread 0				Thread 1
> --------				--------
> atomic_inc_return() returns 1
> spin_lock_irqsave()
> 					atomic_dec_and_test()
> radeon_irq_set()
>
>
Nope that isn't a problem, cause what you really get in your example is:

Thread 0				Thread 1
--------				--------
atomic_inc_return() returns 1
spin_lock_irqsave()
					atomic_dec_and_test()
radeon_irq_set()
spin_unlock_irqrestore()
					spin_lock_irqsave()
					radeon_irq_set()
					spin_unlock_irqrestore()


So testing the atomic counters just determines if we need an update of 
the irq registers or not, and since a significant change will always 
trigger an update we can make sure that the irq regs are always set to 
the last known state. We might call radeon_irq_set more often than 
necessary, but that won't hurt us and is really unlikely.

Also I have found the real reason why using the atomic for preventing ih 
recursion didn't worked as expected - it was just a stupid typo in my 
patch.  But thanks for the comment anyway, it got me to look into the 
right direction for the bug.

Cheers,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2012-06-01 10:44 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-31 20:15 [PATCH 01/10] drm/radeon: remove radeon_fence_create Christian König
2012-05-31 20:15 ` [PATCH 02/10] drm/radeon: add infrastructure for advanced ring synchronization Christian König
2012-05-31 21:09   ` Jerome Glisse
2012-05-31 20:15 ` [PATCH 03/10] drm/radeon: rework ring syncing code Christian König
2012-05-31 20:16 ` [PATCH 04/10] drm/radeon: replace vmram_mutex with mclk_lock v2 Christian König
2012-05-31 20:16 ` [PATCH 05/10] drm/radeon: remove some unneeded structure members Christian König
2012-05-31 20:16 ` [PATCH 06/10] drm/radeon: fix ih ring handling v2 Christian König
2012-05-31 20:16 ` [PATCH 07/10] drm/radeon: apply Murphy's law to the kms irq code v2 Christian König
2012-05-31 20:33   ` Alex Deucher
2012-05-31 20:16 ` [PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics Christian König
2012-06-01  6:19   ` Michel Dänzer
2012-06-01  6:30     ` Michel Dänzer
2012-06-01 10:44       ` Christian König [this message]
2012-06-01 10:55         ` Michel Dänzer
2012-05-31 20:16 ` [PATCH 09/10] drm/radeon: replace cs_mutex with vm_mutex Christian König
2012-05-31 20:16 ` [PATCH 10/10] drm/radeon: work around bugs in caymans compute rings Christian König
  -- strict thread matches above, loose matches on Subject: below --
2012-06-01 11:36 [PATCH 01/10] drm/radeon: remove radeon_fence_create Christian König
2012-06-01 11:36 ` [PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics Christian König
2012-05-24  7:49 [PATCH 01/10] drm/radeon: remove radeon_fence_create Christian König
2012-05-24  7:49 ` [PATCH 08/10] drm/radeon: replace pflip and sw_int counters with atomics Christian König
2012-05-24 11:59   ` Sylvain BERTRAND
2012-05-24 12:29     ` Koenig, Christian
2012-05-24 12:46       ` Sylvain BERTRAND
2012-05-24 12:53         ` Dave Airlie
2012-05-24 12:54           ` Dave Airlie
2012-05-24 14:23             ` Sylvain BERTRAND

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FC89D11.4030703@vodafone.de \
    --to=deathsimple@vodafone.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=michel@daenzer.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox