From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Swapnil Jakhade <sjakhade@cadence.com>,
airlied@linux.ie, daniel@ffwll.ch, robh+dt@kernel.org,
a.hajda@samsung.com, narmstrong@baylibre.com, jonas@kwiboo.se,
jernej.skrabec@siol.net, dri-devel@lists.freedesktop.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
mparab@cadence.com, yamonkar@cadence.com, jsarha@ti.com,
nsekhar@ti.com, praneeth@ti.com
Subject: Re: [PATCH v8 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge
Date: Mon, 24 Aug 2020 05:17:29 +0300 [thread overview]
Message-ID: <20200824021729.GY6002@pendragon.ideasonboard.com> (raw)
In-Reply-To: <a2f2ff9d-0c52-12d9-23c5-bab35ef8f8f6@ti.com>
Hi Tomi,
On Fri, Aug 14, 2020 at 11:22:09AM +0300, Tomi Valkeinen wrote:
> On 11/08/2020 05:36, Laurent Pinchart wrote:
>
> >> +static int cdns_mhdp_connector_init(struct cdns_mhdp_device *mhdp)
> >> +{
> >> + u32 bus_format = MEDIA_BUS_FMT_RGB121212_1X36;
> >> + struct drm_connector *conn = &mhdp->connector;
> >> + struct drm_bridge *bridge = &mhdp->bridge;
> >> + int ret;
> >> +
> >> + if (!bridge->encoder) {
> >> + DRM_ERROR("Parent encoder object not found");
> >> + return -ENODEV;
> >> + }
> >> +
> >> + conn->polled = DRM_CONNECTOR_POLL_HPD;
> >> +
> >> + ret = drm_connector_init(bridge->dev, conn, &cdns_mhdp_conn_funcs,
> >> + DRM_MODE_CONNECTOR_DisplayPort);
> >> + if (ret) {
> >> + DRM_ERROR("Failed to initialize connector with drm\n");
> >> + return ret;
> >> + }
> >> +
> >> + drm_connector_helper_add(conn, &cdns_mhdp_conn_helper_funcs);
> >> +
> >> + ret = drm_display_info_set_bus_formats(&conn->display_info,
> >> + &bus_format, 1);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + conn->display_info.bus_flags = DRM_BUS_FLAG_DE_HIGH;
> >
> > Aren't these supposed to be retrieved from the display ? Why do we need
> > to override them here ?
>
> DE_HIGH is meant for the display controller. I think this should be in bridge->timings->input_bus_flags
>
> >> +static int cdns_mhdp_atomic_check(struct drm_bridge *bridge,
> >> + struct drm_bridge_state *bridge_state,
> >> + struct drm_crtc_state *crtc_state,
> >> + struct drm_connector_state *conn_state)
> >> +{
> >> + struct cdns_mhdp_device *mhdp = bridge_to_mhdp(bridge);
> >> + const struct drm_display_mode *mode = &crtc_state->adjusted_mode;
> >> + int ret;
> >> +
> >> + if (!mhdp->plugged)
> >> + return 0;
> >> +
> >> + mutex_lock(&mhdp->link_mutex);
> >> +
> >> + if (!mhdp->link_up) {
> >> + ret = cdns_mhdp_link_up(mhdp);
> >> + if (ret < 0)
> >> + goto err_check;
> >> + }
> >
> > atomic_check isn't supposed to access the hardware. Is there a reason
> > this is needed ?
>
> We have been going back and forth with this. The basic problem is that
> to understand which videomodes can be used, you need to do link
> training to see the bandwidth available.
>
> I'm not sure if we strictly need to do LT in atomic check, though...
> It would then pass modes that can't be used, but perhaps that's not a
> big issue.
>
> I think the main point with doing LT in certain places is to filter
> the list of video modes passed to userspace, as we can't pass the
> modes from EDID directly without filtering them based on the link
> bandwidth.
I've discussed this on #dri-devel with Daniel a week or two ago. His
advice was to drop LT from atomic check, relying on DPCD (DisplayPort
Configuration Data) instead. If LT then fails to negotiate a high-enough
bandwidth for the mode when enabling the output, the link-status
property should be set to bad, and userspace should retry. I think
you've seen the discussion, I can provide a log if needed.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2020-08-24 2:17 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-06 11:34 [PATCH v8 0/3] drm: Add support for Cadence MHDP DPI/DP bridge and J721E wrapper Swapnil Jakhade
2020-08-06 11:34 ` [PATCH v8 1/3] dt-bindings: drm/bridge: Document Cadence MHDP bridge bindings Swapnil Jakhade
2020-08-11 0:36 ` Laurent Pinchart
2020-08-14 7:13 ` Tomi Valkeinen
2020-08-06 11:34 ` [PATCH v8 2/3] drm: bridge: Add support for Cadence MHDP DPI/DP bridge Swapnil Jakhade
2020-08-07 1:15 ` kernel test robot
2020-08-07 9:38 ` Tomi Valkeinen
2020-08-11 2:36 ` Laurent Pinchart
2020-08-14 8:22 ` Tomi Valkeinen
2020-08-24 2:17 ` Laurent Pinchart [this message]
2020-08-14 9:29 ` Tomi Valkeinen
2020-08-24 2:18 ` Laurent Pinchart
2020-08-26 7:26 ` Tomi Valkeinen
2020-08-06 11:34 ` [PATCH v8 3/3] drm: bridge: cdns-mhdp: Add j721e wrapper Swapnil Jakhade
2020-08-11 2:41 ` Laurent Pinchart
2020-08-12 8:39 ` [PATCH v8 0/3] drm: Add support for Cadence MHDP DPI/DP bridge and J721E wrapper Guido Günther
2020-08-12 10:47 ` Tomi Valkeinen
2020-08-12 13:56 ` Guido Günther
2020-08-24 7:16 ` Swapnil Kashinath Jakhade
2020-08-25 7:32 ` Guido Günther
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=20200824021729.GY6002@pendragon.ideasonboard.com \
--to=laurent.pinchart@ideasonboard.com \
--cc=a.hajda@samsung.com \
--cc=airlied@linux.ie \
--cc=daniel@ffwll.ch \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=jernej.skrabec@siol.net \
--cc=jonas@kwiboo.se \
--cc=jsarha@ti.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mparab@cadence.com \
--cc=narmstrong@baylibre.com \
--cc=nsekhar@ti.com \
--cc=praneeth@ti.com \
--cc=robh+dt@kernel.org \
--cc=sjakhade@cadence.com \
--cc=tomi.valkeinen@ti.com \
--cc=yamonkar@cadence.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).