From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: linux-samsung-soc@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
linux-kernel@vger.kernel.org,
Krzysztof Kozlowski <krzk@kernel.org>,
Kyungmin Park <kyungmin.park@samsung.com>,
dri-devel@lists.freedesktop.org,
Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH 6/7] drm/exynos/decon5433: signal vblank only on odd fields
Date: Wed, 25 Jan 2017 16:06:41 +0200 [thread overview]
Message-ID: <20170125140641.GU31595@intel.com> (raw)
In-Reply-To: <953193f0-484e-0457-baf4-e42b44a3f147@samsung.com>
On Mon, Jan 23, 2017 at 10:15:16AM +0100, Andrzej Hajda wrote:
> On 20.01.2017 14:55, Ville Syrjälä wrote:
> > On Fri, Jan 20, 2017 at 07:52:24AM +0100, Andrzej Hajda wrote:
> >> In case of interlace mode irq is generated for odd and even fields, but
> >> vblank should be signaled only for the last emitted field.
> > I'm pretty sure most drivers signal it for both fields. At least i915
> > does.
>
> The question is which behavior is correct? I have not found any clear
> statement in the documentation, or drm core code.
That's very typical for us unfortunately.
I would say what we should do what i915 does. It allows more flexibility
in how you use the hardware. Eg. then you can actually scan out
interlaced material to an interlaced display and not mess up the fields,
and you can also do 3:2 pulldown type of stuff. Or you can even just
stuff progressive frames down the pipe at field rate.
One problem with interlaced stuff is that we don't have any field
indication in the events, nor do we have a way to flip on a specific
field. I tried to specify the latter for the SETPLANE ioctl way
back when, but it didn't end up being implemented and now we would
need something different for atomic.
> I have guessed that since vblank event is used to signal end of scan-out
> of buffer it should be called after scan-out of whole buffer - in case
> of interlaced mode after scan-out of 2nd field.
Each field has a proper vertical blanking interval, so you'd just end up
totally wasting one of them.
> Maybe my assumption is wrong, in such case this patch should be dropped
> and mixer driver also should be fixed, but before doing that it would be
> good to know for sure how it should be handled correctly.
>
> Regards
> Andrzej
--
Ville Syrjälä
Intel OTC
_______________________________________________
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: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Andrzej Hajda <a.hajda@samsung.com>
Cc: Inki Dae <inki.dae@samsung.com>,
dri-devel@lists.freedesktop.org,
Krzysztof Kozlowski <krzk@kernel.org>,
linux-samsung-soc@vger.kernel.org,
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>,
linux-kernel@vger.kernel.org,
Kyungmin Park <kyungmin.park@samsung.com>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Daniel Vetter <daniel@ffwll.ch>
Subject: Re: [PATCH 6/7] drm/exynos/decon5433: signal vblank only on odd fields
Date: Wed, 25 Jan 2017 16:06:41 +0200 [thread overview]
Message-ID: <20170125140641.GU31595@intel.com> (raw)
In-Reply-To: <953193f0-484e-0457-baf4-e42b44a3f147@samsung.com>
On Mon, Jan 23, 2017 at 10:15:16AM +0100, Andrzej Hajda wrote:
> On 20.01.2017 14:55, Ville Syrjälä wrote:
> > On Fri, Jan 20, 2017 at 07:52:24AM +0100, Andrzej Hajda wrote:
> >> In case of interlace mode irq is generated for odd and even fields, but
> >> vblank should be signaled only for the last emitted field.
> > I'm pretty sure most drivers signal it for both fields. At least i915
> > does.
>
> The question is which behavior is correct? I have not found any clear
> statement in the documentation, or drm core code.
That's very typical for us unfortunately.
I would say what we should do what i915 does. It allows more flexibility
in how you use the hardware. Eg. then you can actually scan out
interlaced material to an interlaced display and not mess up the fields,
and you can also do 3:2 pulldown type of stuff. Or you can even just
stuff progressive frames down the pipe at field rate.
One problem with interlaced stuff is that we don't have any field
indication in the events, nor do we have a way to flip on a specific
field. I tried to specify the latter for the SETPLANE ioctl way
back when, but it didn't end up being implemented and now we would
need something different for atomic.
> I have guessed that since vblank event is used to signal end of scan-out
> of buffer it should be called after scan-out of whole buffer - in case
> of interlaced mode after scan-out of 2nd field.
Each field has a proper vertical blanking interval, so you'd just end up
totally wasting one of them.
> Maybe my assumption is wrong, in such case this patch should be dropped
> and mixer driver also should be fixed, but before doing that it would be
> good to know for sure how it should be handled correctly.
>
> Regards
> Andrzej
--
Ville Syrjälä
Intel OTC
next prev parent reply other threads:[~2017-01-25 14:06 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20170120065229eucas1p22f0eed53220820b1145294029d4bd706@eucas1p2.samsung.com>
2017-01-20 6:52 ` [PATCH 0/7] drm/exynos: add Ultra HD and interlace modes support to Exynos5433 Andrzej Hajda
2017-01-20 6:52 ` Andrzej Hajda
2017-01-20 6:52 ` [PATCH 1/7] drm/exynos/hdmi: add 297MHz pixel clock support Andrzej Hajda
2017-01-20 6:52 ` [PATCH 2/7] drm/exynos/hdmi: fix VSI infoframe registers Andrzej Hajda
2017-01-20 6:52 ` [PATCH 3/7] drm/exynos/hdmi: fix PLL for 27MHz settings Andrzej Hajda
2017-01-20 6:52 ` Andrzej Hajda
2017-01-20 6:52 ` [PATCH 4/7] drm/exynos/hdmi: add bridge support Andrzej Hajda
2017-01-20 6:52 ` Andrzej Hajda
2017-02-01 7:31 ` Inki Dae
2017-02-01 7:31 ` Inki Dae
2017-02-01 7:34 ` Andrzej Hajda
2017-02-01 7:44 ` Inki Dae
2017-02-01 7:44 ` Inki Dae
2017-02-01 8:12 ` Andrzej Hajda
2017-02-01 8:12 ` Andrzej Hajda
2017-02-01 8:17 ` Inki Dae
2017-02-01 8:17 ` Inki Dae
2017-02-01 8:29 ` [PATCH v3 " Andrzej Hajda
2017-02-03 6:38 ` Inki Dae
2017-02-03 6:39 ` Inki Dae
2017-02-03 6:39 ` Inki Dae
2017-01-20 6:52 ` [PATCH 5/7] drm/exynos/decon5433: add support for interlace modes Andrzej Hajda
2017-01-20 6:52 ` Andrzej Hajda
2017-01-20 6:52 ` [PATCH 6/7] drm/exynos/decon5433: signal vblank only on odd fields Andrzej Hajda
2017-01-20 6:52 ` Andrzej Hajda
2017-01-20 13:55 ` Ville Syrjälä
2017-01-23 9:15 ` Andrzej Hajda
2017-01-23 9:15 ` Andrzej Hajda
2017-01-25 14:06 ` Ville Syrjälä [this message]
2017-01-25 14:06 ` Ville Syrjälä
2017-01-26 8:22 ` Andrzej Hajda
2017-01-26 10:42 ` Ville Syrjälä
2017-01-20 6:52 ` [PATCH 7/7] arm64: dts: exynos: configure TV path clocks for Ultra HD modes Andrzej Hajda
2017-01-20 6:52 ` Andrzej Hajda
2017-01-20 14:51 ` Krzysztof Kozlowski
2017-01-23 7:56 ` [PATCH v2 " Andrzej Hajda
2017-01-23 7:56 ` Andrzej Hajda
2017-01-23 9:08 ` Marek Szyprowski
2017-01-23 10:05 ` [PATCH v3 " Andrzej Hajda
2017-01-23 10:05 ` Andrzej Hajda
2017-01-23 16:35 ` Krzysztof Kozlowski
2017-01-20 14:49 ` [PATCH 0/7] drm/exynos: add Ultra HD and interlace modes support to Exynos5433 Krzysztof Kozlowski
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=20170125140641.GU31595@intel.com \
--to=ville.syrjala@linux.intel.com \
--cc=a.hajda@samsung.com \
--cc=b.zolnierkie@samsung.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=krzk@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=m.szyprowski@samsung.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.