| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-id: <b2d6a68f-7bd6-216e-6b1c-dde42ceaf551@samsung.com>
Date: Mon, 15 May 2017 10:39:35 +0200
From: Andrzej Hajda <a.hajda@...sung.com>
To: Jose Abreu <Jose.Abreu@...opsys.com>,
dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org
Cc: Carlos Palminha <CARLOS.PALMINHA@...opsys.com>,
Alexey Brodkin <Alexey.Brodkin@...opsys.com>,
Ville Syrjälä <ville.syrjala@...ux.intel.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Dave Airlie <airlied@...ux.ie>,
Archit Taneja <architt@...eaurora.org>
Subject: Re: [PATCH v3 4/6] drm: Use new mode_valid() helpers in connector
probe helper
On 11.05.2017 11:06, Jose Abreu wrote:
> This changes the connector probe helper function to use the new
> encoder->mode_valid(), bridge->mode_valid() and crtc->mode_valid()
> helper callbacks to validate the modes.
>
> The new callbacks are optional so the behaviour remains the same
> if they are not implemented. If they are, then the code loops
> through all the connector's encodersXbridgesXcrtcs and calls the
> callback.
>
> If at least a valid encoderXbridgeXcrtc combination is found which
> accepts the mode then the function returns MODE_OK.
>
> Signed-off-by: Jose Abreu <joabreu@...opsys.com>
> Cc: Carlos Palminha <palminha@...opsys.com>
> Cc: Alexey Brodkin <abrodkin@...opsys.com>
> Cc: Ville Syrjälä <ville.syrjala@...ux.intel.com>
> Cc: Daniel Vetter <daniel.vetter@...ll.ch>
> Cc: Dave Airlie <airlied@...ux.ie>
> Cc: Andrzej Hajda <a.hajda@...sung.com>
> Cc: Archit Taneja <architt@...eaurora.org>
> ---
>
> Changes v2->v3:
> - Call also bridge->mode_valid (Daniel)
> Changes v1->v2:
> - Use new helpers suggested by Ville
> - Change documentation (Daniel)
>
> drivers/gpu/drm/drm_probe_helper.c | 65 ++++++++++++++++++++++++++++++++++++--
> 1 file changed, 62 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
> index f01abdc..84d660e 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -83,6 +83,61 @@
> return MODE_OK;
> }
>
> +static enum drm_mode_status
> +drm_mode_validate_connector(struct drm_connector *connector,
> + struct drm_display_mode *mode)
> +{
> + struct drm_device *dev = connector->dev;
> + uint32_t *ids = connector->encoder_ids;
> + enum drm_mode_status ret = MODE_OK;
> + unsigned int i;
> +
> + /* Step 1: Validate against connector */
> + ret = drm_connector_mode_valid(connector, mode);
> + if (ret != MODE_OK)
> + return ret;
> +
> + /* Step 2: Validate against encoders and crtcs */
> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> + struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
> + struct drm_crtc *crtc;
> +
> + if (!encoder)
> + continue;
> +
> + ret = drm_encoder_mode_valid(encoder, mode);
> + if (ret != MODE_OK) {
> + /* No point in continuing for crtc check as this encoder
> + * will not accept the mode anyway. If all encoders
> + * reject the mode then, at exit, ret will not be
> + * MODE_OK. */
> + continue;
> + }
> +
> + ret = drm_bridge_mode_valid(encoder->bridge, mode);
> + if (ret != MODE_OK) {
> + /* There is also no point in continuing for crtc check
> + * here. */
> + continue;
> + }
Maybe it is a bikeshedding, but wouldn't be better to call
drm_bridge_mode_valid from drm_encoder_mode_valid, in general call all
bridge related stuff from corresponding encoder stuff?
This is more question about role of encoder->bridge, should it be
treated as encoder's extension, or as 1st class citizen in drm?
Another concern is about order of calls, it is from sink to source, to
keep it consistent bridge should be called before encoder, am I right?
Beside this:
Reviewed-by: Andrzej Hajda <a.hajda@...sung.com>
--
Regards
Andrzej
> +
> + drm_for_each_crtc(crtc, dev) {
> + if (!drm_encoder_crtc_ok(encoder, crtc))
> + continue;
> +
> + ret = drm_crtc_mode_valid(crtc, mode);
> + if (ret == MODE_OK) {
> + /* If we get to this point there is at least
> + * one combination of encoder+crtc that works
> + * for this mode. Lets return now. */
> + return ret;
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
> {
> struct drm_cmdline_mode *cmdline_mode;
> @@ -322,7 +377,11 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
> * - drm_mode_validate_flag() checks the modes against basic connector
> * capabilities (interlace_allowed,doublescan_allowed,stereo_allowed)
> * - the optional &drm_connector_helper_funcs.mode_valid helper can perform
> - * driver and/or hardware specific checks
> + * driver and/or sink specific checks
> + * - the optional &drm_crtc_helper_funcs.mode_valid,
> + * &drm_bridge_funcs.mode_valid and &drm_encoder_helper_funcs.mode_valid
> + * helpers can perform driver and/or source specific checks which are also
> + * enforced by the modeset/atomic helpers
> *
> * 5. Any mode whose status is not OK is pruned from the connector's modes list,
> * accompanied by a debug message indicating the reason for the mode's
> @@ -466,8 +525,8 @@ int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
> if (mode->status == MODE_OK)
> mode->status = drm_mode_validate_flag(mode, mode_flags);
>
> - if (mode->status == MODE_OK && connector_funcs->mode_valid)
> - mode->status = connector_funcs->mode_valid(connector,
> + if (mode->status == MODE_OK)
> + mode->status = drm_mode_validate_connector(connector,
> mode);
> }
>
Powered by blists - more mailing lists