From: Boris Brezillon <bbrezillon@kernel.org>
To: Peter Rosin <peda@axentia.se>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
David Airlie <airlied@linux.ie>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Boris Brezillon <boris.brezillon@bootlin.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/4] drm/atmel-hlcdc: do not immediately disable planes, wait for next frame
Date: Thu, 10 Jan 2019 20:25:22 +0100 [thread overview]
Message-ID: <20190110202522.10206f2d@bbrezillon> (raw)
In-Reply-To: <a31e6514-1643-9e47-cbb4-3323183fd370@axentia.se>
On Thu, 10 Jan 2019 18:51:21 +0000
Peter Rosin <peda@axentia.se> wrote:
> On 2019-01-10 18:29, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 15:10:48 +0000
> > Peter Rosin <peda@axentia.se> wrote:
> >
> >> The A2Q and UPDATE bits have no effect in the channel disable registers.
> >> However, since they are present, assume that the intention is to disable
> >> planes, not immediately as indicated by the RST bit, but on the next
> >> frame shift since that is what A2Q and UPDATE means in the channel enable
> >> registers.
> >>
> >> Disabling the plane on the next frame shift is done with the EN bit,
> >> so use that.
> >
> > It's been a long time, but I think I had a good reason for forcing a
> > reset. IIRC, when you don't do that and the CRTC is disabled before the
> > plane, the EN bit stays around, and next time you queue a plane update,
> > you'll start with an invalid buf pointer.
>
> It might be possible to clear the EN bit in ...CHDR before enabling the
> plane in ...CHER. Or is that too late?
I think I tried that, but I'm not sure (BTW, this change was done in
bd4248bb5e8b ("drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when
disabling it")). Anyway, I'm not even sure this is still needed now
that atomic updates have a wait_for_flip_done/vblank() in the commit
path.
> But this patch is not overly
> important, I just wanted to avoid the resulting "black hole" when the
> plane DMA is disabled mid-frame. But disabling planes is probably not
> something that happens frequently and will perhaps not be noticed at
> all...
Okay. Other patches look good to me, I'm just waiting for Nicolas
feedback before applying them.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <bbrezillon@kernel.org>
To: Peter Rosin <peda@axentia.se>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
David Airlie <airlied@linux.ie>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>,
Boris Brezillon <boris.brezillon@bootlin.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 4/4] drm/atmel-hlcdc: do not immediately disable planes, wait for next frame
Date: Thu, 10 Jan 2019 20:25:22 +0100 [thread overview]
Message-ID: <20190110202522.10206f2d@bbrezillon> (raw)
In-Reply-To: <a31e6514-1643-9e47-cbb4-3323183fd370@axentia.se>
On Thu, 10 Jan 2019 18:51:21 +0000
Peter Rosin <peda@axentia.se> wrote:
> On 2019-01-10 18:29, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 15:10:48 +0000
> > Peter Rosin <peda@axentia.se> wrote:
> >
> >> The A2Q and UPDATE bits have no effect in the channel disable registers.
> >> However, since they are present, assume that the intention is to disable
> >> planes, not immediately as indicated by the RST bit, but on the next
> >> frame shift since that is what A2Q and UPDATE means in the channel enable
> >> registers.
> >>
> >> Disabling the plane on the next frame shift is done with the EN bit,
> >> so use that.
> >
> > It's been a long time, but I think I had a good reason for forcing a
> > reset. IIRC, when you don't do that and the CRTC is disabled before the
> > plane, the EN bit stays around, and next time you queue a plane update,
> > you'll start with an invalid buf pointer.
>
> It might be possible to clear the EN bit in ...CHDR before enabling the
> plane in ...CHER. Or is that too late?
I think I tried that, but I'm not sure (BTW, this change was done in
bd4248bb5e8b ("drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when
disabling it")). Anyway, I'm not even sure this is still needed now
that atomic updates have a wait_for_flip_done/vblank() in the commit
path.
> But this patch is not overly
> important, I just wanted to avoid the resulting "black hole" when the
> plane DMA is disabled mid-frame. But disabling planes is probably not
> something that happens frequently and will perhaps not be noticed at
> all...
Okay. Other patches look good to me, I'm just waiting for Nicolas
feedback before applying them.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <bbrezillon@kernel.org>
To: Peter Rosin <peda@axentia.se>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>,
David Airlie <airlied@linux.ie>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"dri-devel@lists.freedesktop.org"
<dri-devel@lists.freedesktop.org>,
Boris Brezillon <boris.brezillon@bootlin.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Nicolas Ferre <nicolas.ferre@microchip.com>
Subject: Re: [PATCH 4/4] drm/atmel-hlcdc: do not immediately disable planes, wait for next frame
Date: Thu, 10 Jan 2019 20:25:22 +0100 [thread overview]
Message-ID: <20190110202522.10206f2d@bbrezillon> (raw)
In-Reply-To: <a31e6514-1643-9e47-cbb4-3323183fd370@axentia.se>
On Thu, 10 Jan 2019 18:51:21 +0000
Peter Rosin <peda@axentia.se> wrote:
> On 2019-01-10 18:29, Boris Brezillon wrote:
> > On Thu, 10 Jan 2019 15:10:48 +0000
> > Peter Rosin <peda@axentia.se> wrote:
> >
> >> The A2Q and UPDATE bits have no effect in the channel disable registers.
> >> However, since they are present, assume that the intention is to disable
> >> planes, not immediately as indicated by the RST bit, but on the next
> >> frame shift since that is what A2Q and UPDATE means in the channel enable
> >> registers.
> >>
> >> Disabling the plane on the next frame shift is done with the EN bit,
> >> so use that.
> >
> > It's been a long time, but I think I had a good reason for forcing a
> > reset. IIRC, when you don't do that and the CRTC is disabled before the
> > plane, the EN bit stays around, and next time you queue a plane update,
> > you'll start with an invalid buf pointer.
>
> It might be possible to clear the EN bit in ...CHDR before enabling the
> plane in ...CHER. Or is that too late?
I think I tried that, but I'm not sure (BTW, this change was done in
bd4248bb5e8b ("drm: atmel-hlcdc: reset layer A2Q and UPDATE bits when
disabling it")). Anyway, I'm not even sure this is still needed now
that atomic updates have a wait_for_flip_done/vblank() in the commit
path.
> But this patch is not overly
> important, I just wanted to avoid the resulting "black hole" when the
> plane DMA is disabled mid-frame. But disabling planes is probably not
> something that happens frequently and will perhaps not be noticed at
> all...
Okay. Other patches look good to me, I'm just waiting for Nicolas
feedback before applying them.
next prev parent reply other threads:[~2019-01-10 19:25 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 15:10 [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues Peter Rosin
2019-01-10 15:10 ` Peter Rosin
2019-01-10 15:10 ` [PATCH 1/4] drm/atmel-hlcdc: rotate planes counterclockwise Peter Rosin
2019-01-10 15:10 ` Peter Rosin
2019-01-10 15:10 ` [PATCH 2/4] drm/atmel-hlcdc: do not swap w/h of the crtc when a plane is rotated Peter Rosin
2019-01-10 15:10 ` Peter Rosin
2019-01-10 17:48 ` Boris Brezillon
2019-01-10 17:48 ` Boris Brezillon
2019-01-11 13:29 ` Peter Rosin
2019-01-11 13:29 ` Peter Rosin
2019-01-11 13:29 ` Peter Rosin
2019-01-11 14:14 ` Nicolas.Ferre
2019-01-11 14:14 ` Nicolas.Ferre
2019-01-11 14:14 ` Nicolas.Ferre
2019-01-10 15:10 ` [PATCH 3/4] drm/atmel-hlcdc: fix clipping of planes Peter Rosin
2019-01-10 15:10 ` Peter Rosin
2019-01-10 15:10 ` [PATCH 4/4] drm/atmel-hlcdc: do not immediately disable planes, wait for next frame Peter Rosin
2019-01-10 15:10 ` Peter Rosin
2019-01-10 17:29 ` Boris Brezillon
2019-01-10 17:29 ` Boris Brezillon
2019-01-10 17:29 ` Boris Brezillon
2019-01-10 18:51 ` Peter Rosin
2019-01-10 18:51 ` Peter Rosin
2019-01-10 18:51 ` Peter Rosin
2019-01-10 19:25 ` Boris Brezillon [this message]
2019-01-10 19:25 ` Boris Brezillon
2019-01-10 19:25 ` Boris Brezillon
2019-01-11 14:29 ` Peter Rosin
2019-01-11 14:29 ` Peter Rosin
2019-01-11 14:29 ` Peter Rosin
2019-01-16 14:45 ` Boris Brezillon
2019-01-16 14:45 ` Boris Brezillon
2019-01-16 14:45 ` Boris Brezillon
2019-01-10 17:45 ` [PATCH 0/4] drm/atmel-hlcdc: fix plane clipping/rotation issues Boris Brezillon
2019-01-10 17:45 ` Boris Brezillon
2019-01-10 17:45 ` Boris Brezillon
2019-01-10 20:16 ` Sam Ravnborg
2019-01-10 20:16 ` Sam Ravnborg
2019-01-10 20:16 ` Sam Ravnborg
2019-01-11 9:16 ` Peter Rosin
2019-01-11 9:16 ` Peter Rosin
2019-01-11 9:16 ` Peter Rosin
2019-01-10 21:24 ` Peter Rosin
2019-01-10 21:24 ` Peter Rosin
2019-01-11 14:18 ` Nicolas.Ferre
2019-01-11 14:18 ` Nicolas.Ferre
2019-01-11 14:18 ` Nicolas.Ferre
2019-01-27 8:27 ` Boris Brezillon
2019-01-27 8:27 ` Boris Brezillon
2019-01-27 8:27 ` Boris Brezillon
2019-01-31 13:13 ` Peter Rosin
2019-01-31 13:13 ` Peter Rosin
2019-01-31 13:21 ` Boris Brezillon
2019-01-31 13:21 ` Boris Brezillon
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=20190110202522.10206f2d@bbrezillon \
--to=bbrezillon@kernel.org \
--cc=airlied@linux.ie \
--cc=alexandre.belloni@bootlin.com \
--cc=boris.brezillon@bootlin.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
/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.