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>
|
2015-01-23 07:50:32 +07:00
|
|
|
#include <drm/drm_atomic_helper.h>
|
2012-10-03 00:01:07 +07:00
|
|
|
#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:
|
2015-12-16 23:10:00 +07:00
|
|
|
MISSING_CASE(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:
|
2015-12-16 23:10:00 +07:00
|
|
|
MISSING_CASE(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:
|
2015-12-16 23:10:00 +07:00
|
|
|
MISSING_CASE(type);
|
2012-05-15 03:12:51 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
static i915_reg_t
|
|
|
|
hsw_dip_data_reg(struct drm_i915_private *dev_priv,
|
|
|
|
enum transcoder cpu_transcoder,
|
|
|
|
enum hdmi_infoframe_type type,
|
|
|
|
int i)
|
2012-05-15 03:12:51 +07:00
|
|
|
{
|
2013-08-07 02:32:18 +07:00
|
|
|
switch (type) {
|
|
|
|
case HDMI_INFOFRAME_TYPE_AVI:
|
2015-09-19 00:03:37 +07:00
|
|
|
return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i);
|
2013-08-07 02:32:18 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_SPD:
|
2015-09-19 00:03:37 +07:00
|
|
|
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder, i);
|
2013-08-19 22:59:04 +07:00
|
|
|
case HDMI_INFOFRAME_TYPE_VENDOR:
|
2015-09-19 00:03:37 +07:00
|
|
|
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder, i);
|
2012-05-15 03:12:51 +07:00
|
|
|
default:
|
2015-12-16 23:10:00 +07:00
|
|
|
MISSING_CASE(type);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
return INVALID_MMIO_REG;
|
2012-05-15 03:12:51 +07:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2015-11-26 23:27:07 +07:00
|
|
|
static bool g4x_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 05:26:08 +07:00
|
|
|
{
|
2015-11-26 23:27:07 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2014-11-21 04:24:13 +07:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
2014-11-06 05:26:08 +07:00
|
|
|
u32 val = I915_READ(VIDEO_DIP_CTL);
|
|
|
|
|
2015-05-05 21:06:25 +07:00
|
|
|
if ((val & VIDEO_DIP_ENABLE) == 0)
|
|
|
|
return false;
|
2014-11-21 04:24:13 +07:00
|
|
|
|
2015-05-05 21:06:25 +07:00
|
|
|
if ((val & VIDEO_DIP_PORT_MASK) != VIDEO_DIP_PORT(intel_dig_port->port))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return val & (VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_SPD);
|
2014-11-06 05:26:08 +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);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
2012-05-05 03:18:24 +07:00
|
|
|
u32 val = I915_READ(reg);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
int i;
|
2012-05-05 03:18:24 +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: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
|
|
|
}
|
|
|
|
|
2015-11-26 23:27:07 +07:00
|
|
|
static bool ibx_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 05:26:08 +07:00
|
|
|
{
|
2015-11-26 23:27:07 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2015-04-29 19:30:07 +07:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
2015-11-26 23:27:07 +07:00
|
|
|
enum pipe pipe = to_intel_crtc(pipe_config->base.crtc)->pipe;
|
|
|
|
i915_reg_t reg = TVIDEO_DIP_CTL(pipe);
|
2014-11-06 05:26:08 +07:00
|
|
|
u32 val = I915_READ(reg);
|
|
|
|
|
2015-05-05 21:06:25 +07:00
|
|
|
if ((val & VIDEO_DIP_ENABLE) == 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if ((val & VIDEO_DIP_PORT_MASK) != VIDEO_DIP_PORT(intel_dig_port->port))
|
|
|
|
return false;
|
2015-04-29 19:30:07 +07:00
|
|
|
|
2015-05-05 21:06:25 +07:00
|
|
|
return val & (VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
2014-11-06 05:26:08 +07:00
|
|
|
}
|
|
|
|
|
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);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
2012-05-05 03:18:17 +07:00
|
|
|
u32 val = I915_READ(reg);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
int i;
|
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
|
|
|
|
2015-11-26 23:27:07 +07:00
|
|
|
static bool cpt_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 05:26:08 +07:00
|
|
|
{
|
2015-11-26 23:27:07 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
|
|
|
enum pipe pipe = to_intel_crtc(pipe_config->base.crtc)->pipe;
|
|
|
|
u32 val = I915_READ(TVIDEO_DIP_CTL(pipe));
|
2014-11-06 05:26:08 +07:00
|
|
|
|
2015-05-05 21:06:25 +07:00
|
|
|
if ((val & VIDEO_DIP_ENABLE) == 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
return val & (VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
2014-11-06 05:26:08 +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);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t reg = VLV_TVIDEO_DIP_CTL(intel_crtc->pipe);
|
2012-05-05 03:18:17 +07:00
|
|
|
u32 val = I915_READ(reg);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
int i;
|
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
|
|
|
}
|
|
|
|
|
2015-11-26 23:27:07 +07:00
|
|
|
static bool vlv_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 05:26:08 +07:00
|
|
|
{
|
2015-11-26 23:27:07 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2015-04-16 06:52:29 +07:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
2015-11-26 23:27:07 +07:00
|
|
|
enum pipe pipe = to_intel_crtc(pipe_config->base.crtc)->pipe;
|
|
|
|
u32 val = I915_READ(VLV_TVIDEO_DIP_CTL(pipe));
|
2014-11-06 05:26:08 +07:00
|
|
|
|
2015-05-05 21:06:25 +07:00
|
|
|
if ((val & VIDEO_DIP_ENABLE) == 0)
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if ((val & VIDEO_DIP_PORT_MASK) != VIDEO_DIP_PORT(intel_dig_port->port))
|
|
|
|
return false;
|
2015-04-16 06:52:29 +07:00
|
|
|
|
2015-05-05 21:06:25 +07:00
|
|
|
return val & (VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
2014-11-06 05:26:08 +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);
|
2015-09-19 00:03:37 +07:00
|
|
|
enum transcoder cpu_transcoder = intel_crtc->config->cpu_transcoder;
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t ctl_reg = HSW_TVIDEO_DIP_CTL(cpu_transcoder);
|
|
|
|
i915_reg_t data_reg;
|
2013-08-07 02:32:18 +07:00
|
|
|
int i;
|
2012-05-15 03:12:51 +07:00
|
|
|
u32 val = I915_READ(ctl_reg);
|
2012-05-10 20:18:02 +07:00
|
|
|
|
2015-09-19 00:03:37 +07:00
|
|
|
data_reg = hsw_dip_data_reg(dev_priv, cpu_transcoder, type, 0);
|
2012-05-15 03:12:51 +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
|
|
|
mmiowb();
|
2012-05-15 03:12:51 +07:00
|
|
|
for (i = 0; i < len; i += 4) {
|
2015-09-19 00:03:37 +07:00
|
|
|
I915_WRITE(hsw_dip_data_reg(dev_priv, cpu_transcoder,
|
|
|
|
type, i >> 2), *data);
|
2012-05-15 03:12:51 +07:00
|
|
|
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)
|
2015-09-19 00:03:37 +07:00
|
|
|
I915_WRITE(hsw_dip_data_reg(dev_priv, cpu_transcoder,
|
|
|
|
type, i >> 2), 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
|
|
|
}
|
|
|
|
|
2015-11-26 23:27:07 +07:00
|
|
|
static bool hsw_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 05:26:08 +07:00
|
|
|
{
|
2015-11-26 23:27:07 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
|
|
|
u32 val = I915_READ(HSW_TVIDEO_DIP_CTL(pipe_config->cpu_transcoder));
|
2014-11-06 05:26:08 +07:00
|
|
|
|
2015-05-05 21:06:25 +07:00
|
|
|
return val & (VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
|
|
|
|
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
|
|
|
|
VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
|
2014-11-06 05:26:08 +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,
|
2015-09-08 17:40:49 +07:00
|
|
|
const 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) {
|
2015-01-15 19:55:25 +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,
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode)
|
2013-08-19 22:59:04 +07:00
|
|
|
{
|
|
|
|
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,
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode)
|
2012-05-29 02:42:48 +07:00
|
|
|
{
|
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: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t reg = VIDEO_DIP_CTL;
|
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 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;
|
2015-05-05 21:06:24 +07:00
|
|
|
if (port != (val & VIDEO_DIP_PORT_MASK)) {
|
|
|
|
DRM_DEBUG_KMS("video DIP still enabled on port %c\n",
|
|
|
|
(val & VIDEO_DIP_PORT_MASK) >> 29);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
val &= ~(VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_SPD);
|
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, 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) {
|
2015-05-05 21:06:24 +07:00
|
|
|
DRM_DEBUG_KMS("video DIP already enabled on port %c\n",
|
|
|
|
(val & VIDEO_DIP_PORT_MASK) >> 29);
|
|
|
|
return;
|
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;
|
2015-05-05 21:06:24 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_SPD);
|
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
|
|
|
}
|
|
|
|
|
2015-05-05 21:06:20 +07:00
|
|
|
static bool hdmi_sink_is_deep_color(struct drm_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = encoder->dev;
|
|
|
|
struct drm_connector *connector;
|
|
|
|
|
|
|
|
WARN_ON(!drm_modeset_is_locked(&dev->mode_config.connection_mutex));
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HDMI cloning is only supported on g4x which doesn't
|
|
|
|
* support deep color or GCP infoframes anyway so no
|
|
|
|
* need to worry about multiple HDMI sinks here.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(connector, &dev->mode_config.connector_list, head)
|
|
|
|
if (connector->encoder == encoder)
|
|
|
|
return connector->display_info.bpc > 8;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-05-05 21:06:21 +07:00
|
|
|
/*
|
|
|
|
* Determine if default_phase=1 can be indicated in the GCP infoframe.
|
|
|
|
*
|
|
|
|
* From HDMI specification 1.4a:
|
|
|
|
* - The first pixel of each Video Data Period shall always have a pixel packing phase of 0
|
|
|
|
* - The first pixel following each Video Data Period shall have a pixel packing phase of 0
|
|
|
|
* - The PP bits shall be constant for all GCPs and will be equal to the last packing phase
|
|
|
|
* - The first pixel following every transition of HSYNC or VSYNC shall have a pixel packing
|
|
|
|
* phase of 0
|
|
|
|
*/
|
|
|
|
static bool gcp_default_phase_possible(int pipe_bpp,
|
|
|
|
const struct drm_display_mode *mode)
|
|
|
|
{
|
|
|
|
unsigned int pixels_per_group;
|
|
|
|
|
|
|
|
switch (pipe_bpp) {
|
|
|
|
case 30:
|
|
|
|
/* 4 pixels in 5 clocks */
|
|
|
|
pixels_per_group = 4;
|
|
|
|
break;
|
|
|
|
case 36:
|
|
|
|
/* 2 pixels in 3 clocks */
|
|
|
|
pixels_per_group = 2;
|
|
|
|
break;
|
|
|
|
case 48:
|
|
|
|
/* 1 pixel in 2 clocks */
|
|
|
|
pixels_per_group = 1;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* phase information not relevant for 8bpc */
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return mode->crtc_hdisplay % pixels_per_group == 0 &&
|
|
|
|
mode->crtc_htotal % pixels_per_group == 0 &&
|
|
|
|
mode->crtc_hblank_start % pixels_per_group == 0 &&
|
|
|
|
mode->crtc_hblank_end % pixels_per_group == 0 &&
|
|
|
|
mode->crtc_hsync_start % pixels_per_group == 0 &&
|
|
|
|
mode->crtc_hsync_end % pixels_per_group == 0 &&
|
|
|
|
((mode->flags & DRM_MODE_FLAG_INTERLACE) == 0 ||
|
|
|
|
mode->crtc_htotal/2 % pixels_per_group == 0);
|
|
|
|
}
|
|
|
|
|
2015-05-05 21:06:20 +07:00
|
|
|
static bool intel_hdmi_set_gcp_infoframe(struct drm_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = encoder->dev->dev_private;
|
|
|
|
struct intel_crtc *crtc = to_intel_crtc(encoder->crtc);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t reg;
|
|
|
|
u32 val = 0;
|
2015-05-05 21:06:20 +07:00
|
|
|
|
|
|
|
if (HAS_DDI(dev_priv))
|
|
|
|
reg = HSW_TVIDEO_DIP_GCP(crtc->config->cpu_transcoder);
|
2015-12-10 03:29:35 +07:00
|
|
|
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
|
2015-05-05 21:06:20 +07:00
|
|
|
reg = VLV_TVIDEO_DIP_GCP(crtc->pipe);
|
2016-04-07 15:08:05 +07:00
|
|
|
else if (HAS_PCH_SPLIT(dev_priv))
|
2015-05-05 21:06:20 +07:00
|
|
|
reg = TVIDEO_DIP_GCP(crtc->pipe);
|
|
|
|
else
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Indicate color depth whenever the sink supports deep color */
|
|
|
|
if (hdmi_sink_is_deep_color(encoder))
|
|
|
|
val |= GCP_COLOR_INDICATION;
|
|
|
|
|
2015-05-05 21:06:21 +07:00
|
|
|
/* Enable default_phase whenever the display mode is suitably aligned */
|
|
|
|
if (gcp_default_phase_possible(crtc->config->pipe_bpp,
|
|
|
|
&crtc->config->base.adjusted_mode))
|
|
|
|
val |= GCP_DEFAULT_PHASE_ENABLE;
|
|
|
|
|
2015-05-05 21:06:20 +07:00
|
|
|
I915_WRITE(reg, val);
|
|
|
|
|
|
|
|
return val != 0;
|
|
|
|
}
|
|
|
|
|
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,
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode)
|
2012-05-29 02:42:48 +07:00
|
|
|
{
|
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: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
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 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;
|
2015-05-05 21:06:24 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
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, 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)) {
|
2015-05-05 21:06:24 +07:00
|
|
|
WARN(val & VIDEO_DIP_ENABLE,
|
|
|
|
"DIP already enabled on port %c\n",
|
|
|
|
(val & VIDEO_DIP_PORT_MASK) >> 29);
|
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;
|
2015-05-05 21:06:24 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
2012-05-29 02:42:51 +07:00
|
|
|
|
2015-05-05 21:06:20 +07:00
|
|
|
if (intel_hdmi_set_gcp_infoframe(encoder))
|
|
|
|
val |= VIDEO_DIP_ENABLE_GCP;
|
|
|
|
|
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,
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode)
|
2012-05-29 02:42:48 +07:00
|
|
|
{
|
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);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
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 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;
|
2015-05-05 21:06:24 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
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, 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 |
|
2015-05-05 21:06:24 +07:00
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
2012-05-29 02:42:51 +07:00
|
|
|
|
2015-05-05 21:06:20 +07:00
|
|
|
if (intel_hdmi_set_gcp_infoframe(encoder))
|
|
|
|
val |= 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,
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode)
|
2012-05-29 02:42:48 +07:00
|
|
|
{
|
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);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t reg = VLV_TVIDEO_DIP_CTL(intel_crtc->pipe);
|
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 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;
|
2015-05-05 21:06:24 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
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, 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)) {
|
2015-05-05 21:06:24 +07:00
|
|
|
WARN(val & VIDEO_DIP_ENABLE,
|
|
|
|
"DIP already enabled on port %c\n",
|
|
|
|
(val & VIDEO_DIP_PORT_MASK) >> 29);
|
2014-04-03 00:08:51 +07:00
|
|
|
val &= ~VIDEO_DIP_PORT_MASK;
|
|
|
|
val |= port;
|
|
|
|
}
|
|
|
|
|
2012-05-29 02:42:51 +07:00
|
|
|
val |= VIDEO_DIP_ENABLE;
|
2015-05-05 21:06:24 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
2012-05-29 02:42:51 +07:00
|
|
|
|
2015-05-05 21:06:20 +07:00
|
|
|
if (intel_hdmi_set_gcp_infoframe(encoder))
|
|
|
|
val |= 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,
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode)
|
2012-05-29 02:42:48 +07:00
|
|
|
{
|
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);
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
i915_reg_t 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);
|
|
|
|
|
2015-05-05 21:06:24 +07:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_VSC_HSW | VIDEO_DIP_ENABLE_AVI_HSW |
|
|
|
|
VIDEO_DIP_ENABLE_GCP_HSW | VIDEO_DIP_ENABLE_VS_HSW |
|
|
|
|
VIDEO_DIP_ENABLE_GMP_HSW | VIDEO_DIP_ENABLE_SPD_HSW);
|
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
if (!enable) {
|
2015-05-05 21:06:24 +07:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2015-05-05 21:06:20 +07:00
|
|
|
if (intel_hdmi_set_gcp_infoframe(encoder))
|
|
|
|
val |= VIDEO_DIP_ENABLE_GCP_HSW;
|
|
|
|
|
2012-05-29 02:42:53 +07:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2016-05-03 02:08:24 +07:00
|
|
|
void intel_dp_dual_mode_set_tmds_output(struct intel_hdmi *hdmi, bool enable)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = to_i915(intel_hdmi_to_dev(hdmi));
|
|
|
|
struct i2c_adapter *adapter =
|
|
|
|
intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
|
|
|
|
|
|
|
|
if (hdmi->dp_dual_mode.type < DRM_DP_DUAL_MODE_TYPE2_DVI)
|
|
|
|
return;
|
|
|
|
|
|
|
|
DRM_DEBUG_KMS("%s DP dual mode adaptor TMDS output\n",
|
|
|
|
enable ? "Enabling" : "Disabling");
|
|
|
|
|
|
|
|
drm_dp_dual_mode_set_tmds_output(hdmi->dp_dual_mode.type,
|
|
|
|
adapter, enable);
|
|
|
|
}
|
|
|
|
|
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);
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode = &crtc->config->base.adjusted_mode;
|
2013-02-19 05:00:26 +07:00
|
|
|
u32 hdmi_val;
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2016-05-03 02:08:24 +07:00
|
|
|
intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
|
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
hdmi_val = SDVO_ENCODING_HDMI;
|
2015-07-06 19:10:00 +07:00
|
|
|
if (!HAS_PCH_SPLIT(dev) && crtc->config->limited_color_range)
|
|
|
|
hdmi_val |= HDMI_COLOR_RANGE_16_235;
|
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
|
|
|
|
2015-01-15 19:55:25 +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
|
|
|
|
2015-01-15 19:55:25 +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
|
|
|
|
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;
|
2016-02-12 23:55:20 +07:00
|
|
|
bool ret;
|
2012-07-02 18:27:29 +07:00
|
|
|
|
2014-03-05 21:20:54 +07:00
|
|
|
power_domain = intel_display_port_power_domain(encoder);
|
2016-02-12 23:55:20 +07:00
|
|
|
if (!intel_display_power_get_if_enabled(dev_priv, power_domain))
|
2014-03-05 21:20:54 +07:00
|
|
|
return false;
|
|
|
|
|
2016-02-12 23:55:20 +07:00
|
|
|
ret = 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))
|
2016-02-12 23:55:20 +07:00
|
|
|
goto out;
|
2012-07-02 18:27:29 +07:00
|
|
|
|
|
|
|
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);
|
|
|
|
|
2016-02-12 23:55:20 +07:00
|
|
|
ret = true;
|
|
|
|
|
|
|
|
out:
|
|
|
|
intel_display_power_put(dev_priv, power_domain);
|
|
|
|
|
|
|
|
return ret;
|
2012-07-02 18:27:29 +07:00
|
|
|
}
|
|
|
|
|
2013-05-15 07:08:26 +07:00
|
|
|
static void intel_hdmi_get_config(struct intel_encoder *encoder,
|
2015-01-15 19:55:21 +07:00
|
|
|
struct intel_crtc_state *pipe_config)
|
2013-05-15 07:08:26 +07:00
|
|
|
{
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
2014-09-12 19:46:29 +07:00
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2013-05-15 07:08:26 +07:00
|
|
|
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;
|
|
|
|
|
2015-11-26 23:27:07 +07:00
|
|
|
if (intel_hdmi->infoframe_enabled(&encoder->base, pipe_config))
|
2014-11-06 05:26:08 +07:00
|
|
|
pipe_config->has_infoframe = true;
|
|
|
|
|
2014-09-17 19:34:58 +07:00
|
|
|
if (tmp & SDVO_AUDIO_ENABLE)
|
2014-04-25 04:54:52 +07:00
|
|
|
pipe_config->has_audio = true;
|
|
|
|
|
2014-09-12 19:46:29 +07:00
|
|
|
if (!HAS_PCH_SPLIT(dev) &&
|
|
|
|
tmp & HDMI_COLOR_RANGE_16_235)
|
|
|
|
pipe_config->limited_color_range = true;
|
|
|
|
|
2015-01-15 19:55:22 +07:00
|
|
|
pipe_config->base.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;
|
|
|
|
|
2015-05-05 21:06:26 +07:00
|
|
|
if (pipe_config->pixel_multiplier)
|
|
|
|
dotclock /= pipe_config->pixel_multiplier;
|
|
|
|
|
2015-01-15 19:55:22 +07:00
|
|
|
pipe_config->base.adjusted_mode.crtc_clock = dotclock;
|
2016-04-27 19:44:16 +07:00
|
|
|
|
|
|
|
pipe_config->lane_count = 4;
|
2013-05-15 07:08:26 +07:00
|
|
|
}
|
|
|
|
|
2015-05-05 21:06:19 +07:00
|
|
|
static void intel_enable_hdmi_audio(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
|
|
|
|
|
|
|
|
WARN_ON(!crtc->config->has_hdmi_sink);
|
|
|
|
DRM_DEBUG_DRIVER("Enabling HDMI audio on pipe %c\n",
|
|
|
|
pipe_name(crtc->pipe));
|
|
|
|
intel_audio_codec_enable(encoder);
|
|
|
|
}
|
|
|
|
|
2015-05-05 21:06:23 +07:00
|
|
|
static void g4x_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;
|
2015-05-05 21:06:23 +07:00
|
|
|
struct intel_crtc *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;
|
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
temp = I915_READ(intel_hdmi->hdmi_reg);
|
2009-11-02 14:52:30 +07:00
|
|
|
|
2015-05-05 21:06:23 +07:00
|
|
|
temp |= SDVO_ENABLE;
|
|
|
|
if (crtc->config->has_audio)
|
|
|
|
temp |= SDVO_AUDIO_ENABLE;
|
2012-06-05 16:03:39 +07:00
|
|
|
|
2015-05-05 21:06:23 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
|
|
|
|
|
|
|
if (crtc->config->has_audio)
|
|
|
|
intel_enable_hdmi_audio(encoder);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ibx_enable_hdmi(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
u32 temp;
|
|
|
|
|
|
|
|
temp = I915_READ(intel_hdmi->hdmi_reg);
|
2009-11-02 14:52:30 +07:00
|
|
|
|
2015-05-05 21:06:23 +07:00
|
|
|
temp |= SDVO_ENABLE;
|
|
|
|
if (crtc->config->has_audio)
|
|
|
|
temp |= SDVO_AUDIO_ENABLE;
|
2012-06-30 13:59:56 +07:00
|
|
|
|
2015-05-05 21:06:23 +07:00
|
|
|
/*
|
|
|
|
* HW workaround, need to write this twice for issue
|
|
|
|
* that may result in first write getting masked.
|
|
|
|
*/
|
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
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
|
|
|
|
2015-05-05 21:06:23 +07:00
|
|
|
/*
|
|
|
|
* HW workaround, need to toggle enable bit off and on
|
|
|
|
* for 12bpc with pixel repeat.
|
|
|
|
*
|
|
|
|
* FIXME: BSpec says this should be done at the end of
|
|
|
|
* of the modeset sequence, so not sure if this isn't too soon.
|
2012-06-30 13:59:56 +07:00
|
|
|
*/
|
2015-05-05 21:06:23 +07:00
|
|
|
if (crtc->config->pipe_bpp > 24 &&
|
|
|
|
crtc->config->pixel_multiplier > 1) {
|
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp & ~SDVO_ENABLE);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HW workaround, need to write this twice for issue
|
|
|
|
* that may result in first write getting masked.
|
|
|
|
*/
|
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
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
|
|
|
}
|
2014-10-27 21:26:56 +07:00
|
|
|
|
2015-05-05 21:06:23 +07:00
|
|
|
if (crtc->config->has_audio)
|
2015-05-05 21:06:19 +07:00
|
|
|
intel_enable_hdmi_audio(encoder);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void cpt_enable_hdmi(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
enum pipe pipe = crtc->pipe;
|
|
|
|
u32 temp;
|
|
|
|
|
|
|
|
temp = I915_READ(intel_hdmi->hdmi_reg);
|
|
|
|
|
|
|
|
temp |= SDVO_ENABLE;
|
|
|
|
if (crtc->config->has_audio)
|
|
|
|
temp |= SDVO_AUDIO_ENABLE;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* WaEnableHDMI8bpcBefore12bpc:snb,ivb
|
|
|
|
*
|
|
|
|
* The procedure for 12bpc is as follows:
|
|
|
|
* 1. disable HDMI clock gating
|
|
|
|
* 2. enable HDMI with 8bpc
|
|
|
|
* 3. enable HDMI with 12bpc
|
|
|
|
* 4. enable HDMI clock gating
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (crtc->config->pipe_bpp > 24) {
|
|
|
|
I915_WRITE(TRANS_CHICKEN1(pipe),
|
|
|
|
I915_READ(TRANS_CHICKEN1(pipe)) |
|
|
|
|
TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
|
|
|
|
|
|
|
|
temp &= ~SDVO_COLOR_FORMAT_MASK;
|
|
|
|
temp |= SDVO_COLOR_FORMAT_8bpc;
|
2014-10-27 21:26:56 +07:00
|
|
|
}
|
2015-05-05 21:06:19 +07:00
|
|
|
|
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
|
|
|
|
|
|
|
if (crtc->config->pipe_bpp > 24) {
|
|
|
|
temp &= ~SDVO_COLOR_FORMAT_MASK;
|
|
|
|
temp |= HDMI_COLOR_FORMAT_12bpc;
|
|
|
|
|
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
|
|
|
|
|
|
|
I915_WRITE(TRANS_CHICKEN1(pipe),
|
|
|
|
I915_READ(TRANS_CHICKEN1(pipe)) &
|
|
|
|
~TRANS_CHICKEN1_HDMIUNIT_GC_DISABLE);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (crtc->config->has_audio)
|
|
|
|
intel_enable_hdmi_audio(encoder);
|
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);
|
2014-10-27 21:26:55 +07:00
|
|
|
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
|
2012-06-30 13:59:56 +07:00
|
|
|
u32 temp;
|
|
|
|
|
2013-02-19 05:00:26 +07:00
|
|
|
temp = I915_READ(intel_hdmi->hdmi_reg);
|
2012-06-30 13:59:56 +07:00
|
|
|
|
2015-05-05 21:17:34 +07:00
|
|
|
temp &= ~(SDVO_ENABLE | SDVO_AUDIO_ENABLE);
|
2013-02-19 05:00:26 +07:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2015-05-05 21:17:34 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* HW workaround for IBX, we need to move the port
|
|
|
|
* to transcoder A after disabling it to allow the
|
|
|
|
* matching DP port to be enabled on transcoder A.
|
|
|
|
*/
|
|
|
|
if (HAS_PCH_IBX(dev) && crtc->pipe == PIPE_B) {
|
2015-10-31 00:23:22 +07:00
|
|
|
/*
|
|
|
|
* We get CPU/PCH FIFO underruns on the other pipe when
|
|
|
|
* doing the workaround. Sweep them under the rug.
|
|
|
|
*/
|
|
|
|
intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, false);
|
|
|
|
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, false);
|
|
|
|
|
2015-05-05 21:17:34 +07:00
|
|
|
temp &= ~SDVO_PIPE_B_SELECT;
|
|
|
|
temp |= SDVO_ENABLE;
|
|
|
|
/*
|
|
|
|
* HW workaround, need to write this twice for issue
|
|
|
|
* that may result in first write getting masked.
|
|
|
|
*/
|
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
|
|
|
|
|
|
|
temp &= ~SDVO_ENABLE;
|
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2015-10-31 00:23:22 +07:00
|
|
|
|
|
|
|
intel_wait_for_vblank_if_active(dev_priv->dev, PIPE_A);
|
|
|
|
intel_set_cpu_fifo_underrun_reporting(dev_priv, PIPE_A, true);
|
|
|
|
intel_set_pch_fifo_underrun_reporting(dev_priv, PIPE_A, true);
|
2015-05-05 21:17:34 +07:00
|
|
|
}
|
2015-05-05 21:06:20 +07:00
|
|
|
|
2015-05-05 21:06:24 +07:00
|
|
|
intel_hdmi->set_infoframes(&encoder->base, false, NULL);
|
2016-05-03 02:08:24 +07:00
|
|
|
|
|
|
|
intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|
|
|
|
|
2015-05-05 21:17:35 +07:00
|
|
|
static void g4x_disable_hdmi(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
|
|
|
|
|
|
|
|
if (crtc->config->has_audio)
|
|
|
|
intel_audio_codec_disable(encoder);
|
|
|
|
|
|
|
|
intel_disable_hdmi(encoder);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pch_disable_hdmi(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc);
|
|
|
|
|
|
|
|
if (crtc->config->has_audio)
|
|
|
|
intel_audio_codec_disable(encoder);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pch_post_disable_hdmi(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
intel_disable_hdmi(encoder);
|
|
|
|
}
|
|
|
|
|
2016-05-03 02:08:23 +07:00
|
|
|
static int intel_hdmi_source_max_tmds_clock(struct drm_i915_private *dev_priv)
|
2013-07-22 23:02:39 +07:00
|
|
|
{
|
2016-05-03 02:08:23 +07:00
|
|
|
if (IS_G4X(dev_priv))
|
2013-07-22 23:02:39 +07:00
|
|
|
return 165000;
|
2016-05-03 02:08:23 +07:00
|
|
|
else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
|
2013-07-22 23:02:39 +07:00
|
|
|
return 300000;
|
|
|
|
else
|
|
|
|
return 225000;
|
|
|
|
}
|
|
|
|
|
2016-05-03 02:08:23 +07:00
|
|
|
static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
|
|
|
|
bool respect_downstream_limits)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
|
|
|
|
int max_tmds_clock = intel_hdmi_source_max_tmds_clock(to_i915(dev));
|
|
|
|
|
|
|
|
if (respect_downstream_limits) {
|
|
|
|
if (hdmi->dp_dual_mode.max_tmds_clock)
|
|
|
|
max_tmds_clock = min(max_tmds_clock,
|
|
|
|
hdmi->dp_dual_mode.max_tmds_clock);
|
|
|
|
if (!hdmi->has_hdmi_sink)
|
|
|
|
max_tmds_clock = min(max_tmds_clock, 165000);
|
|
|
|
}
|
|
|
|
|
|
|
|
return max_tmds_clock;
|
|
|
|
}
|
|
|
|
|
2015-06-30 23:23:59 +07:00
|
|
|
static enum drm_mode_status
|
|
|
|
hdmi_port_clock_valid(struct intel_hdmi *hdmi,
|
2016-05-03 02:08:23 +07:00
|
|
|
int clock, bool respect_downstream_limits)
|
2015-06-30 23:23:59 +07:00
|
|
|
{
|
|
|
|
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
|
|
|
|
|
|
|
|
if (clock < 25000)
|
|
|
|
return MODE_CLOCK_LOW;
|
2016-05-03 02:08:23 +07:00
|
|
|
if (clock > hdmi_port_clock_limit(hdmi, respect_downstream_limits))
|
2015-06-30 23:23:59 +07:00
|
|
|
return MODE_CLOCK_HIGH;
|
|
|
|
|
2015-07-06 18:44:11 +07:00
|
|
|
/* BXT DPLL can't generate 223-240 MHz */
|
|
|
|
if (IS_BROXTON(dev) && clock > 223333 && clock < 240000)
|
|
|
|
return MODE_CLOCK_RANGE;
|
|
|
|
|
|
|
|
/* CHV DPLL can't generate 216-240 MHz */
|
|
|
|
if (IS_CHERRYVIEW(dev) && clock > 216000 && clock < 240000)
|
2015-06-30 23:23:59 +07:00
|
|
|
return MODE_CLOCK_RANGE;
|
|
|
|
|
|
|
|
return MODE_OK;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
2015-06-30 23:23:59 +07:00
|
|
|
struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
|
|
|
|
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
|
|
|
|
enum drm_mode_status status;
|
|
|
|
int clock;
|
2016-02-02 20:16:39 +07:00
|
|
|
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
|
2015-06-30 23:23:59 +07:00
|
|
|
|
|
|
|
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
|
|
|
|
return MODE_NO_DBLESCAN;
|
2014-09-03 07:03:36 +07:00
|
|
|
|
2015-06-30 23:23:59 +07:00
|
|
|
clock = mode->clock;
|
2016-02-02 20:16:39 +07:00
|
|
|
|
|
|
|
if ((mode->flags & DRM_MODE_FLAG_3D_MASK) == DRM_MODE_FLAG_3D_FRAME_PACKING)
|
|
|
|
clock *= 2;
|
|
|
|
|
|
|
|
if (clock > max_dotclk)
|
|
|
|
return MODE_CLOCK_HIGH;
|
|
|
|
|
2014-09-03 07:03:36 +07:00
|
|
|
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
|
|
|
|
clock *= 2;
|
|
|
|
|
2015-06-30 23:23:59 +07:00
|
|
|
/* check if we can do 8bpc */
|
|
|
|
status = hdmi_port_clock_valid(hdmi, clock, true);
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2015-06-30 23:23:59 +07:00
|
|
|
/* if we can't do 8bpc we may still be able to do 12bpc */
|
|
|
|
if (!HAS_GMCH_DISPLAY(dev) && status != MODE_OK)
|
|
|
|
status = hdmi_port_clock_valid(hdmi, clock * 3 / 2, true);
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2015-06-30 23:23:59 +07:00
|
|
|
return status;
|
2009-01-03 04:33:00 +07:00
|
|
|
}
|
|
|
|
|
2015-03-20 21:18:11 +07:00
|
|
|
static bool hdmi_12bpc_possible(struct intel_crtc_state *crtc_state)
|
2014-03-03 21:15:29 +07:00
|
|
|
{
|
2015-03-20 21:18:11 +07:00
|
|
|
struct drm_device *dev = crtc_state->base.crtc->dev;
|
|
|
|
struct drm_atomic_state *state;
|
2014-03-03 21:15:29 +07:00
|
|
|
struct intel_encoder *encoder;
|
2015-04-21 21:12:59 +07:00
|
|
|
struct drm_connector *connector;
|
2015-03-20 21:18:11 +07:00
|
|
|
struct drm_connector_state *connector_state;
|
2014-03-03 21:15:29 +07:00
|
|
|
int count = 0, count_hdmi = 0;
|
2015-03-20 21:18:11 +07:00
|
|
|
int i;
|
2014-03-03 21:15:29 +07:00
|
|
|
|
2014-07-21 16:53:45 +07:00
|
|
|
if (HAS_GMCH_DISPLAY(dev))
|
2014-03-03 21:15:29 +07:00
|
|
|
return false;
|
|
|
|
|
2015-03-20 21:18:11 +07:00
|
|
|
state = crtc_state->base.state;
|
|
|
|
|
2015-04-21 21:12:59 +07:00
|
|
|
for_each_connector_in_state(state, connector, connector_state, i) {
|
2015-03-20 21:18:11 +07:00
|
|
|
if (connector_state->crtc != crtc_state->base.crtc)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
encoder = to_intel_encoder(connector_state->best_encoder);
|
|
|
|
|
2014-03-03 21:15:29 +07:00
|
|
|
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,
|
2015-01-15 19:55:21 +07:00
|
|
|
struct intel_crtc_state *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;
|
2015-01-15 19:55:22 +07:00
|
|
|
struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
|
2015-06-30 23:23:59 +07:00
|
|
|
int clock_8bpc = pipe_config->base.adjusted_mode.crtc_clock;
|
|
|
|
int clock_12bpc = clock_8bpc * 3 / 2;
|
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;
|
|
|
|
|
2014-11-06 05:26:08 +07:00
|
|
|
if (pipe_config->has_hdmi_sink)
|
|
|
|
pipe_config->has_infoframe = true;
|
|
|
|
|
2013-01-17 21:31:29 +07:00
|
|
|
if (intel_hdmi->color_range_auto) {
|
|
|
|
/* See CEA-861-E - 5.1 Default Encoding Parameters */
|
2015-07-06 19:10:00 +07:00
|
|
|
pipe_config->limited_color_range =
|
|
|
|
pipe_config->has_hdmi_sink &&
|
|
|
|
drm_match_cea_mode(adjusted_mode) > 1;
|
|
|
|
} else {
|
|
|
|
pipe_config->limited_color_range =
|
|
|
|
intel_hdmi->limited_color_range;
|
2013-01-17 21:31:29 +07:00
|
|
|
}
|
|
|
|
|
2014-09-03 07:03:36 +07:00
|
|
|
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK) {
|
|
|
|
pipe_config->pixel_multiplier = 2;
|
2015-06-30 23:23:59 +07:00
|
|
|
clock_8bpc *= 2;
|
2015-05-05 21:06:27 +07:00
|
|
|
clock_12bpc *= 2;
|
2014-09-03 07:03:36 +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 &&
|
2016-05-03 02:08:23 +07:00
|
|
|
hdmi_port_clock_valid(intel_hdmi, clock_12bpc, true) == MODE_OK &&
|
2015-06-30 19:33:54 +07:00
|
|
|
hdmi_12bpc_possible(pipe_config)) {
|
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;
|
2015-06-30 23:23:59 +07:00
|
|
|
|
|
|
|
pipe_config->port_clock = clock_8bpc;
|
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
|
|
|
}
|
|
|
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2015-06-30 23:23:59 +07:00
|
|
|
if (hdmi_port_clock_valid(intel_hdmi, pipe_config->port_clock,
|
|
|
|
false) != MODE_OK) {
|
|
|
|
DRM_DEBUG_KMS("unsupported HDMI clock, rejecting mode\n");
|
2013-04-19 16:24:33 +07:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-09-08 17:40:48 +07:00
|
|
|
/* Set user selected PAR to incoming mode's member */
|
|
|
|
adjusted_mode->picture_aspect_ratio = intel_hdmi->aspect_ratio;
|
|
|
|
|
2016-04-27 19:44:16 +07:00
|
|
|
pipe_config->lane_count = 4;
|
|
|
|
|
2009-01-03 04:33:00 +07:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
static void
|
|
|
|
intel_hdmi_unset_edid(struct drm_connector *connector)
|
2009-04-02 12:13:26 +07:00
|
|
|
{
|
2010-09-09 22:20:55 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
2009-04-02 12:13:26 +07:00
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
intel_hdmi->has_hdmi_sink = false;
|
|
|
|
intel_hdmi->has_audio = false;
|
|
|
|
intel_hdmi->rgb_quant_range_selectable = false;
|
|
|
|
|
2016-05-03 02:08:23 +07:00
|
|
|
intel_hdmi->dp_dual_mode.type = DRM_DP_DUAL_MODE_NONE;
|
|
|
|
intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
|
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
kfree(to_intel_connector(connector)->detect_edid);
|
|
|
|
to_intel_connector(connector)->detect_edid = NULL;
|
|
|
|
}
|
|
|
|
|
2016-05-03 02:08:23 +07:00
|
|
|
static void
|
2016-05-04 18:45:22 +07:00
|
|
|
intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
|
2016-05-03 02:08:23 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = to_i915(connector->dev);
|
|
|
|
struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
|
2016-05-04 18:45:22 +07:00
|
|
|
enum port port = hdmi_to_dig_port(hdmi)->port;
|
2016-05-03 02:08:23 +07:00
|
|
|
struct i2c_adapter *adapter =
|
|
|
|
intel_gmbus_get_adapter(dev_priv, hdmi->ddc_bus);
|
|
|
|
enum drm_dp_dual_mode_type type = drm_dp_dual_mode_detect(adapter);
|
|
|
|
|
2016-05-04 18:45:22 +07:00
|
|
|
/*
|
|
|
|
* Type 1 DVI adaptors are not required to implement any
|
|
|
|
* registers, so we can't always detect their presence.
|
|
|
|
* Ideally we should be able to check the state of the
|
|
|
|
* CONFIG1 pin, but no such luck on our hardware.
|
|
|
|
*
|
|
|
|
* The only method left to us is to check the VBT to see
|
|
|
|
* if the port is a dual mode capable DP port. But let's
|
|
|
|
* only do that when we sucesfully read the EDID, to avoid
|
|
|
|
* confusing log messages about DP dual mode adaptors when
|
|
|
|
* there's nothing connected to the port.
|
|
|
|
*/
|
|
|
|
if (type == DRM_DP_DUAL_MODE_UNKNOWN) {
|
|
|
|
if (has_edid &&
|
|
|
|
intel_bios_is_port_dp_dual_mode(dev_priv, port)) {
|
|
|
|
DRM_DEBUG_KMS("Assuming DP dual mode adaptor presence based on VBT\n");
|
|
|
|
type = DRM_DP_DUAL_MODE_TYPE1_DVI;
|
|
|
|
} else {
|
|
|
|
type = DRM_DP_DUAL_MODE_NONE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (type == DRM_DP_DUAL_MODE_NONE)
|
2016-05-03 02:08:23 +07:00
|
|
|
return;
|
|
|
|
|
|
|
|
hdmi->dp_dual_mode.type = type;
|
|
|
|
hdmi->dp_dual_mode.max_tmds_clock =
|
|
|
|
drm_dp_dual_mode_max_tmds_clock(type, adapter);
|
|
|
|
|
|
|
|
DRM_DEBUG_KMS("DP dual mode adaptor (%s) detected (max TMDS clock: %d kHz)\n",
|
|
|
|
drm_dp_get_dual_mode_type_name(type),
|
|
|
|
hdmi->dp_dual_mode.max_tmds_clock);
|
|
|
|
}
|
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
static bool
|
drm/i915: Check live status before reading edid
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.
The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.
This is explained here in, in a rough way:
HPD line ________________
|\ T1 = Monitor Hotplug causing IRQ
| \______________________________________
| |
| |
| | T2 = Live status is stable
| | _____________________________________
| | /|
Live status _____________|_|/ |
| | |
| | |
| | |
T0 T1 T2
(Between T1 and T2 Live status fluctuates or can be even low, depending on
the monitor)
After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.
This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-15 11:14:20 +07:00
|
|
|
intel_hdmi_set_edid(struct drm_connector *connector, bool force)
|
2014-09-03 02:04:01 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = to_i915(connector->dev);
|
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
drm/i915: Check live status before reading edid
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.
The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.
This is explained here in, in a rough way:
HPD line ________________
|\ T1 = Monitor Hotplug causing IRQ
| \______________________________________
| |
| |
| | T2 = Live status is stable
| | _____________________________________
| | /|
Live status _____________|_|/ |
| | |
| | |
| | |
T0 T1 T2
(Between T1 and T2 Live status fluctuates or can be even low, depending on
the monitor)
After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.
This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-15 11:14:20 +07:00
|
|
|
struct edid *edid = NULL;
|
2014-09-03 02:04:01 +07:00
|
|
|
bool connected = false;
|
2013-07-21 02:27:08 +07:00
|
|
|
|
2015-11-20 01:55:00 +07:00
|
|
|
if (force) {
|
|
|
|
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
|
2014-03-05 21:20:53 +07:00
|
|
|
|
drm/i915: Check live status before reading edid
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.
The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.
This is explained here in, in a rough way:
HPD line ________________
|\ T1 = Monitor Hotplug causing IRQ
| \______________________________________
| |
| |
| | T2 = Live status is stable
| | _____________________________________
| | /|
Live status _____________|_|/ |
| | |
| | |
| | |
T0 T1 T2
(Between T1 and T2 Live status fluctuates or can be even low, depending on
the monitor)
After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.
This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-15 11:14:20 +07:00
|
|
|
edid = drm_get_edid(connector,
|
|
|
|
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
|
|
|
|
2016-05-04 18:45:22 +07:00
|
|
|
intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
|
2016-05-03 02:08:23 +07:00
|
|
|
|
2015-11-20 01:55:00 +07:00
|
|
|
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
|
|
|
|
}
|
2009-06-05 14:38:43 +07:00
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
to_intel_connector(connector)->detect_edid = edid;
|
|
|
|
if (edid && edid->input & DRM_EDID_INPUT_DIGITAL) {
|
|
|
|
intel_hdmi->rgb_quant_range_selectable =
|
|
|
|
drm_rgb_quant_range_selectable(edid);
|
|
|
|
|
|
|
|
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
|
2012-02-14 10:45:36 +07:00
|
|
|
if (intel_hdmi->force_audio != HDMI_AUDIO_AUTO)
|
|
|
|
intel_hdmi->has_audio =
|
2014-09-03 02:04:01 +07:00
|
|
|
intel_hdmi->force_audio == HDMI_AUDIO_ON;
|
|
|
|
|
|
|
|
if (intel_hdmi->force_audio != HDMI_AUDIO_OFF_DVI)
|
|
|
|
intel_hdmi->has_hdmi_sink =
|
|
|
|
drm_detect_hdmi_monitor(edid);
|
|
|
|
|
|
|
|
connected = true;
|
2010-09-19 15:29:33 +07:00
|
|
|
}
|
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
return connected;
|
|
|
|
}
|
|
|
|
|
2015-10-09 02:50:57 +07:00
|
|
|
static enum drm_connector_status
|
|
|
|
intel_hdmi_detect(struct drm_connector *connector, bool force)
|
2014-09-03 02:04:01 +07:00
|
|
|
{
|
2015-10-09 02:50:57 +07:00
|
|
|
enum drm_connector_status status;
|
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
|
|
|
struct drm_i915_private *dev_priv = to_i915(connector->dev);
|
drm/i915: Check live status before reading edid
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.
The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.
This is explained here in, in a rough way:
HPD line ________________
|\ T1 = Monitor Hotplug causing IRQ
| \______________________________________
| |
| |
| | T2 = Live status is stable
| | _____________________________________
| | /|
Live status _____________|_|/ |
| | |
| | |
| | |
T0 T1 T2
(Between T1 and T2 Live status fluctuates or can be even low, depending on
the monitor)
After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.
This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-15 11:14:20 +07:00
|
|
|
bool live_status = false;
|
2015-12-15 11:40:30 +07:00
|
|
|
unsigned int try;
|
2014-09-03 02:04:01 +07:00
|
|
|
|
2015-10-09 02:50:57 +07:00
|
|
|
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
|
|
|
|
connector->base.id, connector->name);
|
|
|
|
|
2015-11-20 01:55:01 +07:00
|
|
|
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
|
|
|
|
|
2015-12-23 15:11:35 +07:00
|
|
|
for (try = 0; !live_status && try < 9; try++) {
|
2015-12-15 11:40:30 +07:00
|
|
|
if (try)
|
|
|
|
msleep(10);
|
drm/i915: Check live status before reading edid
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.
The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.
This is explained here in, in a rough way:
HPD line ________________
|\ T1 = Monitor Hotplug causing IRQ
| \______________________________________
| |
| |
| | T2 = Live status is stable
| | _____________________________________
| | /|
Live status _____________|_|/ |
| | |
| | |
| | |
T0 T1 T2
(Between T1 and T2 Live status fluctuates or can be even low, depending on
the monitor)
After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.
This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-15 11:14:20 +07:00
|
|
|
live_status = intel_digital_port_connected(dev_priv,
|
|
|
|
hdmi_to_dig_port(intel_hdmi));
|
|
|
|
}
|
|
|
|
|
2016-04-21 18:18:32 +07:00
|
|
|
if (!live_status) {
|
|
|
|
DRM_DEBUG_KMS("HDMI live status down\n");
|
|
|
|
/*
|
|
|
|
* Live status register is not reliable on all intel platforms.
|
|
|
|
* So consider live_status only for certain platforms, for
|
|
|
|
* others, read EDID to determine presence of sink.
|
|
|
|
*/
|
|
|
|
if (INTEL_INFO(dev_priv)->gen < 7 || IS_IVYBRIDGE(dev_priv))
|
|
|
|
live_status = true;
|
|
|
|
}
|
drm/i915: Check live status before reading edid
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.
The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.
This is explained here in, in a rough way:
HPD line ________________
|\ T1 = Monitor Hotplug causing IRQ
| \______________________________________
| |
| |
| | T2 = Live status is stable
| | _____________________________________
| | /|
Live status _____________|_|/ |
| | |
| | |
| | |
T0 T1 T2
(Between T1 and T2 Live status fluctuates or can be even low, depending on
the monitor)
After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.
This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-15 11:14:20 +07:00
|
|
|
|
2015-10-09 02:50:57 +07:00
|
|
|
intel_hdmi_unset_edid(connector);
|
drm/i915: Add hot_plug hook for hdmi encoder
This patch adds a separate probe function for HDMI
EDID read over DDC channel. This function has been
registered as a .hot_plug handler for HDMI encoder.
The current implementation of hdmi_detect()
function re-sets the cached HDMI edid (in connector->detect_edid) in
every detect call.This function gets called many times, sometimes
directly from userspace probes, forcing drivers to read EDID every
detect function call.This causes several problems like:
1. Race conditions in multiple hot_plug / unplug cases, between
interrupts bottom halves and userspace detections.
2. Many Un-necessary EDID reads for single hotplug/unplug
3. HDMI complaince failures which expects only one EDID read per hotplug
This function will be serving the purpose of really reading the EDID
by really probing the DDC channel, and updating the cached EDID.
The plan is to:
1. i915 IRQ handler bottom half function already calls
intel_encoder->hotplug() function. Adding This probe function which
will read the EDID only in case of a hotplug / unplug.
2. During init_connector this probe will be called to read the edid
3. Reuse the cached EDID in hdmi_detect() function.
The "< gen7" check is there because this was tested only for >=gen7
platforms. For older platforms the hotplug/reading edid path remains same.
v2: Calling set_edid instead of hdmi_probe during init.
Also, for platforms having DDI, intel_encoder for DP and HDMI is same
(taken from intel_dig_port), so for DP also, hot_plug function gets called
which is not intended here. So, check for HDMI in intel_hdmi_probe
Rely on HPD for updating edid only for platforms gen > 8 and also for VLV.
v3: Dropping the gen < 8 || !VLV check. Now all platforms should rely on
hotplug or init for updating the edid.(Daniel)
Also, calling hdmi_probe in init instead of set_edid
v4: Renaming intel_hdmi_probe to intel_hdmi_hot_plug.
Also calling this hotplug handler from intel_hpd_init to take care of init
resume scenarios.
v5: Moved the call to encoder hotplug during init to separate patch(Daniel)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
[danvet: Mark intel_hdmi_hot_plug as static.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-10-05 18:13:15 +07:00
|
|
|
|
2015-10-09 02:50:57 +07:00
|
|
|
if (intel_hdmi_set_edid(connector, live_status)) {
|
2014-09-03 02:04:01 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
|
|
|
|
|
|
|
hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
|
|
|
|
status = connector_status_connected;
|
2015-10-09 02:50:57 +07:00
|
|
|
} else
|
2014-09-03 02:04:01 +07:00
|
|
|
status = connector_status_disconnected;
|
2014-03-05 21:20:53 +07:00
|
|
|
|
2015-11-20 01:55:01 +07:00
|
|
|
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
static void
|
|
|
|
intel_hdmi_force(struct drm_connector *connector)
|
2009-01-03 04:33:00 +07:00
|
|
|
{
|
2014-09-03 02:04:01 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
|
|
|
|
connector->base.id, connector->name);
|
2009-01-03 04:33:00 +07:00
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
intel_hdmi_unset_edid(connector);
|
2014-03-05 21:20:53 +07:00
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
if (connector->status != connector_status_connected)
|
|
|
|
return;
|
2014-03-05 21:20:53 +07:00
|
|
|
|
drm/i915: Check live status before reading edid
The Bspec is very clear that Live status must be checked about before
trying to read EDID over DDC channel. This patch makes sure that HDMI
EDID is read only when live status is up.
The live status doesn't seem to perform very consistent across various
platforms when tested with different monitors. The reason behind that is
some monitors are late to provide right voltage to set live_status up.
So, after getting the interrupt, for a small duration, live status reg
fluctuates, and then settles down showing the correct staus.
This is explained here in, in a rough way:
HPD line ________________
|\ T1 = Monitor Hotplug causing IRQ
| \______________________________________
| |
| |
| | T2 = Live status is stable
| | _____________________________________
| | /|
Live status _____________|_|/ |
| | |
| | |
| | |
T0 T1 T2
(Between T1 and T2 Live status fluctuates or can be even low, depending on
the monitor)
After several experiments, we have concluded that a max delay
of 30ms is enough to allow the live status to settle down with
most of the monitors. This total delay of 30ms has been split into
a resolution of 3 retries of 10ms each, for the better cases.
This delay is kept at 30ms, keeping in consideration that, HDCP compliance
expect the HPD handler to respond a plug out in 100ms, by disabling port.
v2: Adding checks for VLV/CHV as well. Reusing old ibx and g4x functions
to check digital port status. Adding a separate function to get bxt live
status (Daniel)
v3: Using intel_encoder->hpd_pin to check the live status (Siva)
Moving the live status read to intel_hdmi_probe and passing parameter
to read/not to read the edid. (me)
v4:
* Added live status check for all platforms using
intel_digital_port_connected.
* Rebased on top of Jani's DP cleanup series
* Some monitors take time in setting the live status. So retry for few
times if this is a connect HPD
v5: Removed extra "drm/i915" from commit message. Adding Shashank's sob
which was missed.
v6: Drop the (!detect_edid && !live_status check) check because for DDI
ports which are enumerated as hdmi as well as DP, we don't have a
mechanism to differentiate between DP and hdmi inside the encoder's
hot_plug. This leads to call to the hdmi's hot_plug hook for DP as well
as hdmi which leads to issues during unplug because of the above check.
v7: Make intel_digital_port_connected global in this patch, some
reformatting of while loop, adding a print when live status is not
up. (Rodrigo)
v8: Rebase it on nightly which involved skipping the hot_plug hook for now
and letting the live_status check happen in detect until the hpd handling
part is finalized (Daniel)
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Sonika Jindal <sonika.jindal@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-09-15 11:14:20 +07:00
|
|
|
intel_hdmi_set_edid(connector, true);
|
2014-09-03 02:04:01 +07:00
|
|
|
hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
|
|
|
|
}
|
2014-03-05 21:20:53 +07:00
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
static int intel_hdmi_get_modes(struct drm_connector *connector)
|
|
|
|
{
|
|
|
|
struct edid *edid;
|
|
|
|
|
|
|
|
edid = to_intel_connector(connector)->detect_edid;
|
|
|
|
if (edid == NULL)
|
|
|
|
return 0;
|
2014-03-05 21:20:53 +07:00
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
return intel_connector_update_modes(connector, edid);
|
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)
|
|
|
|
{
|
|
|
|
bool has_audio = false;
|
2014-09-03 02:04:01 +07:00
|
|
|
struct edid *edid;
|
2011-02-10 01:46:58 +07:00
|
|
|
|
2014-09-03 02:04:01 +07:00
|
|
|
edid = to_intel_connector(connector)->detect_edid;
|
|
|
|
if (edid && edid->input & DRM_EDID_INPUT_DIGITAL)
|
|
|
|
has_audio = drm_detect_monitor_audio(edid);
|
2014-03-05 21:20:53 +07:00
|
|
|
|
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;
|
2015-07-06 19:10:00 +07:00
|
|
|
bool old_range = intel_hdmi->limited_color_range;
|
2013-04-22 22:07:23 +07:00
|
|
|
|
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;
|
2015-07-06 19:10:00 +07:00
|
|
|
intel_hdmi->limited_color_range = false;
|
2013-01-17 21:31:29 +07:00
|
|
|
break;
|
|
|
|
case INTEL_BROADCAST_RGB_LIMITED:
|
|
|
|
intel_hdmi->color_range_auto = false;
|
2015-07-06 19:10:00 +07:00
|
|
|
intel_hdmi->limited_color_range = true;
|
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 &&
|
2015-07-06 19:10:00 +07:00
|
|
|
old_range == intel_hdmi->limited_color_range)
|
2013-04-22 22:07:23 +07:00
|
|
|
return 0;
|
|
|
|
|
2011-02-22 05:23:52 +07:00
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
2014-06-11 12:36:01 +07:00
|
|
|
if (property == connector->dev->mode_config.aspect_ratio_property) {
|
|
|
|
switch (val) {
|
|
|
|
case DRM_MODE_PICTURE_ASPECT_NONE:
|
|
|
|
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
|
|
|
|
break;
|
|
|
|
case DRM_MODE_PICTURE_ASPECT_4_3:
|
|
|
|
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_4_3;
|
|
|
|
break;
|
|
|
|
case DRM_MODE_PICTURE_ASPECT_16_9:
|
|
|
|
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_16_9;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
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);
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode = &intel_crtc->config->base.adjusted_mode;
|
2014-04-06 01:51:35 +07:00
|
|
|
|
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,
|
2015-01-15 19:55:25 +07:00
|
|
|
intel_crtc->config->has_hdmi_sink,
|
2014-04-25 04:54:47 +07:00
|
|
|
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);
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode = &intel_crtc->config->base.adjusted_mode;
|
2016-04-27 19:44:24 +07:00
|
|
|
|
|
|
|
vlv_phy_pre_encoder_enable(encoder);
|
2013-07-30 16:20:31 +07:00
|
|
|
|
2016-04-27 19:44:22 +07:00
|
|
|
/* HDMI 1.0V-2dB */
|
|
|
|
vlv_set_phy_signal_level(encoder, 0x2b245f5f, 0x00002000, 0x5578b83a,
|
|
|
|
0x2b247878);
|
|
|
|
|
2014-04-25 04:54:47 +07:00
|
|
|
intel_hdmi->set_infoframes(&encoder->base,
|
2015-01-15 19:55:25 +07:00
|
|
|
intel_crtc->config->has_hdmi_sink,
|
2014-04-25 04:54:47 +07:00
|
|
|
adjusted_mode);
|
2014-04-06 01:51:35 +07:00
|
|
|
|
2015-05-05 21:06:23 +07:00
|
|
|
g4x_enable_hdmi(encoder);
|
2013-07-30 16:20:31 +07:00
|
|
|
|
2015-04-10 22:21:31 +07:00
|
|
|
vlv_wait_port_ready(dev_priv, dport, 0x0);
|
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
|
|
|
{
|
2014-04-25 04:54:56 +07:00
|
|
|
intel_hdmi_prepare(encoder);
|
|
|
|
|
2016-04-27 19:44:23 +07:00
|
|
|
vlv_phy_pre_pll_enable(encoder);
|
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)
|
|
|
|
{
|
2014-06-28 06:04:02 +07:00
|
|
|
intel_hdmi_prepare(encoder);
|
|
|
|
|
2016-04-27 19:44:19 +07:00
|
|
|
chv_phy_pre_pll_enable(encoder);
|
2014-04-09 17:29:05 +07:00
|
|
|
}
|
|
|
|
|
2015-07-09 03:45:49 +07:00
|
|
|
static void chv_hdmi_post_pll_disable(struct intel_encoder *encoder)
|
|
|
|
{
|
2016-04-27 19:44:21 +07:00
|
|
|
chv_phy_post_pll_disable(encoder);
|
2015-07-09 03:45:49 +07:00
|
|
|
}
|
|
|
|
|
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
|
|
|
{
|
|
|
|
/* Reset lanes to avoid HDMI flicker (VLV w/a) */
|
2016-04-27 19:44:25 +07:00
|
|
|
vlv_phy_reset_lanes(encoder);
|
2013-04-19 04:51:36 +07:00
|
|
|
}
|
|
|
|
|
2014-04-09 17:29:00 +07:00
|
|
|
static void chv_hdmi_post_disable(struct intel_encoder *encoder)
|
|
|
|
{
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
|
2015-05-27 00:42:30 +07:00
|
|
|
mutex_lock(&dev_priv->sb_lock);
|
2014-04-09 17:29:00 +07:00
|
|
|
|
2015-07-10 00:14:11 +07:00
|
|
|
/* Assert data lane reset */
|
|
|
|
chv_data_lane_soft_reset(encoder, true);
|
2014-04-09 17:29:00 +07:00
|
|
|
|
2015-05-27 00:42:30 +07:00
|
|
|
mutex_unlock(&dev_priv->sb_lock);
|
2014-04-09 17:29:00 +07:00
|
|
|
}
|
|
|
|
|
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);
|
2014-11-22 02:13:02 +07:00
|
|
|
struct intel_hdmi *intel_hdmi = &dport->hdmi;
|
2014-04-09 17:28:20 +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);
|
2015-09-08 17:40:49 +07:00
|
|
|
const struct drm_display_mode *adjusted_mode = &intel_crtc->config->base.adjusted_mode;
|
2015-04-10 22:21:27 +07:00
|
|
|
|
2016-04-27 19:44:20 +07:00
|
|
|
chv_phy_pre_encoder_enable(encoder);
|
2014-08-18 18:42:45 +07:00
|
|
|
|
2014-04-09 17:28:20 +07:00
|
|
|
/* FIXME: Program the support xxx V-dB */
|
|
|
|
/* Use 800mV-0dB */
|
2016-04-27 19:44:17 +07:00
|
|
|
chv_set_phy_signal_level(encoder, 128, 102, false);
|
2014-04-09 17:28:20 +07:00
|
|
|
|
2014-11-22 02:13:02 +07:00
|
|
|
intel_hdmi->set_infoframes(&encoder->base,
|
2015-01-15 19:55:25 +07:00
|
|
|
intel_crtc->config->has_hdmi_sink,
|
2014-11-22 02:13:02 +07:00
|
|
|
adjusted_mode);
|
|
|
|
|
2015-05-05 21:06:23 +07:00
|
|
|
g4x_enable_hdmi(encoder);
|
2014-04-09 17:28:20 +07:00
|
|
|
|
2015-04-10 22:21:31 +07:00
|
|
|
vlv_wait_port_ready(dev_priv, dport, 0x0);
|
drm/i915: Trick CL2 into life on CHV when using pipe B with port B
Normmally the common lane in a PHY channel gets powered up when some
of the data lanes get powered up. But when we're driving port B with
pipe B we don't want to enabled any of the data lanes, and just want
the DPLL in the common lane to be active.
To make that happens we have to temporarily enable some data lanes
after which we can access the DPLL registers in the common lane. Once
the pipe is up and running we can drop the power override on the data
lanes allowing them to shut down. From this point forward the common
lane will in fact stay powered on until the data lanes in the other
channel get powered down.
Ville's extended explanation from the review thread:
On Wed, Aug 19, 2015 at 07:47:41AM +0530, Deepak wrote:
> One Q, why only for port B? Port C is also in same common lane right?
Port B is in the first PHY channel which also houses CL1. CL1 always
powers up whenever any lanes in either PHY channel are powered up.
CL2 only powers up if lanes in the second channel (ie. the one with
port C) powers up.
So in this scenario (pipe B->port B) we want the DPLL from CL2, but
ideally we only want to power up the lanes for port B. Powering up
port B lanes will only power up CL1, but as we need CL2 instead we
need to, temporarily, power up some lanes in port C as well.
Crossing the streams the other way (pipe A->port C) is not a problem
since CL1 powers up whenever anything else powers up. So powering up
some port C lanes is enough on its own to make the CL1 DPLL
operational, even though CL1 and the lanes live in separate channels.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Deepak S <deepak.s@linux.intel.com>
[danvet: Amend commit message with extended explanation.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-09 03:45:55 +07:00
|
|
|
|
|
|
|
/* Second common lane will stay alive on its own now */
|
2016-04-27 19:44:20 +07:00
|
|
|
chv_phy_release_cl2_override(encoder);
|
2014-04-09 17:28:20 +07:00
|
|
|
}
|
|
|
|
|
2009-01-03 04:33:00 +07:00
|
|
|
static void intel_hdmi_destroy(struct drm_connector *connector)
|
|
|
|
{
|
2014-09-05 03:43:45 +07:00
|
|
|
kfree(to_intel_connector(connector)->detect_edid);
|
2009-01-03 04:33:00 +07:00
|
|
|
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 = {
|
2015-08-05 17:37:06 +07:00
|
|
|
.dpms = drm_atomic_helper_connector_dpms,
|
2009-01-03 04:33:00 +07:00
|
|
|
.detect = intel_hdmi_detect,
|
2014-09-03 02:04:01 +07:00
|
|
|
.force = intel_hdmi_force,
|
2009-01-03 04:33:00 +07:00
|
|
|
.fill_modes = drm_helper_probe_single_connector_modes,
|
2010-09-19 15:29:33 +07:00
|
|
|
.set_property = intel_hdmi_set_property,
|
2015-01-23 07:51:27 +07:00
|
|
|
.atomic_get_property = intel_connector_atomic_get_property,
|
2016-06-24 20:00:15 +07:00
|
|
|
.late_register = intel_connector_register,
|
2016-06-17 17:40:33 +07:00
|
|
|
.early_unregister = intel_connector_unregister,
|
2009-01-03 04:33:00 +07:00
|
|
|
.destroy = intel_hdmi_destroy,
|
2015-01-23 07:50:32 +07:00
|
|
|
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
|
2015-03-20 21:18:06 +07:00
|
|
|
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
|
2009-01-03 04:33:00 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct drm_connector_helper_funcs intel_hdmi_connector_helper_funcs = {
|
|
|
|
.get_modes = intel_hdmi_get_modes,
|
|
|
|
.mode_valid = intel_hdmi_mode_valid,
|
|
|
|
};
|
|
|
|
|
|
|
|
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;
|
2014-06-11 12:36:01 +07:00
|
|
|
intel_attach_aspect_ratio_property(connector);
|
|
|
|
intel_hdmi->aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
|
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;
|
2015-08-17 15:04:04 +07:00
|
|
|
uint8_t alternate_ddc_pin;
|
2010-09-15 18:03:59 +07:00
|
|
|
|
2016-06-03 16:17:43 +07:00
|
|
|
DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
|
|
|
|
port_name(port));
|
|
|
|
|
2015-12-09 00:59:38 +07:00
|
|
|
if (WARN(intel_dig_port->max_lanes < 4,
|
|
|
|
"Not enough lanes (%d) for HDMI on port %c\n",
|
|
|
|
intel_dig_port->max_lanes, port_name(port)))
|
|
|
|
return;
|
|
|
|
|
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:
|
2015-04-01 14:58:05 +07:00
|
|
|
if (IS_BROXTON(dev_priv))
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_1_BXT;
|
|
|
|
else
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_DPB;
|
2015-08-10 12:05:36 +07:00
|
|
|
/*
|
|
|
|
* On BXT A0/A1, sw needs to activate DDIA HPD logic and
|
|
|
|
* interrupts to check the external panel connection.
|
|
|
|
*/
|
2015-10-20 19:22:02 +07:00
|
|
|
if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_A1))
|
2015-08-10 12:05:36 +07:00
|
|
|
intel_encoder->hpd_pin = HPD_PORT_A;
|
|
|
|
else
|
|
|
|
intel_encoder->hpd_pin = HPD_PORT_B;
|
2012-07-13 01:19:59 +07:00
|
|
|
break;
|
|
|
|
case PORT_C:
|
2015-04-01 14:58:05 +07:00
|
|
|
if (IS_BROXTON(dev_priv))
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_2_BXT;
|
|
|
|
else
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_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:
|
2015-04-01 14:58:05 +07:00
|
|
|
if (WARN_ON(IS_BROXTON(dev_priv)))
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_DISABLED;
|
|
|
|
else if (IS_CHERRYVIEW(dev_priv))
|
2015-03-27 05:20:19 +07:00
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_DPD_CHV;
|
2014-04-09 17:28:52 +07:00
|
|
|
else
|
2015-03-27 05:20:19 +07:00
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_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;
|
2015-08-17 15:04:04 +07:00
|
|
|
case PORT_E:
|
|
|
|
/* On SKL PORT E doesn't have seperate GMBUS pin
|
|
|
|
* We rely on VBT to set a proper alternate GMBUS pin. */
|
|
|
|
alternate_ddc_pin =
|
|
|
|
dev_priv->vbt.ddi_port_info[PORT_E].alternate_ddc_pin;
|
|
|
|
switch (alternate_ddc_pin) {
|
|
|
|
case DDC_PIN_B:
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_DPB;
|
|
|
|
break;
|
|
|
|
case DDC_PIN_C:
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_DPC;
|
|
|
|
break;
|
|
|
|
case DDC_PIN_D:
|
|
|
|
intel_hdmi->ddc_bus = GMBUS_PIN_DPD;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
MISSING_CASE(alternate_ddc_pin);
|
|
|
|
}
|
|
|
|
intel_encoder->hpd_pin = HPD_PORT_E;
|
|
|
|
break;
|
2012-07-13 01:19:59 +07:00
|
|
|
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
|
|
|
|
2015-12-10 03:29:35 +07:00
|
|
|
if (IS_VALLEYVIEW(dev) || IS_CHERRYVIEW(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;
|
2014-11-06 05:26:08 +07:00
|
|
|
intel_hdmi->infoframe_enabled = vlv_infoframe_enabled;
|
2014-07-22 12:43:46 +07:00
|
|
|
} else if (IS_G4X(dev)) {
|
2013-03-09 01:46:01 +07:00
|
|
|
intel_hdmi->write_infoframe = g4x_write_infoframe;
|
|
|
|
intel_hdmi->set_infoframes = g4x_set_infoframes;
|
2014-11-06 05:26:08 +07:00
|
|
|
intel_hdmi->infoframe_enabled = g4x_infoframe_enabled;
|
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;
|
2014-11-06 05:26:08 +07:00
|
|
|
intel_hdmi->infoframe_enabled = hsw_infoframe_enabled;
|
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;
|
2014-11-06 05:26:08 +07:00
|
|
|
intel_hdmi->infoframe_enabled = ibx_infoframe_enabled;
|
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;
|
2014-11-06 05:26:08 +07:00
|
|
|
intel_hdmi->infoframe_enabled = cpt_infoframe_enabled;
|
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;
|
2012-10-27 04:05:47 +07:00
|
|
|
|
|
|
|
intel_hdmi_add_properties(intel_hdmi, connector);
|
|
|
|
|
|
|
|
intel_connector_attach_encoder(intel_connector, intel_encoder);
|
2015-09-04 20:26:11 +07:00
|
|
|
intel_hdmi->attached_connector = intel_connector;
|
2012-10-27 04:05:47 +07:00
|
|
|
|
|
|
|
/* 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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
void intel_hdmi_init(struct drm_device *dev,
|
|
|
|
i915_reg_t 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;
|
|
|
|
|
2015-04-10 14:59:10 +07:00
|
|
|
intel_connector = intel_connector_alloc();
|
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,
|
2016-05-28 00:59:24 +07:00
|
|
|
DRM_MODE_ENCODER_TMDS, "HDMI %c", port_name(port));
|
2012-10-27 04:05:52 +07:00
|
|
|
|
2013-03-27 06:44:55 +07:00
|
|
|
intel_encoder->compute_config = intel_hdmi_compute_config;
|
2015-05-05 21:17:35 +07:00
|
|
|
if (HAS_PCH_SPLIT(dev)) {
|
|
|
|
intel_encoder->disable = pch_disable_hdmi;
|
|
|
|
intel_encoder->post_disable = pch_post_disable_hdmi;
|
|
|
|
} else {
|
|
|
|
intel_encoder->disable = g4x_disable_hdmi;
|
|
|
|
}
|
2012-10-27 04:05:52 +07:00
|
|
|
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;
|
2015-07-09 03:45:49 +07:00
|
|
|
intel_encoder->post_pll_disable = chv_hdmi_post_pll_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;
|
2015-05-05 21:06:19 +07:00
|
|
|
if (HAS_PCH_CPT(dev))
|
|
|
|
intel_encoder->enable = cpt_enable_hdmi;
|
2015-05-05 21:06:23 +07:00
|
|
|
else if (HAS_PCH_IBX(dev))
|
|
|
|
intel_encoder->enable = ibx_enable_hdmi;
|
2015-05-05 21:06:19 +07:00
|
|
|
else
|
2015-05-05 21:06:23 +07:00
|
|
|
intel_encoder->enable = g4x_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;
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 20:33:26 +07:00
|
|
|
intel_dig_port->dp.output_reg = INVALID_MMIO_REG;
|
2015-12-09 00:59:38 +07:00
|
|
|
intel_dig_port->max_lanes = 4;
|
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
|
|
|
}
|