dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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