linux/drivers/gpu/drm/drm_probe_helper.c

1150 lines
35 KiB
C
Raw Permalink Normal View History

/*
* Copyright (c) 2006-2008 Intel Corporation
* Copyright (c) 2007 Dave Airlie <airlied@linux.ie>
*
* DRM core CRTC related functions
*
* Permission to use, copy, modify, distribute, and sell this software and its
* documentation for any purpose is hereby granted without fee, provided that
* the above copyright notice appear in all copies and that both that copyright
* notice and this permission notice appear in supporting documentation, and
* that the name of the copyright holders not be used in advertising or
* publicity pertaining to distribution of the software without specific,
* written prior permission. The copyright holders make no representations
* about the suitability of this software for any purpose. It is provided "as
* is" without express or implied warranty.
*
* THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE,
* INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO
* EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR
* CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
* DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
* TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE
* OF THIS SOFTWARE.
*
* Authors:
* Keith Packard
* Eric Anholt <eric@anholt.net>
* Dave Airlie <airlied@linux.ie>
* Jesse Barnes <jesse.barnes@intel.com>
*/
#include <linux/export.h>
#include <linux/moduleparam.h>
#include <drm/drm_bridge.h>
#include <drm/drm_client.h>
#include <drm/drm_crtc.h>
#include <drm/drm_edid.h>
#include <drm/drm_fb_helper.h>
#include <drm/drm_fourcc.h>
#include <drm/drm_modeset_helper_vtables.h>
#include <drm/drm_print.h>
drm: Split out drm_probe_helper.h Having the probe helper stuff (which pretty much everyone needs) in the drm_crtc_helper.h file (which atomic drivers should never need) is confusing. Split them out. To make sure I actually achieved the goal here I went through all drivers. And indeed, all atomic drivers are now free of drm_crtc_helper.h includes. v2: Make it compile. There was so much compile fail on arm drivers that I figured I'll better not include any of the acks on v1. v3: Massive rebase because i915 has lost a lot of drmP.h includes, but not all: Through drm_crtc_helper.h > drm_modeset_helper.h -> drmP.h there was still one, which this patch largely removes. Which means rolling out lots more includes all over. This will also conflict with ongoing drmP.h cleanup by others I expect. v3: Rebase on top of atomic bochs. v4: Review from Laurent for bridge/rcar/omap/shmob/core bits: - (re)move some of the added includes, use the better include files in other places (all suggested from Laurent adopted unchanged). - sort alphabetically v5: Actually try to sort them, and while at it, sort all the ones I touch. v6: Rebase onto i915 changes. v7: Rebase once more. Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Benjamin Gaignard <benjamin.gaignard@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com> Acked-by: CK Hu <ck.hu@mediatek.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Sam Ravnborg <sam@ravnborg.org> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: linux-arm-kernel@lists.infradead.org Cc: virtualization@lists.linux-foundation.org Cc: etnaviv@lists.freedesktop.org Cc: linux-samsung-soc@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: linux-mediatek@lists.infradead.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: nouveau@lists.freedesktop.org Cc: spice-devel@lists.freedesktop.org Cc: amd-gfx@lists.freedesktop.org Cc: linux-renesas-soc@vger.kernel.org Cc: linux-rockchip@lists.infradead.org Cc: linux-stm32@st-md-mailman.stormreply.com Cc: linux-tegra@vger.kernel.org Cc: xen-devel@lists.xen.org Link: https://patchwork.freedesktop.org/patch/msgid/20190117210334.13234-1-daniel.vetter@ffwll.ch
2019-01-17 21:03:34 +00:00
#include <drm/drm_probe_helper.h>
#include <drm/drm_sysfs.h>
#include "drm_crtc_helper_internal.h"
/**
* DOC: output probing helper overview
*
* This library provides some helper code for output probing. It provides an
* implementation of the core &drm_connector_funcs.fill_modes interface with
* drm_helper_probe_single_connector_modes().
*
* It also provides support for polling connectors with a work item and for
* generic hotplug interrupt handling where the driver doesn't or cannot keep
* track of a per-connector hpd interrupt.
*
* This helper library can be used independently of the modeset helper library.
* Drivers can also overwrite different parts e.g. use their own hotplug
* handling code to avoid probing unrelated outputs.
*
* The probe helpers share the function table structures with other display
* helper libraries. See &struct drm_connector_helper_funcs for the details.
*/
static bool drm_kms_helper_poll = true;
module_param_named(poll, drm_kms_helper_poll, bool, 0600);
static enum drm_mode_status
drm_mode_validate_flag(const struct drm_display_mode *mode,
int flags)
{
if ((mode->flags & DRM_MODE_FLAG_INTERLACE) &&
!(flags & DRM_MODE_FLAG_INTERLACE))
return MODE_NO_INTERLACE;
if ((mode->flags & DRM_MODE_FLAG_DBLSCAN) &&
!(flags & DRM_MODE_FLAG_DBLSCAN))
return MODE_NO_DBLESCAN;
if ((mode->flags & DRM_MODE_FLAG_3D_MASK) &&
!(flags & DRM_MODE_FLAG_3D_MASK))
return MODE_NO_STEREO;
return MODE_OK;
}
static int
drm_mode_validate_pipeline(struct drm_display_mode *mode,
struct drm_connector *connector,
struct drm_modeset_acquire_ctx *ctx,
enum drm_mode_status *status)
{
struct drm_device *dev = connector->dev;
struct drm_encoder *encoder;
int ret;
/* Step 1: Validate against connector */
ret = drm_connector_mode_valid(connector, mode, ctx, status);
if (ret || *status != MODE_OK)
return ret;
/* Step 2: Validate against encoders and crtcs */
drm_connector_for_each_possible_encoder(connector, encoder) {
struct drm_bridge *bridge;
struct drm_crtc *crtc;
*status = drm_encoder_mode_valid(encoder, mode);
if (*status != 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;
}
bridge = drm_bridge_chain_get_first_bridge(encoder);
Merge tag 'drm-intel-next-2020-07-15' of git://anongit.freedesktop.org/drm/drm-intel into drm-next drm/i915 features for v5.9, batch #2 Highlights: - Very early DG1 enabling (Abdiel, Lucas, Anusha) Gem/GT: - Fix spinlock recursion on signaling a signaled request (Chris) - Perf: Use GTT when saving/restoring engine GPR (Umesh Nerlige Ramappa) - SSEU refactoring, debugfs move under gt/ (Daniele, Venkata Sandeep Dhanalakota) - Various GT refactoring and cleanup, preparation for future changes (Daniele) - Adjust HuC state accordingly after GuC fetch error (Michał Winiarski) - UC debugfs updates (Michał Winiarski) - Only revoke the GGTT mmappings on aperture detiling changes (Chris) - Only revoke mmap handlers if active (Chris) - Split the context's obj:vma lut into its own mutex (Chris) - Various memory, mmap and performance optimisations (Chris) - Improve system stability in case of false CS events (Chris) - Various refactorings and cleanup (Chris) - Always reset the engine on execlist failures (Chris) - Trace placement of timeline HWSP (Chris) - Update dma-attributes for our sg DMA (Chris) Display: - TGL CDCLK workaround tweaks to unbreak 8K display support (Stanislav) - A number of FBC fixes, along with i865 FBC enabling (Ville) - Validate MST modes against PBN limits (Lyude, Shawn Lee) - Do not access non-existing swizzle registers (Lucas) - Revert GEN11+ HBR3 rate fix that caused issues on TGL (Matt Atwood) - Update TGL+ combo phy initialization to match spec update (José) - Fix HDCP Content Protection property state machine (Anshuman) - Fix HDCP revoked keys handling (Ram) - Improve DDI BUF status checks and waits (Manasi) - Various SDVO+HDMI+DVI fixes around colorimetry, clocking, pixel repeat etc. (Ville) - DP voltage swing function refactoring (José) - WARN if max vswing/pre-emphasis violates the DP spec (Ville) Other: - Add new EHL PCI IDs (José) - Unify struct intel_digital_port variable naming (Lucas) - Various taint updates to aid debugging and improve CI (Michał Winiarski) - Straggler conversions to new mmio register accessors (Daniele) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/87a70029vz.fsf@intel.com
2020-07-30 19:25:42 +00:00
*status = drm_bridge_chain_mode_valid(bridge,
&connector->display_info,
mode);
if (*status != MODE_OK) {
/* There is also no point in continuing for crtc check
* here. */
continue;
}
drm_for_each_crtc(crtc, dev) {
if (!drm_encoder_crtc_ok(encoder, crtc))
continue;
*status = drm_crtc_mode_valid(crtc, mode);
if (*status == 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 0;
}
}
}
return 0;
}
drm: Perform cmdline mode parsing during connector initialisation i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter). However, that command line mode is first parsed by drm_fb_helper_initial_config() which is called after i915.ko's custom initial_config() as a fallback method. So in order for us to honour it, we need to move the cmdline parser earlier. If we perform the connector cmdline parsing as soon as we initialise the connector, that cmdline mode and forced status is then available even if the fbdev helper is not compiled in or never called. We also then expose the cmdline user mode in the connector mode lists. v2: Rebase after connector->name upheaval. v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely simplifies things while at that. v4: Fix checkpatch. v5: Select FB_CMDLINE to adapt to the changed fbdev patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-08-06 08:08:32 +00:00
static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
{
drm: Only create a cmdline mode if no probed modes match The intention of using video=<connector>:<mode> is primarily to select the user's preferred resolution at startup. Currently we always create a new mode irrespective of whether the monitor has a native mode at the desired resolution. This has the issue that we may then select the fake mode rather the native mode during fb_helper->inital_config() and so if the fake mode is invalid we then end up with a loss of signal. Oops. This invalid fake mode would also be exported to userspace, who potentially may make the same mistake. To avoid this issue, we filter out the added command line mode if we detect the desired resolution (and clock if specified) amongst the probed modes. This fixes the immediate problem of adding a duplicate mode, but perhaps more generically we should avoid adding a GTF mode if the monitor has an EDID that is not GTF-compatible, or similarly for CVT. Was meant to fix a regression from commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Aug 6 10:08:32 2014 +0200 drm: Perform cmdline mode parsing during connector initialisation but Radek explained that the original bug is no longer reproducible on latest kernels. v2: Explicitly delete our earlier cmdline mode v3: Mode pruning should now be sufficient to delete stale cmdline modes v4: Compute the vrefresh for the probed mode Reported-by: Radek Dostál <rd@radekdostal.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Radek Dostál <rd@radekdostal.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Drop cc: stable since no longer a pressing bugfix, just nice-to-have.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464774651-20376-1-git-send-email-chris@chris-wilson.co.uk
2016-06-01 09:50:51 +00:00
struct drm_cmdline_mode *cmdline_mode;
drm: Perform cmdline mode parsing during connector initialisation i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter). However, that command line mode is first parsed by drm_fb_helper_initial_config() which is called after i915.ko's custom initial_config() as a fallback method. So in order for us to honour it, we need to move the cmdline parser earlier. If we perform the connector cmdline parsing as soon as we initialise the connector, that cmdline mode and forced status is then available even if the fbdev helper is not compiled in or never called. We also then expose the cmdline user mode in the connector mode lists. v2: Rebase after connector->name upheaval. v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely simplifies things while at that. v4: Fix checkpatch. v5: Select FB_CMDLINE to adapt to the changed fbdev patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-08-06 08:08:32 +00:00
struct drm_display_mode *mode;
drm: Only create a cmdline mode if no probed modes match The intention of using video=<connector>:<mode> is primarily to select the user's preferred resolution at startup. Currently we always create a new mode irrespective of whether the monitor has a native mode at the desired resolution. This has the issue that we may then select the fake mode rather the native mode during fb_helper->inital_config() and so if the fake mode is invalid we then end up with a loss of signal. Oops. This invalid fake mode would also be exported to userspace, who potentially may make the same mistake. To avoid this issue, we filter out the added command line mode if we detect the desired resolution (and clock if specified) amongst the probed modes. This fixes the immediate problem of adding a duplicate mode, but perhaps more generically we should avoid adding a GTF mode if the monitor has an EDID that is not GTF-compatible, or similarly for CVT. Was meant to fix a regression from commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Aug 6 10:08:32 2014 +0200 drm: Perform cmdline mode parsing during connector initialisation but Radek explained that the original bug is no longer reproducible on latest kernels. v2: Explicitly delete our earlier cmdline mode v3: Mode pruning should now be sufficient to delete stale cmdline modes v4: Compute the vrefresh for the probed mode Reported-by: Radek Dostál <rd@radekdostal.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Radek Dostál <rd@radekdostal.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Drop cc: stable since no longer a pressing bugfix, just nice-to-have.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464774651-20376-1-git-send-email-chris@chris-wilson.co.uk
2016-06-01 09:50:51 +00:00
cmdline_mode = &connector->cmdline_mode;
if (!cmdline_mode->specified)
drm: Perform cmdline mode parsing during connector initialisation i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter). However, that command line mode is first parsed by drm_fb_helper_initial_config() which is called after i915.ko's custom initial_config() as a fallback method. So in order for us to honour it, we need to move the cmdline parser earlier. If we perform the connector cmdline parsing as soon as we initialise the connector, that cmdline mode and forced status is then available even if the fbdev helper is not compiled in or never called. We also then expose the cmdline user mode in the connector mode lists. v2: Rebase after connector->name upheaval. v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely simplifies things while at that. v4: Fix checkpatch. v5: Select FB_CMDLINE to adapt to the changed fbdev patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-08-06 08:08:32 +00:00
return 0;
drm: Only create a cmdline mode if no probed modes match The intention of using video=<connector>:<mode> is primarily to select the user's preferred resolution at startup. Currently we always create a new mode irrespective of whether the monitor has a native mode at the desired resolution. This has the issue that we may then select the fake mode rather the native mode during fb_helper->inital_config() and so if the fake mode is invalid we then end up with a loss of signal. Oops. This invalid fake mode would also be exported to userspace, who potentially may make the same mistake. To avoid this issue, we filter out the added command line mode if we detect the desired resolution (and clock if specified) amongst the probed modes. This fixes the immediate problem of adding a duplicate mode, but perhaps more generically we should avoid adding a GTF mode if the monitor has an EDID that is not GTF-compatible, or similarly for CVT. Was meant to fix a regression from commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Aug 6 10:08:32 2014 +0200 drm: Perform cmdline mode parsing during connector initialisation but Radek explained that the original bug is no longer reproducible on latest kernels. v2: Explicitly delete our earlier cmdline mode v3: Mode pruning should now be sufficient to delete stale cmdline modes v4: Compute the vrefresh for the probed mode Reported-by: Radek Dostál <rd@radekdostal.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Radek Dostál <rd@radekdostal.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Drop cc: stable since no longer a pressing bugfix, just nice-to-have.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464774651-20376-1-git-send-email-chris@chris-wilson.co.uk
2016-06-01 09:50:51 +00:00
/* Only add a GTF mode if we find no matching probed modes */
list_for_each_entry(mode, &connector->probed_modes, head) {
if (mode->hdisplay != cmdline_mode->xres ||
mode->vdisplay != cmdline_mode->yres)
continue;
if (cmdline_mode->refresh_specified) {
/* The probed mode's vrefresh is set until later */
if (drm_mode_vrefresh(mode) != cmdline_mode->refresh)
continue;
}
/* Mark the matching mode as being preferred by the user */
mode->type |= DRM_MODE_TYPE_USERDEF;
drm: Only create a cmdline mode if no probed modes match The intention of using video=<connector>:<mode> is primarily to select the user's preferred resolution at startup. Currently we always create a new mode irrespective of whether the monitor has a native mode at the desired resolution. This has the issue that we may then select the fake mode rather the native mode during fb_helper->inital_config() and so if the fake mode is invalid we then end up with a loss of signal. Oops. This invalid fake mode would also be exported to userspace, who potentially may make the same mistake. To avoid this issue, we filter out the added command line mode if we detect the desired resolution (and clock if specified) amongst the probed modes. This fixes the immediate problem of adding a duplicate mode, but perhaps more generically we should avoid adding a GTF mode if the monitor has an EDID that is not GTF-compatible, or similarly for CVT. Was meant to fix a regression from commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Aug 6 10:08:32 2014 +0200 drm: Perform cmdline mode parsing during connector initialisation but Radek explained that the original bug is no longer reproducible on latest kernels. v2: Explicitly delete our earlier cmdline mode v3: Mode pruning should now be sufficient to delete stale cmdline modes v4: Compute the vrefresh for the probed mode Reported-by: Radek Dostál <rd@radekdostal.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Radek Dostál <rd@radekdostal.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Drop cc: stable since no longer a pressing bugfix, just nice-to-have.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464774651-20376-1-git-send-email-chris@chris-wilson.co.uk
2016-06-01 09:50:51 +00:00
return 0;
}
drm: Perform cmdline mode parsing during connector initialisation i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter). However, that command line mode is first parsed by drm_fb_helper_initial_config() which is called after i915.ko's custom initial_config() as a fallback method. So in order for us to honour it, we need to move the cmdline parser earlier. If we perform the connector cmdline parsing as soon as we initialise the connector, that cmdline mode and forced status is then available even if the fbdev helper is not compiled in or never called. We also then expose the cmdline user mode in the connector mode lists. v2: Rebase after connector->name upheaval. v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely simplifies things while at that. v4: Fix checkpatch. v5: Select FB_CMDLINE to adapt to the changed fbdev patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-08-06 08:08:32 +00:00
mode = drm_mode_create_from_cmdline_mode(connector->dev,
drm: Only create a cmdline mode if no probed modes match The intention of using video=<connector>:<mode> is primarily to select the user's preferred resolution at startup. Currently we always create a new mode irrespective of whether the monitor has a native mode at the desired resolution. This has the issue that we may then select the fake mode rather the native mode during fb_helper->inital_config() and so if the fake mode is invalid we then end up with a loss of signal. Oops. This invalid fake mode would also be exported to userspace, who potentially may make the same mistake. To avoid this issue, we filter out the added command line mode if we detect the desired resolution (and clock if specified) amongst the probed modes. This fixes the immediate problem of adding a duplicate mode, but perhaps more generically we should avoid adding a GTF mode if the monitor has an EDID that is not GTF-compatible, or similarly for CVT. Was meant to fix a regression from commit eaf99c749d43ae74ac7ffece5512f3c73f01dfd2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Wed Aug 6 10:08:32 2014 +0200 drm: Perform cmdline mode parsing during connector initialisation but Radek explained that the original bug is no longer reproducible on latest kernels. v2: Explicitly delete our earlier cmdline mode v3: Mode pruning should now be sufficient to delete stale cmdline modes v4: Compute the vrefresh for the probed mode Reported-by: Radek Dostál <rd@radekdostal.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Radek Dostál <rd@radekdostal.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Drop cc: stable since no longer a pressing bugfix, just nice-to-have.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1464774651-20376-1-git-send-email-chris@chris-wilson.co.uk
2016-06-01 09:50:51 +00:00
cmdline_mode);
drm: Perform cmdline mode parsing during connector initialisation i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter). However, that command line mode is first parsed by drm_fb_helper_initial_config() which is called after i915.ko's custom initial_config() as a fallback method. So in order for us to honour it, we need to move the cmdline parser earlier. If we perform the connector cmdline parsing as soon as we initialise the connector, that cmdline mode and forced status is then available even if the fbdev helper is not compiled in or never called. We also then expose the cmdline user mode in the connector mode lists. v2: Rebase after connector->name upheaval. v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely simplifies things while at that. v4: Fix checkpatch. v5: Select FB_CMDLINE to adapt to the changed fbdev patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-08-06 08:08:32 +00:00
if (mode == NULL)
return 0;
drm_mode_probed_add(connector, mode);
return 1;
}
enum drm_mode_status drm_crtc_mode_valid(struct drm_crtc *crtc,
const struct drm_display_mode *mode)
{
const struct drm_crtc_helper_funcs *crtc_funcs = crtc->helper_private;
if (!crtc_funcs || !crtc_funcs->mode_valid)
return MODE_OK;
return crtc_funcs->mode_valid(crtc, mode);
}
enum drm_mode_status drm_encoder_mode_valid(struct drm_encoder *encoder,
const struct drm_display_mode *mode)
{
const struct drm_encoder_helper_funcs *encoder_funcs =
encoder->helper_private;
if (!encoder_funcs || !encoder_funcs->mode_valid)
return MODE_OK;
return encoder_funcs->mode_valid(encoder, mode);
}
int
drm_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode,
struct drm_modeset_acquire_ctx *ctx,
enum drm_mode_status *status)
{
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
int ret = 0;
if (!connector_funcs)
*status = MODE_OK;
else if (connector_funcs->mode_valid_ctx)
ret = connector_funcs->mode_valid_ctx(connector, mode, ctx,
status);
else if (connector_funcs->mode_valid)
*status = connector_funcs->mode_valid(connector, mode);
else
*status = MODE_OK;
return ret;
}
#define DRM_OUTPUT_POLL_PERIOD (10*HZ)
/**
* drm_kms_helper_poll_enable - re-enable output polling.
* @dev: drm_device
*
* This function re-enables the output polling work, after it has been
* temporarily disabled using drm_kms_helper_poll_disable(), for example over
* suspend/resume.
*
* Drivers can call this helper from their device resume implementation. It is
* not an error to call this even when output polling isn't enabled.
*
* Note that calls to enable and disable polling must be strictly ordered, which
* is automatically the case when they're only call from suspend/resume
* callbacks.
*/
void drm_kms_helper_poll_enable(struct drm_device *dev)
{
bool poll = false;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
2016-08-31 11:09:05 +00:00
unsigned long delay = DRM_OUTPUT_POLL_PERIOD;
if (!dev->mode_config.poll_enabled || !drm_kms_helper_poll)
return;
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
if (connector->polled & (DRM_CONNECTOR_POLL_CONNECT |
DRM_CONNECTOR_POLL_DISCONNECT))
poll = true;
}
drm_connector_list_iter_end(&conn_iter);
2016-08-31 11:09:05 +00:00
if (dev->mode_config.delayed_event) {
/*
* FIXME:
*
* Use short (1s) delay to handle the initial delayed event.
* This delay should not be needed, but Optimus/nouveau will
* fail in a mysterious way if the delayed event is handled as
* soon as possible like it is done in
* drm_helper_probe_single_connector_modes() in case the poll
* was enabled before.
*/
2016-08-31 11:09:05 +00:00
poll = true;
delay = HZ;
2016-08-31 11:09:05 +00:00
}
if (poll)
2016-08-31 11:09:05 +00:00
schedule_delayed_work(&dev->mode_config.output_poll_work, delay);
}
EXPORT_SYMBOL(drm_kms_helper_poll_enable);
static enum drm_connector_status
drm_helper_probe_detect_ctx(struct drm_connector *connector, bool force)
{
const struct drm_connector_helper_funcs *funcs = connector->helper_private;
struct drm_modeset_acquire_ctx ctx;
int ret;
drm_modeset_acquire_init(&ctx, 0);
retry:
ret = drm_modeset_lock(&connector->dev->mode_config.connection_mutex, &ctx);
if (!ret) {
if (funcs->detect_ctx)
ret = funcs->detect_ctx(connector, &ctx, force);
else if (connector->funcs->detect)
ret = connector->funcs->detect(connector, force);
else
ret = connector_status_connected;
}
if (ret == -EDEADLK) {
drm_modeset_backoff(&ctx);
goto retry;
}
if (WARN_ON(ret < 0))
ret = connector_status_unknown;
if (ret != connector->status)
connector->epoch_counter += 1;
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
return ret;
}
/**
* drm_helper_probe_detect - probe connector status
* @connector: connector to probe
* @ctx: acquire_ctx, or NULL to let this function handle locking.
* @force: Whether destructive probe operations should be performed.
*
* This function calls the detect callbacks of the connector.
* This function returns &drm_connector_status, or
* if @ctx is set, it might also return -EDEADLK.
*/
int
drm_helper_probe_detect(struct drm_connector *connector,
struct drm_modeset_acquire_ctx *ctx,
bool force)
{
const struct drm_connector_helper_funcs *funcs = connector->helper_private;
struct drm_device *dev = connector->dev;
int ret;
if (!ctx)
return drm_helper_probe_detect_ctx(connector, force);
ret = drm_modeset_lock(&dev->mode_config.connection_mutex, ctx);
if (ret)
return ret;
if (funcs->detect_ctx)
ret = funcs->detect_ctx(connector, ctx, force);
else if (connector->funcs->detect)
ret = connector->funcs->detect(connector, force);
else
ret = connector_status_connected;
if (ret != connector->status)
connector->epoch_counter += 1;
return ret;
}
EXPORT_SYMBOL(drm_helper_probe_detect);
static int drm_helper_probe_get_modes(struct drm_connector *connector)
{
const struct drm_connector_helper_funcs *connector_funcs =
connector->helper_private;
int count;
count = connector_funcs->get_modes(connector);
/*
* Fallback for when DDC probe failed in drm_get_edid() and thus skipped
* override/firmware EDID.
*/
if (count == 0 && connector->status == connector_status_connected)
count = drm_add_override_edid_modes(connector);
return count;
}
static int __drm_helper_update_and_validate(struct drm_connector *connector,
uint32_t maxX, uint32_t maxY,
struct drm_modeset_acquire_ctx *ctx)
{
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode;
int mode_flags = 0;
int ret;
drm_connector_list_update(connector);
if (connector->interlace_allowed)
mode_flags |= DRM_MODE_FLAG_INTERLACE;
if (connector->doublescan_allowed)
mode_flags |= DRM_MODE_FLAG_DBLSCAN;
if (connector->stereo_allowed)
mode_flags |= DRM_MODE_FLAG_3D_MASK;
list_for_each_entry(mode, &connector->modes, head) {
if (mode->status != MODE_OK)
continue;
mode->status = drm_mode_validate_driver(dev, mode);
if (mode->status != MODE_OK)
continue;
mode->status = drm_mode_validate_size(mode, maxX, maxY);
if (mode->status != MODE_OK)
continue;
mode->status = drm_mode_validate_flag(mode, mode_flags);
if (mode->status != MODE_OK)
continue;
ret = drm_mode_validate_pipeline(mode, connector, ctx,
&mode->status);
if (ret) {
drm_dbg_kms(dev,
"drm_mode_validate_pipeline failed: %d\n",
ret);
if (drm_WARN_ON_ONCE(dev, ret != -EDEADLK))
mode->status = MODE_ERROR;
else
return -EDEADLK;
}
if (mode->status != MODE_OK)
continue;
mode->status = drm_mode_validate_ycbcr420(mode, connector);
}
return 0;
}
/**
* drm_helper_probe_single_connector_modes - get complete set of display modes
* @connector: connector to probe
* @maxX: max width for modes
* @maxY: max height for modes
*
* Based on the helper callbacks implemented by @connector in struct
* &drm_connector_helper_funcs try to detect all valid modes. Modes will first
* be added to the connector's probed_modes list, then culled (based on validity
* and the @maxX, @maxY parameters) and put into the normal modes list.
*
* Intended to be used as a generic implementation of the
* &drm_connector_funcs.fill_modes() vfunc for drivers that use the CRTC helpers
* for output mode filtering and detection.
*
* The basic procedure is as follows
*
* 1. All modes currently on the connector's modes list are marked as stale
*
* 2. New modes are added to the connector's probed_modes list with
* drm_mode_probed_add(). New modes start their life with status as OK.
* Modes are added from a single source using the following priority order.
*
* - &drm_connector_helper_funcs.get_modes vfunc
* - if the connector status is connector_status_connected, standard
* VESA DMT modes up to 1024x768 are automatically added
* (drm_add_modes_noedid())
*
* Finally modes specified via the kernel command line (video=...) are
* added in addition to what the earlier probes produced
* (drm_helper_probe_add_cmdline_mode()). These modes are generated
* using the VESA GTF/CVT formulas.
*
* 3. Modes are moved from the probed_modes list to the modes list. Potential
* duplicates are merged together (see drm_connector_list_update()).
* After this step the probed_modes list will be empty again.
*
* 4. Any non-stale mode on the modes list then undergoes validation
*
* - drm_mode_validate_basic() performs basic sanity checks
* - drm_mode_validate_size() filters out modes larger than @maxX and @maxY
* (if specified)
* - 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 or
* &drm_connector_helper_funcs.mode_valid_ctx helpers can perform 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
* rejection (see drm_mode_prune_invalid()).
*
* Returns:
* The number of modes found on @connector.
*/
int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
uint32_t maxX, uint32_t maxY)
{
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode;
int count = 0, ret;
enum drm_connector_status old_status;
struct drm_modeset_acquire_ctx ctx;
WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
drm_modeset_acquire_init(&ctx, 0);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id,
connector->name);
retry:
ret = drm_modeset_lock(&dev->mode_config.connection_mutex, &ctx);
if (ret == -EDEADLK) {
drm_modeset_backoff(&ctx);
goto retry;
} else
WARN_ON(ret < 0);
/* set all old modes to the stale state */
list_for_each_entry(mode, &connector->modes, head)
mode->status = MODE_STALE;
old_status = connector->status;
if (connector->force) {
if (connector->force == DRM_FORCE_ON ||
connector->force == DRM_FORCE_ON_DIGITAL)
connector->status = connector_status_connected;
else
connector->status = connector_status_disconnected;
if (connector->funcs->force)
connector->funcs->force(connector);
} else {
ret = drm_helper_probe_detect(connector, &ctx, true);
if (ret == -EDEADLK) {
drm_modeset_backoff(&ctx);
goto retry;
} else if (WARN(ret < 0, "Invalid return value %i for connector detection\n", ret))
ret = connector_status_unknown;
connector->status = ret;
}
/*
* Normally either the driver's hpd code or the poll loop should
* pick up any changes and fire the hotplug event. But if
* userspace sneaks in a probe, we might miss a change. Hence
* check here, and if anything changed start the hotplug code.
*/
if (old_status != connector->status) {
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] status updated from %s to %s\n",
connector->base.id,
connector->name,
drm_get_connector_status_name(old_status),
drm_get_connector_status_name(connector->status));
/*
* The hotplug event code might call into the fb
* helpers, and so expects that we do not hold any
* locks. Fire up the poll struct instead, it will
* disable itself again.
*/
dev->mode_config.delayed_event = true;
if (dev->mode_config.poll_enabled)
schedule_delayed_work(&dev->mode_config.output_poll_work,
0);
}
/* Re-enable polling in case the global poll config changed. */
if (drm_kms_helper_poll != dev->mode_config.poll_running)
drm_kms_helper_poll_enable(dev);
dev->mode_config.poll_running = drm_kms_helper_poll;
if (connector->status == connector_status_disconnected) {
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] disconnected\n",
connector->base.id, connector->name);
drm_connector_update_edid_property(connector, NULL);
drm/probe-helper: For DP, add 640x480 if all other modes are bad As per Displayport spec section 5.2.1.2 ("Video Timing Format") says that all detachable sinks shall support 640x480 @60Hz as a fail safe mode. A DP compliance test expected us to utilize the above fact when all modes it presented to the DP source were not achievable. It presented only modes that would be achievable with more lanes and/or higher speeds than we had available and expected that when we couldn't do that then we'd fall back to 640x480 even though it didn't advertise this size. In order to pass the compliance test (and also support any users who might fall into a similar situation with their display), we need to add 640x480 into the list of modes. However, we don't want to add 640x480 all the time. Despite the fact that the DP spec says all sinks _shall support_ 640x480, they're not guaranteed to support it _well_. Continuing to read the spec you can see that the display is not required to really treat 640x480 equal to all the other modes. It doesn't need to scale or anything--just display the pixels somehow for failsafe purposes. It should also be noted that it's not hard to find a display hooked up via DisplayPort that _doesn't_ support 640x480 at all. The HP ZR30w screen I'm sitting in front of has a native DP port and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI display via a DP to HDMI adapter and that screen definitely doesn't support 640x480. As a compromise solution, let's only add the 640x480 mode if: * We're on DP. * All other modes have been pruned. This acknowledges that 640x480 might not be the best mode to use but, since sinks are _supposed_ to support it, we will at least fall back to it if there's nothing else. Note that we _don't_ add higher resolution modes like 1024x768 in this case. We only add those modes for a failed EDID read where we have no idea what's going on. In the case where we've pruned all modes then instead we only want 640x480 which is the only defined "Fail Safe" resolution. This patch originated in response to Kuogee Hsieh's patch [1]. [1] https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220511155749.v3.2.I4ac7f55aa446699f8c200a23c10463256f6f439f@changeid
2022-05-11 22:58:08 +00:00
drm_mode_prune_invalid(dev, &connector->modes, false);
goto exit;
}
count = drm_helper_probe_get_modes(connector);
drm: add fallback override/firmware EDID modes workaround We've moved the override and firmware EDID (simply "override EDID" from now on) handling to the low level drm_do_get_edid() function in order to transparently use the override throughout the stack. The idea is that you get the override EDID via the ->get_modes() hook. Unfortunately, there are scenarios where the DDC probe in drm_get_edid() called via ->get_modes() fails, although the preceding ->detect() succeeds. In the case reported by Paul Wise, the ->detect() hook, intel_crt_detect(), relies on hotplug detect, bypassing the DDC. In the case reported by Ilpo Järvinen, there is no ->detect() hook, which is interpreted as connected. The subsequent DDC probe reached via ->get_modes() fails, and we don't even look at the override EDID, resulting in no modes being added. Because drm_get_edid() is used via ->detect() all over the place, we can't trivially remove the DDC probe, as it leads to override EDID effectively meaning connector forcing. The goal is that connector forcing and override EDID remain orthogonal. Generally, the underlying problem here is the conflation of ->detect() and ->get_modes() via drm_get_edid(). The former should just detect, and the latter should just get the modes, typically via reading the EDID. As long as drm_get_edid() is used in ->detect(), it needs to retain the DDC probe. Or such users need to have a separate DDC probe step first. The EDID caching between ->detect() and ->get_modes() done by some drivers is a further complication that prevents us from making drm_do_get_edid() adapt to the two cases. Work around the regression by falling back to a separate attempt at getting the override EDID at drm_helper_probe_single_connector_modes() level. With a working DDC and override EDID, it'll never be called; the override EDID will come via ->get_modes(). There will still be a failing DDC probe attempt in the cases that require the fallback. v2: - Call drm_connector_update_edid_property (Paul) - Update commit message about EDID caching (Daniel) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107583 Reported-by: Paul Wise <pabs3@bonedaddy.net> Cc: Paul Wise <pabs3@bonedaddy.net> References: http://mid.mail-archive.com/alpine.DEB.2.20.1905262211270.24390@whs-18.cs.helsinki.fi Reported-by: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi> Cc: Ilpo Järvinen <ilpo.jarvinen@cs.helsinki.fi> Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> References: 15f080f08d48 ("drm/edid: respect connector force for drm_get_edid ddc probe") Fixes: 53fd40a90f3c ("drm: handle override and firmware EDID at drm_do_get_edid() level") Cc: <stable@vger.kernel.org> # v4.15+ 56a2b7f2a39a drm/edid: abstract override/firmware EDID retrieval Cc: <stable@vger.kernel.org> # v4.15+ Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Harish Chegondi <harish.chegondi@intel.com> Tested-by: Paul Wise <pabs3@bonedaddy.net> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190610093054.28445-1-jani.nikula@intel.com
2019-06-10 09:30:54 +00:00
if (count == 0 && (connector->status == connector_status_connected ||
drm/probe-helper: Default to 640x480 if no EDID on DP If we're unable to read the EDID for a display because it's corrupt / bogus / invalid then we'll add a set of standard modes for the display. Since we have no true information about the connected display, these modes are essentially guesses but better than nothing. At the moment, none of the modes returned is marked as preferred, but the modes are sorted such that the higher resolution modes are listed first. When userspace sees these modes presented by the kernel it needs to figure out which one to pick. At least one userspace, ChromeOS [1] seems to use the rules (which seem pretty reasonable): 1. Try to pick the first mode marked as preferred. 2. Try to pick the mode which matches the first detailed timing descriptor in the EDID. 3. If no modes were marked as preferred then pick the first mode. Unfortunately, userspace's rules combined with what the kernel is doing causes us to fail section 4.2.2.6 (EDID Corruption Detection) of the DP 1.4a Link CTS. That test case says that, while it's OK to allow some implementation-specific fall-back modes if the EDID is bad that userspace should _default_ to 640x480. Let's fix this by marking 640x480 as default for DP in the no-EDID case. NOTES: - In the discussion around v3 of this patch [2] there was talk about solving this in userspace and I even implemented a patch that would have solved this for ChromeOS, but then the discussion turned back to solving this in the kernel. - Also in the discussion of v3 [2] it was requested to limit this change to just DP since folks were worried that it would break some subtle corner case on VGA or HDMI. [1] https://source.chromium.org/chromium/chromium/src/+/a051f741d0a15caff2251301efe081c30e0f4a96:ui/ozone/platform/drm/common/drm_util.cc;l=488 [2] https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112302.v4.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
2022-06-01 18:23:24 +00:00
connector->status == connector_status_unknown)) {
count = drm_add_modes_noedid(connector, 1024, 768);
drm/probe-helper: Default to 640x480 if no EDID on DP If we're unable to read the EDID for a display because it's corrupt / bogus / invalid then we'll add a set of standard modes for the display. Since we have no true information about the connected display, these modes are essentially guesses but better than nothing. At the moment, none of the modes returned is marked as preferred, but the modes are sorted such that the higher resolution modes are listed first. When userspace sees these modes presented by the kernel it needs to figure out which one to pick. At least one userspace, ChromeOS [1] seems to use the rules (which seem pretty reasonable): 1. Try to pick the first mode marked as preferred. 2. Try to pick the mode which matches the first detailed timing descriptor in the EDID. 3. If no modes were marked as preferred then pick the first mode. Unfortunately, userspace's rules combined with what the kernel is doing causes us to fail section 4.2.2.6 (EDID Corruption Detection) of the DP 1.4a Link CTS. That test case says that, while it's OK to allow some implementation-specific fall-back modes if the EDID is bad that userspace should _default_ to 640x480. Let's fix this by marking 640x480 as default for DP in the no-EDID case. NOTES: - In the discussion around v3 of this patch [2] there was talk about solving this in userspace and I even implemented a patch that would have solved this for ChromeOS, but then the discussion turned back to solving this in the kernel. - Also in the discussion of v3 [2] it was requested to limit this change to just DP since folks were worried that it would break some subtle corner case on VGA or HDMI. [1] https://source.chromium.org/chromium/chromium/src/+/a051f741d0a15caff2251301efe081c30e0f4a96:ui/ozone/platform/drm/common/drm_util.cc;l=488 [2] https://lore.kernel.org/r/20220513130533.v3.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Acked-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220601112302.v4.1.I31ec454f8d4ffce51a7708a8092f8a6f9c929092@changeid
2022-06-01 18:23:24 +00:00
/*
* Section 4.2.2.6 (EDID Corruption Detection) of the DP 1.4a
* Link CTS specifies that 640x480 (the official "failsafe"
* mode) needs to be the default if there's no EDID.
*/
if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort)
drm_set_preferred_mode(connector, 640, 480);
}
drm: Perform cmdline mode parsing during connector initialisation i915.ko has a custom fbdev initialisation routine that aims to preserve the current mode set by the BIOS, unless overruled by the user. The user's wishes are determined by what, if any, mode is specified on the command line (via the video= parameter). However, that command line mode is first parsed by drm_fb_helper_initial_config() which is called after i915.ko's custom initial_config() as a fallback method. So in order for us to honour it, we need to move the cmdline parser earlier. If we perform the connector cmdline parsing as soon as we initialise the connector, that cmdline mode and forced status is then available even if the fbdev helper is not compiled in or never called. We also then expose the cmdline user mode in the connector mode lists. v2: Rebase after connector->name upheaval. v3: Adapt mga200 to look for the cmdline mode in the new place. Nicely simplifies things while at that. v4: Fix checkpatch. v5: Select FB_CMDLINE to adapt to the changed fbdev patch. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73154 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Cc: dri-devel@lists.freedesktop.org Cc: Julia Lemire <jlemire@matrox.com> Cc: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-08-06 08:08:32 +00:00
count += drm_helper_probe_add_cmdline_mode(connector);
if (count != 0) {
ret = __drm_helper_update_and_validate(connector, maxX, maxY, &ctx);
if (ret == -EDEADLK) {
drm_modeset_backoff(&ctx);
goto retry;
}
}
drm/probe-helper: For DP, add 640x480 if all other modes are bad As per Displayport spec section 5.2.1.2 ("Video Timing Format") says that all detachable sinks shall support 640x480 @60Hz as a fail safe mode. A DP compliance test expected us to utilize the above fact when all modes it presented to the DP source were not achievable. It presented only modes that would be achievable with more lanes and/or higher speeds than we had available and expected that when we couldn't do that then we'd fall back to 640x480 even though it didn't advertise this size. In order to pass the compliance test (and also support any users who might fall into a similar situation with their display), we need to add 640x480 into the list of modes. However, we don't want to add 640x480 all the time. Despite the fact that the DP spec says all sinks _shall support_ 640x480, they're not guaranteed to support it _well_. Continuing to read the spec you can see that the display is not required to really treat 640x480 equal to all the other modes. It doesn't need to scale or anything--just display the pixels somehow for failsafe purposes. It should also be noted that it's not hard to find a display hooked up via DisplayPort that _doesn't_ support 640x480 at all. The HP ZR30w screen I'm sitting in front of has a native DP port and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI display via a DP to HDMI adapter and that screen definitely doesn't support 640x480. As a compromise solution, let's only add the 640x480 mode if: * We're on DP. * All other modes have been pruned. This acknowledges that 640x480 might not be the best mode to use but, since sinks are _supposed_ to support it, we will at least fall back to it if there's nothing else. Note that we _don't_ add higher resolution modes like 1024x768 in this case. We only add those modes for a failed EDID read where we have no idea what's going on. In the case where we've pruned all modes then instead we only want 640x480 which is the only defined "Fail Safe" resolution. This patch originated in response to Kuogee Hsieh's patch [1]. [1] https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220511155749.v3.2.I4ac7f55aa446699f8c200a23c10463256f6f439f@changeid
2022-05-11 22:58:08 +00:00
drm_mode_prune_invalid(dev, &connector->modes, true);
drm/probe-helper: For DP, add 640x480 if all other modes are bad As per Displayport spec section 5.2.1.2 ("Video Timing Format") says that all detachable sinks shall support 640x480 @60Hz as a fail safe mode. A DP compliance test expected us to utilize the above fact when all modes it presented to the DP source were not achievable. It presented only modes that would be achievable with more lanes and/or higher speeds than we had available and expected that when we couldn't do that then we'd fall back to 640x480 even though it didn't advertise this size. In order to pass the compliance test (and also support any users who might fall into a similar situation with their display), we need to add 640x480 into the list of modes. However, we don't want to add 640x480 all the time. Despite the fact that the DP spec says all sinks _shall support_ 640x480, they're not guaranteed to support it _well_. Continuing to read the spec you can see that the display is not required to really treat 640x480 equal to all the other modes. It doesn't need to scale or anything--just display the pixels somehow for failsafe purposes. It should also be noted that it's not hard to find a display hooked up via DisplayPort that _doesn't_ support 640x480 at all. The HP ZR30w screen I'm sitting in front of has a native DP port and doesn't work at 640x480. I also plugged in a tiny 800x480 HDMI display via a DP to HDMI adapter and that screen definitely doesn't support 640x480. As a compromise solution, let's only add the 640x480 mode if: * We're on DP. * All other modes have been pruned. This acknowledges that 640x480 might not be the best mode to use but, since sinks are _supposed_ to support it, we will at least fall back to it if there's nothing else. Note that we _don't_ add higher resolution modes like 1024x768 in this case. We only add those modes for a failed EDID read where we have no idea what's going on. In the case where we've pruned all modes then instead we only want 640x480 which is the only defined "Fail Safe" resolution. This patch originated in response to Kuogee Hsieh's patch [1]. [1] https://lore.kernel.org/r/1650671124-14030-1-git-send-email-quic_khsieh@quicinc.com Signed-off-by: Douglas Anderson <dianders@chromium.org> Tested-by: Kuogee Hsieh <quic_khsieh@quicinc.com> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220511155749.v3.2.I4ac7f55aa446699f8c200a23c10463256f6f439f@changeid
2022-05-11 22:58:08 +00:00
/*
* Displayport spec section 5.2.1.2 ("Video Timing Format") says that
* all detachable sinks shall support 640x480 @60Hz as a fail safe
* mode. If all modes were pruned, perhaps because they need more
* lanes or a higher pixel clock than available, at least try to add
* in 640x480.
*/
if (list_empty(&connector->modes) &&
connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
count = drm_add_modes_noedid(connector, 640, 480);
ret = __drm_helper_update_and_validate(connector, maxX, maxY, &ctx);
if (ret == -EDEADLK) {
drm_modeset_backoff(&ctx);
goto retry;
}
drm_mode_prune_invalid(dev, &connector->modes, true);
}
exit:
drm_modeset_drop_locks(&ctx);
drm_modeset_acquire_fini(&ctx);
if (list_empty(&connector->modes))
return 0;
drm_mode_sort(&connector->modes);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] probed modes :\n", connector->base.id,
connector->name);
list_for_each_entry(mode, &connector->modes, head) {
drm_mode_set_crtcinfo(mode, CRTC_INTERLACE_HALVE_V);
drm_mode_debug_printmodeline(mode);
}
return count;
}
EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
/**
* drm_kms_helper_hotplug_event - fire off KMS hotplug events
* @dev: drm_device whose connector state changed
*
* This function fires off the uevent for userspace and also calls the
* output_poll_changed function, which is most commonly used to inform the fbdev
* emulation code and allow it to update the fbcon output configuration.
*
* Drivers should call this from their hotplug handling code when a change is
* detected. Note that this function does not do any output detection of its
* own, like drm_helper_hpd_irq_event() does - this is assumed to be done by the
* driver already.
*
* This function must be called from process context with no mode
* setting locks held.
*
* If only a single connector has changed, consider calling
* drm_kms_helper_connector_hotplug_event() instead.
*/
void drm_kms_helper_hotplug_event(struct drm_device *dev)
{
/* send a uevent + call fbdev */
drm_sysfs_hotplug_event(dev);
if (dev->mode_config.funcs->output_poll_changed)
dev->mode_config.funcs->output_poll_changed(dev);
drm_client_dev_hotplug(dev);
}
EXPORT_SYMBOL(drm_kms_helper_hotplug_event);
/**
* drm_kms_helper_connector_hotplug_event - fire off a KMS connector hotplug event
* @connector: drm_connector which has changed
*
* This is the same as drm_kms_helper_hotplug_event(), except it fires a more
* fine-grained uevent for a single connector.
*/
void drm_kms_helper_connector_hotplug_event(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
/* send a uevent + call fbdev */
drm_sysfs_connector_hotplug_event(connector);
if (dev->mode_config.funcs->output_poll_changed)
dev->mode_config.funcs->output_poll_changed(dev);
drm_client_dev_hotplug(dev);
}
EXPORT_SYMBOL(drm_kms_helper_connector_hotplug_event);
static void output_poll_execute(struct work_struct *work)
{
struct delayed_work *delayed_work = to_delayed_work(work);
struct drm_device *dev = container_of(delayed_work, struct drm_device, mode_config.output_poll_work);
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
enum drm_connector_status old_status;
bool repoll = false, changed;
u64 old_epoch_counter;
drm: Flush output polling on shutdown We need to mark the output polling as disabled to prevent concurrent irqs from queuing new work as shutdown the probe -- causing that work to execute after we have freed the structs: <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) <4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 <4> [341.846578] RSP: 0018:ffffc900006cfdb0 EFLAGS: 00010286 <4> [341.846583] RAX: 0000000000000000 RBX: ffff88826759a168 RCX: 0000000000000000 <4> [341.846589] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffffffff8112844c <4> [341.846595] RBP: ffff8882708fa548 R08: 0000000000000000 R09: 0000000000039600 <4> [341.846601] R10: 0000000000000000 R11: 0000000000000ce4 R12: ffffffffa07de1e0 <4> [341.846607] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffa07de2d0 <4> [341.846613] FS: 00007f62b5ae0e40(0000) GS:ffff888276380000(0000) knlGS:0000000000000000 <4> [341.846620] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.846626] CR2: 000055a4e064f4a0 CR3: 0000000266b16006 CR4: 00000000003606e0 <4> [341.846632] Call Trace: <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] <4> [341.846784] pci_device_remove+0x36/0xb0 <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 <4> [341.846795] driver_detach+0x3f/0x80 <4> [341.846800] bus_remove_driver+0x53/0xd0 <4> [341.846805] pci_unregister_driver+0x25/0xa0 <4> [341.846843] i915_exit+0x16/0x1c [i915] <4> [341.846849] __se_sys_delete_module+0x162/0x210 <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c <4> [341.846859] ? do_syscall_64+0xd/0x1c0 <4> [341.846864] do_syscall_64+0x55/0x1c0 <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [341.846875] RIP: 0033:0x7f62b51871b7 <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 <4> [341.846897] RSP: 002b:00007ffe7a227138 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 <4> [341.846904] RAX: ffffffffffffffda RBX: 00007ffe7a2272b0 RCX: 00007f62b51871b7 <4> [341.846910] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000557cd6b55948 <4> [341.846916] RBP: 0000557cd6b558e0 R08: 0000557cd6b5594c R09: 00007ffe7a227160 <4> [341.846922] R10: 00007ffe7a226134 R11: 0000000000000206 R12: 0000000000000000 <4> [341.846927] R13: 00007ffe7a227820 R14: 0000000000000000 R15: 0000000000000000 <4> [341.846936] irq event stamp: 3547847 <4> [341.846940] hardirqs last enabled at (3547847): [<ffffffff819aad2c>] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [341.846949] hardirqs last disabled at (3547846): [<ffffffff819aab9d>] _raw_spin_lock_irqsave+0xd/0x50 <4> [341.846957] softirqs last enabled at (3547376): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9 <4> [341.846966] softirqs last disabled at (3547367): [<ffffffff810b6379>] irq_exit+0xa9/0xc0 <4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes : <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa <4> [341.890628] general protection fault: 0000 [#1] PREEMPT SMP PTI <4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.890646] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.890655] Workqueue: events output_poll_execute <4> [341.890663] RIP: 0010:drm_setup_crtcs+0x13e/0xbe0 <4> [341.890669] Code: 00 41 8b 44 24 58 85 c0 0f 8e f9 01 00 00 44 8b 6c 24 20 44 8b 74 24 28 31 db 31 ed 49 8b 44 24 60 48 63 d5 44 89 ee 83 c5 01 <48> 8b 04 d0 44 89 f2 48 8b 38 48 8b 87 88 01 00 00 48 8b 40 20 e8 <4> [341.890686] RSP: 0018:ffffc9000033fd40 EFLAGS: 00010202 <4> [341.890692] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000002 RCX: 0000000000000000 <4> [341.890700] RDX: 0000000000000001 RSI: 0000000000000c80 RDI: 00000000ffffffff <4> [341.890707] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 <4> [341.890715] R10: 0000000000000c80 R11: 0000000000000000 R12: ffff888267599fe8 <4> [341.890722] R13: 0000000000000c80 R14: 0000000000000708 R15: 0000000000000007 <4> [341.890730] FS: 0000000000000000(0000) GS:ffff888276200000(0000) knlGS:0000000000000000 <4> [341.890739] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.890745] CR2: 000055a4e064f4a0 CR3: 000000026d234003 CR4: 00000000003606f0 <4> [341.890752] Call Trace: <4> [341.890760] drm_fb_helper_hotplug_event.part.24+0x89/0xb0 <4> [341.890768] drm_kms_helper_hotplug_event+0x21/0x30 <4> [341.890774] output_poll_execute+0x9d/0x1a0 <4> [341.890782] process_one_work+0x245/0x610 <4> [341.890790] worker_thread+0x37/0x380 <4> [341.890796] ? process_one_work+0x610/0x610 <4> [341.890802] kthread+0x119/0x130 <4> [341.890808] ? kthread_park+0x80/0x80 <4> [341.890815] ret_from_fork+0x3a/0x50 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603135910.15979-2-chris@chris-wilson.co.uk
2019-06-03 13:58:57 +00:00
if (!dev->mode_config.poll_enabled)
return;
/* Pick up any changes detected by the probe functions. */
changed = dev->mode_config.delayed_event;
dev->mode_config.delayed_event = false;
if (!drm_kms_helper_poll)
goto out;
if (!mutex_trylock(&dev->mode_config.mutex)) {
repoll = true;
goto out;
}
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
/* Ignore forced connectors. */
if (connector->force)
continue;
/* Ignore HPD capable connectors and connectors where we don't
* want any hotplug detection at all for polling. */
if (!connector->polled || connector->polled == DRM_CONNECTOR_POLL_HPD)
continue;
old_status = connector->status;
/* if we are connected and don't want to poll for disconnect
skip it */
if (old_status == connector_status_connected &&
!(connector->polled & DRM_CONNECTOR_POLL_DISCONNECT))
continue;
repoll = true;
old_epoch_counter = connector->epoch_counter;
connector->status = drm_helper_probe_detect(connector, NULL, false);
if (old_epoch_counter != connector->epoch_counter) {
const char *old, *new;
/*
* The poll work sets force=false when calling detect so
* that drivers can avoid to do disruptive tests (e.g.
* when load detect cycles could cause flickering on
* other, running displays). This bears the risk that we
* flip-flop between unknown here in the poll work and
* the real state when userspace forces a full detect
* call after receiving a hotplug event due to this
* change.
*
* Hence clamp an unknown detect status to the old
* value.
*/
if (connector->status == connector_status_unknown) {
connector->status = old_status;
continue;
}
old = drm_get_connector_status_name(old_status);
new = drm_get_connector_status_name(connector->status);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] "
"status updated from %s to %s\n",
connector->base.id,
connector->name,
old, new);
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] epoch counter %llu -> %llu\n",
connector->base.id, connector->name,
old_epoch_counter, connector->epoch_counter);
changed = true;
}
}
drm_connector_list_iter_end(&conn_iter);
mutex_unlock(&dev->mode_config.mutex);
out:
if (changed)
drm_kms_helper_hotplug_event(dev);
if (repoll)
schedule_delayed_work(delayed_work, DRM_OUTPUT_POLL_PERIOD);
}
/**
* drm_kms_helper_is_poll_worker - is %current task an output poll worker?
*
* Determine if %current task is an output poll worker. This can be used
* to select distinct code paths for output polling versus other contexts.
*
* One use case is to avoid a deadlock between the output poll worker and
* the autosuspend worker wherein the latter waits for polling to finish
* upon calling drm_kms_helper_poll_disable(), while the former waits for
* runtime suspend to finish upon calling pm_runtime_get_sync() in a
* connector ->detect hook.
*/
bool drm_kms_helper_is_poll_worker(void)
{
struct work_struct *work = current_work();
return work && work->func == output_poll_execute;
}
EXPORT_SYMBOL(drm_kms_helper_is_poll_worker);
/**
* drm_kms_helper_poll_disable - disable output polling
* @dev: drm_device
*
* This function disables the output polling work.
*
* Drivers can call this helper from their device suspend implementation. It is
* not an error to call this even when output polling isn't enabled or already
* disabled. Polling is re-enabled by calling drm_kms_helper_poll_enable().
*
* Note that calls to enable and disable polling must be strictly ordered, which
* is automatically the case when they're only call from suspend/resume
* callbacks.
*/
void drm_kms_helper_poll_disable(struct drm_device *dev)
{
if (!dev->mode_config.poll_enabled)
return;
cancel_delayed_work_sync(&dev->mode_config.output_poll_work);
}
EXPORT_SYMBOL(drm_kms_helper_poll_disable);
/**
* drm_kms_helper_poll_init - initialize and enable output polling
* @dev: drm_device
*
* This function initializes and then also enables output polling support for
* @dev. Drivers which do not have reliable hotplug support in hardware can use
* this helper infrastructure to regularly poll such connectors for changes in
* their connection state.
*
* Drivers can control which connectors are polled by setting the
* DRM_CONNECTOR_POLL_CONNECT and DRM_CONNECTOR_POLL_DISCONNECT flags. On
* connectors where probing live outputs can result in visual distortion drivers
* should not set the DRM_CONNECTOR_POLL_DISCONNECT flag to avoid this.
* Connectors which have no flag or only DRM_CONNECTOR_POLL_HPD set are
* completely ignored by the polling logic.
*
* Note that a connector can be both polled and probed from the hotplug handler,
* in case the hotplug interrupt is known to be unreliable.
*/
void drm_kms_helper_poll_init(struct drm_device *dev)
{
INIT_DELAYED_WORK(&dev->mode_config.output_poll_work, output_poll_execute);
dev->mode_config.poll_enabled = true;
drm_kms_helper_poll_enable(dev);
}
EXPORT_SYMBOL(drm_kms_helper_poll_init);
/**
* drm_kms_helper_poll_fini - disable output polling and clean it up
* @dev: drm_device
*/
void drm_kms_helper_poll_fini(struct drm_device *dev)
{
drm: Flush output polling on shutdown We need to mark the output polling as disabled to prevent concurrent irqs from queuing new work as shutdown the probe -- causing that work to execute after we have freed the structs: <4> [341.846490] DEBUG_LOCKS_WARN_ON(mutex_is_locked(lock)) <4> [341.846497] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846508] Modules linked in: i915(-) vgem thunderbolt snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm mcs7830 btusb usbnet btrtl mii btbcm btintel bluetooth ecdh_generic ecc mei_me mei prime_numbers i2c_hid pinctrl_sunrisepoint pinctrl_intel [last unloaded: i915] <4> [341.846546] CPU: 3 PID: 3300 Comm: i915_module_loa Tainted: G U 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.846553] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.846560] RIP: 0010:mutex_destroy+0x49/0x50 <4> [341.846565] Code: 00 00 5b c3 e8 a8 9f 3b 00 85 c0 74 ed 8b 05 3e 55 23 01 85 c0 75 e3 48 c7 c6 00 d0 08 82 48 c7 c7 a8 aa 07 82 e8 e7 08 fa ff <0f> 0b eb cc 0f 1f 00 48 b8 11 11 11 11 11 11 11 11 48 89 76 20 48 <4> [341.846578] RSP: 0018:ffffc900006cfdb0 EFLAGS: 00010286 <4> [341.846583] RAX: 0000000000000000 RBX: ffff88826759a168 RCX: 0000000000000000 <4> [341.846589] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffffffff8112844c <4> [341.846595] RBP: ffff8882708fa548 R08: 0000000000000000 R09: 0000000000039600 <4> [341.846601] R10: 0000000000000000 R11: 0000000000000ce4 R12: ffffffffa07de1e0 <4> [341.846607] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffffa07de2d0 <4> [341.846613] FS: 00007f62b5ae0e40(0000) GS:ffff888276380000(0000) knlGS:0000000000000000 <4> [341.846620] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.846626] CR2: 000055a4e064f4a0 CR3: 0000000266b16006 CR4: 00000000003606e0 <4> [341.846632] Call Trace: <4> [341.846639] drm_fb_helper_fini.part.17+0xb3/0x100 <4> [341.846682] intel_fbdev_fini+0x20/0x80 [i915] <4> [341.846722] intel_modeset_cleanup+0x9a/0x140 [i915] <4> [341.846750] i915_driver_unload+0xa3/0x100 [i915] <4> [341.846778] i915_pci_remove+0x19/0x30 [i915] <4> [341.846784] pci_device_remove+0x36/0xb0 <4> [341.846790] device_release_driver_internal+0xd3/0x1b0 <4> [341.846795] driver_detach+0x3f/0x80 <4> [341.846800] bus_remove_driver+0x53/0xd0 <4> [341.846805] pci_unregister_driver+0x25/0xa0 <4> [341.846843] i915_exit+0x16/0x1c [i915] <4> [341.846849] __se_sys_delete_module+0x162/0x210 <4> [341.846855] ? trace_hardirqs_off_thunk+0x1a/0x1c <4> [341.846859] ? do_syscall_64+0xd/0x1c0 <4> [341.846864] do_syscall_64+0x55/0x1c0 <4> [341.846869] entry_SYSCALL_64_after_hwframe+0x49/0xbe <4> [341.846875] RIP: 0033:0x7f62b51871b7 <4> [341.846881] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 <4> [341.846897] RSP: 002b:00007ffe7a227138 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 <4> [341.846904] RAX: ffffffffffffffda RBX: 00007ffe7a2272b0 RCX: 00007f62b51871b7 <4> [341.846910] RDX: 0000000000000001 RSI: 0000000000000800 RDI: 0000557cd6b55948 <4> [341.846916] RBP: 0000557cd6b558e0 R08: 0000557cd6b5594c R09: 00007ffe7a227160 <4> [341.846922] R10: 00007ffe7a226134 R11: 0000000000000206 R12: 0000000000000000 <4> [341.846927] R13: 00007ffe7a227820 R14: 0000000000000000 R15: 0000000000000000 <4> [341.846936] irq event stamp: 3547847 <4> [341.846940] hardirqs last enabled at (3547847): [<ffffffff819aad2c>] _raw_spin_unlock_irqrestore+0x4c/0x60 <4> [341.846949] hardirqs last disabled at (3547846): [<ffffffff819aab9d>] _raw_spin_lock_irqsave+0xd/0x50 <4> [341.846957] softirqs last enabled at (3547376): [<ffffffff81c0033a>] __do_softirq+0x33a/0x4b9 <4> [341.846966] softirqs last disabled at (3547367): [<ffffffff810b6379>] irq_exit+0xa9/0xc0 <4> [341.846973] WARNING: CPU: 3 PID: 3300 at kernel/locking/mutex-debug.c:103 mutex_destroy+0x49/0x50 <4> [341.846980] ---[ end trace ba94ca8952ba970e ]--- <7> [341.866547] [drm:intel_dp_detect [i915]] MST support? port A: no, sink: no, modparam: yes <7> [341.890480] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890530] [drm:drm_add_edid_modes] ELD: no CEA Extension found <7> [341.890537] [drm:drm_add_display_info] non_desktop set to 0 <7> [341.890578] [drm:drm_helper_probe_single_connector_modes] [CONNECTOR:86:eDP-1] probed modes : <7> [341.890589] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 60 373250 3200 3248 3280 3360 1800 1803 1808 1852 0x48 0xa <7> [341.890602] [drm:drm_mode_debug_printmodeline] Modeline "3200x1800": 48 298600 3200 3248 3280 3360 1800 1803 1808 1852 0x40 0xa <4> [341.890628] general protection fault: 0000 [#1] PREEMPT SMP PTI <4> [341.890636] CPU: 0 PID: 508 Comm: kworker/0:4 Tainted: G U W 5.2.0-rc2-CI-CI_DRM_6175+ #1 <4> [341.890646] Hardware name: Dell Inc. XPS 13 9360/0823VW, BIOS 2.9.0 07/09/2018 <4> [341.890655] Workqueue: events output_poll_execute <4> [341.890663] RIP: 0010:drm_setup_crtcs+0x13e/0xbe0 <4> [341.890669] Code: 00 41 8b 44 24 58 85 c0 0f 8e f9 01 00 00 44 8b 6c 24 20 44 8b 74 24 28 31 db 31 ed 49 8b 44 24 60 48 63 d5 44 89 ee 83 c5 01 <48> 8b 04 d0 44 89 f2 48 8b 38 48 8b 87 88 01 00 00 48 8b 40 20 e8 <4> [341.890686] RSP: 0018:ffffc9000033fd40 EFLAGS: 00010202 <4> [341.890692] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000002 RCX: 0000000000000000 <4> [341.890700] RDX: 0000000000000001 RSI: 0000000000000c80 RDI: 00000000ffffffff <4> [341.890707] RBP: 0000000000000002 R08: 0000000000000000 R09: 0000000000000000 <4> [341.890715] R10: 0000000000000c80 R11: 0000000000000000 R12: ffff888267599fe8 <4> [341.890722] R13: 0000000000000c80 R14: 0000000000000708 R15: 0000000000000007 <4> [341.890730] FS: 0000000000000000(0000) GS:ffff888276200000(0000) knlGS:0000000000000000 <4> [341.890739] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 <4> [341.890745] CR2: 000055a4e064f4a0 CR3: 000000026d234003 CR4: 00000000003606f0 <4> [341.890752] Call Trace: <4> [341.890760] drm_fb_helper_hotplug_event.part.24+0x89/0xb0 <4> [341.890768] drm_kms_helper_hotplug_event+0x21/0x30 <4> [341.890774] output_poll_execute+0x9d/0x1a0 <4> [341.890782] process_one_work+0x245/0x610 <4> [341.890790] worker_thread+0x37/0x380 <4> [341.890796] ? process_one_work+0x610/0x610 <4> [341.890802] kthread+0x119/0x130 <4> [341.890808] ? kthread_park+0x80/0x80 <4> [341.890815] ret_from_fork+0x3a/0x50 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109964 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190603135910.15979-2-chris@chris-wilson.co.uk
2019-06-03 13:58:57 +00:00
if (!dev->mode_config.poll_enabled)
return;
dev->mode_config.poll_enabled = false;
cancel_delayed_work_sync(&dev->mode_config.output_poll_work);
}
EXPORT_SYMBOL(drm_kms_helper_poll_fini);
static bool check_connector_changed(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
enum drm_connector_status old_status;
u64 old_epoch_counter;
/* Only handle HPD capable connectors. */
drm_WARN_ON(dev, !(connector->polled & DRM_CONNECTOR_POLL_HPD));
drm_WARN_ON(dev, !mutex_is_locked(&dev->mode_config.mutex));
old_status = connector->status;
old_epoch_counter = connector->epoch_counter;
connector->status = drm_helper_probe_detect(connector, NULL, false);
if (old_epoch_counter == connector->epoch_counter) {
drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Same epoch counter %llu\n",
connector->base.id,
connector->name,
connector->epoch_counter);
return false;
}
drm_dbg_kms(dev, "[CONNECTOR:%d:%s] status updated from %s to %s\n",
connector->base.id,
connector->name,
drm_get_connector_status_name(old_status),
drm_get_connector_status_name(connector->status));
drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Changed epoch counter %llu => %llu\n",
connector->base.id,
connector->name,
old_epoch_counter,
connector->epoch_counter);
return true;
}
/**
* drm_connector_helper_hpd_irq_event - hotplug processing
* @connector: drm_connector
*
* Drivers can use this helper function to run a detect cycle on a connector
* which has the DRM_CONNECTOR_POLL_HPD flag set in its &polled member.
*
* This helper function is useful for drivers which can track hotplug
* interrupts for a single connector. Drivers that want to send a
* hotplug event for all connectors or can't track hotplug interrupts
* per connector need to use drm_helper_hpd_irq_event().
*
* This function must be called from process context with no mode
* setting locks held.
*
* Note that a connector can be both polled and probed from the hotplug
* handler, in case the hotplug interrupt is known to be unreliable.
*
* Returns:
* A boolean indicating whether the connector status changed or not
*/
bool drm_connector_helper_hpd_irq_event(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
bool changed;
mutex_lock(&dev->mode_config.mutex);
changed = check_connector_changed(connector);
mutex_unlock(&dev->mode_config.mutex);
if (changed) {
drm_kms_helper_connector_hotplug_event(connector);
drm_dbg_kms(dev, "[CONNECTOR:%d:%s] Sent hotplug event\n",
connector->base.id,
connector->name);
}
return changed;
}
EXPORT_SYMBOL(drm_connector_helper_hpd_irq_event);
/**
* drm_helper_hpd_irq_event - hotplug processing
* @dev: drm_device
*
* Drivers can use this helper function to run a detect cycle on all connectors
* which have the DRM_CONNECTOR_POLL_HPD flag set in their &polled member. All
* other connectors are ignored, which is useful to avoid reprobing fixed
* panels.
*
* This helper function is useful for drivers which can't or don't track hotplug
* interrupts for each connector.
*
* Drivers which support hotplug interrupts for each connector individually and
* which have a more fine-grained detect logic can use
* drm_connector_helper_hpd_irq_event(). Alternatively, they should bypass this
* code and directly call drm_kms_helper_hotplug_event() in case the connector
* state changed.
*
* This function must be called from process context with no mode
* setting locks held.
*
* Note that a connector can be both polled and probed from the hotplug handler,
* in case the hotplug interrupt is known to be unreliable.
*
* Returns:
* A boolean indicating whether the connector status changed or not
*/
bool drm_helper_hpd_irq_event(struct drm_device *dev)
{
struct drm_connector *connector, *first_changed_connector = NULL;
struct drm_connector_list_iter conn_iter;
int changed = 0;
if (!dev->mode_config.poll_enabled)
return false;
mutex_lock(&dev->mode_config.mutex);
drm_connector_list_iter_begin(dev, &conn_iter);
drm_for_each_connector_iter(connector, &conn_iter) {
/* Only handle HPD capable connectors. */
if (!(connector->polled & DRM_CONNECTOR_POLL_HPD))
continue;
if (check_connector_changed(connector)) {
if (!first_changed_connector) {
drm_connector_get(connector);
first_changed_connector = connector;
}
changed++;
}
}
drm_connector_list_iter_end(&conn_iter);
mutex_unlock(&dev->mode_config.mutex);
if (changed == 1)
drm_kms_helper_connector_hotplug_event(first_changed_connector);
else if (changed > 0)
drm_kms_helper_hotplug_event(dev);
if (first_changed_connector)
drm_connector_put(first_changed_connector);
return changed;
}
EXPORT_SYMBOL(drm_helper_hpd_irq_event);
/**
* drm_crtc_helper_mode_valid_fixed - Validates a display mode
* @crtc: the crtc
* @mode: the mode to validate
* @fixed_mode: the display hardware's mode
*
* Returns:
* MODE_OK on success, or another mode-status code otherwise.
*/
enum drm_mode_status drm_crtc_helper_mode_valid_fixed(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
const struct drm_display_mode *fixed_mode)
{
if (mode->hdisplay != fixed_mode->hdisplay && mode->vdisplay != fixed_mode->vdisplay)
return MODE_ONE_SIZE;
else if (mode->hdisplay != fixed_mode->hdisplay)
return MODE_ONE_WIDTH;
else if (mode->vdisplay != fixed_mode->vdisplay)
return MODE_ONE_HEIGHT;
return MODE_OK;
}
EXPORT_SYMBOL(drm_crtc_helper_mode_valid_fixed);
/**
* drm_connector_helper_get_modes_from_ddc - Updates the connector's EDID
* property from the connector's
* DDC channel
* @connector: The connector
*
* Returns:
* The number of detected display modes.
*
* Uses a connector's DDC channel to retrieve EDID data and update the
* connector's EDID property and display modes. Drivers can use this
* function to implement struct &drm_connector_helper_funcs.get_modes
* for connectors with a DDC channel.
*/
int drm_connector_helper_get_modes_from_ddc(struct drm_connector *connector)
{
struct edid *edid;
int count = 0;
if (!connector->ddc)
return 0;
edid = drm_get_edid(connector, connector->ddc);
// clears property if EDID is NULL
drm_connector_update_edid_property(connector, edid);
if (edid) {
count = drm_add_edid_modes(connector, edid);
kfree(edid);
}
return count;
}
EXPORT_SYMBOL(drm_connector_helper_get_modes_from_ddc);
/**
* drm_connector_helper_get_modes_fixed - Duplicates a display mode for a connector
* @connector: the connector
* @fixed_mode: the display hardware's mode
*
* This function duplicates a display modes for a connector. Drivers for hardware
* that only supports a single fixed mode can use this function in their connector's
* get_modes helper.
*
* Returns:
* The number of created modes.
*/
int drm_connector_helper_get_modes_fixed(struct drm_connector *connector,
const struct drm_display_mode *fixed_mode)
{
struct drm_device *dev = connector->dev;
struct drm_display_mode *mode;
mode = drm_mode_duplicate(dev, fixed_mode);
if (!mode) {
drm_err(dev, "Failed to duplicate mode " DRM_MODE_FMT "\n",
DRM_MODE_ARG(fixed_mode));
return 0;
}
if (mode->name[0] == '\0')
drm_mode_set_name(mode);
mode->type |= DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
if (mode->width_mm)
connector->display_info.width_mm = mode->width_mm;
if (mode->height_mm)
connector->display_info.height_mm = mode->height_mm;
return 1;
}
EXPORT_SYMBOL(drm_connector_helper_get_modes_fixed);
/**
* drm_connector_helper_get_modes - Read EDID and update connector.
* @connector: The connector
*
* Read the EDID using drm_edid_read() (which requires that connector->ddc is
* set), and update the connector using the EDID.
*
* This can be used as the "default" connector helper .get_modes() hook if the
* driver does not need any special processing. This is sets the example what
* custom .get_modes() hooks should do regarding EDID read and connector update.
*
* Returns: Number of modes.
*/
int drm_connector_helper_get_modes(struct drm_connector *connector)
{
const struct drm_edid *drm_edid;
int count;
drm_edid = drm_edid_read(connector);
/*
* Unconditionally update the connector. If the EDID was read
* successfully, fill in the connector information derived from the
* EDID. Otherwise, if the EDID is NULL, clear the connector
* information.
*/
count = drm_edid_connector_update(connector, drm_edid);
drm_edid_free(drm_edid);
return count;
}
EXPORT_SYMBOL(drm_connector_helper_get_modes);