From: "Christian König" <deathsimple@vodafone.de>
To: "Michel Dänzer" <michel@daenzer.net>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed
Date: Fri, 27 Jun 2014 10:18:51 +0200 [thread overview]
Message-ID: <53AD28EB.1020304@vodafone.de> (raw)
In-Reply-To: <53ACDDBC.80201@daenzer.net>
Am 27.06.2014 04:58, schrieb Michel Dänzer:
> On 26.06.2014 19:39, Christian König wrote:
>> Am 26.06.2014 11:29, schrieb Michel Dänzer:
>>> From: Michel Dänzer <michel.daenzer@amd.com>
>>>
>>> Prevents radeon_crtc_handle_flip() from running before
>>> radeon_flip_work_func(), resulting in a kernel panic due to the BUG_ON()
>>> in drm_vblank_put().
>>>
>>> Tested-by: Dieter Nützel <Dieter@nuetzel-hh.de>
>>> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
>> Does patch #2 alone fixes the problem as well?
> It should avoid the panic as well.
>
>
>> I would rather want to avoid turning the pflip interrupt on and off.
> What's the problem with that? It's not like we're saving any register
> writes by not doing it.
We don't? As far as I can see we reprogram all interrupt registers if
any of the interrupts changed, this has already lead to quite some
additional overhead in the fence waiting code.
>
> The diagnostic messages Dieter was getting with only patch #2 show that
> the pflip interrupt often triggers unnecessarily, potentially wasting
> power by waking up the CPU from a power saving state pointlessly.
That's a really good point, but my question would rather be why does the
pflip interrupt fires if there isn't any pflip?
Turning the vblank and other interrupts off makes sense because they
fire anyway, but pflip should only fire if we really made a request for
it to do so.
Regards,
Christian.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2014-06-27 8:19 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-26 9:29 [PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed Michel Dänzer
2014-06-26 9:29 ` [PATCH 2/2] drm/radeon: Track the status of a page flip more explicitly Michel Dänzer
2014-06-30 9:12 ` [PATCH v2] " Michel Dänzer
2014-06-30 9:14 ` Christian König
2014-07-01 16:23 ` Alex Deucher
2014-06-26 10:39 ` [PATCH 1/2] drm/radeon: Only enable and handle pageflip interrupts when needed Christian König
2014-06-26 11:51 ` Dieter Nützel
2014-06-27 0:53 ` Dieter Nützel
2014-06-27 1:03 ` Michel Dänzer
2014-06-27 1:08 ` Dieter Nützel
2014-06-27 2:06 ` Dieter Nützel
2014-06-27 3:03 ` Michel Dänzer
2014-06-27 3:17 ` Michel Dänzer
2014-06-27 2:58 ` Michel Dänzer
2014-06-27 8:18 ` Christian König [this message]
2014-06-27 9:44 ` Michel Dänzer
2014-06-27 10:47 ` Christian König
2014-06-30 9:34 ` Michel Dänzer
2014-06-30 12:31 ` Christian König
2014-06-30 16:22 ` Dieter Nützel
2014-07-01 8:14 ` [PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank Michel Dänzer
2014-07-01 8:14 ` [PATCH 2/2] drm/radeon: Remove radeon_kms_pflip_irq_get/put() Michel Dänzer
2014-07-01 10:12 ` [PATCH 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank Christian König
2014-07-02 3:55 ` [PATCH v2 " Michel Dänzer
2014-07-02 3:55 ` [PATCH v2 2/2] drm/radeon: Remove radeon_kms_pflip_irq_get/put() and the pflip atomic Michel Dänzer
2014-07-02 10:10 ` [PATCH 1/2] drm/radeon: Move pinning the BO back to radeon_crtc_page_flip() Michel Dänzer
2014-07-02 10:10 ` [PATCH 2/2] drm/radeon: Complete page flip even if waiting on the BO fence fails Michel Dänzer
2014-07-02 11:42 ` [PATCH 1/2] drm/radeon: Move pinning the BO back to radeon_crtc_page_flip() Christian König
2014-07-02 11:35 ` [PATCH v2 1/2] drm/radeon: Program page flips to execute in hblank instead of vblank Christian König
2014-07-01 16:46 ` [PATCH " Dieter Nützel
2014-07-02 0:29 ` Michel Dänzer
2014-07-02 3:01 ` Dieter Nützel
2014-07-02 3:11 ` Michel Dänzer
2014-07-02 3:52 ` Michel Dänzer
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=53AD28EB.1020304@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.