OpenCloudOS-Kernel/drivers/gpu/drm/i915/display/intel_crt.c

1089 lines
31 KiB
C
Raw Normal View History

/*
* Copyright © 2006-2007 Intel Corporation
*
* Permission is hereby granted, free of charge, to any person obtaining a
* copy of this software and associated documentation files (the "Software"),
* to deal in the Software without restriction, including without limitation
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
* and/or sell copies of the Software, and to permit persons to whom the
* Software is furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice (including the next
* paragraph) shall be included in all copies or substantial portions of the
* Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
* DEALINGS IN THE SOFTWARE.
*
* Authors:
* Eric Anholt <eric@anholt.net>
*/
#include <linux/dmi.h>
#include <linux/i2c.h>
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h percpu.h is included by sched.h and module.h and thus ends up being included when building most .c files. percpu.h includes slab.h which in turn includes gfp.h making everything defined by the two files universally available and complicating inclusion dependencies. percpu.h -> slab.h dependency is about to be removed. Prepare for this change by updating users of gfp and slab facilities include those headers directly instead of assuming availability. As this conversion needs to touch large number of source files, the following script is used as the basis of conversion. http://userweb.kernel.org/~tj/misc/slabh-sweep.py The script does the followings. * Scan files for gfp and slab usages and update includes such that only the necessary includes are there. ie. if only gfp is used, gfp.h, if slab is used, slab.h. * When the script inserts a new include, it looks at the include blocks and try to put the new include such that its order conforms to its surrounding. It's put in the include block which contains core kernel includes, in the same order that the rest are ordered - alphabetical, Christmas tree, rev-Xmas-tree or at the end if there doesn't seem to be any matching order. * If the script can't find a place to put a new include (mostly because the file doesn't have fitting include block), it prints out an error message indicating which .h file needs to be added to the file. The conversion was done in the following steps. 1. The initial automatic conversion of all .c files updated slightly over 4000 files, deleting around 700 includes and adding ~480 gfp.h and ~3000 slab.h inclusions. The script emitted errors for ~400 files. 2. Each error was manually checked. Some didn't need the inclusion, some needed manual addition while adding it to implementation .h or embedding .c file was more appropriate for others. This step added inclusions to around 150 files. 3. The script was run again and the output was compared to the edits from #2 to make sure no file was left behind. 4. Several build tests were done and a couple of problems were fixed. e.g. lib/decompress_*.c used malloc/free() wrappers around slab APIs requiring slab.h to be added manually. 5. The script was run on all .h files but without automatically editing them as sprinkling gfp.h and slab.h inclusions around .h files could easily lead to inclusion dependency hell. Most gfp.h inclusion directives were ignored as stuff from gfp.h was usually wildly available and often used in preprocessor macros. Each slab.h inclusion directive was examined and added manually as necessary. 6. percpu.h was updated not to include slab.h. 7. Build test were done on the following configurations and failures were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my distributed build env didn't work with gcov compiles) and a few more options had to be turned off depending on archs to make things build (like ipr on powerpc/64 which failed due to missing writeq). * x86 and x86_64 UP and SMP allmodconfig and a custom test config. * powerpc and powerpc64 SMP allmodconfig * sparc and sparc64 SMP allmodconfig * ia64 SMP allmodconfig * s390 SMP allmodconfig * alpha SMP allmodconfig * um on x86_64 SMP allmodconfig 8. percpu.h modifications were reverted so that it could be applied as a separate patch and serve as bisection point. Given the fact that I had only a couple of failures from tests on step 6, I'm fairly confident about the coverage of this conversion patch. If there is a breakage, it's likely to be something in one of the arch headers which should be easily discoverable easily on most builds of the specific arch. Signed-off-by: Tejun Heo <tj@kernel.org> Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
#include <linux/slab.h>
#include <drm/drm_atomic_helper.h>
#include <drm/drm_crtc.h>
#include <drm/drm_edid.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-18 05:03:34 +08:00
#include <drm/drm_probe_helper.h>
#include <drm/i915_drm.h>
#include "i915_drv.h"
#include "intel_connector.h"
#include "intel_crt.h"
#include "intel_ddi.h"
#include "intel_display_types.h"
#include "intel_fifo_underrun.h"
#include "intel_gmbus.h"
#include "intel_hotplug.h"
/* Here's the desired hotplug mode */
#define ADPA_HOTPLUG_BITS (ADPA_CRT_HOTPLUG_PERIOD_128 | \
ADPA_CRT_HOTPLUG_WARMUP_10MS | \
ADPA_CRT_HOTPLUG_SAMPLE_4S | \
ADPA_CRT_HOTPLUG_VOLTAGE_50 | \
ADPA_CRT_HOTPLUG_VOLREF_325MV | \
ADPA_CRT_HOTPLUG_ENABLE)
struct intel_crt {
struct intel_encoder base;
/* DPMS state is stored in the connector, which we need in the
* encoder's enable/disable callbacks */
struct intel_connector *connector;
bool force_hotplug_required;
drm/i915: Type safe register read/write Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 21:33:26 +08:00
i915_reg_t adpa_reg;
};
static struct intel_crt *intel_encoder_to_crt(struct intel_encoder *encoder)
{
return container_of(encoder, struct intel_crt, base);
}
static struct intel_crt *intel_attached_crt(struct intel_connector *connector)
{
return intel_encoder_to_crt(intel_attached_encoder(connector));
}
bool intel_crt_port_enabled(struct drm_i915_private *dev_priv,
i915_reg_t adpa_reg, enum pipe *pipe)
{
u32 val;
val = intel_de_read(dev_priv, adpa_reg);
/* asserts want to know the pipe even if the port is disabled */
if (HAS_PCH_CPT(dev_priv))
*pipe = (val & ADPA_PIPE_SEL_MASK_CPT) >> ADPA_PIPE_SEL_SHIFT_CPT;
else
*pipe = (val & ADPA_PIPE_SEL_MASK) >> ADPA_PIPE_SEL_SHIFT;
return val & ADPA_DAC_ENABLE;
}
static bool intel_crt_get_hw_state(struct intel_encoder *encoder,
enum pipe *pipe)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crt *crt = intel_encoder_to_crt(encoder);
intel_wakeref_t wakeref;
bool ret;
wakeref = intel_display_power_get_if_enabled(dev_priv,
encoder->power_domain);
if (!wakeref)
return false;
ret = intel_crt_port_enabled(dev_priv, crt->adpa_reg, pipe);
intel_display_power_put(dev_priv, encoder->power_domain, wakeref);
return ret;
}
static unsigned int intel_crt_get_flags(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crt *crt = intel_encoder_to_crt(encoder);
u32 tmp, flags = 0;
tmp = intel_de_read(dev_priv, crt->adpa_reg);
if (tmp & ADPA_HSYNC_ACTIVE_HIGH)
flags |= DRM_MODE_FLAG_PHSYNC;
else
flags |= DRM_MODE_FLAG_NHSYNC;
if (tmp & ADPA_VSYNC_ACTIVE_HIGH)
flags |= DRM_MODE_FLAG_PVSYNC;
else
flags |= DRM_MODE_FLAG_NVSYNC;
return flags;
}
static void intel_crt_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
pipe_config->output_types |= BIT(INTEL_OUTPUT_ANALOG);
pipe_config->hw.adjusted_mode.flags |= intel_crt_get_flags(encoder);
pipe_config->hw.adjusted_mode.crtc_clock = pipe_config->port_clock;
}
static void hsw_crt_get_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
intel_ddi_get_config(encoder, pipe_config);
pipe_config->hw.adjusted_mode.flags &= ~(DRM_MODE_FLAG_PHSYNC |
DRM_MODE_FLAG_NHSYNC |
DRM_MODE_FLAG_PVSYNC |
DRM_MODE_FLAG_NVSYNC);
pipe_config->hw.adjusted_mode.flags |= intel_crt_get_flags(encoder);
pipe_config->hw.adjusted_mode.crtc_clock = lpt_get_iclkip(dev_priv);
}
drm/i915: convert dpms functions of dvo/sdvo/crt Yeah, big patch but I couldn't come up with a neat idea of how to split it up further, that wouldn't break dpms on cloned configs somehow. But the changes in dvo/sdvo/crt are all pretty much orthonogal, so it's not too bad a patch. These are the only encoders that support cloning, which requires a few special changes compared to the previous patches. - Compute the desired state of the display pipe by walking all connected encoders and checking whether any has active connectors. To make this clearer, drop the old mode parameter to the crtc dpms function and rename it to intel_crtc_update_dpms. - There's the curious case of intel_crtc->dpms_mode. With the previous patches to remove the overlay pipe A code and to rework the load detect pipe code, the big users are gone. We still keep it to avoid enabling the pipe twice, but we duplicate this logic with crtc->active, too. Still, leave this for now and just push a fake dpms mode into it that reflects the state of the display pipe. Changes in the encoder dpms functions: - We clamp the dpms state to the supported range right away. This is escpecially important for the VGA outputs, where only older hw supports the intermediate states. This (and the crt->adpa_reg patch) allows us to unify the crt dpms code again between all variants (gmch, vlv and pch). - We only enable/disable the output for dvo/sdvo and leave the encoder running. The encoder will be disabled/enabled when we switch the state of the entire output pipeline (which will happen right away for non-cloned setups). This way the duplication is reduced and strange interaction when disabling output ports at the wrong time avoided. The dpms code for all three types of connectors contains a bit of duplicated logic, but I think keeping these special cases separate is simpler: CRT is the only one that hanldes intermediate dpms state (which requires extra logic to enable/disable things in the right order), and introducing some abstraction just to share the code between dvo and sdvo smells like overkill. We can do that once someone bothers to implement cloning for the more modern outputs. But I doubt that this will ever happen. v2: s/crtc/crt/_set_dpms, noticed by Paulo Zanoni. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-02 04:42:24 +08:00
/* Note: The caller is required to filter out dpms modes not supported by the
* platform. */
static void intel_crt_set_dpms(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
int mode)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
drm/i915: convert dpms functions of dvo/sdvo/crt Yeah, big patch but I couldn't come up with a neat idea of how to split it up further, that wouldn't break dpms on cloned configs somehow. But the changes in dvo/sdvo/crt are all pretty much orthonogal, so it's not too bad a patch. These are the only encoders that support cloning, which requires a few special changes compared to the previous patches. - Compute the desired state of the display pipe by walking all connected encoders and checking whether any has active connectors. To make this clearer, drop the old mode parameter to the crtc dpms function and rename it to intel_crtc_update_dpms. - There's the curious case of intel_crtc->dpms_mode. With the previous patches to remove the overlay pipe A code and to rework the load detect pipe code, the big users are gone. We still keep it to avoid enabling the pipe twice, but we duplicate this logic with crtc->active, too. Still, leave this for now and just push a fake dpms mode into it that reflects the state of the display pipe. Changes in the encoder dpms functions: - We clamp the dpms state to the supported range right away. This is escpecially important for the VGA outputs, where only older hw supports the intermediate states. This (and the crt->adpa_reg patch) allows us to unify the crt dpms code again between all variants (gmch, vlv and pch). - We only enable/disable the output for dvo/sdvo and leave the encoder running. The encoder will be disabled/enabled when we switch the state of the entire output pipeline (which will happen right away for non-cloned setups). This way the duplication is reduced and strange interaction when disabling output ports at the wrong time avoided. The dpms code for all three types of connectors contains a bit of duplicated logic, but I think keeping these special cases separate is simpler: CRT is the only one that hanldes intermediate dpms state (which requires extra logic to enable/disable things in the right order), and introducing some abstraction just to share the code between dvo and sdvo smells like overkill. We can do that once someone bothers to implement cloning for the more modern outputs. But I doubt that this will ever happen. v2: s/crtc/crt/_set_dpms, noticed by Paulo Zanoni. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-02 04:42:24 +08:00
struct intel_crt *crt = intel_encoder_to_crt(encoder);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
const struct drm_display_mode *adjusted_mode = &crtc_state->hw.adjusted_mode;
u32 adpa;
if (INTEL_GEN(dev_priv) >= 5)
adpa = ADPA_HOTPLUG_BITS;
else
adpa = 0;
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
adpa |= ADPA_HSYNC_ACTIVE_HIGH;
if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
adpa |= ADPA_VSYNC_ACTIVE_HIGH;
/* For CPT allow 3 pipe config, for others just use A or B */
if (HAS_PCH_LPT(dev_priv))
; /* Those bits don't exist here */
else if (HAS_PCH_CPT(dev_priv))
adpa |= ADPA_PIPE_SEL_CPT(crtc->pipe);
else
adpa |= ADPA_PIPE_SEL(crtc->pipe);
if (!HAS_PCH_SPLIT(dev_priv))
intel_de_write(dev_priv, BCLRPAT(crtc->pipe), 0);
switch (mode) {
case DRM_MODE_DPMS_ON:
adpa |= ADPA_DAC_ENABLE;
break;
case DRM_MODE_DPMS_STANDBY:
adpa |= ADPA_DAC_ENABLE | ADPA_HSYNC_CNTL_DISABLE;
break;
case DRM_MODE_DPMS_SUSPEND:
adpa |= ADPA_DAC_ENABLE | ADPA_VSYNC_CNTL_DISABLE;
break;
case DRM_MODE_DPMS_OFF:
adpa |= ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE;
break;
}
intel_de_write(dev_priv, crt->adpa_reg, adpa);
}
static void intel_disable_crt(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
intel_crt_set_dpms(encoder, old_crtc_state, DRM_MODE_DPMS_OFF);
}
static void pch_disable_crt(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
}
static void pch_post_disable_crt(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
intel_disable_crt(encoder, old_crtc_state, old_conn_state);
}
static void hsw_disable_crt(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
drm_WARN_ON(&dev_priv->drm, !old_crtc_state->has_pch_encoder);
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
}
static void hsw_post_disable_crt(struct intel_encoder *encoder,
const struct intel_crtc_state *old_crtc_state,
const struct drm_connector_state *old_conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
intel_crtc_vblank_off(old_crtc_state);
intel_disable_pipe(old_crtc_state);
intel_ddi_disable_transcoder_func(old_crtc_state);
ilk_pfit_disable(old_crtc_state);
intel_ddi_disable_pipe_clock(old_crtc_state);
pch_post_disable_crt(encoder, old_crtc_state, old_conn_state);
lpt_disable_pch_transcoder(dev_priv);
lpt_disable_iclkip(dev_priv);
intel_ddi_fdi_post_disable(encoder, old_crtc_state, old_conn_state);
drm_WARN_ON(&dev_priv->drm, !old_crtc_state->has_pch_encoder);
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
}
static void hsw_pre_pll_enable_crt(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
drm_WARN_ON(&dev_priv->drm, !crtc_state->has_pch_encoder);
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
}
static void hsw_pre_enable_crt(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
enum pipe pipe = crtc->pipe;
drm_WARN_ON(&dev_priv->drm, !crtc_state->has_pch_encoder);
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
hsw_fdi_link_train(encoder, crtc_state);
intel_ddi_enable_pipe_clock(crtc_state);
}
static void hsw_enable_crt(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
enum pipe pipe = crtc->pipe;
drm_WARN_ON(&dev_priv->drm, !crtc_state->has_pch_encoder);
intel_enable_pipe(crtc_state);
lpt_pch_enable(crtc_state);
intel_crtc_vblank_on(crtc_state);
intel_crt_set_dpms(encoder, crtc_state, DRM_MODE_DPMS_ON);
intel_wait_for_vblank(dev_priv, pipe);
intel_wait_for_vblank(dev_priv, pipe);
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, true);
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
}
static void intel_enable_crt(struct intel_encoder *encoder,
const struct intel_crtc_state *crtc_state,
const struct drm_connector_state *conn_state)
{
intel_crt_set_dpms(encoder, crtc_state, DRM_MODE_DPMS_ON);
}
static enum drm_mode_status
intel_crt_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
struct drm_device *dev = connector->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
int max_dotclk = dev_priv->max_dotclk_freq;
int max_clock;
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
return MODE_NO_DBLESCAN;
if (mode->clock < 25000)
return MODE_CLOCK_LOW;
if (HAS_PCH_LPT(dev_priv))
max_clock = 180000;
else if (IS_VALLEYVIEW(dev_priv))
/*
* 270 MHz due to current DPLL limits,
* DAC limit supposedly 355 MHz.
*/
max_clock = 270000;
else if (IS_GEN_RANGE(dev_priv, 3, 4))
max_clock = 400000;
else
max_clock = 350000;
if (mode->clock > max_clock)
return MODE_CLOCK_HIGH;
if (mode->clock > max_dotclk)
return MODE_CLOCK_HIGH;
/* The FDI receiver on LPT only supports 8bpc and only has 2 lanes. */
if (HAS_PCH_LPT(dev_priv) &&
ilk_get_lanes_required(mode->clock, 270000, 24) > 2)
return MODE_CLOCK_HIGH;
/* HSW/BDW FDI limited to 4k */
if (mode->hdisplay > 4096)
return MODE_H_ILLEGAL;
return MODE_OK;
}
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
static int intel_crt_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
return -EINVAL;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
return 0;
}
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
static int pch_crt_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
return -EINVAL;
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
return 0;
}
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
static int hsw_crt_compute_config(struct intel_encoder *encoder,
struct intel_crtc_state *pipe_config,
struct drm_connector_state *conn_state)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct drm_display_mode *adjusted_mode =
&pipe_config->hw.adjusted_mode;
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
return -EINVAL;
/* HSW/BDW FDI limited to 4k */
if (adjusted_mode->crtc_hdisplay > 4096 ||
adjusted_mode->crtc_hblank_start > 4096)
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
return -EINVAL;
pipe_config->has_pch_encoder = true;
pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB;
/* LPT FDI RX only supports 8bpc. */
if (HAS_PCH_LPT(dev_priv)) {
if (pipe_config->bw_constrained && pipe_config->pipe_bpp < 24) {
DRM_DEBUG_KMS("LPT only supports 24bpp\n");
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
return -EINVAL;
}
pipe_config->pipe_bpp = 24;
}
/* FDI must always be 2.7 GHz */
pipe_config->port_clock = 135000 * 2;
drm/i915: Pass down rc in intel_encoder->compute_config() Something that I completely missed when implementing the new MST VCPI atomic helpers is that with those helpers, there's technically a chance of us having to grab additional modeset locks in ->compute_config() and furthermore, that means we have the potential to hit a normal modeset deadlock. However, because ->compute_config() only returns a bool this means we can't return -EDEADLK when we need to drop locks and try again which means we end up just failing the atomic check permanently. Whoops. So, fix this by modifying ->compute_config() to pass down an actual error code instead of a bool so that the atomic check can be restarted on modeset deadlocks. Thanks to Ville Syrjälä for pointing this out! Changes since v1: * Add some newlines * Return only -EINVAL from hsw_crt_compute_config() * Propogate return code from intel_dp_compute_dsc_params() * Change all of the intel_dp_compute_link_config*() variants * Don't miss if (hdmi_port_clock_valid()) branch in intel_hdmi_compute_config() [Cherry-picked from drm-misc-next to drm-intel-next-queued to fix linux-next & drm-tip conflict, while waiting for proper propagation of the DP MST series that this commit fixes. In hindsight, a topic branch might have been a better approach for it.] Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: eceae1472467 ("drm/dp_mst: Start tracking per-port VCPI allocations") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109320 Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190115200800.3121-1-lyude@redhat.com (cherry picked from commit 96550555a78ca3c9fda4b358549a5622810fe32c) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch>
2019-01-16 04:08:00 +08:00
return 0;
}
static bool ilk_crt_detect_hotplug(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct intel_crt *crt = intel_attached_crt(to_intel_connector(connector));
struct drm_i915_private *dev_priv = to_i915(dev);
u32 adpa;
bool ret;
/* The first time through, trigger an explicit detection cycle */
if (crt->force_hotplug_required) {
bool turn_off_dac = HAS_PCH_SPLIT(dev_priv);
u32 save_adpa;
crt->force_hotplug_required = false;
save_adpa = adpa = intel_de_read(dev_priv, crt->adpa_reg);
DRM_DEBUG_KMS("trigger hotplug detect cycle: adpa=0x%x\n", adpa);
adpa |= ADPA_CRT_HOTPLUG_FORCE_TRIGGER;
if (turn_off_dac)
adpa &= ~ADPA_DAC_ENABLE;
intel_de_write(dev_priv, crt->adpa_reg, adpa);
if (intel_de_wait_for_clear(dev_priv,
crt->adpa_reg,
ADPA_CRT_HOTPLUG_FORCE_TRIGGER,
1000))
DRM_DEBUG_KMS("timed out waiting for FORCE_TRIGGER");
if (turn_off_dac) {
intel_de_write(dev_priv, crt->adpa_reg, save_adpa);
intel_de_posting_read(dev_priv, crt->adpa_reg);
}
}
/* Check the status to see if both blue and green are on now */
adpa = intel_de_read(dev_priv, crt->adpa_reg);
if ((adpa & ADPA_CRT_HOTPLUG_MONITOR_MASK) != 0)
ret = true;
else
ret = false;
DRM_DEBUG_KMS("ironlake hotplug adpa=0x%x, result %d\n", adpa, ret);
return ret;
}
static bool valleyview_crt_detect_hotplug(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct intel_crt *crt = intel_attached_crt(to_intel_connector(connector));
struct drm_i915_private *dev_priv = to_i915(dev);
bool reenable_hpd;
u32 adpa;
bool ret;
u32 save_adpa;
/*
* Doing a force trigger causes a hpd interrupt to get sent, which can
* get us stuck in a loop if we're polling:
* - We enable power wells and reset the ADPA
* - output_poll_exec does force probe on VGA, triggering a hpd
* - HPD handler waits for poll to unlock dev->mode_config.mutex
* - output_poll_exec shuts off the ADPA, unlocks
* dev->mode_config.mutex
* - HPD handler runs, resets ADPA and brings us back to the start
*
* Just disable HPD interrupts here to prevent this
*/
reenable_hpd = intel_hpd_disable(dev_priv, crt->base.hpd_pin);
save_adpa = adpa = intel_de_read(dev_priv, crt->adpa_reg);
DRM_DEBUG_KMS("trigger hotplug detect cycle: adpa=0x%x\n", adpa);
adpa |= ADPA_CRT_HOTPLUG_FORCE_TRIGGER;
intel_de_write(dev_priv, crt->adpa_reg, adpa);
if (intel_de_wait_for_clear(dev_priv, crt->adpa_reg,
ADPA_CRT_HOTPLUG_FORCE_TRIGGER, 1000)) {
DRM_DEBUG_KMS("timed out waiting for FORCE_TRIGGER");
intel_de_write(dev_priv, crt->adpa_reg, save_adpa);
}
/* Check the status to see if both blue and green are on now */
adpa = intel_de_read(dev_priv, crt->adpa_reg);
if ((adpa & ADPA_CRT_HOTPLUG_MONITOR_MASK) != 0)
ret = true;
else
ret = false;
DRM_DEBUG_KMS("valleyview hotplug adpa=0x%x, result %d\n", adpa, ret);
if (reenable_hpd)
intel_hpd_enable(dev_priv, crt->base.hpd_pin);
return ret;
}
static bool intel_crt_detect_hotplug(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
u32 stat;
bool ret = false;
int i, tries = 0;
if (HAS_PCH_SPLIT(dev_priv))
return ilk_crt_detect_hotplug(connector);
if (IS_VALLEYVIEW(dev_priv))
return valleyview_crt_detect_hotplug(connector);
/*
* On 4 series desktop, CRT detect sequence need to be done twice
* to get a reliable result.
*/
if (IS_G45(dev_priv))
tries = 2;
else
tries = 1;
for (i = 0; i < tries ; i++) {
/* turn on the FORCE_DETECT */
i915_hotplug_interrupt_update(dev_priv,
CRT_HOTPLUG_FORCE_DETECT,
CRT_HOTPLUG_FORCE_DETECT);
/* wait for FORCE_DETECT to go off */
if (intel_de_wait_for_clear(dev_priv, PORT_HOTPLUG_EN,
CRT_HOTPLUG_FORCE_DETECT, 1000))
DRM_DEBUG_KMS("timed out waiting for FORCE_DETECT to go off");
}
stat = intel_de_read(dev_priv, PORT_HOTPLUG_STAT);
if ((stat & CRT_HOTPLUG_MONITOR_MASK) != CRT_HOTPLUG_MONITOR_NONE)
ret = true;
/* clear the interrupt we just generated, if any */
intel_de_write(dev_priv, PORT_HOTPLUG_STAT, CRT_HOTPLUG_INT_STATUS);
i915_hotplug_interrupt_update(dev_priv, CRT_HOTPLUG_FORCE_DETECT, 0);
return ret;
}
static struct edid *intel_crt_get_edid(struct drm_connector *connector,
struct i2c_adapter *i2c)
{
struct edid *edid;
edid = drm_get_edid(connector, i2c);
if (!edid && !intel_gmbus_is_forced_bit(i2c)) {
DRM_DEBUG_KMS("CRT GMBUS EDID read failed, retry using GPIO bit-banging\n");
intel_gmbus_force_bit(i2c, true);
edid = drm_get_edid(connector, i2c);
intel_gmbus_force_bit(i2c, false);
}
return edid;
}
/* local version of intel_ddc_get_modes() to use intel_crt_get_edid() */
static int intel_crt_ddc_get_modes(struct drm_connector *connector,
struct i2c_adapter *adapter)
{
struct edid *edid;
int ret;
edid = intel_crt_get_edid(connector, adapter);
if (!edid)
return 0;
ret = intel_connector_update_modes(connector, edid);
kfree(edid);
return ret;
}
static bool intel_crt_detect_ddc(struct drm_connector *connector)
{
struct intel_crt *crt = intel_attached_crt(to_intel_connector(connector));
struct drm_i915_private *dev_priv = to_i915(crt->base.base.dev);
struct edid *edid;
struct i2c_adapter *i2c;
bool ret = false;
BUG_ON(crt->base.type != INTEL_OUTPUT_ANALOG);
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->vbt.crt_ddc_pin);
edid = intel_crt_get_edid(connector, i2c);
if (edid) {
bool is_digital = edid->input & DRM_EDID_INPUT_DIGITAL;
/*
* This may be a DVI-I connector with a shared DDC
* link between analog and digital outputs, so we
* have to check the EDID input spec of the attached device.
*/
if (!is_digital) {
DRM_DEBUG_KMS("CRT detected via DDC:0x50 [EDID]\n");
ret = true;
} else {
DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [EDID reports a digital panel]\n");
}
} else {
DRM_DEBUG_KMS("CRT not detected via DDC:0x50 [no valid EDID found]\n");
}
kfree(edid);
return ret;
}
static enum drm_connector_status
intel_crt_load_detect(struct intel_crt *crt, u32 pipe)
{
struct drm_device *dev = crt->base.base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_uncore *uncore = &dev_priv->uncore;
u32 save_bclrpat;
u32 save_vtotal;
u32 vtotal, vactive;
u32 vsample;
u32 vblank, vblank_start, vblank_end;
u32 dsl;
drm/i915: Type safe register read/write Make I915_READ and I915_WRITE more type safe by wrapping the register offset in a struct. This should eliminate most of the fumbles we've had with misplaced parens. This only takes care of normal mmio registers. We could extend the idea to other register types and define each with its own struct. That way you wouldn't be able to accidentally pass the wrong thing to a specific register access function. The gpio_reg setup is probably the ugliest thing left. But I figure I'd just leave it for now, and wait for some divine inspiration to strike before making it nice. As for the generated code, it's actually a bit better sometimes. Eg. looking at i915_irq_handler(), we can see the following change: lea 0x70024(%rdx,%rax,1),%r9d mov $0x1,%edx - movslq %r9d,%r9 - mov %r9,%rsi - mov %r9,-0x58(%rbp) - callq *0xd8(%rbx) + mov %r9d,%esi + mov %r9d,-0x48(%rbp) callq *0xd8(%rbx) So previously gcc thought the register offset might be signed and decided to sign extend it, just in case. The rest appears to be mostly just minor shuffling of instructions. v2: i915_mmio_reg_{offset,equal,valid}() helpers added s/_REG/_MMIO/ in the register defines mo more switch statements left to worry about ring_emit stuff got sorted in a prep patch cmd parser, lrc context and w/a batch buildup also in prep patch vgpu stuff cleaned up and moved to a prep patch all other unrelated changes split out v3: Rebased due to BXT DSI/BLC, MOCS, etc. v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/ Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 21:33:26 +08:00
i915_reg_t bclrpat_reg, vtotal_reg,
vblank_reg, vsync_reg, pipeconf_reg, pipe_dsl_reg;
u8 st00;
enum drm_connector_status status;
DRM_DEBUG_KMS("starting load-detect on CRT\n");
bclrpat_reg = BCLRPAT(pipe);
vtotal_reg = VTOTAL(pipe);
vblank_reg = VBLANK(pipe);
vsync_reg = VSYNC(pipe);
pipeconf_reg = PIPECONF(pipe);
pipe_dsl_reg = PIPEDSL(pipe);
save_bclrpat = intel_uncore_read(uncore, bclrpat_reg);
save_vtotal = intel_uncore_read(uncore, vtotal_reg);
vblank = intel_uncore_read(uncore, vblank_reg);
vtotal = ((save_vtotal >> 16) & 0xfff) + 1;
vactive = (save_vtotal & 0x7ff) + 1;
vblank_start = (vblank & 0xfff) + 1;
vblank_end = ((vblank >> 16) & 0xfff) + 1;
/* Set the border color to purple. */
intel_uncore_write(uncore, bclrpat_reg, 0x500050);
if (!IS_GEN(dev_priv, 2)) {
u32 pipeconf = intel_uncore_read(uncore, pipeconf_reg);
intel_uncore_write(uncore,
pipeconf_reg,
pipeconf | PIPECONF_FORCE_BORDER);
intel_uncore_posting_read(uncore, pipeconf_reg);
/* Wait for next Vblank to substitue
* border color for Color info */
intel_wait_for_vblank(dev_priv, pipe);
st00 = intel_uncore_read8(uncore, _VGA_MSR_WRITE);
status = ((st00 & (1 << 4)) != 0) ?
connector_status_connected :
connector_status_disconnected;
intel_uncore_write(uncore, pipeconf_reg, pipeconf);
} else {
bool restore_vblank = false;
int count, detect;
/*
* If there isn't any border, add some.
* Yes, this will flicker
*/
if (vblank_start <= vactive && vblank_end >= vtotal) {
u32 vsync = intel_de_read(dev_priv, vsync_reg);
u32 vsync_start = (vsync & 0xffff) + 1;
vblank_start = vsync_start;
intel_uncore_write(uncore,
vblank_reg,
(vblank_start - 1) |
((vblank_end - 1) << 16));
restore_vblank = true;
}
/* sample in the vertical border, selecting the larger one */
if (vblank_start - vactive >= vtotal - vblank_end)
vsample = (vblank_start + vactive) >> 1;
else
vsample = (vtotal + vblank_end) >> 1;
/*
* Wait for the border to be displayed
*/
while (intel_uncore_read(uncore, pipe_dsl_reg) >= vactive)
;
while ((dsl = intel_uncore_read(uncore, pipe_dsl_reg)) <=
vsample)
;
/*
* Watch ST00 for an entire scanline
*/
detect = 0;
count = 0;
do {
count++;
/* Read the ST00 VGA status register */
st00 = intel_uncore_read8(uncore, _VGA_MSR_WRITE);
if (st00 & (1 << 4))
detect++;
} while ((intel_uncore_read(uncore, pipe_dsl_reg) == dsl));
/* restore vblank if necessary */
if (restore_vblank)
intel_uncore_write(uncore, vblank_reg, vblank);
/*
* If more than 3/4 of the scanline detected a monitor,
* then it is assumed to be present. This works even on i830,
* where there isn't any way to force the border color across
* the screen
*/
status = detect * 4 > count * 3 ?
connector_status_connected :
connector_status_disconnected;
}
/* Restore previous settings */
intel_uncore_write(uncore, bclrpat_reg, save_bclrpat);
return status;
}
drm/i915: Register shadow VGA even when it produces spurious detection results Having a shadow VGA connector is useful for testing purposes. We currently skip registering the connector on machines where the CRT detect falsely reports it as connected. Let's instead move the the blacklist check to the detect callback (and hpd setup) and if we get a match we always report the connector as disconnected. This way we get a shadow VGA connector to help with testing, while we still avoid the user facing problems from the incorrect detection results. commit 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB") doesn't provide much in the way of details as to why 'ACER ZGB' was added to the blacklist. Trying to trace it further leads me to a chromeos bugreport I can't access. So based on the fact that the commit added the "/* Skip machines without VGA that falsely report hotplug events */" comment, I'm going to assume that it was just spurious CRT detection. So it should be safe to move the blacklist to just block the detection and hpd without causing a regression on said machine. In fact Stéphane confirmed on irc that the problem was indeed just crappy hotplug detect: "22:29 < marcheu> vsyrjala: the port isn't there, but the load detect is improperly stubbed in hw 22:29 < marcheu> vsyrjala: so it floats" so this change should be perfectly fine. v2: Add irc quote from Stéphane Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Olof Johansson <olofj@chromium.org> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474881646-1326-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-09-26 17:20:45 +08:00
static int intel_spurious_crt_detect_dmi_callback(const struct dmi_system_id *id)
{
DRM_DEBUG_DRIVER("Skipping CRT detection for %s\n", id->ident);
return 1;
}
static const struct dmi_system_id intel_spurious_crt_detect[] = {
{
.callback = intel_spurious_crt_detect_dmi_callback,
.ident = "ACER ZGB",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ACER"),
DMI_MATCH(DMI_PRODUCT_NAME, "ZGB"),
},
},
{
.callback = intel_spurious_crt_detect_dmi_callback,
.ident = "Intel DZ77BH-55K",
.matches = {
DMI_MATCH(DMI_BOARD_VENDOR, "Intel Corporation"),
DMI_MATCH(DMI_BOARD_NAME, "DZ77BH-55K"),
},
},
drm/i915: Register shadow VGA even when it produces spurious detection results Having a shadow VGA connector is useful for testing purposes. We currently skip registering the connector on machines where the CRT detect falsely reports it as connected. Let's instead move the the blacklist check to the detect callback (and hpd setup) and if we get a match we always report the connector as disconnected. This way we get a shadow VGA connector to help with testing, while we still avoid the user facing problems from the incorrect detection results. commit 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB") doesn't provide much in the way of details as to why 'ACER ZGB' was added to the blacklist. Trying to trace it further leads me to a chromeos bugreport I can't access. So based on the fact that the commit added the "/* Skip machines without VGA that falsely report hotplug events */" comment, I'm going to assume that it was just spurious CRT detection. So it should be safe to move the blacklist to just block the detection and hpd without causing a regression on said machine. In fact Stéphane confirmed on irc that the problem was indeed just crappy hotplug detect: "22:29 < marcheu> vsyrjala: the port isn't there, but the load detect is improperly stubbed in hw 22:29 < marcheu> vsyrjala: so it floats" so this change should be perfectly fine. v2: Add irc quote from Stéphane Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Olof Johansson <olofj@chromium.org> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474881646-1326-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-09-26 17:20:45 +08:00
{ }
};
static int
intel_crt_detect(struct drm_connector *connector,
struct drm_modeset_acquire_ctx *ctx,
bool force)
{
struct drm_i915_private *dev_priv = to_i915(connector->dev);
struct intel_crt *crt = intel_attached_crt(to_intel_connector(connector));
struct intel_encoder *intel_encoder = &crt->base;
intel_wakeref_t wakeref;
int status, ret;
struct intel_load_detect_pipe tmp;
DRM_DEBUG_KMS("[CONNECTOR:%d:%s] force=%d\n",
connector->base.id, connector->name,
force);
if (i915_modparams.load_detect_test) {
wakeref = intel_display_power_get(dev_priv,
intel_encoder->power_domain);
goto load_detect;
}
drm/i915: Register shadow VGA even when it produces spurious detection results Having a shadow VGA connector is useful for testing purposes. We currently skip registering the connector on machines where the CRT detect falsely reports it as connected. Let's instead move the the blacklist check to the detect callback (and hpd setup) and if we get a match we always report the connector as disconnected. This way we get a shadow VGA connector to help with testing, while we still avoid the user facing problems from the incorrect detection results. commit 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT initialization on ZGB") doesn't provide much in the way of details as to why 'ACER ZGB' was added to the blacklist. Trying to trace it further leads me to a chromeos bugreport I can't access. So based on the fact that the commit added the "/* Skip machines without VGA that falsely report hotplug events */" comment, I'm going to assume that it was just spurious CRT detection. So it should be safe to move the blacklist to just block the detection and hpd without causing a regression on said machine. In fact Stéphane confirmed on irc that the problem was indeed just crappy hotplug detect: "22:29 < marcheu> vsyrjala: the port isn't there, but the load detect is improperly stubbed in hw 22:29 < marcheu> vsyrjala: so it floats" so this change should be perfectly fine. v2: Add irc quote from Stéphane Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Olof Johansson <olofj@chromium.org> Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1474881646-1326-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-09-26 17:20:45 +08:00
/* Skip machines without VGA that falsely report hotplug events */
if (dmi_check_system(intel_spurious_crt_detect))
return connector_status_disconnected;
wakeref = intel_display_power_get(dev_priv,
intel_encoder->power_domain);
if (I915_HAS_HOTPLUG(dev_priv)) {
drm/i915/crt: Do not rely upon the HPD presence pin VGA hotplug detection "works" by measuring the resistance across certain pins. A lot of kvm switches fumble this and wire up cheap resistors with the wrong resistance or don't bother at all. To accomodate these, also try to detect a connected monitor by trying to grab the edid. Contrary to !HAS_HOTPLUG platforms we don't bother with an actual load-detection cycle when the output is life - that would be actual work to implement because things moved around. This is the big difference to Chris Wilson's original approach: commit 9e612a008fa7fe493a473454def56aa321479495 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 31 13:08:53 2012 +0100 drm/i915/crt: Do not rely upon the HPD presence pin This blew up on Linus' machine because it errornously detected a vga screen (without and edid and hence only the default modes), leading to it's prompt removal: commit 8f53369b753f5f4c7684c2eb0b592152abb1dd00 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 8 14:53:06 2012 -0700 Revert "drm/i915/crt: Do not rely upon the HPD presence pin" Some digging around in Bspec shows the reason why load detect doesn't work on newer chips - the legacy VGA load detect bit isn't wired up any longer: Public Snb Bspec, Vol3 Part1, 1.1.1 ST00 Input Status 0, bit4: "RGB Comparator / Sense. This bit is here for compatibility and will always return one. Monitor detection must be done be done through the programming of registers in the MMIO space. 0 = Below threshold 1 = Above threshold" v2: Add a comment in the code that load detect on hotplug capable machines is broken and pimp the commit message with a quote of Bspec to show why. Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 21:30:32 +08:00
/* We can not rely on the HPD pin always being correctly wired
* up, for example many KVM do not pass it through, and so
* only trust an assertion that the monitor is connected.
*/
if (intel_crt_detect_hotplug(connector)) {
DRM_DEBUG_KMS("CRT detected via hotplug\n");
status = connector_status_connected;
goto out;
drm/i915/crt: Do not rely upon the HPD presence pin VGA hotplug detection "works" by measuring the resistance across certain pins. A lot of kvm switches fumble this and wire up cheap resistors with the wrong resistance or don't bother at all. To accomodate these, also try to detect a connected monitor by trying to grab the edid. Contrary to !HAS_HOTPLUG platforms we don't bother with an actual load-detection cycle when the output is life - that would be actual work to implement because things moved around. This is the big difference to Chris Wilson's original approach: commit 9e612a008fa7fe493a473454def56aa321479495 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 31 13:08:53 2012 +0100 drm/i915/crt: Do not rely upon the HPD presence pin This blew up on Linus' machine because it errornously detected a vga screen (without and edid and hence only the default modes), leading to it's prompt removal: commit 8f53369b753f5f4c7684c2eb0b592152abb1dd00 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 8 14:53:06 2012 -0700 Revert "drm/i915/crt: Do not rely upon the HPD presence pin" Some digging around in Bspec shows the reason why load detect doesn't work on newer chips - the legacy VGA load detect bit isn't wired up any longer: Public Snb Bspec, Vol3 Part1, 1.1.1 ST00 Input Status 0, bit4: "RGB Comparator / Sense. This bit is here for compatibility and will always return one. Monitor detection must be done be done through the programming of registers in the MMIO space. 0 = Below threshold 1 = Above threshold" v2: Add a comment in the code that load detect on hotplug capable machines is broken and pimp the commit message with a quote of Bspec to show why. Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 21:30:32 +08:00
} else
DRM_DEBUG_KMS("CRT not detected via hotplug\n");
}
if (intel_crt_detect_ddc(connector)) {
status = connector_status_connected;
goto out;
}
drm/i915/crt: Do not rely upon the HPD presence pin VGA hotplug detection "works" by measuring the resistance across certain pins. A lot of kvm switches fumble this and wire up cheap resistors with the wrong resistance or don't bother at all. To accomodate these, also try to detect a connected monitor by trying to grab the edid. Contrary to !HAS_HOTPLUG platforms we don't bother with an actual load-detection cycle when the output is life - that would be actual work to implement because things moved around. This is the big difference to Chris Wilson's original approach: commit 9e612a008fa7fe493a473454def56aa321479495 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 31 13:08:53 2012 +0100 drm/i915/crt: Do not rely upon the HPD presence pin This blew up on Linus' machine because it errornously detected a vga screen (without and edid and hence only the default modes), leading to it's prompt removal: commit 8f53369b753f5f4c7684c2eb0b592152abb1dd00 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 8 14:53:06 2012 -0700 Revert "drm/i915/crt: Do not rely upon the HPD presence pin" Some digging around in Bspec shows the reason why load detect doesn't work on newer chips - the legacy VGA load detect bit isn't wired up any longer: Public Snb Bspec, Vol3 Part1, 1.1.1 ST00 Input Status 0, bit4: "RGB Comparator / Sense. This bit is here for compatibility and will always return one. Monitor detection must be done be done through the programming of registers in the MMIO space. 0 = Below threshold 1 = Above threshold" v2: Add a comment in the code that load detect on hotplug capable machines is broken and pimp the commit message with a quote of Bspec to show why. Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 21:30:32 +08:00
/* Load detection is broken on HPD capable machines. Whoever wants a
* broken monitor (without edid) to work behind a broken kvm (that fails
* to have the right resistors for HP detection) needs to fix this up.
* For now just bail out. */
if (I915_HAS_HOTPLUG(dev_priv)) {
status = connector_status_disconnected;
goto out;
}
drm/i915/crt: Do not rely upon the HPD presence pin VGA hotplug detection "works" by measuring the resistance across certain pins. A lot of kvm switches fumble this and wire up cheap resistors with the wrong resistance or don't bother at all. To accomodate these, also try to detect a connected monitor by trying to grab the edid. Contrary to !HAS_HOTPLUG platforms we don't bother with an actual load-detection cycle when the output is life - that would be actual work to implement because things moved around. This is the big difference to Chris Wilson's original approach: commit 9e612a008fa7fe493a473454def56aa321479495 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu May 31 13:08:53 2012 +0100 drm/i915/crt: Do not rely upon the HPD presence pin This blew up on Linus' machine because it errornously detected a vga screen (without and edid and hence only the default modes), leading to it's prompt removal: commit 8f53369b753f5f4c7684c2eb0b592152abb1dd00 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Fri Jun 8 14:53:06 2012 -0700 Revert "drm/i915/crt: Do not rely upon the HPD presence pin" Some digging around in Bspec shows the reason why load detect doesn't work on newer chips - the legacy VGA load detect bit isn't wired up any longer: Public Snb Bspec, Vol3 Part1, 1.1.1 ST00 Input Status 0, bit4: "RGB Comparator / Sense. This bit is here for compatibility and will always return one. Monitor detection must be done be done through the programming of registers in the MMIO space. 0 = Below threshold 1 = Above threshold" v2: Add a comment in the code that load detect on hotplug capable machines is broken and pimp the commit message with a quote of Bspec to show why. Reported-and-tested-by: Matthieu LAVIE <boiteamadmax@hotmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=50501 Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-16 21:30:32 +08:00
load_detect:
if (!force) {
status = connector->status;
goto out;
}
/* for pre-945g platforms use load detect */
ret = intel_get_load_detect_pipe(connector, &tmp, ctx);
if (ret > 0) {
if (intel_crt_detect_ddc(connector))
status = connector_status_connected;
else if (INTEL_GEN(dev_priv) < 4)
status = intel_crt_load_detect(crt,
to_intel_crtc(connector->state->crtc)->pipe);
else if (i915_modparams.load_detect_test)
status = connector_status_disconnected;
else
status = connector_status_unknown;
intel_release_load_detect_pipe(connector, &tmp, ctx);
} else if (ret == 0) {
status = connector_status_unknown;
} else {
status = ret;
}
out:
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
2019-10-29 02:15:17 +08:00
/*
* Make sure the refs for power wells enabled during detect are
* dropped to avoid a new detect cycle triggered by HPD polling.
*/
intel_display_power_flush_work(dev_priv);
return status;
}
static int intel_crt_get_modes(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crt *crt = intel_attached_crt(to_intel_connector(connector));
struct intel_encoder *intel_encoder = &crt->base;
intel_wakeref_t wakeref;
struct i2c_adapter *i2c;
int ret;
wakeref = intel_display_power_get(dev_priv,
intel_encoder->power_domain);
i2c = intel_gmbus_get_adapter(dev_priv, dev_priv->vbt.crt_ddc_pin);
ret = intel_crt_ddc_get_modes(connector, i2c);
if (ret || !IS_G4X(dev_priv))
goto out;
/* Try to probe digital port for output in DVI-I -> VGA mode. */
i2c = intel_gmbus_get_adapter(dev_priv, GMBUS_PIN_DPB);
ret = intel_crt_ddc_get_modes(connector, i2c);
out:
intel_display_power_put(dev_priv, intel_encoder->power_domain, wakeref);
return ret;
}
void intel_crt_reset(struct drm_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
struct intel_crt *crt = intel_encoder_to_crt(to_intel_encoder(encoder));
if (INTEL_GEN(dev_priv) >= 5) {
u32 adpa;
adpa = intel_de_read(dev_priv, crt->adpa_reg);
adpa &= ~ADPA_CRT_HOTPLUG_MASK;
adpa |= ADPA_HOTPLUG_BITS;
intel_de_write(dev_priv, crt->adpa_reg, adpa);
intel_de_posting_read(dev_priv, crt->adpa_reg);
DRM_DEBUG_KMS("crt adpa set to 0x%x\n", adpa);
crt->force_hotplug_required = true;
}
}
/*
* Routines for controlling stuff on the analog port
*/
static const struct drm_connector_funcs intel_crt_connector_funcs = {
.fill_modes = drm_helper_probe_single_connector_modes,
.late_register = intel_connector_register,
.early_unregister = intel_connector_unregister,
.destroy = intel_connector_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
};
static const struct drm_connector_helper_funcs intel_crt_connector_helper_funcs = {
.detect_ctx = intel_crt_detect,
.mode_valid = intel_crt_mode_valid,
.get_modes = intel_crt_get_modes,
};
static const struct drm_encoder_funcs intel_crt_enc_funcs = {
.reset = intel_crt_reset,
.destroy = intel_encoder_destroy,
};
void intel_crt_init(struct drm_i915_private *dev_priv)
{
struct drm_connector *connector;
struct intel_crt *crt;
struct intel_connector *intel_connector;
i915_reg_t adpa_reg;
u32 adpa;
if (HAS_PCH_SPLIT(dev_priv))
adpa_reg = PCH_ADPA;
else if (IS_VALLEYVIEW(dev_priv))
adpa_reg = VLV_ADPA;
else
adpa_reg = ADPA;
adpa = intel_de_read(dev_priv, adpa_reg);
if ((adpa & ADPA_DAC_ENABLE) == 0) {
/*
* On some machines (some IVB at least) CRT can be
* fused off, but there's no known fuse bit to
* indicate that. On these machine the ADPA register
* works normally, except the DAC enable bit won't
* take. So the only way to tell is attempt to enable
* it and see what happens.
*/
intel_de_write(dev_priv, adpa_reg,
adpa | ADPA_DAC_ENABLE | ADPA_HSYNC_CNTL_DISABLE | ADPA_VSYNC_CNTL_DISABLE);
if ((intel_de_read(dev_priv, adpa_reg) & ADPA_DAC_ENABLE) == 0)
return;
intel_de_write(dev_priv, adpa_reg, adpa);
}
crt = kzalloc(sizeof(struct intel_crt), GFP_KERNEL);
if (!crt)
return;
intel_connector = intel_connector_alloc();
if (!intel_connector) {
kfree(crt);
return;
}
connector = &intel_connector->base;
crt->connector = intel_connector;
drm_connector_init(&dev_priv->drm, &intel_connector->base,
&intel_crt_connector_funcs, DRM_MODE_CONNECTOR_VGA);
drm_encoder_init(&dev_priv->drm, &crt->base.base, &intel_crt_enc_funcs,
DRM_MODE_ENCODER_DAC, "CRT");
intel_connector_attach_encoder(intel_connector, &crt->base);
crt->base.type = INTEL_OUTPUT_ANALOG;
crt->base.cloneable = (1 << INTEL_OUTPUT_DVO) | (1 << INTEL_OUTPUT_HDMI);
if (IS_I830(dev_priv))
crt->base.pipe_mask = BIT(PIPE_A);
else
crt->base.pipe_mask = ~0;
if (IS_GEN(dev_priv, 2))
connector->interlace_allowed = 0;
else
connector->interlace_allowed = 1;
connector->doublescan_allowed = 0;
crt->adpa_reg = adpa_reg;
crt->base.power_domain = POWER_DOMAIN_PORT_CRT;
if (I915_HAS_HOTPLUG(dev_priv) &&
!dmi_check_system(intel_spurious_crt_detect)) {
crt->base.hpd_pin = HPD_CRT;
crt->base.hotplug = intel_encoder_hotplug;
}
if (HAS_DDI(dev_priv)) {
crt->base.port = PORT_E;
crt->base.get_config = hsw_crt_get_config;
crt->base.get_hw_state = intel_ddi_get_hw_state;
crt->base.compute_config = hsw_crt_compute_config;
crt->base.pre_pll_enable = hsw_pre_pll_enable_crt;
crt->base.pre_enable = hsw_pre_enable_crt;
crt->base.enable = hsw_enable_crt;
crt->base.disable = hsw_disable_crt;
crt->base.post_disable = hsw_post_disable_crt;
} else {
if (HAS_PCH_SPLIT(dev_priv)) {
crt->base.compute_config = pch_crt_compute_config;
crt->base.disable = pch_disable_crt;
crt->base.post_disable = pch_post_disable_crt;
} else {
crt->base.compute_config = intel_crt_compute_config;
crt->base.disable = intel_disable_crt;
}
crt->base.port = PORT_NONE;
crt->base.get_config = intel_crt_get_config;
crt->base.get_hw_state = intel_crt_get_hw_state;
crt->base.enable = intel_enable_crt;
}
intel_connector->get_hw_state = intel_connector_get_hw_state;
drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
if (!I915_HAS_HOTPLUG(dev_priv))
intel_connector->polled = DRM_CONNECTOR_POLL_CONNECT;
/*
* Configure the automatic hotplug detection stuff
*/
crt->force_hotplug_required = false;
/*
* TODO: find a proper way to discover whether we need to set the the
* polarity and link reversal bits or not, instead of relying on the
* BIOS.
*/
if (HAS_PCH_LPT(dev_priv)) {
u32 fdi_config = FDI_RX_POLARITY_REVERSED_LPT |
FDI_RX_LINK_REVERSAL_OVERRIDE;
dev_priv->fdi_rx_config = intel_de_read(dev_priv,
FDI_RX_CTL(PIPE_A)) & fdi_config;
}
intel_crt_reset(&crt->base.base);
}