From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Benoit Parrot <bparrot@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
devicetree@vger.kernel.org,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
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: Wed, 04 Apr 2018 17:23:35 +0300 [thread overview]
Message-ID: <1527419.mcdjVnGTTs@avalon> (raw)
In-Reply-To: <20180404131511.GB7303@ti.com>
Hi Benoit,
On Wednesday, 4 April 2018 16:15:11 EEST Benoit Parrot wrote:
> Tomi Valkeinen wrote on Wed [2018-Apr-04 14:12:13 +0300]:
> > On 26/03/18 19:21, Benoit Parrot wrote:
> >> Currently available display mode from a connector are filtered out
> >> based only on pixel clock capability. However we also need to filter
> >> out wider mode if we cannot handle them based on available pipeline
> >> capabilities.
> >>
> >> Signed-off-by: Benoit Parrot <bparrot@ti.com>
> >> ---
> >>
> >> drivers/gpu/drm/omapdrm/dss/dispc.c | 27 +++++++++++++++++++++++++
> >> drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 +
> >> drivers/gpu/drm/omapdrm/omap_connector.c | 10 ++++++++++
> >> 3 files changed, 38 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> b/drivers/gpu/drm/omapdrm/dss/dispc.c index 624dee22f46b..35541d4441df
> >> 100644
> >--- a/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> +++ b/drivers/gpu/drm/omapdrm/dss/dispc.c
> >> @@ -100,6 +100,8 @@ struct dispc_features {
> >> u8 mgr_height_start;
> >> u16 mgr_width_max;
> >> u16 mgr_height_max;
> >> + u16 ovl_width_max;
> >> + u16 ovl_height_max;
> >> unsigned long max_lcd_pclk;
> >> unsigned long max_tv_pclk;
> >> unsigned int max_downscale;
> >> @@ -2465,6 +2467,12 @@ static int dispc_ovl_calc_scaling(unsigned long
> >> pclk, unsigned long lclk,
> >> return 0;
> >> }
> >>
> >> +static void dispc_ovl_get_max_size(u16 *width, u16 *height)
> >> +{
> >> + *width = dispc.feat->ovl_width_max;
> >> + *height = dispc.feat->ovl_height_max;
> >> +}
> >> +
> >> static int dispc_ovl_setup_common(enum omap_plane_id plane,
> >> enum omap_overlay_caps caps, u32 paddr, u32 p_uv_addr,
> >> u16 screen_width, int pos_x, int pos_y, u16 width, u16 height,
> >> @@ -2500,6 +2508,10 @@ static int dispc_ovl_setup_common(enum
> >> omap_plane_id plane,
> >> out_width = out_width == 0 ? width : out_width;
> >> out_height = out_height == 0 ? height : out_height;
> >>
> >> + 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.
> >> void dispc_set_ops(const struct dispc_ops *o);
> >>
> >> diff --git a/drivers/gpu/drm/omapdrm/omap_connector.c
> >> b/drivers/gpu/drm/omapdrm/omap_connector.c index
> >> a0d7b1d905e8..d5e059abb555 100644
> >> --- a/drivers/gpu/drm/omapdrm/omap_connector.c
> >> +++ b/drivers/gpu/drm/omapdrm/omap_connector.c
> >> @@ -197,6 +197,16 @@ static int omap_connector_mode_valid(struct
> >> drm_connector *connector,
> >> r = 0;
> >> }
> >>
> >> + /* 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 ?
--
Regards,
Laurent Pinchart
_______________________________________________
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-04 14:23 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 [this message]
2018-04-05 10:21 ` Tomi Valkeinen
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=1527419.mcdjVnGTTs@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=bparrot@ti.com \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jsarha@ti.com \
--cc=peter.ujfalusi@ti.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.