From: Tomi Valkeinen <tomi.valkeinen@ti.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Benoit Parrot <bparrot@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
devicetree@vger.kernel.org, Jyri Sarha <jsarha@ti.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [Patch v2 1/6] drm/omap: Add ability to filter out modes which can't be supported
Date: Thu, 5 Apr 2018 13:21:30 +0300 [thread overview]
Message-ID: <f8e60ec4-20ec-4b7d-f102-bc9d7d50e37a@ti.com> (raw)
In-Reply-To: <1527419.mcdjVnGTTs@avalon>
On 04/04/18 17:23, Laurent Pinchart wrote:
>>>> + WARN(out_width > dispc.feat->ovl_width_max,
>>>> + "Requested OVL width (%d) is larger than can be supported
>>>> (%d).\n",
>>>> + out_width, dispc.feat->ovl_width_max);
>>>
>>> Why don't you return an error here? I don't see a need for WARN here.
>>
>> So here you mean replace the WARN with something like this:
>>
>> if (out_width > dispc.feat->ovl_width_max) {
>> DSSERR("Requested OVL width (%d) is larger than can be supported (%d).
> \n",
>> out_width, dispc.feat->ovl_width_max);
>> return -EINVAL;
>> }
>
> Can this happen ? If we reject invalid settings in omapdrm we should never get
> them here.
That's true. And we should check them in the plane atomic check (but do
we?).
In that case I don't mind a warn there, but you should still return an
error if it happens, instead of continuing with bad config.
>>>> + /* Check if the advertised width exceed what the pipeline can do */
>>>> + if (!r) {
>>>> + struct omap_drm_private *priv = dev->dev_private;
>>>> + u16 width, height;
>>>> +
>>>> + priv->dispc_ops->ovl_get_max_size(&width, &height);
>>>> + if (mode->hdisplay > width)
>>>> + r = -EINVAL;
>>>
>>> You should check the height also.
>>
>> Yeah, I'll fix that.
>
> Unless I'm mistaken the restriction doesn't come from the output side of the
> display controller but from the overlays (planes), right ? Shouldn't it then
> be implemented in the drm_plane_helper_funcs.atomic_check operation ?
Yes, but I don't so. If our planes can support up to, say, 1000. Then we
plug in a monitor with native width of 1100, which omapdrm would accept
happily and try to use it by default. But we can't show fbdev or any
normal setup there, because the planes won't support it. How would we
manage that?
While not strictly correct, I think it's fine to reject videomodes which
can't be shown with a normal full-screen plane.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2018-04-05 10:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-26 16:21 [Patch v2 0/6] drm/omap: Add virtual-planes support Benoit Parrot
2018-03-26 16:21 ` [Patch v2 1/6] drm/omap: Add ability to filter out modes which can't be supported Benoit Parrot
2018-04-04 11:12 ` Tomi Valkeinen
2018-04-04 13:15 ` Benoit Parrot
2018-04-04 14:23 ` Laurent Pinchart
2018-04-05 10:21 ` Tomi Valkeinen [this message]
2018-04-24 19:08 ` Laurent Pinchart
2018-03-26 16:21 ` [Patch v2 2/6] dt-bindings: display/ti: Move common dispc bindings to omap-dss.txt Benoit Parrot
2018-04-04 14:29 ` Laurent Pinchart
2018-04-27 13:26 ` Benoit Parrot
2018-03-26 16:21 ` [Patch v2 3/6] dt-bindings: display/ti: Add plane binding to dispc node Benoit Parrot
2018-04-04 14:36 ` Laurent Pinchart
2018-04-04 14:56 ` Tomi Valkeinen
2018-04-19 6:35 ` Daniel Vetter
2018-03-26 16:21 ` [Patch v2 4/6] drm/omap: Add virtual plane DT parsing support Benoit Parrot
2018-03-26 16:21 ` [Patch v2 5/6] drm/omap: Add virtual plane support to omap_plane Benoit Parrot
2018-04-05 11:14 ` Tomi Valkeinen
2018-03-26 16:21 ` [Patch v2 6/6] drm/omap: Allow wider display when a virtual plane is available Benoit Parrot
2018-04-05 10:40 ` Tomi Valkeinen
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=f8e60ec4-20ec-4b7d-f102-bc9d7d50e37a@ti.com \
--to=tomi.valkeinen@ti.com \
--cc=bparrot@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=peter.ujfalusi@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;
as well as URLs for NNTP newsgroup(s).