2009-01-03 04:33:00 +07:00
|
|
|
/*
|
|
|
|
* Copyright 2006 Dave Airlie <airlied@linux.ie>
|
|
|
|
* Copyright © 2006-2009 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>
|
|
|
|
* Jesse Barnes <jesse.barnes@intel.com>
|
|
|
|
*/
|
|
|
|
|
|
|
|
#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 15:04:11 +07:00
|
|
|
#include <linux/slab.h>
|
2009-01-03 04:33:00 +07:00
|
|
|
#include <linux/delay.h>
|
2013-08-07 02:32:18 +07:00
|
|
|
#include <linux/hdmi.h>
|
2012-10-03 00:01:07 +07:00
|
|
|
#include <drm/drmP.h>
|
|
|
|
#include <drm/drm_crtc.h>
|
|
|
|
#include <drm/drm_edid.h>
|
2009-01-03 04:33:00 +07:00
|
|
|
#include "intel_drv.h"
|
2012-10-03 00:01:07 +07:00
|
|
|
#include <drm/i915_drm.h>
|
2009-01-03 04:33:00 +07:00
|
|
|
#include "i915_drv.h"
|
|
|
|
|
2012-10-27 04:05:45 +07:00
|
|
|
static struct drm_device *intel_hdmi_to_dev(struct intel_hdmi *intel_hdmi)
|
|
|
|
{
|
2012-10-27 04:05:46 +07:00
|
|
|
return hdmi_to_dig_port(intel_hdmi)->base.base.dev;
|
2012-10-27 04:05:45 +07:00
|
|
|
}
|
|
|
|
|
2012-06-12 21:36:45 +07:00
|
|
|
static void
|
|
|
|
assert_hdmi_port_disabled(struct intel_hdmi *intel_hdmi)
|
|
|
|
{
|
2012-10-27 04:05:45 +07:00
|
|
|
struct drm_device *dev = intel_hdmi_to_dev(intel_hdmi);
|
2012-06-12 21:36:45 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
uint32_t enabled_bits;
|
|
|
|
|
2012-11-24 00:30:39 +07:00
|
|
|
enabled_bits = HAS_DDI(dev) ? DDI_BUF_CTL_ENABLE : SDVO_ENABLE;
|
2012-06-12 21:36:45 +07:00
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
WARN(I915_READ(intel_hdmi->hdmi_reg) & enabled_bits,
|
2012-06-12 21:36:45 +07:00
|
|
|
"HDMI port enabled, expecting disabled\n");
|
|
|
|
}
|
|
|
|
|
2012-05-10 01:37:30 +07:00
|
|
|
struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder)
|
2010-08-04 19:50:23 +07:00
|
|
|
{
|
2012-10-27 04:05:46 +07:00
|
|
|
struct intel_digital_port *intel_dig_port =
|
|
|
|
container_of(encoder, struct intel_digital_port, base.base);
|
|
|
|
return &intel_dig_port->hdmi;
|
2010-08-04 19:50:23 +07:00
|
|
|
}
|
|
|
|
|
2010-09-09 22:20:55 +07:00
|
|
|
static struct intel_hdmi *intel_attached_hdmi(struct drm_connector *connector)
|
|
|
|
{
|
2012-10-27 04:05:46 +07:00
|
|
|
return enc_to_intel_hdmi(&intel_attached_encoder(connector)->base);
|
2010-09-09 22:20:55 +07:00
|
|
|
}
|
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
static u32 g4x_infoframe_index(enum hdmi_infoframe_type type)
|
2010-09-25 02:44:32 +07:00
|
|
|
{
|
2013-08-07 02:32:18 +07:00
|
|
|
switch (type) {
|
|
|
|
case HDMI_INFOFRAME_TYPE_AVI:
|
2012-05-15 03:12:50 +07:00
|
|
|
return VIDEO_DIP_SELECT_AVI;
|
2013-08-07 02:32:18 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_SPD:
|
2012-05-15 03:12:50 +07:00
|
|
|
return VIDEO_DIP_SELECT_SPD;
|
2013-08-19 22:59:04 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_VENDOR:
|
|
|
|
return VIDEO_DIP_SELECT_VENDOR;
|
2011-08-03 23:22:55 +07:00
|
|
|
default:
|
2013-08-07 02:32:18 +07:00
|
|
|
DRM_DEBUG_DRIVER("unknown info frame type %d\n", type);
|
2012-05-15 03:12:50 +07:00
|
|
|
return 0;
|
2011-08-03 23:22:55 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
static u32 g4x_infoframe_enable(enum hdmi_infoframe_type type)
|
2011-08-03 23:22:55 +07:00
|
|
|
{
|
2013-08-07 02:32:18 +07:00
|
|
|
switch (type) {
|
|
|
|
case HDMI_INFOFRAME_TYPE_AVI:
|
2012-05-15 03:12:50 +07:00
|
|
|
return VIDEO_DIP_ENABLE_AVI;
|
2013-08-07 02:32:18 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_SPD:
|
2012-05-15 03:12:50 +07:00
|
|
|
return VIDEO_DIP_ENABLE_SPD;
|
2013-08-19 22:59:04 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_VENDOR:
|
|
|
|
return VIDEO_DIP_ENABLE_VENDOR;
|
2012-05-05 03:18:20 +07:00
|
|
|
default:
|
2013-08-07 02:32:18 +07:00
|
|
|
DRM_DEBUG_DRIVER("unknown info frame type %d\n", type);
|
2012-05-15 03:12:50 +07:00
|
|
|
return 0;
|
2012-05-05 03:18:20 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
static u32 hsw_infoframe_enable(enum hdmi_infoframe_type type)
|
2012-05-15 03:12:51 +07:00
|
|
|
{
|
2013-08-07 02:32:18 +07:00
|
|
|
switch (type) {
|
|
|
|
case HDMI_INFOFRAME_TYPE_AVI:
|
2012-05-15 03:12:51 +07:00
|
|
|
return VIDEO_DIP_ENABLE_AVI_HSW;
|
2013-08-07 02:32:18 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_SPD:
|
2012-05-15 03:12:51 +07:00
|
|
|
return VIDEO_DIP_ENABLE_SPD_HSW;
|
2013-08-19 22:59:04 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_VENDOR:
|
|
|
|
return VIDEO_DIP_ENABLE_VS_HSW;
|
2012-05-15 03:12:51 +07:00
|
|
|
default:
|
2013-08-07 02:32:18 +07:00
|
|
|
DRM_DEBUG_DRIVER("unknown info frame type %d\n", type);
|
2012-05-15 03:12:51 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
static u32 hsw_infoframe_data_reg(enum hdmi_infoframe_type type,
|
drm/i915: Reorganize display pipe register accesses
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
v3: Added EDP pipe comment, removed redundant offset arrays for
MSA_MISC and DDI_FUNC_CTL.
v4: Rename patch and report object size increase.
v5: Change location of commas, add PIPE_EDP into enum pipe
v6: Insert PIPE_EDP_OFFSET into pipe offset array
v7: Set I915_MAX_PIPES back to 3, change more registers accessors
to use the new macros, get rid of _PIPE_INC and add dev_priv
as a parameter where required by the new macros.
Upcoming hardware will not have the various display pipe register
ranges evenly spaced in memory. Change register address calculations
into array lookups.
Tested on SNB, VLV, IVB, Gen2 and HSW w/eDP.
I left the UMS cruft untouched.
Size differences:
text data bss dec hex filename
596431 4634 56 601121 92c21 i915.ko (new)
593199 4634 56 597889 91f81 i915.ko (old)
Signed-off-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-02-04 19:22:24 +07:00
|
|
|
enum transcoder cpu_transcoder,
|
|
|
|
struct drm_i915_private *dev_priv)
|
2012-05-15 03:12:51 +07:00
|
|
|
{
|
2013-08-07 02:32:18 +07:00
|
|
|
switch (type) {
|
|
|
|
case HDMI_INFOFRAME_TYPE_AVI:
|
2013-02-26 05:55:16 +07:00
|
|
|
return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder);
|
2013-08-07 02:32:18 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_SPD:
|
2013-02-26 05:55:16 +07:00
|
|
|
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder);
|
2013-08-19 22:59:04 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_VENDOR:
|
|
|
|
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder);
|
2012-05-15 03:12:51 +07:00
|
|
|
default:
|
2013-08-07 02:32:18 +07:00
|
|
|
DRM_DEBUG_DRIVER("unknown info frame type %d\n", type);
|
2012-05-15 03:12:51 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-05-08 20:19:06 +07:00
|
|
|
static void g4x_write_infoframe(struct drm_encoder *encoder,
|
2013-08-07 02:32:18 +07:00
|
|
|
enum hdmi_infoframe_type type,
|
2013-12-10 20:19:08 +07:00
|
|
|
const void *frame, ssize_t len)
|
2011-08-03 23:22:55 +07:00
|
|
|
{
|
2013-12-10 20:19:08 +07:00
|
|
|
const uint32_t *data = frame;
|
2010-09-25 02:44:32 +07:00
|
|
|
struct drm_device *dev = encoder->dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-05-05 03:18:17 +07:00
|
|
|
u32 val = I915_READ(VIDEO_DIP_CTL);
|
2013-08-07 02:32:18 +07:00
|
|
|
int i;
|
2010-09-25 02:44:32 +07:00
|
|
|
|
2012-05-29 02:42:51 +07:00
|
|
|
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
|
|
|
|
|
2012-05-05 03:18:18 +07:00
|
|
|
val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
|
2013-08-07 02:32:18 +07:00
|
|
|
val |= g4x_infoframe_index(type);
|
2012-05-05 03:18:17 +07:00
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
val &= ~g4x_infoframe_enable(type);
|
2011-08-03 23:22:55 +07:00
|
|
|
|
2012-05-05 03:18:17 +07:00
|
|
|
I915_WRITE(VIDEO_DIP_CTL, val);
|
2010-09-25 02:44:32 +07:00
|
|
|
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2011-08-03 23:22:55 +07:00
|
|
|
for (i = 0; i < len; i += 4) {
|
2010-09-25 02:44:32 +07:00
|
|
|
I915_WRITE(VIDEO_DIP_DATA, *data);
|
|
|
|
data++;
|
|
|
|
}
|
2012-09-25 23:23:34 +07:00
|
|
|
/* Write every possible data byte to force correct ECC calculation. */
|
|
|
|
for (; i < VIDEO_DIP_DATA_SIZE; i += 4)
|
|
|
|
I915_WRITE(VIDEO_DIP_DATA, 0);
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2010-09-25 02:44:32 +07:00
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
val |= g4x_infoframe_enable(type);
|
2012-05-05 03:18:22 +07:00
|
|
|
val &= ~VIDEO_DIP_FREQ_MASK;
|
2012-05-08 19:41:00 +07:00
|
|
|
val |= VIDEO_DIP_FREQ_VSYNC;
|
2011-08-03 23:22:55 +07:00
|
|
|
|
2012-05-05 03:18:17 +07:00
|
|
|
I915_WRITE(VIDEO_DIP_CTL, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(VIDEO_DIP_CTL);
|
2010-09-25 02:44:32 +07:00
|
|
|
}
|
|
|
|
|
2012-05-05 03:18:24 +07:00
|
|
|
static void ibx_write_infoframe(struct drm_encoder *encoder,
|
2013-08-07 02:32:18 +07:00
|
|
|
enum hdmi_infoframe_type type,
|
2013-12-10 20:19:08 +07:00
|
|
|
const void *frame, ssize_t len)
|
2012-05-05 03:18:24 +07:00
|
|
|
{
|
2013-12-10 20:19:08 +07:00
|
|
|
const uint32_t *data = frame;
|
2012-05-05 03:18:24 +07:00
|
|
|
struct drm_device *dev = encoder->dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-05-15 03:12:50 +07:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
|
2013-08-07 02:32:18 +07:00
|
|
|
int i, reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
2012-05-05 03:18:24 +07:00
|
|
|
u32 val = I915_READ(reg);
|
|
|
|
|
2012-05-29 02:42:51 +07:00
|
|
|
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
|
|
|
|
|
2012-05-05 03:18:24 +07:00
|
|
|
val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
|
2013-08-07 02:32:18 +07:00
|
|
|
val |= g4x_infoframe_index(type);
|
2012-05-05 03:18:24 +07:00
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
val &= ~g4x_infoframe_enable(type);
|
2012-05-05 03:18:24 +07:00
|
|
|
|
|
|
|
I915_WRITE(reg, val);
|
|
|
|
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2012-05-05 03:18:24 +07:00
|
|
|
for (i = 0; i < len; i += 4) {
|
|
|
|
I915_WRITE(TVIDEO_DIP_DATA(intel_crtc->pipe), *data);
|
|
|
|
data++;
|
|
|
|
}
|
2012-09-25 23:23:34 +07:00
|
|
|
/* Write every possible data byte to force correct ECC calculation. */
|
|
|
|
for (; i < VIDEO_DIP_DATA_SIZE; i += 4)
|
|
|
|
I915_WRITE(TVIDEO_DIP_DATA(intel_crtc->pipe), 0);
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2012-05-05 03:18:24 +07:00
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
val |= g4x_infoframe_enable(type);
|
2012-05-05 03:18:24 +07:00
|
|
|
val &= ~VIDEO_DIP_FREQ_MASK;
|
2012-05-08 19:41:00 +07:00
|
|
|
val |= VIDEO_DIP_FREQ_VSYNC;
|
2012-05-05 03:18:24 +07:00
|
|
|
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2012-05-05 03:18:24 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void cpt_write_infoframe(struct drm_encoder *encoder,
|
2013-08-07 02:32:18 +07:00
|
|
|
enum hdmi_infoframe_type type,
|
2013-12-10 20:19:08 +07:00
|
|
|
const void *frame, ssize_t len)
|
2011-07-09 01:31:57 +07:00
|
|
|
{
|
2013-12-10 20:19:08 +07:00
|
|
|
const uint32_t *data = frame;
|
2011-07-09 01:31:57 +07:00
|
|
|
struct drm_device *dev = encoder->dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-05-15 03:12:50 +07:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
|
2013-08-07 02:32:18 +07:00
|
|
|
int i, reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
2012-05-05 03:18:17 +07:00
|
|
|
u32 val = I915_READ(reg);
|
2011-07-09 01:31:57 +07:00
|
|
|
|
2012-05-29 02:42:51 +07:00
|
|
|
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
|
|
|
|
|
2011-09-22 12:46:00 +07:00
|
|
|
val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
|
2013-08-07 02:32:18 +07:00
|
|
|
val |= g4x_infoframe_index(type);
|
2011-08-03 23:22:55 +07:00
|
|
|
|
2012-05-05 03:18:21 +07:00
|
|
|
/* The DIP control register spec says that we need to update the AVI
|
|
|
|
* infoframe without clearing its enable bit */
|
2013-08-07 02:32:18 +07:00
|
|
|
if (type != HDMI_INFOFRAME_TYPE_AVI)
|
|
|
|
val &= ~g4x_infoframe_enable(type);
|
2012-05-05 03:18:21 +07:00
|
|
|
|
2012-05-05 03:18:17 +07:00
|
|
|
I915_WRITE(reg, val);
|
2011-08-03 23:22:55 +07:00
|
|
|
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2011-08-03 23:22:55 +07:00
|
|
|
for (i = 0; i < len; i += 4) {
|
2011-07-09 01:31:57 +07:00
|
|
|
I915_WRITE(TVIDEO_DIP_DATA(intel_crtc->pipe), *data);
|
|
|
|
data++;
|
|
|
|
}
|
2012-09-25 23:23:34 +07:00
|
|
|
/* Write every possible data byte to force correct ECC calculation. */
|
|
|
|
for (; i < VIDEO_DIP_DATA_SIZE; i += 4)
|
|
|
|
I915_WRITE(TVIDEO_DIP_DATA(intel_crtc->pipe), 0);
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2011-07-09 01:31:57 +07:00
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
val |= g4x_infoframe_enable(type);
|
2012-05-05 03:18:22 +07:00
|
|
|
val &= ~VIDEO_DIP_FREQ_MASK;
|
2012-05-08 19:41:00 +07:00
|
|
|
val |= VIDEO_DIP_FREQ_VSYNC;
|
2011-08-03 23:22:55 +07:00
|
|
|
|
2012-05-05 03:18:17 +07:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2011-08-03 23:22:55 +07:00
|
|
|
}
|
2012-03-29 03:39:32 +07:00
|
|
|
|
|
|
|
static void vlv_write_infoframe(struct drm_encoder *encoder,
|
2013-08-07 02:32:18 +07:00
|
|
|
enum hdmi_infoframe_type type,
|
2013-12-10 20:19:08 +07:00
|
|
|
const void *frame, ssize_t len)
|
2012-03-29 03:39:32 +07:00
|
|
|
{
|
2013-12-10 20:19:08 +07:00
|
|
|
const uint32_t *data = frame;
|
2012-03-29 03:39:32 +07:00
|
|
|
struct drm_device *dev = encoder->dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-05-15 03:12:50 +07:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
|
2013-08-07 02:32:18 +07:00
|
|
|
int i, reg = VLV_TVIDEO_DIP_CTL(intel_crtc->pipe);
|
2012-05-05 03:18:17 +07:00
|
|
|
u32 val = I915_READ(reg);
|
2012-03-29 03:39:32 +07:00
|
|
|
|
2012-05-29 02:42:51 +07:00
|
|
|
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
|
|
|
|
|
2012-03-29 03:39:32 +07:00
|
|
|
val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
|
2013-08-07 02:32:18 +07:00
|
|
|
val |= g4x_infoframe_index(type);
|
2012-05-05 03:18:17 +07:00
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
val &= ~g4x_infoframe_enable(type);
|
2012-03-29 03:39:32 +07:00
|
|
|
|
2012-05-05 03:18:17 +07:00
|
|
|
I915_WRITE(reg, val);
|
2012-03-29 03:39:32 +07:00
|
|
|
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2012-03-29 03:39:32 +07:00
|
|
|
for (i = 0; i < len; i += 4) {
|
|
|
|
I915_WRITE(VLV_TVIDEO_DIP_DATA(intel_crtc->pipe), *data);
|
|
|
|
data++;
|
|
|
|
}
|
2012-09-25 23:23:34 +07:00
|
|
|
/* Write every possible data byte to force correct ECC calculation. */
|
|
|
|
for (; i < VIDEO_DIP_DATA_SIZE; i += 4)
|
|
|
|
I915_WRITE(VLV_TVIDEO_DIP_DATA(intel_crtc->pipe), 0);
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2012-03-29 03:39:32 +07:00
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
val |= g4x_infoframe_enable(type);
|
2012-05-05 03:18:22 +07:00
|
|
|
val &= ~VIDEO_DIP_FREQ_MASK;
|
2012-05-08 19:41:00 +07:00
|
|
|
val |= VIDEO_DIP_FREQ_VSYNC;
|
2012-03-29 03:39:32 +07:00
|
|
|
|
2012-05-05 03:18:17 +07:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2012-03-29 03:39:32 +07:00
|
|
|
}
|
|
|
|
|
2012-05-10 20:18:02 +07:00
|
|
|
static void hsw_write_infoframe(struct drm_encoder *encoder,
|
2013-08-07 02:32:18 +07:00
|
|
|
enum hdmi_infoframe_type type,
|
2013-12-10 20:19:08 +07:00
|
|
|
const void *frame, ssize_t len)
|
2012-05-10 20:18:02 +07:00
|
|
|
{
|
2013-12-10 20:19:08 +07:00
|
|
|
const uint32_t *data = frame;
|
2012-05-15 03:12:51 +07:00
|
|
|
struct drm_device *dev = encoder->dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
|
2013-04-18 01:15:07 +07:00
|
|
|
u32 ctl_reg = HSW_TVIDEO_DIP_CTL(intel_crtc->config.cpu_transcoder);
|
2013-08-07 02:32:18 +07:00
|
|
|
u32 data_reg;
|
|
|
|
int i;
|
2012-05-15 03:12:51 +07:00
|
|
|
u32 val = I915_READ(ctl_reg);
|
2012-05-10 20:18:02 +07:00
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
data_reg = hsw_infoframe_data_reg(type,
|
drm/i915: Reorganize display pipe register accesses
RFCv2: Reorganize array indexing so that full offsets can be used as
is. It makes grepping for registers in i915_reg.h much easier. Also
move offset arrays to intel_device_info.
v1: Fixed offsets for VLV, proper eDP handling
v2: Fixed BCLRPAT, PIPESRC, PIPECONF and DSP* macros.
v3: Added EDP pipe comment, removed redundant offset arrays for
MSA_MISC and DDI_FUNC_CTL.
v4: Rename patch and report object size increase.
v5: Change location of commas, add PIPE_EDP into enum pipe
v6: Insert PIPE_EDP_OFFSET into pipe offset array
v7: Set I915_MAX_PIPES back to 3, change more registers accessors
to use the new macros, get rid of _PIPE_INC and add dev_priv
as a parameter where required by the new macros.
Upcoming hardware will not have the various display pipe register
ranges evenly spaced in memory. Change register address calculations
into array lookups.
Tested on SNB, VLV, IVB, Gen2 and HSW w/eDP.
I left the UMS cruft untouched.
Size differences:
text data bss dec hex filename
596431 4634 56 601121 92c21 i915.ko (new)
593199 4634 56 597889 91f81 i915.ko (old)
Signed-off-by: Antti Koskipaa <antti.koskipaa@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-02-04 19:22:24 +07:00
|
|
|
intel_crtc->config.cpu_transcoder,
|
|
|
|
dev_priv);
|
2012-05-15 03:12:51 +07:00
|
|
|
if (data_reg == 0)
|
|
|
|
return;
|
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
val &= ~hsw_infoframe_enable(type);
|
2012-05-15 03:12:51 +07:00
|
|
|
I915_WRITE(ctl_reg, val);
|
|
|
|
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2012-05-15 03:12:51 +07:00
|
|
|
for (i = 0; i < len; i += 4) {
|
|
|
|
I915_WRITE(data_reg + i, *data);
|
|
|
|
data++;
|
|
|
|
}
|
2012-09-25 23:23:34 +07:00
|
|
|
/* Write every possible data byte to force correct ECC calculation. */
|
|
|
|
for (; i < VIDEO_DIP_DATA_SIZE; i += 4)
|
|
|
|
I915_WRITE(data_reg + i, 0);
|
2012-05-29 02:43:00 +07:00
|
|
|
mmiowb();
|
2012-05-10 20:18:02 +07:00
|
|
|
|
2013-08-07 02:32:18 +07:00
|
|
|
val |= hsw_infoframe_enable(type);
|
2012-05-15 03:12:51 +07:00
|
|
|
I915_WRITE(ctl_reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(ctl_reg);
|
2012-05-10 20:18:02 +07:00
|
|
|
}
|
|
|
|
|
2013-08-07 02:32:19 +07:00
|
|
|
/*
|
|
|
|
* The data we write to the DIP data buffer registers is 1 byte bigger than the
|
|
|
|
* HDMI infoframe size because of an ECC/reserved byte at position 3 (starting
|
|
|
|
* at 0). It's also a byte used by DisplayPort so the same DIP registers can be
|
|
|
|
* used for both technologies.
|
|
|
|
*
|
|
|
|
* DW0: Reserved/ECC/DP | HB2 | HB1 | HB0
|
|
|
|
* DW1: DB3 | DB2 | DB1 | DB0
|
|
|
|
* DW2: DB7 | DB6 | DB5 | DB4
|
|
|
|
* DW3: ...
|
|
|
|
*
|
|
|
|
* (HB is Header Byte, DB is Data Byte)
|
|
|
|
*
|
|
|
|
* The hdmi pack() functions don't know about that hardware specific hole so we
|
|
|
|
* trick them by giving an offset into the buffer and moving back the header
|
|
|
|
* bytes by one.
|
|
|
|
*/
|
2013-08-07 02:32:24 +07:00
|
|
|
static void intel_write_infoframe(struct drm_encoder *encoder,
|
|
|
|
union hdmi_infoframe *frame)
|
2011-08-03 23:22:55 +07:00
|
|
|
{
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
|
2013-08-07 02:32:19 +07:00
|
|
|
uint8_t buffer[VIDEO_DIP_DATA_SIZE];
|
|
|
|
ssize_t len;
|
2011-08-03 23:22:55 +07:00
|
|
|
|
2013-08-07 02:32:19 +07:00
|
|
|
/* see comment above for the reason for this offset */
|
|
|
|
len = hdmi_infoframe_pack(frame, buffer + 1, sizeof(buffer) - 1);
|
|
|
|
if (len < 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Insert the 'hole' (see big comment above) at position 3 */
|
|
|
|
buffer[0] = buffer[1];
|
|
|
|
buffer[1] = buffer[2];
|
|
|
|
buffer[2] = buffer[3];
|
|
|
|
buffer[3] = 0;
|
|
|
|
len++;
|
2011-08-03 23:22:55 +07:00
|
|
|
|
2013-08-07 02:32:19 +07:00
|
|
|
intel_hdmi->write_infoframe(encoder, frame->any.type, buffer, len);
|
2011-08-03 23:22:55 +07:00
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:48 +07:00
|
|
|
static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
|
2012-04-14 02:31:41 +07:00
|
|
|
struct drm_display_mode *adjusted_mode)
|
2011-08-03 23:22:55 +07:00
|
|
|
{
|
2013-01-17 21:31:31 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
|
2013-03-27 06:44:56 +07:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
|
2013-08-07 02:32:19 +07:00
|
|
|
union hdmi_infoframe frame;
|
|
|
|
int ret;
|
2011-08-03 23:22:55 +07:00
|
|
|
|
2013-08-07 02:32:19 +07:00
|
|
|
ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
|
|
|
|
adjusted_mode);
|
|
|
|
if (ret < 0) {
|
|
|
|
DRM_ERROR("couldn't fill AVI infoframe\n");
|
|
|
|
return;
|
|
|
|
}
|
2012-04-14 02:31:41 +07:00
|
|
|
|
2013-01-17 21:31:31 +07:00
|
|
|
if (intel_hdmi->rgb_quant_range_selectable) {
|
2013-03-27 06:44:56 +07:00
|
|
|
if (intel_crtc->config.limited_color_range)
|
2013-08-07 02:32:19 +07:00
|
|
|
frame.avi.quantization_range =
|
|
|
|
HDMI_QUANTIZATION_RANGE_LIMITED;
|
2013-01-17 21:31:31 +07:00
|
|
|
else
|
2013-08-07 02:32:19 +07:00
|
|
|
frame.avi.quantization_range =
|
|
|
|
HDMI_QUANTIZATION_RANGE_FULL;
|
2013-01-17 21:31:31 +07:00
|
|
|
}
|
|
|
|
|
2013-08-07 02:32:24 +07:00
|
|
|
intel_write_infoframe(encoder, &frame);
|
2011-07-09 01:31:57 +07:00
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:48 +07:00
|
|
|
static void intel_hdmi_set_spd_infoframe(struct drm_encoder *encoder)
|
2011-08-03 23:22:56 +07:00
|
|
|
{
|
2013-08-07 02:32:19 +07:00
|
|
|
union hdmi_infoframe frame;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = hdmi_spd_infoframe_init(&frame.spd, "Intel", "Integrated gfx");
|
|
|
|
if (ret < 0) {
|
|
|
|
DRM_ERROR("couldn't fill SPD infoframe\n");
|
|
|
|
return;
|
|
|
|
}
|
2011-08-03 23:22:56 +07:00
|
|
|
|
2013-08-07 02:32:19 +07:00
|
|
|
frame.spd.sdi = HDMI_SPD_SDI_PC;
|
2011-08-03 23:22:56 +07:00
|
|
|
|
2013-08-07 02:32:24 +07:00
|
|
|
intel_write_infoframe(encoder, &frame);
|
2011-08-03 23:22:56 +07:00
|
|
|
}
|
|
|
|
|
2013-08-19 22:59:04 +07:00
|
|
|
static void
|
|
|
|
intel_hdmi_set_hdmi_infoframe(struct drm_encoder *encoder,
|
|
|
|
struct drm_display_mode *adjusted_mode)
|
|
|
|
{
|
|
|
|
union hdmi_infoframe frame;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
|
|
|
|
adjusted_mode);
|
|
|
|
if (ret < 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
intel_write_infoframe(encoder, &frame);
|
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:48 +07:00
|
|
|
static void g4x_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 04:54:47 +07:00
|
|
|
bool enable,
|
2012-05-29 02:42:48 +07:00
|
|
|
struct drm_display_mode *adjusted_mode)
|
|
|
|
{
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
struct drm_i915_private *dev_priv = encoder->dev->dev_private;
|
2013-01-24 20:29:26 +07:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
|
|
|
struct intel_hdmi *intel_hdmi = &intel_dig_port->hdmi;
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
u32 reg = VIDEO_DIP_CTL;
|
|
|
|
u32 val = I915_READ(reg);
|
2014-01-24 04:15:34 +07:00
|
|
|
u32 port = VIDEO_DIP_PORT(intel_dig_port->port);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
|
2012-06-12 21:36:45 +07:00
|
|
|
assert_hdmi_port_disabled(intel_hdmi);
|
|
|
|
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
/* If the registers were not initialized yet, they might be zeroes,
|
|
|
|
* which means we're selecting the AVI DIP and we're setting its
|
|
|
|
* frequency to once. This seems to really confuse the HW and make
|
|
|
|
* things stop working (the register spec says the AVI always needs to
|
|
|
|
* be sent every VSync). So here we avoid writing to the register more
|
|
|
|
* than we need and also explicitly select the AVI DIP and explicitly
|
|
|
|
* set its frequency to every VSync. Avoiding to write it twice seems to
|
|
|
|
* be enough to solve the problem, but being defensive shouldn't hurt us
|
|
|
|
* either. */
|
|
|
|
val |= VIDEO_DIP_SELECT_AVI | VIDEO_DIP_FREQ_VSYNC;
|
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
if (!enable) {
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
if (!(val & VIDEO_DIP_ENABLE))
|
|
|
|
return;
|
|
|
|
val &= ~VIDEO_DIP_ENABLE;
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:54 +07:00
|
|
|
if (port != (val & VIDEO_DIP_PORT_MASK)) {
|
|
|
|
if (val & VIDEO_DIP_ENABLE) {
|
|
|
|
val &= ~VIDEO_DIP_ENABLE;
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 02:42:54 +07:00
|
|
|
}
|
|
|
|
val &= ~VIDEO_DIP_PORT_MASK;
|
|
|
|
val |= port;
|
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:51 +07:00
|
|
|
val |= VIDEO_DIP_ENABLE;
|
2012-05-29 02:42:53 +07:00
|
|
|
val &= ~VIDEO_DIP_ENABLE_VENDOR;
|
2012-05-29 02:42:51 +07:00
|
|
|
|
2012-05-29 02:42:50 +07:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 02:42:50 +07:00
|
|
|
|
2012-05-29 02:42:48 +07:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder);
|
2013-08-19 22:59:04 +07:00
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
|
2012-05-29 02:42:48 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void ibx_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 04:54:47 +07:00
|
|
|
bool enable,
|
2012-05-29 02:42:48 +07:00
|
|
|
struct drm_display_mode *adjusted_mode)
|
|
|
|
{
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
struct drm_i915_private *dev_priv = encoder->dev->dev_private;
|
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
|
2013-01-24 20:29:26 +07:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
|
|
|
struct intel_hdmi *intel_hdmi = &intel_dig_port->hdmi;
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
u32 reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
|
|
|
u32 val = I915_READ(reg);
|
2014-01-24 04:15:34 +07:00
|
|
|
u32 port = VIDEO_DIP_PORT(intel_dig_port->port);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
|
2012-06-12 21:36:45 +07:00
|
|
|
assert_hdmi_port_disabled(intel_hdmi);
|
|
|
|
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
/* See the big comment in g4x_set_infoframes() */
|
|
|
|
val |= VIDEO_DIP_SELECT_AVI | VIDEO_DIP_FREQ_VSYNC;
|
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
if (!enable) {
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
if (!(val & VIDEO_DIP_ENABLE))
|
|
|
|
return;
|
|
|
|
val &= ~VIDEO_DIP_ENABLE;
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:54 +07:00
|
|
|
if (port != (val & VIDEO_DIP_PORT_MASK)) {
|
|
|
|
if (val & VIDEO_DIP_ENABLE) {
|
|
|
|
val &= ~VIDEO_DIP_ENABLE;
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 02:42:54 +07:00
|
|
|
}
|
|
|
|
val &= ~VIDEO_DIP_PORT_MASK;
|
|
|
|
val |= port;
|
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:51 +07:00
|
|
|
val |= VIDEO_DIP_ENABLE;
|
2012-05-29 02:42:53 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_GCP);
|
2012-05-29 02:42:51 +07:00
|
|
|
|
2012-05-29 02:42:50 +07:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 02:42:50 +07:00
|
|
|
|
2012-05-29 02:42:48 +07:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder);
|
2013-08-19 22:59:04 +07:00
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
|
2012-05-29 02:42:48 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void cpt_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 04:54:47 +07:00
|
|
|
bool enable,
|
2012-05-29 02:42:48 +07:00
|
|
|
struct drm_display_mode *adjusted_mode)
|
|
|
|
{
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
struct drm_i915_private *dev_priv = encoder->dev->dev_private;
|
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
|
|
|
|
u32 reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
|
|
|
u32 val = I915_READ(reg);
|
|
|
|
|
2012-06-12 21:36:45 +07:00
|
|
|
assert_hdmi_port_disabled(intel_hdmi);
|
|
|
|
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
/* See the big comment in g4x_set_infoframes() */
|
|
|
|
val |= VIDEO_DIP_SELECT_AVI | VIDEO_DIP_FREQ_VSYNC;
|
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
if (!enable) {
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
if (!(val & VIDEO_DIP_ENABLE))
|
|
|
|
return;
|
|
|
|
val &= ~(VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI);
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:51 +07:00
|
|
|
/* Set both together, unset both together: see the spec. */
|
|
|
|
val |= VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI;
|
2012-05-29 02:42:53 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_GCP);
|
2012-05-29 02:42:51 +07:00
|
|
|
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 02:42:51 +07:00
|
|
|
|
2012-05-29 02:42:48 +07:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder);
|
2013-08-19 22:59:04 +07:00
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
|
2012-05-29 02:42:48 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void vlv_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 04:54:47 +07:00
|
|
|
bool enable,
|
2012-05-29 02:42:48 +07:00
|
|
|
struct drm_display_mode *adjusted_mode)
|
|
|
|
{
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
struct drm_i915_private *dev_priv = encoder->dev->dev_private;
|
2014-04-03 00:08:51 +07:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
|
|
|
|
u32 reg = VLV_TVIDEO_DIP_CTL(intel_crtc->pipe);
|
|
|
|
u32 val = I915_READ(reg);
|
2014-04-03 00:08:51 +07:00
|
|
|
u32 port = VIDEO_DIP_PORT(intel_dig_port->port);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
|
2012-06-12 21:36:45 +07:00
|
|
|
assert_hdmi_port_disabled(intel_hdmi);
|
|
|
|
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
/* See the big comment in g4x_set_infoframes() */
|
|
|
|
val |= VIDEO_DIP_SELECT_AVI | VIDEO_DIP_FREQ_VSYNC;
|
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
if (!enable) {
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
if (!(val & VIDEO_DIP_ENABLE))
|
|
|
|
return;
|
|
|
|
val &= ~VIDEO_DIP_ENABLE;
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-04-03 00:08:51 +07:00
|
|
|
if (port != (val & VIDEO_DIP_PORT_MASK)) {
|
|
|
|
if (val & VIDEO_DIP_ENABLE) {
|
|
|
|
val &= ~VIDEO_DIP_ENABLE;
|
|
|
|
I915_WRITE(reg, val);
|
|
|
|
POSTING_READ(reg);
|
|
|
|
}
|
|
|
|
val &= ~VIDEO_DIP_PORT_MASK;
|
|
|
|
val |= port;
|
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:51 +07:00
|
|
|
val |= VIDEO_DIP_ENABLE;
|
2014-04-03 00:08:52 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_AVI | VIDEO_DIP_ENABLE_VENDOR |
|
|
|
|
VIDEO_DIP_ENABLE_GAMUT | VIDEO_DIP_ENABLE_GCP);
|
2012-05-29 02:42:51 +07:00
|
|
|
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 02:42:51 +07:00
|
|
|
|
2012-05-29 02:42:48 +07:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder);
|
2013-08-19 22:59:04 +07:00
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
|
2012-05-29 02:42:48 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void hsw_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 04:54:47 +07:00
|
|
|
bool enable,
|
2012-05-29 02:42:48 +07:00
|
|
|
struct drm_display_mode *adjusted_mode)
|
|
|
|
{
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
struct drm_i915_private *dev_priv = encoder->dev->dev_private;
|
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->crtc);
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
|
2013-04-18 01:15:07 +07:00
|
|
|
u32 reg = HSW_TVIDEO_DIP_CTL(intel_crtc->config.cpu_transcoder);
|
2012-05-29 02:42:53 +07:00
|
|
|
u32 val = I915_READ(reg);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
|
2012-06-12 21:36:45 +07:00
|
|
|
assert_hdmi_port_disabled(intel_hdmi);
|
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
if (!enable) {
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
I915_WRITE(reg, 0);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
drm/i915: properly alternate between DVI and HDMI
This solves problems that happen when you alternate between HDMI and
DVI on the same port. I can reproduce these problems using DP->HDMI
and DP->DVI adapters on a DP port.
When you first plug HDMI and then plug DVI, you need to stop sending
DIPs, even if the port is in DVI mode (see the HDMI register spec). If
you don't stop sending DIPs, you'll see a pink vertical line on the
left side of the screen, some modes will give you a black screen, some
modes won't work correctly.
When you first plug DVI and then plug HDMI, you need to properly
enable the DIPs, otherwise the HW won't send them. After spending a
lot of time investigating this, I concluded that if the DIPs are
disabled, we should not write to the DIP register again because when
we do this, we also set the AVI InfoFrame frequency to "once", and
this seems to really confuse our hardware. Since this problem was not
exactly easy to debug, I'm adopting the defensive behavior and not
just avoing the "disable twice" sequence, but also explicitly
selecting the AVI InfoFrame and setting its frequency to a correct
one.
Also, move the "is_dvi" check from intel_set_infoframe to the
set_infoframes functions since now they're going to be the first ones
to deal with the DIP registers.
This patch adds the code to fix the problem, but it depends on the
removal of some code that can't be removed right now and will come
later in the patch series. The patch that we need is:
- drm/i915: don't write 0 to DIP control at HDMI init
[danvet: Paulo clarified that this additional patch is only required
to make the fix complete, this patch here alone doesn't introduce a
regression but only partially solves the problem of randomly clearing
the dip registers.]
V2: Be even more defensive by selecting AVI and setting its frequency
outside the "is_dvi" check.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-29 02:42:49 +07:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:53 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_GCP_HSW |
|
|
|
|
VIDEO_DIP_ENABLE_VS_HSW | VIDEO_DIP_ENABLE_GMP_HSW);
|
|
|
|
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 02:43:00 +07:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 02:42:53 +07:00
|
|
|
|
2012-05-29 02:42:48 +07:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, adjusted_mode);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder);
|
2013-08-19 22:59:04 +07:00
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, adjusted_mode);
|
2012-05-29 02:42:48 +07:00
|
|
|
}
|
|
|
|
|
2014-04-25 04:54:56 +07:00
|
|
|
static void intel_hdmi_prepare(struct intel_encoder *encoder)
|
2009-01-03 04:33:00 +07:00
|
|
|
{
|
2013-07-22 02:37:04 +07:00
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2009-01-03 04:33:00 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2013-07-22 02:37:04 +07:00
|
|
|
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
struct drm_display_mode *adjusted_mode = &crtc->config.adjusted_mode;
|
2013-02-19 05:00:26 +07:00
|
|
|
u32 hdmi_val;
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
hdmi_val = SDVO_ENCODING_HDMI;
|
2013-06-25 18:16:34 +07:00
|
|
|
if (!HAS_PCH_SPLIT(dev))
|
2013-02-19 05:00:26 +07:00
|
|
|
hdmi_val |= intel_hdmi->color_range;
|
2010-07-17 01:46:31 +07:00
|
|
|
if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
|
2013-02-19 05:00:26 +07:00
|
|
|
hdmi_val |= SDVO_VSYNC_ACTIVE_HIGH;
|
2010-07-17 01:46:31 +07:00
|
|
|
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
|
2013-02-19 05:00:26 +07:00
|
|
|
hdmi_val |= SDVO_HSYNC_ACTIVE_HIGH;
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2013-07-22 02:37:04 +07:00
|
|
|
if (crtc->config.pipe_bpp > 24)
|
2013-02-20 02:21:47 +07:00
|
|
|
hdmi_val |= HDMI_COLOR_FORMAT_12bpc;
|
2011-06-25 02:19:25 +07:00
|
|
|
else
|
2013-02-20 02:21:47 +07:00
|
|
|
hdmi_val |= SDVO_COLOR_FORMAT_8bpc;
|
2011-06-25 02:19:25 +07:00
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
if (crtc->config.has_hdmi_sink)
|
2013-02-20 02:21:46 +07:00
|
|
|
hdmi_val |= HDMI_MODE_SELECT_HDMI;
|
2010-09-10 09:39:40 +07:00
|
|
|
|
2014-04-25 04:54:52 +07:00
|
|
|
if (crtc->config.has_audio) {
|
2014-04-25 04:54:47 +07:00
|
|
|
WARN_ON(!crtc->config.has_hdmi_sink);
|
drm/i915: pass ELD to HDMI/DP audio driver
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake,
SandyBridge/CougarPoint and IvyBridge/PantherPoint chips.
ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio
capabilities of the plugged monitor. It's built and passed to audio
driver in 2 steps:
(1) at get_modes time, parse EDID and save ELD to drm_connector.eld[]
(2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw
ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver
This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP.
Test scheme: plug in the HDMI/DP monitor, and run
cat /proc/asound/card0/eld*
to check if the monitor name, HDMI/DP type, etc. show up correctly.
Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always
reads 0 (reserved). Without knowing the port number, I worked it around
by setting the ELD_valid bit for ALL the three ports. It's tested to not
be a problem, because the audio driver will find invalid ELD data and
hence rightfully abort, even when it sees the ELD_valid indicator.
Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing.
CC: Zhao Yakui <yakui.zhao@intel.com>
CC: Wang Zhenyu <zhenyu.z.wang@intel.com>
CC: Jeremy Bush <contractfrombelow@gmail.com>
CC: Christopher White <c.white@pulseforce.com>
CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com>
CC: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Wu Fengguang <fengguang.wu@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
2011-09-05 13:25:34 +07:00
|
|
|
DRM_DEBUG_DRIVER("Enabling HDMI audio on pipe %c\n",
|
2013-07-22 02:37:04 +07:00
|
|
|
pipe_name(crtc->pipe));
|
2013-02-19 05:00:26 +07:00
|
|
|
hdmi_val |= SDVO_AUDIO_ENABLE;
|
2013-07-22 02:37:04 +07:00
|
|
|
intel_write_eld(&encoder->base, adjusted_mode);
|
2010-09-25 02:44:32 +07:00
|
|
|
}
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2011-10-12 23:01:58 +07:00
|
|
|
if (HAS_PCH_CPT(dev))
|
2013-07-22 02:37:04 +07:00
|
|
|
hdmi_val |= SDVO_PIPE_SEL_CPT(crtc->pipe);
|
2014-04-09 17:28:21 +07:00
|
|
|
else if (IS_CHERRYVIEW(dev))
|
|
|
|
hdmi_val |= SDVO_PIPE_SEL_CHV(crtc->pipe);
|
2013-02-20 02:21:46 +07:00
|
|
|
else
|
2013-07-22 02:37:04 +07:00
|
|
|
hdmi_val |= SDVO_PIPE_SEL(crtc->pipe);
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, hdmi_val);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|
|
|
|
|
2012-07-02 18:27:29 +07:00
|
|
|
static bool intel_hdmi_get_hw_state(struct intel_encoder *encoder,
|
|
|
|
enum pipe *pipe)
|
2009-01-03 04:33:00 +07:00
|
|
|
{
|
2012-07-02 18:27:29 +07:00
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2009-01-03 04:33:00 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-07-02 18:27:29 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
2014-03-05 21:20:54 +07:00
|
|
|
enum intel_display_power_domain power_domain;
|
2012-07-02 18:27:29 +07:00
|
|
|
u32 tmp;
|
|
|
|
|
2014-03-05 21:20:54 +07:00
|
|
|
power_domain = intel_display_port_power_domain(encoder);
|
|
|
|
if (!intel_display_power_enabled(dev_priv, power_domain))
|
|
|
|
return false;
|
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
tmp = I915_READ(intel_hdmi->hdmi_reg);
|
2012-07-02 18:27:29 +07:00
|
|
|
|
|
|
|
if (!(tmp & SDVO_ENABLE))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (HAS_PCH_CPT(dev))
|
|
|
|
*pipe = PORT_TO_PIPE_CPT(tmp);
|
2014-04-09 17:28:55 +07:00
|
|
|
else if (IS_CHERRYVIEW(dev))
|
|
|
|
*pipe = SDVO_PORT_TO_PIPE_CHV(tmp);
|
2012-07-02 18:27:29 +07:00
|
|
|
else
|
|
|
|
*pipe = PORT_TO_PIPE(tmp);
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-05-15 07:08:26 +07:00
|
|
|
static void intel_hdmi_get_config(struct intel_encoder *encoder,
|
|
|
|
struct intel_crtc_config *pipe_config)
|
|
|
|
{
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
|
|
|
|
u32 tmp, flags = 0;
|
2013-09-13 20:00:08 +07:00
|
|
|
int dotclock;
|
2013-05-15 07:08:26 +07:00
|
|
|
|
|
|
|
tmp = I915_READ(intel_hdmi->hdmi_reg);
|
|
|
|
|
|
|
|
if (tmp & SDVO_HSYNC_ACTIVE_HIGH)
|
|
|
|
flags |= DRM_MODE_FLAG_PHSYNC;
|
|
|
|
else
|
|
|
|
flags |= DRM_MODE_FLAG_NHSYNC;
|
|
|
|
|
|
|
|
if (tmp & SDVO_VSYNC_ACTIVE_HIGH)
|
|
|
|
flags |= DRM_MODE_FLAG_PVSYNC;
|
|
|
|
else
|
|
|
|
flags |= DRM_MODE_FLAG_NVSYNC;
|
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
if (tmp & HDMI_MODE_SELECT_HDMI)
|
|
|
|
pipe_config->has_hdmi_sink = true;
|
|
|
|
|
2014-04-25 04:54:52 +07:00
|
|
|
if (tmp & HDMI_MODE_SELECT_HDMI)
|
|
|
|
pipe_config->has_audio = true;
|
|
|
|
|
2013-05-15 07:08:26 +07:00
|
|
|
pipe_config->adjusted_mode.flags |= flags;
|
2013-09-13 20:00:08 +07:00
|
|
|
|
|
|
|
if ((tmp & SDVO_COLOR_FORMAT_MASK) == HDMI_COLOR_FORMAT_12bpc)
|
|
|
|
dotclock = pipe_config->port_clock * 2 / 3;
|
|
|
|
else
|
|
|
|
dotclock = pipe_config->port_clock;
|
|
|
|
|
|
|
|
if (HAS_PCH_SPLIT(dev_priv->dev))
|
|
|
|
ironlake_check_encoder_dotclock(pipe_config, dotclock);
|
|
|
|
|
2013-09-25 22:45:37 +07:00
|
|
|
pipe_config->adjusted_mode.crtc_clock = dotclock;
|
2013-05-15 07:08:26 +07:00
|
|
|
}
|
|
|
|
|
2012-06-30 13:59:56 +07:00
|
|
|
static void intel_enable_hdmi(struct intel_encoder *encoder)
|
2009-01-03 04:33:00 +07:00
|
|
|
{
|
2012-06-30 13:59:56 +07:00
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2009-01-03 04:33:00 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2013-02-20 02:21:46 +07:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
|
2012-06-30 13:59:56 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
2009-01-03 04:33:00 +07:00
|
|
|
u32 temp;
|
2011-12-09 19:42:20 +07:00
|
|
|
u32 enable_bits = SDVO_ENABLE;
|
|
|
|
|
2014-04-25 04:54:52 +07:00
|
|
|
if (intel_crtc->config.has_audio)
|
2011-12-09 19:42:20 +07:00
|
|
|
enable_bits |= SDVO_AUDIO_ENABLE;
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
temp = I915_READ(intel_hdmi->hdmi_reg);
|
2009-11-02 14:52:30 +07:00
|
|
|
|
2012-06-05 16:03:39 +07:00
|
|
|
/* HW workaround for IBX, we need to move the port to transcoder A
|
2013-02-20 02:21:46 +07:00
|
|
|
* before disabling it, so restore the transcoder select bit here. */
|
|
|
|
if (HAS_PCH_IBX(dev))
|
|
|
|
enable_bits |= SDVO_PIPE_SEL(intel_crtc->pipe);
|
2012-06-05 16:03:39 +07:00
|
|
|
|
2009-11-02 14:52:30 +07:00
|
|
|
/* HW workaround, need to toggle enable bit off and on for 12bpc, but
|
|
|
|
* we do this anyway which shows more stable in testing.
|
|
|
|
*/
|
2010-01-29 07:45:52 +07:00
|
|
|
if (HAS_PCH_SPLIT(dev)) {
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp & ~SDVO_ENABLE);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2009-11-02 14:52:30 +07:00
|
|
|
}
|
|
|
|
|
2012-06-30 13:59:56 +07:00
|
|
|
temp |= enable_bits;
|
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2012-06-30 13:59:56 +07:00
|
|
|
|
|
|
|
/* HW workaround, need to write this twice for issue that may result
|
|
|
|
* in first write getting masked.
|
|
|
|
*/
|
|
|
|
if (HAS_PCH_SPLIT(dev)) {
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|
2013-07-30 16:20:31 +07:00
|
|
|
}
|
2013-04-19 04:51:36 +07:00
|
|
|
|
2013-07-30 16:20:31 +07:00
|
|
|
static void vlv_enable_hdmi(struct intel_encoder *encoder)
|
|
|
|
{
|
2012-06-30 13:59:56 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void intel_disable_hdmi(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
u32 temp;
|
2012-09-13 10:19:00 +07:00
|
|
|
u32 enable_bits = SDVO_ENABLE | SDVO_AUDIO_ENABLE;
|
2012-06-30 13:59:56 +07:00
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
temp = I915_READ(intel_hdmi->hdmi_reg);
|
2012-06-30 13:59:56 +07:00
|
|
|
|
|
|
|
/* HW workaround for IBX, we need to move the port to transcoder A
|
|
|
|
* before disabling it. */
|
|
|
|
if (HAS_PCH_IBX(dev)) {
|
|
|
|
struct drm_crtc *crtc = encoder->base.crtc;
|
|
|
|
int pipe = crtc ? to_intel_crtc(crtc)->pipe : -1;
|
|
|
|
|
|
|
|
if (temp & SDVO_PIPE_B_SELECT) {
|
|
|
|
temp &= ~SDVO_PIPE_B_SELECT;
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2012-06-30 13:59:56 +07:00
|
|
|
|
|
|
|
/* Again we need to write this twice. */
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2012-06-30 13:59:56 +07:00
|
|
|
|
|
|
|
/* Transcoder selection bits only update
|
|
|
|
* effectively on vblank. */
|
|
|
|
if (crtc)
|
|
|
|
intel_wait_for_vblank(dev, pipe);
|
|
|
|
else
|
|
|
|
msleep(50);
|
|
|
|
}
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|
2009-11-02 14:52:30 +07:00
|
|
|
|
2012-06-30 13:59:56 +07:00
|
|
|
/* HW workaround, need to toggle enable bit off and on for 12bpc, but
|
|
|
|
* we do this anyway which shows more stable in testing.
|
|
|
|
*/
|
|
|
|
if (HAS_PCH_SPLIT(dev)) {
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp & ~SDVO_ENABLE);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2012-06-30 13:59:56 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
temp &= ~enable_bits;
|
2009-11-02 14:52:30 +07:00
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2009-11-02 14:52:30 +07:00
|
|
|
|
|
|
|
/* HW workaround, need to write this twice for issue that may result
|
|
|
|
* in first write getting masked.
|
|
|
|
*/
|
2010-01-29 07:45:52 +07:00
|
|
|
if (HAS_PCH_SPLIT(dev)) {
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2009-11-02 14:52:30 +07:00
|
|
|
}
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|
|
|
|
|
2014-03-27 16:08:45 +07:00
|
|
|
static int hdmi_portclock_limit(struct intel_hdmi *hdmi, bool respect_dvi_limit)
|
2013-07-22 23:02:39 +07:00
|
|
|
{
|
|
|
|
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
|
|
|
|
|
2014-03-27 16:08:45 +07:00
|
|
|
if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev))
|
2013-07-22 23:02:39 +07:00
|
|
|
return 165000;
|
2013-11-03 11:07:51 +07:00
|
|
|
else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8)
|
2013-07-22 23:02:39 +07:00
|
|
|
return 300000;
|
|
|
|
else
|
|
|
|
return 225000;
|
|
|
|
}
|
|
|
|
|
2013-11-28 22:29:18 +07:00
|
|
|
static enum drm_mode_status
|
|
|
|
intel_hdmi_mode_valid(struct drm_connector *connector,
|
|
|
|
struct drm_display_mode *mode)
|
2009-01-03 04:33:00 +07:00
|
|
|
{
|
2014-03-27 16:08:45 +07:00
|
|
|
if (mode->clock > hdmi_portclock_limit(intel_attached_hdmi(connector),
|
|
|
|
true))
|
2009-01-03 04:33:00 +07:00
|
|
|
return MODE_CLOCK_HIGH;
|
|
|
|
if (mode->clock < 20000)
|
2011-05-30 17:48:26 +07:00
|
|
|
return MODE_CLOCK_LOW;
|
2009-01-03 04:33:00 +07:00
|
|
|
|
|
|
|
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
|
|
|
|
return MODE_NO_DBLESCAN;
|
|
|
|
|
|
|
|
return MODE_OK;
|
|
|
|
}
|
|
|
|
|
2014-03-03 21:15:29 +07:00
|
|
|
static bool hdmi_12bpc_possible(struct intel_crtc *crtc)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = crtc->base.dev;
|
|
|
|
struct intel_encoder *encoder;
|
|
|
|
int count = 0, count_hdmi = 0;
|
|
|
|
|
|
|
|
if (!HAS_PCH_SPLIT(dev))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.head) {
|
|
|
|
if (encoder->new_crtc != crtc)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
count_hdmi += encoder->type == INTEL_OUTPUT_HDMI;
|
|
|
|
count++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HDMI 12bpc affects the clocks, so it's only possible
|
|
|
|
* when not cloning with other encoder types.
|
|
|
|
*/
|
|
|
|
return count_hdmi > 0 && count_hdmi == count;
|
|
|
|
}
|
|
|
|
|
2013-03-27 06:44:55 +07:00
|
|
|
bool intel_hdmi_compute_config(struct intel_encoder *encoder,
|
|
|
|
struct intel_crtc_config *pipe_config)
|
2009-01-03 04:33:00 +07:00
|
|
|
{
|
2013-03-27 06:44:55 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_display_mode *adjusted_mode = &pipe_config->adjusted_mode;
|
2013-09-25 22:45:37 +07:00
|
|
|
int clock_12bpc = pipe_config->adjusted_mode.crtc_clock * 3 / 2;
|
2014-03-27 16:08:45 +07:00
|
|
|
int portclock_limit = hdmi_portclock_limit(intel_hdmi, false);
|
drm/i915: implement fdi auto-dithering
So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.
The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.
But ports compute their state under the assumption that the bpp they
pick will be the one selected, e.g. the display port bw computations
won't work otherwise. Now we could adjust our code to again up-dither
to the computed DP link parameters, but that's pointless.
So instead when the pipe needs to adjust parameters we need to retry
the pipe_config computation at the encoder stage. Furthermore we need
to inform encoders that they should not increase bandwidth
requirements if possible. This is required for the hdmi code, which
prefers the pipe to up-dither to either of the two possible hdmi bpc
values.
LVDS has a similar requirement, although that's probably only
theoretical in nature: It's unlikely that we'll ever see an 8bpc
high-res lvds panel (which is required to hit the 2 fdi lane limit).
eDP is the only thing which could increase the pipe_bpp setting again,
even when in the retry-loop. This could hit the WARN. Two reasons for
not bothering:
- On many eDP panels we'll get a black screen if the bpp settings
don't match vbt. So failing the modeset is the right thing to do.
But since that also means it's the only way to light up the panel,
it should work. So we shouldn't be able to hit this WARN.
- There are still opens around the eDP panel handling, and maybe we
need additional tricks. Before that happens it's imo no use trying
to be too clever.
Worst case we just need to kill that WARN or maybe fail the compute
config stage if the eDP connector can't get the bpp setting it wants.
And since this can only happen with an fdi link in between and so for
pch eDP panels it's rather unlikely to blow up, if ever.
v2: Rebased on top of a bikeshed from Paulo.
v3: Improve commit message around eDP handling with the stuff
things with Imre.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-21 06:00:16 +07:00
|
|
|
int desired_bpp;
|
2013-01-17 21:31:28 +07:00
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
pipe_config->has_hdmi_sink = intel_hdmi->has_hdmi_sink;
|
|
|
|
|
2013-01-17 21:31:29 +07:00
|
|
|
if (intel_hdmi->color_range_auto) {
|
|
|
|
/* See CEA-861-E - 5.1 Default Encoding Parameters */
|
2014-04-25 04:54:47 +07:00
|
|
|
if (pipe_config->has_hdmi_sink &&
|
2012-12-20 21:41:44 +07:00
|
|
|
drm_match_cea_mode(adjusted_mode) > 1)
|
2013-02-20 02:21:47 +07:00
|
|
|
intel_hdmi->color_range = HDMI_COLOR_RANGE_16_235;
|
2013-01-17 21:31:29 +07:00
|
|
|
else
|
|
|
|
intel_hdmi->color_range = 0;
|
|
|
|
}
|
|
|
|
|
2013-01-17 21:31:28 +07:00
|
|
|
if (intel_hdmi->color_range)
|
2013-03-27 06:44:56 +07:00
|
|
|
pipe_config->limited_color_range = true;
|
2013-01-17 21:31:28 +07:00
|
|
|
|
2013-03-27 06:44:55 +07:00
|
|
|
if (HAS_PCH_SPLIT(dev) && !HAS_DDI(dev))
|
|
|
|
pipe_config->has_pch_encoder = true;
|
|
|
|
|
2014-04-25 04:54:52 +07:00
|
|
|
if (pipe_config->has_hdmi_sink && intel_hdmi->has_audio)
|
|
|
|
pipe_config->has_audio = true;
|
|
|
|
|
drm/i915: precompute pipe bpp before touching the hw
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the encoder and crtc functions, according to
whatever constraints there are.
3. Decide whether to use dither by comparing the stored plane bpp with
computed pipe_bpp.
There are a few slight functional changes in this patch:
- LVDS connector are now also going through the EDID clamping. But in
a 2nd change we now unconditionally force the lvds bpc value - this
shouldn't matter in reality when the panel setup is consistent, but
better safe than sorry.
- HDMI now forces the pipe_bpp to the selected value - I think that's
what we actually want, since otherwise at least the pixelclock
computations are wrong (I'm not sure whether the port would accept
e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
the next higher bpc value, since otherwise there's no way to make
use of the 12 bpc mode (since the next patch will remove the 12bpc
plane format, it doesn't exist).
Both of these changes are due to the removal of the
pipe_bpp = min(display_bpp, plane_bpp);
statement.
Another slight change is the reworking of the dp bpc code:
- For the mode_valid callback it's sufficient to only check whether
the mode would fit at the lowest bpc.
- The bandwidth computation code is a bit restructured: It now walks
all available bpp values in an outer loop and the codeblock that
computes derived values (once a good configuration is found) has been
moved out of the for loop maze. This is prep work to allow us to
successively fall back on bpc values, and also correctly support bpc
values != 8 or 6.
v2: Rebased on top of Paulo Zanoni's little refactoring to use more
drm dp helper functions.
v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
range work.
v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.
v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
in a later patch though again.
v6: Fix spelling in a comment.
v7: Debug output improvements for the bpp computation.
v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
things!
v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
was lost in a rebase.
v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
that. Still unsure whether this is the way to go, but at least 6bpc
for a 8bpc hdmi output seems to work.
v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
depth on DP. Adjust the code.
v12: Rebased.
v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
requested from Jesse Barnes.
v14: Split out the special 6BPC handling for DP, as requested by Jesse
Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-27 06:44:58 +07:00
|
|
|
/*
|
|
|
|
* HDMI is either 12 or 8, so if the display lets 10bpc sneak
|
|
|
|
* through, clamp it down. Note that g4x/vlv don't support 12bpc hdmi
|
2013-04-19 16:24:33 +07:00
|
|
|
* outputs. We also need to check that the higher clock still fits
|
|
|
|
* within limits.
|
drm/i915: precompute pipe bpp before touching the hw
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the encoder and crtc functions, according to
whatever constraints there are.
3. Decide whether to use dither by comparing the stored plane bpp with
computed pipe_bpp.
There are a few slight functional changes in this patch:
- LVDS connector are now also going through the EDID clamping. But in
a 2nd change we now unconditionally force the lvds bpc value - this
shouldn't matter in reality when the panel setup is consistent, but
better safe than sorry.
- HDMI now forces the pipe_bpp to the selected value - I think that's
what we actually want, since otherwise at least the pixelclock
computations are wrong (I'm not sure whether the port would accept
e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
the next higher bpc value, since otherwise there's no way to make
use of the 12 bpc mode (since the next patch will remove the 12bpc
plane format, it doesn't exist).
Both of these changes are due to the removal of the
pipe_bpp = min(display_bpp, plane_bpp);
statement.
Another slight change is the reworking of the dp bpc code:
- For the mode_valid callback it's sufficient to only check whether
the mode would fit at the lowest bpc.
- The bandwidth computation code is a bit restructured: It now walks
all available bpp values in an outer loop and the codeblock that
computes derived values (once a good configuration is found) has been
moved out of the for loop maze. This is prep work to allow us to
successively fall back on bpc values, and also correctly support bpc
values != 8 or 6.
v2: Rebased on top of Paulo Zanoni's little refactoring to use more
drm dp helper functions.
v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
range work.
v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.
v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
in a later patch though again.
v6: Fix spelling in a comment.
v7: Debug output improvements for the bpp computation.
v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
things!
v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
was lost in a rebase.
v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
that. Still unsure whether this is the way to go, but at least 6bpc
for a 8bpc hdmi output seems to work.
v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
depth on DP. Adjust the code.
v12: Rebased.
v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
requested from Jesse Barnes.
v14: Split out the special 6BPC handling for DP, as requested by Jesse
Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-27 06:44:58 +07:00
|
|
|
*/
|
2014-04-25 04:54:47 +07:00
|
|
|
if (pipe_config->pipe_bpp > 8*3 && pipe_config->has_hdmi_sink &&
|
2014-03-03 21:15:29 +07:00
|
|
|
clock_12bpc <= portclock_limit &&
|
|
|
|
hdmi_12bpc_possible(encoder->new_crtc)) {
|
drm/i915: implement fdi auto-dithering
So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.
The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.
But ports compute their state under the assumption that the bpp they
pick will be the one selected, e.g. the display port bw computations
won't work otherwise. Now we could adjust our code to again up-dither
to the computed DP link parameters, but that's pointless.
So instead when the pipe needs to adjust parameters we need to retry
the pipe_config computation at the encoder stage. Furthermore we need
to inform encoders that they should not increase bandwidth
requirements if possible. This is required for the hdmi code, which
prefers the pipe to up-dither to either of the two possible hdmi bpc
values.
LVDS has a similar requirement, although that's probably only
theoretical in nature: It's unlikely that we'll ever see an 8bpc
high-res lvds panel (which is required to hit the 2 fdi lane limit).
eDP is the only thing which could increase the pipe_bpp setting again,
even when in the retry-loop. This could hit the WARN. Two reasons for
not bothering:
- On many eDP panels we'll get a black screen if the bpp settings
don't match vbt. So failing the modeset is the right thing to do.
But since that also means it's the only way to light up the panel,
it should work. So we shouldn't be able to hit this WARN.
- There are still opens around the eDP panel handling, and maybe we
need additional tricks. Before that happens it's imo no use trying
to be too clever.
Worst case we just need to kill that WARN or maybe fail the compute
config stage if the eDP connector can't get the bpp setting it wants.
And since this can only happen with an fdi link in between and so for
pch eDP panels it's rather unlikely to blow up, if ever.
v2: Rebased on top of a bikeshed from Paulo.
v3: Improve commit message around eDP handling with the stuff
things with Imre.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-21 06:00:16 +07:00
|
|
|
DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
|
|
|
|
desired_bpp = 12*3;
|
2013-04-19 16:24:33 +07:00
|
|
|
|
|
|
|
/* Need to adjust the port link by 1.5x for 12bpc. */
|
2013-06-01 22:16:21 +07:00
|
|
|
pipe_config->port_clock = clock_12bpc;
|
drm/i915: precompute pipe bpp before touching the hw
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the encoder and crtc functions, according to
whatever constraints there are.
3. Decide whether to use dither by comparing the stored plane bpp with
computed pipe_bpp.
There are a few slight functional changes in this patch:
- LVDS connector are now also going through the EDID clamping. But in
a 2nd change we now unconditionally force the lvds bpc value - this
shouldn't matter in reality when the panel setup is consistent, but
better safe than sorry.
- HDMI now forces the pipe_bpp to the selected value - I think that's
what we actually want, since otherwise at least the pixelclock
computations are wrong (I'm not sure whether the port would accept
e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
the next higher bpc value, since otherwise there's no way to make
use of the 12 bpc mode (since the next patch will remove the 12bpc
plane format, it doesn't exist).
Both of these changes are due to the removal of the
pipe_bpp = min(display_bpp, plane_bpp);
statement.
Another slight change is the reworking of the dp bpc code:
- For the mode_valid callback it's sufficient to only check whether
the mode would fit at the lowest bpc.
- The bandwidth computation code is a bit restructured: It now walks
all available bpp values in an outer loop and the codeblock that
computes derived values (once a good configuration is found) has been
moved out of the for loop maze. This is prep work to allow us to
successively fall back on bpc values, and also correctly support bpc
values != 8 or 6.
v2: Rebased on top of Paulo Zanoni's little refactoring to use more
drm dp helper functions.
v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
range work.
v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.
v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
in a later patch though again.
v6: Fix spelling in a comment.
v7: Debug output improvements for the bpp computation.
v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
things!
v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
was lost in a rebase.
v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
that. Still unsure whether this is the way to go, but at least 6bpc
for a 8bpc hdmi output seems to work.
v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
depth on DP. Adjust the code.
v12: Rebased.
v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
requested from Jesse Barnes.
v14: Split out the special 6BPC handling for DP, as requested by Jesse
Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-27 06:44:58 +07:00
|
|
|
} else {
|
drm/i915: implement fdi auto-dithering
So on a bunch of setups we only have 2 fdi lanes available, e.g. hsw
VGA or 3 pipes on ivb. And seemingly a lot of modes don't quite fit
into this, among them the default 1080p mode.
The solution is to dither down the pipe a bit so that everything fits,
which this patch implements.
But ports compute their state under the assumption that the bpp they
pick will be the one selected, e.g. the display port bw computations
won't work otherwise. Now we could adjust our code to again up-dither
to the computed DP link parameters, but that's pointless.
So instead when the pipe needs to adjust parameters we need to retry
the pipe_config computation at the encoder stage. Furthermore we need
to inform encoders that they should not increase bandwidth
requirements if possible. This is required for the hdmi code, which
prefers the pipe to up-dither to either of the two possible hdmi bpc
values.
LVDS has a similar requirement, although that's probably only
theoretical in nature: It's unlikely that we'll ever see an 8bpc
high-res lvds panel (which is required to hit the 2 fdi lane limit).
eDP is the only thing which could increase the pipe_bpp setting again,
even when in the retry-loop. This could hit the WARN. Two reasons for
not bothering:
- On many eDP panels we'll get a black screen if the bpp settings
don't match vbt. So failing the modeset is the right thing to do.
But since that also means it's the only way to light up the panel,
it should work. So we shouldn't be able to hit this WARN.
- There are still opens around the eDP panel handling, and maybe we
need additional tricks. Before that happens it's imo no use trying
to be too clever.
Worst case we just need to kill that WARN or maybe fail the compute
config stage if the eDP connector can't get the bpp setting it wants.
And since this can only happen with an fdi link in between and so for
pch eDP panels it's rather unlikely to blow up, if ever.
v2: Rebased on top of a bikeshed from Paulo.
v3: Improve commit message around eDP handling with the stuff
things with Imre.
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-21 06:00:16 +07:00
|
|
|
DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
|
|
|
|
desired_bpp = 8*3;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!pipe_config->bw_constrained) {
|
|
|
|
DRM_DEBUG_KMS("forcing pipe bpc to %i for HDMI\n", desired_bpp);
|
|
|
|
pipe_config->pipe_bpp = desired_bpp;
|
drm/i915: precompute pipe bpp before touching the hw
The procedure has now 3 steps:
1. Compute the bpp that the plane will output, this is done in
pipe_config_set_bpp and stored into pipe_config->pipe_bpp. Also,
this function clamps the pipe_bpp to whatever limit the EDID of any
connected output specifies.
2. Adjust the pipe_bpp in the encoder and crtc functions, according to
whatever constraints there are.
3. Decide whether to use dither by comparing the stored plane bpp with
computed pipe_bpp.
There are a few slight functional changes in this patch:
- LVDS connector are now also going through the EDID clamping. But in
a 2nd change we now unconditionally force the lvds bpc value - this
shouldn't matter in reality when the panel setup is consistent, but
better safe than sorry.
- HDMI now forces the pipe_bpp to the selected value - I think that's
what we actually want, since otherwise at least the pixelclock
computations are wrong (I'm not sure whether the port would accept
e.g. 10 bpc when in 12bpc mode). Contrary to the old code, we pick
the next higher bpc value, since otherwise there's no way to make
use of the 12 bpc mode (since the next patch will remove the 12bpc
plane format, it doesn't exist).
Both of these changes are due to the removal of the
pipe_bpp = min(display_bpp, plane_bpp);
statement.
Another slight change is the reworking of the dp bpc code:
- For the mode_valid callback it's sufficient to only check whether
the mode would fit at the lowest bpc.
- The bandwidth computation code is a bit restructured: It now walks
all available bpp values in an outer loop and the codeblock that
computes derived values (once a good configuration is found) has been
moved out of the for loop maze. This is prep work to allow us to
successively fall back on bpc values, and also correctly support bpc
values != 8 or 6.
v2: Rebased on top of Paulo Zanoni's little refactoring to use more
drm dp helper functions.
v3: Rebased on top of Jani's eDP bpp fix and Ville's limited color
range work.
v4: Remove the INTEL_MODE_DP_FORCE_6BPC #define, no longer needed.
v5: Remove intel_crtc->bpp, too, and fix up the 12bpc check in the
hdmi code. Also fixup the bpp check in intel_dp.c, it'll get reworked
in a later patch though again.
v6: Fix spelling in a comment.
v7: Debug output improvements for the bpp computation.
v8: Fixup 6bpc lvds check - dual-link and 8bpc mode are different
things!
v9: Reinstate the fix to properly ignore the firmware edp bpp ... this
was lost in a rebase.
v10: Both g4x and vlv lack 12bpc pipes, so don't enforce that we have
that. Still unsure whether this is the way to go, but at least 6bpc
for a 8bpc hdmi output seems to work.
v11: And g4x/vlv also lack 12bpc hdmi support, so only support high
depth on DP. Adjust the code.
v12: Rebased.
v13: Split out the introduction of pipe_config->dither|pipe_bpp, as
requested from Jesse Barnes.
v14: Split out the special 6BPC handling for DP, as requested by Jesse
Barnes.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-27 06:44:58 +07:00
|
|
|
}
|
|
|
|
|
2013-09-25 22:45:37 +07:00
|
|
|
if (adjusted_mode->crtc_clock > portclock_limit) {
|
2013-04-19 16:24:33 +07:00
|
|
|
DRM_DEBUG_KMS("too high HDMI clock, rejecting mode\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2009-01-03 04:33:00 +07:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2009-05-05 23:52:46 +07:00
|
|
|
static enum drm_connector_status
|
2010-09-14 17:07:23 +07:00
|
|
|
intel_hdmi_detect(struct drm_connector *connector, bool force)
|
2009-04-02 12:13:26 +07:00
|
|
|
{
|
2012-12-13 23:09:00 +07:00
|
|
|
struct drm_device *dev = connector->dev;
|
2010-09-09 22:20:55 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
2012-10-27 04:05:49 +07:00
|
|
|
struct intel_digital_port *intel_dig_port =
|
|
|
|
hdmi_to_dig_port(intel_hdmi);
|
|
|
|
struct intel_encoder *intel_encoder = &intel_dig_port->base;
|
2012-12-13 23:09:00 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2010-07-21 05:44:45 +07:00
|
|
|
struct edid *edid;
|
2014-03-05 21:20:53 +07:00
|
|
|
enum intel_display_power_domain power_domain;
|
2009-05-05 23:52:46 +07:00
|
|
|
enum drm_connector_status status = connector_status_disconnected;
|
2009-04-02 12:13:26 +07:00
|
|
|
|
2013-07-21 02:27:08 +07:00
|
|
|
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
|
2014-06-03 18:56:17 +07:00
|
|
|
connector->base.id, connector->name);
|
2013-07-21 02:27:08 +07:00
|
|
|
|
2014-03-05 21:20:53 +07:00
|
|
|
power_domain = intel_display_port_power_domain(intel_encoder);
|
|
|
|
intel_display_power_get(dev_priv, power_domain);
|
|
|
|
|
2010-08-04 19:50:23 +07:00
|
|
|
intel_hdmi->has_hdmi_sink = false;
|
2010-09-10 09:39:40 +07:00
|
|
|
intel_hdmi->has_audio = false;
|
2013-01-17 21:31:31 +07:00
|
|
|
intel_hdmi->rgb_quant_range_selectable = false;
|
2010-07-21 05:44:45 +07:00
|
|
|
edid = drm_get_edid(connector,
|
2012-03-28 01:36:14 +07:00
|
|
|
intel_gmbus_get_adapter(dev_priv,
|
|
|
|
intel_hdmi->ddc_bus));
|
drm/i915: hdmi detection according by reading edid
According to investigations from windows team ,hw team,
and our test results on all 4x platofrms available
(gm45, g45b, q45, g45a, g45c, g41a, and g41), we find
currently Hot plug live status and Hot plug interrupt
detection are not reliable, sometime the results from
the two approaches are contradicts. So we chose edid
detection for hdmi output.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
2009-07-16 16:23:09 +07:00
|
|
|
|
2009-05-05 23:52:46 +07:00
|
|
|
if (edid) {
|
2009-06-22 12:14:55 +07:00
|
|
|
if (edid->input & DRM_EDID_INPUT_DIGITAL) {
|
2009-05-05 23:52:46 +07:00
|
|
|
status = connector_status_connected;
|
2012-02-14 10:45:36 +07:00
|
|
|
if (intel_hdmi->force_audio != HDMI_AUDIO_OFF_DVI)
|
|
|
|
intel_hdmi->has_hdmi_sink =
|
|
|
|
drm_detect_hdmi_monitor(edid);
|
2010-09-10 09:39:40 +07:00
|
|
|
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
|
2013-01-17 21:31:31 +07:00
|
|
|
intel_hdmi->rgb_quant_range_selectable =
|
|
|
|
drm_rgb_quant_range_selectable(edid);
|
2009-05-05 23:52:46 +07:00
|
|
|
}
|
|
|
|
kfree(edid);
|
2009-04-02 12:13:26 +07:00
|
|
|
}
|
2009-06-05 14:38:43 +07:00
|
|
|
|
2010-09-19 15:29:33 +07:00
|
|
|
if (status == connector_status_connected) {
|
2012-02-14 10:45:36 +07:00
|
|
|
if (intel_hdmi->force_audio != HDMI_AUDIO_AUTO)
|
|
|
|
intel_hdmi->has_audio =
|
|
|
|
(intel_hdmi->force_audio == HDMI_AUDIO_ON);
|
2012-10-27 04:05:49 +07:00
|
|
|
intel_encoder->type = INTEL_OUTPUT_HDMI;
|
2010-09-19 15:29:33 +07:00
|
|
|
}
|
|
|
|
|
2014-03-05 21:20:53 +07:00
|
|
|
intel_display_power_put(dev_priv, power_domain);
|
|
|
|
|
drm/i915: hdmi detection according by reading edid
According to investigations from windows team ,hw team,
and our test results on all 4x platofrms available
(gm45, g45b, q45, g45a, g45c, g41a, and g41), we find
currently Hot plug live status and Hot plug interrupt
detection are not reliable, sometime the results from
the two approaches are contradicts. So we chose edid
detection for hdmi output.
Signed-off-by: Ma Ling <ling.ma@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
2009-07-16 16:23:09 +07:00
|
|
|
return status;
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int intel_hdmi_get_modes(struct drm_connector *connector)
|
|
|
|
{
|
2014-03-05 21:20:53 +07:00
|
|
|
struct intel_encoder *intel_encoder = intel_attached_encoder(connector);
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&intel_encoder->base);
|
2010-07-21 05:44:45 +07:00
|
|
|
struct drm_i915_private *dev_priv = connector->dev->dev_private;
|
2014-03-05 21:20:53 +07:00
|
|
|
enum intel_display_power_domain power_domain;
|
|
|
|
int ret;
|
2009-01-03 04:33:00 +07:00
|
|
|
|
|
|
|
/* We should parse the EDID data and find out if it's an HDMI sink so
|
|
|
|
* we can send audio to it.
|
|
|
|
*/
|
|
|
|
|
2014-03-05 21:20:53 +07:00
|
|
|
power_domain = intel_display_port_power_domain(intel_encoder);
|
|
|
|
intel_display_power_get(dev_priv, power_domain);
|
|
|
|
|
|
|
|
ret = intel_ddc_get_modes(connector,
|
2012-03-28 01:36:14 +07:00
|
|
|
intel_gmbus_get_adapter(dev_priv,
|
|
|
|
intel_hdmi->ddc_bus));
|
2014-03-05 21:20:53 +07:00
|
|
|
|
|
|
|
intel_display_power_put(dev_priv, power_domain);
|
|
|
|
|
|
|
|
return ret;
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|
|
|
|
|
2011-02-10 01:46:58 +07:00
|
|
|
static bool
|
|
|
|
intel_hdmi_detect_audio(struct drm_connector *connector)
|
|
|
|
{
|
2014-03-05 21:20:53 +07:00
|
|
|
struct intel_encoder *intel_encoder = intel_attached_encoder(connector);
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&intel_encoder->base);
|
2011-02-10 01:46:58 +07:00
|
|
|
struct drm_i915_private *dev_priv = connector->dev->dev_private;
|
2014-03-05 21:20:53 +07:00
|
|
|
enum intel_display_power_domain power_domain;
|
2011-02-10 01:46:58 +07:00
|
|
|
struct edid *edid;
|
|
|
|
bool has_audio = false;
|
|
|
|
|
2014-03-05 21:20:53 +07:00
|
|
|
power_domain = intel_display_port_power_domain(intel_encoder);
|
|
|
|
intel_display_power_get(dev_priv, power_domain);
|
|
|
|
|
2011-02-10 01:46:58 +07:00
|
|
|
edid = drm_get_edid(connector,
|
2012-03-28 01:36:14 +07:00
|
|
|
intel_gmbus_get_adapter(dev_priv,
|
|
|
|
intel_hdmi->ddc_bus));
|
2011-02-10 01:46:58 +07:00
|
|
|
if (edid) {
|
|
|
|
if (edid->input & DRM_EDID_INPUT_DIGITAL)
|
|
|
|
has_audio = drm_detect_monitor_audio(edid);
|
|
|
|
kfree(edid);
|
|
|
|
}
|
|
|
|
|
2014-03-05 21:20:53 +07:00
|
|
|
intel_display_power_put(dev_priv, power_domain);
|
|
|
|
|
2011-02-10 01:46:58 +07:00
|
|
|
return has_audio;
|
|
|
|
}
|
|
|
|
|
2010-09-19 15:29:33 +07:00
|
|
|
static int
|
|
|
|
intel_hdmi_set_property(struct drm_connector *connector,
|
2012-05-15 03:12:50 +07:00
|
|
|
struct drm_property *property,
|
|
|
|
uint64_t val)
|
2010-09-19 15:29:33 +07:00
|
|
|
{
|
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
2012-10-27 04:05:46 +07:00
|
|
|
struct intel_digital_port *intel_dig_port =
|
|
|
|
hdmi_to_dig_port(intel_hdmi);
|
2011-02-22 05:23:52 +07:00
|
|
|
struct drm_i915_private *dev_priv = connector->dev->dev_private;
|
2010-09-19 15:29:33 +07:00
|
|
|
int ret;
|
|
|
|
|
2012-10-12 08:36:04 +07:00
|
|
|
ret = drm_object_property_set_value(&connector->base, property, val);
|
2010-09-19 15:29:33 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2011-05-13 04:17:24 +07:00
|
|
|
if (property == dev_priv->force_audio_property) {
|
2012-02-14 10:45:36 +07:00
|
|
|
enum hdmi_force_audio i = val;
|
2011-02-10 01:46:58 +07:00
|
|
|
bool has_audio;
|
|
|
|
|
|
|
|
if (i == intel_hdmi->force_audio)
|
2010-09-19 15:29:33 +07:00
|
|
|
return 0;
|
|
|
|
|
2011-02-10 01:46:58 +07:00
|
|
|
intel_hdmi->force_audio = i;
|
2010-09-19 15:29:33 +07:00
|
|
|
|
2012-02-14 10:45:36 +07:00
|
|
|
if (i == HDMI_AUDIO_AUTO)
|
2011-02-10 01:46:58 +07:00
|
|
|
has_audio = intel_hdmi_detect_audio(connector);
|
|
|
|
else
|
2012-02-14 10:45:36 +07:00
|
|
|
has_audio = (i == HDMI_AUDIO_ON);
|
2011-02-10 01:46:58 +07:00
|
|
|
|
2012-02-14 10:45:36 +07:00
|
|
|
if (i == HDMI_AUDIO_OFF_DVI)
|
|
|
|
intel_hdmi->has_hdmi_sink = 0;
|
2010-09-19 15:29:33 +07:00
|
|
|
|
2011-02-10 01:46:58 +07:00
|
|
|
intel_hdmi->has_audio = has_audio;
|
2010-09-19 15:29:33 +07:00
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
2011-02-22 05:23:52 +07:00
|
|
|
if (property == dev_priv->broadcast_rgb_property) {
|
2013-04-22 22:07:23 +07:00
|
|
|
bool old_auto = intel_hdmi->color_range_auto;
|
|
|
|
uint32_t old_range = intel_hdmi->color_range;
|
|
|
|
|
2013-01-17 21:31:29 +07:00
|
|
|
switch (val) {
|
|
|
|
case INTEL_BROADCAST_RGB_AUTO:
|
|
|
|
intel_hdmi->color_range_auto = true;
|
|
|
|
break;
|
|
|
|
case INTEL_BROADCAST_RGB_FULL:
|
|
|
|
intel_hdmi->color_range_auto = false;
|
|
|
|
intel_hdmi->color_range = 0;
|
|
|
|
break;
|
|
|
|
case INTEL_BROADCAST_RGB_LIMITED:
|
|
|
|
intel_hdmi->color_range_auto = false;
|
2013-02-20 02:21:47 +07:00
|
|
|
intel_hdmi->color_range = HDMI_COLOR_RANGE_16_235;
|
2013-01-17 21:31:29 +07:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2013-04-22 22:07:23 +07:00
|
|
|
|
|
|
|
if (old_auto == intel_hdmi->color_range_auto &&
|
|
|
|
old_range == intel_hdmi->color_range)
|
|
|
|
return 0;
|
|
|
|
|
2011-02-22 05:23:52 +07:00
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
2010-09-19 15:29:33 +07:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
done:
|
2012-12-19 23:08:43 +07:00
|
|
|
if (intel_dig_port->base.base.crtc)
|
|
|
|
intel_crtc_restore_mode(intel_dig_port->base.base.crtc);
|
2010-09-19 15:29:33 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-04-06 01:51:35 +07:00
|
|
|
static void intel_hdmi_pre_enable(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(encoder->base.crtc);
|
|
|
|
struct drm_display_mode *adjusted_mode =
|
|
|
|
&intel_crtc->config.adjusted_mode;
|
|
|
|
|
2014-04-25 04:54:56 +07:00
|
|
|
intel_hdmi_prepare(encoder);
|
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
intel_hdmi->set_infoframes(&encoder->base,
|
|
|
|
intel_crtc->config.has_hdmi_sink,
|
|
|
|
adjusted_mode);
|
2014-04-06 01:51:35 +07:00
|
|
|
}
|
|
|
|
|
2013-10-16 16:07:41 +07:00
|
|
|
static void vlv_hdmi_pre_enable(struct intel_encoder *encoder)
|
2013-04-19 04:51:36 +07:00
|
|
|
{
|
|
|
|
struct intel_digital_port *dport = enc_to_dig_port(&encoder->base);
|
2014-04-06 01:51:35 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = &dport->hdmi;
|
2013-04-19 04:51:36 +07:00
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_crtc *intel_crtc =
|
|
|
|
to_intel_crtc(encoder->base.crtc);
|
2014-04-06 01:51:35 +07:00
|
|
|
struct drm_display_mode *adjusted_mode =
|
|
|
|
&intel_crtc->config.adjusted_mode;
|
2013-11-06 13:36:35 +07:00
|
|
|
enum dpio_channel port = vlv_dport_to_channel(dport);
|
2013-04-19 04:51:36 +07:00
|
|
|
int pipe = intel_crtc->pipe;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
/* Enable clock channels for this port */
|
2013-07-27 01:57:35 +07:00
|
|
|
mutex_lock(&dev_priv->dpio_lock);
|
2013-11-07 09:43:30 +07:00
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW8(port));
|
2013-04-19 04:51:36 +07:00
|
|
|
val = 0;
|
|
|
|
if (pipe)
|
|
|
|
val |= (1<<21);
|
|
|
|
else
|
|
|
|
val &= ~(1<<21);
|
|
|
|
val |= 0x001000c4;
|
2013-11-07 09:43:30 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW8(port), val);
|
2013-04-19 04:51:36 +07:00
|
|
|
|
|
|
|
/* HDMI 1.0V-2dB */
|
2013-11-07 09:43:30 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW5(port), 0);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW4(port), 0x2b245f5f);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW2(port), 0x5578b83a);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW3(port), 0x0c782040);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX3_DW4(port), 0x2b247878);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW11(port), 0x00030000);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW9(port), 0x00002000);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW5(port), DPIO_TX_OCALINIT_EN);
|
2013-04-19 04:51:36 +07:00
|
|
|
|
|
|
|
/* Program lane clock */
|
2013-11-07 09:43:30 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW14(port), 0x00760018);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW23(port), 0x00400888);
|
2013-07-27 01:57:35 +07:00
|
|
|
mutex_unlock(&dev_priv->dpio_lock);
|
2013-07-30 16:20:31 +07:00
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
intel_hdmi->set_infoframes(&encoder->base,
|
|
|
|
intel_crtc->config.has_hdmi_sink,
|
|
|
|
adjusted_mode);
|
2014-04-06 01:51:35 +07:00
|
|
|
|
2013-07-30 16:20:31 +07:00
|
|
|
intel_enable_hdmi(encoder);
|
|
|
|
|
2013-11-06 13:36:35 +07:00
|
|
|
vlv_wait_port_ready(dev_priv, dport);
|
2013-04-19 04:51:36 +07:00
|
|
|
}
|
|
|
|
|
2013-10-16 16:07:41 +07:00
|
|
|
static void vlv_hdmi_pre_pll_enable(struct intel_encoder *encoder)
|
2013-04-19 04:51:36 +07:00
|
|
|
{
|
|
|
|
struct intel_digital_port *dport = enc_to_dig_port(&encoder->base);
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2013-09-05 19:41:49 +07:00
|
|
|
struct intel_crtc *intel_crtc =
|
|
|
|
to_intel_crtc(encoder->base.crtc);
|
2013-11-06 13:36:35 +07:00
|
|
|
enum dpio_channel port = vlv_dport_to_channel(dport);
|
2013-09-05 19:41:49 +07:00
|
|
|
int pipe = intel_crtc->pipe;
|
2013-04-19 04:51:36 +07:00
|
|
|
|
2014-04-25 04:54:56 +07:00
|
|
|
intel_hdmi_prepare(encoder);
|
|
|
|
|
2013-04-19 04:51:36 +07:00
|
|
|
/* Program Tx lane resets to default */
|
2013-07-27 01:57:35 +07:00
|
|
|
mutex_lock(&dev_priv->dpio_lock);
|
2013-11-07 09:43:30 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW0(port),
|
2013-04-19 04:51:36 +07:00
|
|
|
DPIO_PCS_TX_LANE2_RESET |
|
|
|
|
DPIO_PCS_TX_LANE1_RESET);
|
2013-11-07 09:43:30 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(port),
|
2013-04-19 04:51:36 +07:00
|
|
|
DPIO_PCS_CLK_CRI_RXEB_EIOS_EN |
|
|
|
|
DPIO_PCS_CLK_CRI_RXDIGFILTSG_EN |
|
|
|
|
(1<<DPIO_PCS_CLK_DATAWIDTH_SHIFT) |
|
|
|
|
DPIO_PCS_CLK_SOFT_RESET);
|
|
|
|
|
|
|
|
/* Fix up inter-pair skew failure */
|
2013-11-07 09:43:30 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW12(port), 0x00750f00);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW11(port), 0x00001500);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW14(port), 0x40400000);
|
|
|
|
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW9(port), 0x00002000);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW5(port), DPIO_TX_OCALINIT_EN);
|
2013-07-27 01:57:35 +07:00
|
|
|
mutex_unlock(&dev_priv->dpio_lock);
|
2013-04-19 04:51:36 +07:00
|
|
|
}
|
|
|
|
|
2014-04-09 17:29:05 +07:00
|
|
|
static void chv_hdmi_pre_pll_enable(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_digital_port *dport = enc_to_dig_port(&encoder->base);
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_crtc *intel_crtc =
|
|
|
|
to_intel_crtc(encoder->base.crtc);
|
|
|
|
enum dpio_channel ch = vlv_dport_to_channel(dport);
|
|
|
|
enum pipe pipe = intel_crtc->pipe;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
mutex_lock(&dev_priv->dpio_lock);
|
|
|
|
|
2014-05-27 20:30:18 +07:00
|
|
|
/* program left/right clock distribution */
|
|
|
|
if (pipe != PIPE_B) {
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW5_CH0);
|
|
|
|
val &= ~(CHV_BUFLEFTENA1_MASK | CHV_BUFRIGHTENA1_MASK);
|
|
|
|
if (ch == DPIO_CH0)
|
|
|
|
val |= CHV_BUFLEFTENA1_FORCE;
|
|
|
|
if (ch == DPIO_CH1)
|
|
|
|
val |= CHV_BUFRIGHTENA1_FORCE;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW5_CH0, val);
|
|
|
|
} else {
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, _CHV_CMN_DW1_CH1);
|
|
|
|
val &= ~(CHV_BUFLEFTENA2_MASK | CHV_BUFRIGHTENA2_MASK);
|
|
|
|
if (ch == DPIO_CH0)
|
|
|
|
val |= CHV_BUFLEFTENA2_FORCE;
|
|
|
|
if (ch == DPIO_CH1)
|
|
|
|
val |= CHV_BUFRIGHTENA2_FORCE;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, _CHV_CMN_DW1_CH1, val);
|
|
|
|
}
|
|
|
|
|
2014-04-09 17:29:05 +07:00
|
|
|
/* program clock channel usage */
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW8(ch));
|
|
|
|
val |= CHV_PCS_USEDCLKCHANNEL_OVRRIDE;
|
|
|
|
if (pipe != PIPE_B)
|
|
|
|
val &= ~CHV_PCS_USEDCLKCHANNEL;
|
|
|
|
else
|
|
|
|
val |= CHV_PCS_USEDCLKCHANNEL;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW8(ch), val);
|
|
|
|
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW8(ch));
|
|
|
|
val |= CHV_PCS_USEDCLKCHANNEL_OVRRIDE;
|
|
|
|
if (pipe != PIPE_B)
|
|
|
|
val &= ~CHV_PCS_USEDCLKCHANNEL;
|
|
|
|
else
|
|
|
|
val |= CHV_PCS_USEDCLKCHANNEL;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW8(ch), val);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This a a bit weird since generally CL
|
|
|
|
* matches the pipe, but here we need to
|
|
|
|
* pick the CL based on the port.
|
|
|
|
*/
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW19(ch));
|
|
|
|
if (pipe != PIPE_B)
|
|
|
|
val &= ~CHV_CMN_USEDCLKCHANNEL;
|
|
|
|
else
|
|
|
|
val |= CHV_CMN_USEDCLKCHANNEL;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW19(ch), val);
|
|
|
|
|
|
|
|
mutex_unlock(&dev_priv->dpio_lock);
|
|
|
|
}
|
|
|
|
|
2013-10-16 16:07:41 +07:00
|
|
|
static void vlv_hdmi_post_disable(struct intel_encoder *encoder)
|
2013-04-19 04:51:36 +07:00
|
|
|
{
|
|
|
|
struct intel_digital_port *dport = enc_to_dig_port(&encoder->base);
|
|
|
|
struct drm_i915_private *dev_priv = encoder->base.dev->dev_private;
|
2013-09-05 19:41:49 +07:00
|
|
|
struct intel_crtc *intel_crtc =
|
|
|
|
to_intel_crtc(encoder->base.crtc);
|
2013-11-06 13:36:35 +07:00
|
|
|
enum dpio_channel port = vlv_dport_to_channel(dport);
|
2013-09-05 19:41:49 +07:00
|
|
|
int pipe = intel_crtc->pipe;
|
2013-04-19 04:51:36 +07:00
|
|
|
|
|
|
|
/* Reset lanes to avoid HDMI flicker (VLV w/a) */
|
|
|
|
mutex_lock(&dev_priv->dpio_lock);
|
2013-11-07 09:43:30 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW0(port), 0x00000000);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS_DW1(port), 0x00e00060);
|
2013-04-19 04:51:36 +07:00
|
|
|
mutex_unlock(&dev_priv->dpio_lock);
|
|
|
|
}
|
|
|
|
|
2014-04-09 17:29:00 +07:00
|
|
|
static void chv_hdmi_post_disable(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_digital_port *dport = enc_to_dig_port(&encoder->base);
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_crtc *intel_crtc =
|
|
|
|
to_intel_crtc(encoder->base.crtc);
|
|
|
|
enum dpio_channel ch = vlv_dport_to_channel(dport);
|
|
|
|
enum pipe pipe = intel_crtc->pipe;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
mutex_lock(&dev_priv->dpio_lock);
|
|
|
|
|
|
|
|
/* Propagate soft reset to data lane reset */
|
2014-04-09 17:29:02 +07:00
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
|
2014-04-28 18:15:24 +07:00
|
|
|
val |= CHV_PCS_REQ_SOFTRESET_EN;
|
2014-04-09 17:29:02 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
|
2014-04-28 18:15:24 +07:00
|
|
|
|
2014-04-09 17:29:02 +07:00
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
|
|
|
|
val |= CHV_PCS_REQ_SOFTRESET_EN;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
|
|
|
|
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
|
|
|
|
val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
|
|
|
|
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
|
2014-04-09 17:29:00 +07:00
|
|
|
val &= ~(DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
|
2014-04-09 17:29:02 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
|
2014-04-09 17:29:00 +07:00
|
|
|
|
|
|
|
mutex_unlock(&dev_priv->dpio_lock);
|
|
|
|
}
|
|
|
|
|
2014-04-09 17:28:20 +07:00
|
|
|
static void chv_hdmi_pre_enable(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_digital_port *dport = enc_to_dig_port(&encoder->base);
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_crtc *intel_crtc =
|
|
|
|
to_intel_crtc(encoder->base.crtc);
|
|
|
|
enum dpio_channel ch = vlv_dport_to_channel(dport);
|
|
|
|
int pipe = intel_crtc->pipe;
|
|
|
|
int data, i;
|
|
|
|
u32 val;
|
|
|
|
|
|
|
|
mutex_lock(&dev_priv->dpio_lock);
|
2014-04-09 17:28:58 +07:00
|
|
|
|
|
|
|
/* Deassert soft data lane reset*/
|
2014-04-09 17:29:02 +07:00
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW1(ch));
|
2014-04-28 18:15:24 +07:00
|
|
|
val |= CHV_PCS_REQ_SOFTRESET_EN;
|
2014-04-09 17:29:02 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW1(ch), val);
|
|
|
|
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW1(ch));
|
|
|
|
val |= CHV_PCS_REQ_SOFTRESET_EN;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW1(ch), val);
|
|
|
|
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW0(ch));
|
|
|
|
val |= (DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW0(ch), val);
|
2014-04-28 18:15:24 +07:00
|
|
|
|
2014-04-09 17:29:02 +07:00
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW0(ch));
|
2014-04-09 17:28:58 +07:00
|
|
|
val |= (DPIO_PCS_TX_LANE2_RESET | DPIO_PCS_TX_LANE1_RESET);
|
2014-04-09 17:29:02 +07:00
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW0(ch), val);
|
2014-04-09 17:28:58 +07:00
|
|
|
|
|
|
|
/* Program Tx latency optimal setting */
|
2014-04-09 17:28:20 +07:00
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
/* Set the latency optimal bit */
|
|
|
|
data = (i == 1) ? 0x0 : 0x6;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW11(ch, i),
|
|
|
|
data << DPIO_FRC_LATENCY_SHFIT);
|
|
|
|
|
|
|
|
/* Set the upar bit */
|
|
|
|
data = (i == 1) ? 0x0 : 0x1;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW14(ch, i),
|
|
|
|
data << DPIO_UPAR_SHIFT);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Data lane stagger programming */
|
|
|
|
/* FIXME: Fix up value only after power analysis */
|
|
|
|
|
|
|
|
/* Clear calc init */
|
2014-04-09 17:29:04 +07:00
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
|
|
|
|
val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
|
|
|
|
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
|
|
|
|
val &= ~(DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3);
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
|
2014-04-09 17:28:20 +07:00
|
|
|
|
|
|
|
/* FIXME: Program the support xxx V-dB */
|
|
|
|
/* Use 800mV-0dB */
|
2014-04-09 17:29:03 +07:00
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW4(ch, i));
|
|
|
|
val &= ~DPIO_SWING_DEEMPH9P5_MASK;
|
|
|
|
val |= 128 << DPIO_SWING_DEEMPH9P5_SHIFT;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW4(ch, i), val);
|
|
|
|
}
|
2014-04-09 17:28:20 +07:00
|
|
|
|
2014-04-09 17:29:03 +07:00
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW2(ch, i));
|
|
|
|
val &= ~DPIO_SWING_MARGIN_MASK;
|
|
|
|
val |= 102 << DPIO_SWING_MARGIN_SHIFT;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW2(ch, i), val);
|
|
|
|
}
|
2014-04-09 17:28:20 +07:00
|
|
|
|
|
|
|
/* Disable unique transition scale */
|
2014-04-09 17:29:03 +07:00
|
|
|
for (i = 0; i < 4; i++) {
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, CHV_TX_DW3(ch, i));
|
|
|
|
val &= ~DPIO_TX_UNIQ_TRANS_SCALE_EN;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, CHV_TX_DW3(ch, i), val);
|
|
|
|
}
|
2014-04-09 17:28:20 +07:00
|
|
|
|
|
|
|
/* Additional steps for 1200mV-0dB */
|
|
|
|
#if 0
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_TX_DW3(ch));
|
|
|
|
if (ch)
|
|
|
|
val |= DPIO_TX_UNIQ_TRANS_SCALE_CH1;
|
|
|
|
else
|
|
|
|
val |= DPIO_TX_UNIQ_TRANS_SCALE_CH0;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW3(ch), val);
|
|
|
|
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_TX_DW2(ch),
|
|
|
|
vlv_dpio_read(dev_priv, pipe, VLV_TX_DW2(ch)) |
|
|
|
|
(0x9a << DPIO_UNIQ_TRANS_SCALE_SHIFT));
|
|
|
|
#endif
|
|
|
|
/* Start swing calculation */
|
2014-04-09 17:29:04 +07:00
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS01_DW10(ch));
|
|
|
|
val |= DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS01_DW10(ch), val);
|
|
|
|
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, VLV_PCS23_DW10(ch));
|
|
|
|
val |= DPIO_PCS_SWING_CALC_TX0_TX2 | DPIO_PCS_SWING_CALC_TX1_TX3;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, VLV_PCS23_DW10(ch), val);
|
2014-04-09 17:28:20 +07:00
|
|
|
|
|
|
|
/* LRC Bypass */
|
|
|
|
val = vlv_dpio_read(dev_priv, pipe, CHV_CMN_DW30);
|
|
|
|
val |= DPIO_LRC_BYPASS;
|
|
|
|
vlv_dpio_write(dev_priv, pipe, CHV_CMN_DW30, val);
|
|
|
|
|
|
|
|
mutex_unlock(&dev_priv->dpio_lock);
|
|
|
|
|
|
|
|
intel_enable_hdmi(encoder);
|
|
|
|
|
|
|
|
vlv_wait_port_ready(dev_priv, dport);
|
|
|
|
}
|
|
|
|
|
2009-01-03 04:33:00 +07:00
|
|
|
static void intel_hdmi_destroy(struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
drm_connector_cleanup(connector);
|
2010-03-29 14:57:42 +07:00
|
|
|
kfree(connector);
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct drm_connector_funcs intel_hdmi_connector_funcs = {
|
2012-06-30 13:59:56 +07:00
|
|
|
.dpms = intel_connector_dpms,
|
2009-01-03 04:33:00 +07:00
|
|
|
.detect = intel_hdmi_detect,
|
|
|
|
.fill_modes = drm_helper_probe_single_connector_modes,
|
2010-09-19 15:29:33 +07:00
|
|
|
.set_property = intel_hdmi_set_property,
|
2009-01-03 04:33:00 +07:00
|
|
|
.destroy = intel_hdmi_destroy,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct drm_connector_helper_funcs intel_hdmi_connector_helper_funcs = {
|
|
|
|
.get_modes = intel_hdmi_get_modes,
|
|
|
|
.mode_valid = intel_hdmi_mode_valid,
|
2010-09-09 22:20:55 +07:00
|
|
|
.best_encoder = intel_best_encoder,
|
2009-01-03 04:33:00 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct drm_encoder_funcs intel_hdmi_enc_funcs = {
|
2010-08-04 19:50:23 +07:00
|
|
|
.destroy = intel_encoder_destroy,
|
2009-01-03 04:33:00 +07:00
|
|
|
};
|
|
|
|
|
2010-09-19 15:29:33 +07:00
|
|
|
static void
|
|
|
|
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *connector)
|
|
|
|
{
|
2011-05-13 04:17:24 +07:00
|
|
|
intel_attach_force_audio_property(connector);
|
2011-02-22 05:23:52 +07:00
|
|
|
intel_attach_broadcast_rgb_property(connector);
|
2013-01-17 21:31:29 +07:00
|
|
|
intel_hdmi->color_range_auto = true;
|
2010-09-19 15:29:33 +07:00
|
|
|
}
|
|
|
|
|
2012-10-27 04:05:52 +07:00
|
|
|
void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
|
|
|
|
struct intel_connector *intel_connector)
|
2009-01-03 04:33:00 +07:00
|
|
|
{
|
2012-10-27 04:05:47 +07:00
|
|
|
struct drm_connector *connector = &intel_connector->base;
|
|
|
|
struct intel_hdmi *intel_hdmi = &intel_dig_port->hdmi;
|
|
|
|
struct intel_encoder *intel_encoder = &intel_dig_port->base;
|
|
|
|
struct drm_device *dev = intel_encoder->base.dev;
|
2009-01-03 04:33:00 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-10-27 04:05:50 +07:00
|
|
|
enum port port = intel_dig_port->port;
|
2010-09-15 18:03:59 +07:00
|
|
|
|
2009-01-03 04:33:00 +07:00
|
|
|
drm_connector_init(dev, connector, &intel_hdmi_connector_funcs,
|
2009-09-24 02:08:29 +07:00
|
|
|
DRM_MODE_CONNECTOR_HDMIA);
|
2009-01-03 04:33:00 +07:00
|
|
|
drm_connector_helper_add(connector, &intel_hdmi_connector_helper_funcs);
|
|
|
|
|
2012-01-28 20:49:26 +07:00
|
|
|
connector->interlace_allowed = 1;
|
2009-01-03 04:33:00 +07:00
|
|
|
connector->doublescan_allowed = 0;
|
2013-09-25 22:45:40 +07:00
|
|
|
connector->stereo_allowed = 1;
|
2012-07-13 01:08:18 +07:00
|
|
|
|
2012-07-13 01:19:59 +07:00
|
|
|
switch (port) {
|
|
|
|
case PORT_B:
|
2010-07-21 05:44:45 +07:00
|
|
|
intel_hdmi->ddc_bus = GMBUS_PORT_DPB;
|
2013-02-26 00:06:49 +07:00
|
|
|
intel_encoder->hpd_pin = HPD_PORT_B;
|
2012-07-13 01:19:59 +07:00
|
|
|
break;
|
|
|
|
case PORT_C:
|
2012-05-10 01:37:28 +07:00
|
|
|
intel_hdmi->ddc_bus = GMBUS_PORT_DPC;
|
2013-02-26 00:06:49 +07:00
|
|
|
intel_encoder->hpd_pin = HPD_PORT_C;
|
2012-07-13 01:19:59 +07:00
|
|
|
break;
|
|
|
|
case PORT_D:
|
2014-04-09 17:28:52 +07:00
|
|
|
if (IS_CHERRYVIEW(dev))
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PORT_DPD_CHV;
|
|
|
|
else
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PORT_DPD;
|
2013-02-26 00:06:49 +07:00
|
|
|
intel_encoder->hpd_pin = HPD_PORT_D;
|
2012-07-13 01:19:59 +07:00
|
|
|
break;
|
|
|
|
case PORT_A:
|
2013-02-26 00:06:49 +07:00
|
|
|
intel_encoder->hpd_pin = HPD_PORT_A;
|
2012-07-13 01:19:59 +07:00
|
|
|
/* Internal port only for eDP. */
|
|
|
|
default:
|
2012-05-10 01:37:13 +07:00
|
|
|
BUG();
|
2009-08-24 12:50:24 +07:00
|
|
|
}
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2013-03-09 01:46:01 +07:00
|
|
|
if (IS_VALLEYVIEW(dev)) {
|
2012-03-29 03:39:32 +07:00
|
|
|
intel_hdmi->write_infoframe = vlv_write_infoframe;
|
2012-05-29 02:42:48 +07:00
|
|
|
intel_hdmi->set_infoframes = vlv_set_infoframes;
|
2013-03-09 01:46:01 +07:00
|
|
|
} else if (!HAS_PCH_SPLIT(dev)) {
|
|
|
|
intel_hdmi->write_infoframe = g4x_write_infoframe;
|
|
|
|
intel_hdmi->set_infoframes = g4x_set_infoframes;
|
2013-02-19 05:00:23 +07:00
|
|
|
} else if (HAS_DDI(dev)) {
|
2012-05-10 20:18:02 +07:00
|
|
|
intel_hdmi->write_infoframe = hsw_write_infoframe;
|
2012-05-29 02:42:48 +07:00
|
|
|
intel_hdmi->set_infoframes = hsw_set_infoframes;
|
2012-05-05 03:18:24 +07:00
|
|
|
} else if (HAS_PCH_IBX(dev)) {
|
|
|
|
intel_hdmi->write_infoframe = ibx_write_infoframe;
|
2012-05-29 02:42:48 +07:00
|
|
|
intel_hdmi->set_infoframes = ibx_set_infoframes;
|
2012-05-05 03:18:24 +07:00
|
|
|
} else {
|
|
|
|
intel_hdmi->write_infoframe = cpt_write_infoframe;
|
2012-05-29 02:42:48 +07:00
|
|
|
intel_hdmi->set_infoframes = cpt_set_infoframes;
|
2011-09-22 12:46:00 +07:00
|
|
|
}
|
2011-08-03 23:22:55 +07:00
|
|
|
|
2012-11-24 00:30:39 +07:00
|
|
|
if (HAS_DDI(dev))
|
2012-10-27 04:05:51 +07:00
|
|
|
intel_connector->get_hw_state = intel_ddi_connector_get_hw_state;
|
|
|
|
else
|
|
|
|
intel_connector->get_hw_state = intel_connector_get_hw_state;
|
2014-02-11 22:12:48 +07:00
|
|
|
intel_connector->unregister = intel_connector_unregister;
|
2012-10-27 04:05:47 +07:00
|
|
|
|
|
|
|
intel_hdmi_add_properties(intel_hdmi, connector);
|
|
|
|
|
|
|
|
intel_connector_attach_encoder(intel_connector, intel_encoder);
|
|
|
|
drm_sysfs_connector_add(connector);
|
|
|
|
|
|
|
|
/* For G4X desktop chip, PEG_BAND_GAP_DATA 3:0 must first be written
|
|
|
|
* 0xd. Failure to do so will result in spurious interrupts being
|
|
|
|
* generated on the port when a cable is not attached.
|
|
|
|
*/
|
|
|
|
if (IS_G4X(dev) && !IS_GM45(dev)) {
|
|
|
|
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
|
|
|
|
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
void intel_hdmi_init(struct drm_device *dev, int hdmi_reg, enum port port)
|
2012-10-27 04:05:47 +07:00
|
|
|
{
|
|
|
|
struct intel_digital_port *intel_dig_port;
|
|
|
|
struct intel_encoder *intel_encoder;
|
|
|
|
struct intel_connector *intel_connector;
|
|
|
|
|
2013-09-19 17:18:32 +07:00
|
|
|
intel_dig_port = kzalloc(sizeof(*intel_dig_port), GFP_KERNEL);
|
2012-10-27 04:05:47 +07:00
|
|
|
if (!intel_dig_port)
|
|
|
|
return;
|
|
|
|
|
2013-09-19 17:18:32 +07:00
|
|
|
intel_connector = kzalloc(sizeof(*intel_connector), GFP_KERNEL);
|
2012-10-27 04:05:47 +07:00
|
|
|
if (!intel_connector) {
|
|
|
|
kfree(intel_dig_port);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
intel_encoder = &intel_dig_port->base;
|
|
|
|
|
|
|
|
drm_encoder_init(dev, &intel_encoder->base, &intel_hdmi_enc_funcs,
|
|
|
|
DRM_MODE_ENCODER_TMDS);
|
2012-10-27 04:05:52 +07:00
|
|
|
|
2013-03-27 06:44:55 +07:00
|
|
|
intel_encoder->compute_config = intel_hdmi_compute_config;
|
2012-10-27 04:05:52 +07:00
|
|
|
intel_encoder->disable = intel_disable_hdmi;
|
|
|
|
intel_encoder->get_hw_state = intel_hdmi_get_hw_state;
|
2013-05-15 07:08:26 +07:00
|
|
|
intel_encoder->get_config = intel_hdmi_get_config;
|
2014-04-09 17:28:20 +07:00
|
|
|
if (IS_CHERRYVIEW(dev)) {
|
2014-04-09 17:29:05 +07:00
|
|
|
intel_encoder->pre_pll_enable = chv_hdmi_pre_pll_enable;
|
2014-04-09 17:28:20 +07:00
|
|
|
intel_encoder->pre_enable = chv_hdmi_pre_enable;
|
|
|
|
intel_encoder->enable = vlv_enable_hdmi;
|
2014-04-09 17:29:00 +07:00
|
|
|
intel_encoder->post_disable = chv_hdmi_post_disable;
|
2014-04-09 17:28:20 +07:00
|
|
|
} else if (IS_VALLEYVIEW(dev)) {
|
2013-10-16 16:07:41 +07:00
|
|
|
intel_encoder->pre_pll_enable = vlv_hdmi_pre_pll_enable;
|
|
|
|
intel_encoder->pre_enable = vlv_hdmi_pre_enable;
|
2013-07-30 16:20:31 +07:00
|
|
|
intel_encoder->enable = vlv_enable_hdmi;
|
2013-10-16 16:07:41 +07:00
|
|
|
intel_encoder->post_disable = vlv_hdmi_post_disable;
|
2013-07-30 16:20:31 +07:00
|
|
|
} else {
|
2014-04-06 01:51:35 +07:00
|
|
|
intel_encoder->pre_enable = intel_hdmi_pre_enable;
|
2013-07-30 16:20:31 +07:00
|
|
|
intel_encoder->enable = intel_enable_hdmi;
|
2013-04-19 04:51:36 +07:00
|
|
|
}
|
2012-06-30 13:59:56 +07:00
|
|
|
|
2012-10-27 04:05:47 +07:00
|
|
|
intel_encoder->type = INTEL_OUTPUT_HDMI;
|
2014-04-28 18:07:43 +07:00
|
|
|
if (IS_CHERRYVIEW(dev)) {
|
|
|
|
if (port == PORT_D)
|
|
|
|
intel_encoder->crtc_mask = 1 << 2;
|
|
|
|
else
|
|
|
|
intel_encoder->crtc_mask = (1 << 0) | (1 << 1);
|
|
|
|
} else {
|
|
|
|
intel_encoder->crtc_mask = (1 << 0) | (1 << 1) | (1 << 2);
|
|
|
|
}
|
2014-03-03 21:15:30 +07:00
|
|
|
intel_encoder->cloneable = 1 << INTEL_OUTPUT_ANALOG;
|
2014-03-03 21:15:31 +07:00
|
|
|
/*
|
|
|
|
* BSpec is unclear about HDMI+HDMI cloning on g4x, but it seems
|
|
|
|
* to work on real hardware. And since g4x can send infoframes to
|
|
|
|
* only one port anyway, nothing is lost by allowing it.
|
|
|
|
*/
|
|
|
|
if (IS_G4X(dev))
|
|
|
|
intel_encoder->cloneable |= 1 << INTEL_OUTPUT_HDMI;
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2012-10-27 04:05:50 +07:00
|
|
|
intel_dig_port->port = port;
|
2013-02-19 05:00:26 +07:00
|
|
|
intel_dig_port->hdmi.hdmi_reg = hdmi_reg;
|
2012-10-27 04:05:47 +07:00
|
|
|
intel_dig_port->dp.output_reg = 0;
|
2010-09-19 15:29:33 +07:00
|
|
|
|
2012-10-27 04:05:47 +07:00
|
|
|
intel_hdmi_init_connector(intel_dig_port, intel_connector);
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|