From: Jyri Sarha <jsarha@ti.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: tomi.valkeinen@ti.com, laurent.pinchart@ideasonboard.com,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH RFC] drm/atomic: Disable planes on blanked CRTC and enable on unblank
Date: Wed, 18 Nov 2015 17:52:45 +0200 [thread overview]
Message-ID: <564C9ECD.3050101@ti.com> (raw)
In-Reply-To: <20151116160604.GY16848@phenom.ffwll.local>
On 11/16/15 18:06, Daniel Vetter wrote:
> On Thu, Nov 05, 2015 at 05:03:09PM +0200, Jyri Sarha wrote:
>> Disable planes if they are on to be blanked CRTC and enable them when
>> the CRTC is turned back on by DMPS.
>>
>> This is desirable on HW that loses its context on blanking. When
>> planes are enabled and disabled with the associated CRTCs, there is no
>> need to restore the plane context in runtime_resume callback.
>>
>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>> ---
>> We would need something like this to get rid off OMAPDSS somewhat
>> messy runtime_resume code. How does this look, could this generic
>> solution be refined to be acceptable to mainline, or should we start
>> looking a local solution to omapdrm?
>>
>> BTW, with this patch the planes are sometimes disabled multiple
>> times. So probably a boolean (or maybe two like on crtc) should be
>> added to drm_plane_state to track and avoid multiple shutdowns.
>
> The recommended way to do this is to call drm_atomic_add_affected_planes
> from your crtc's atomic_check callback when active_changed is set. This
> will also take care of enabling all planes again. For disabling we don't
> yet have a helper yet, but it would be easy to create a
> drm_atomic_helper_disable_planes(crtc) which just walks over all planes in
> an atomic update that are currently using the given crtc and disables it
> using plane_helper_funcs->atomic_disable. That would again require
> drm_atomic_add_affected_planes to be called first.
>
> This way current helper behaviour is unchanged, but it'd be easy to
> construct the behaviour you want using helpers with
> drm_atomic_add_affected_planes called from the crtc->disable hook.
>
> I thought there was an rfc patch somewhere for this, but I can't find it
> any more.
It appears that in the end these instructions were really all I needed.
There is only one thing that still bothers me. When implementing the
feature you described above, I had a print in the code to see if it
actually did anything. At first - because of my mistake - it did not,
but the plane context was still restored just fine on drm_next and
mainline linux. However the same omapdrm code did not restore the plane
context on our 4.1 based Linux branch.
So something similar to what I tried to accomplish has been implemented
some where between Linux 4.1 and 4.3?
Anyway, after back-porting the above fix works perfectly on our 4.1
based branch.
Thanks,
Jyri
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2015-11-18 15:52 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-05 15:03 [PATCH RFC] drm/atomic: Disable planes on blanked CRTC and enable on unblank Jyri Sarha
2015-11-16 16:06 ` Daniel Vetter
2015-11-18 15:52 ` Jyri Sarha [this message]
2015-11-18 16:04 ` Daniel Vetter
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=564C9ECD.3050101@ti.com \
--to=jsarha@ti.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=tomi.valkeinen@ti.com \
/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