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 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.