2009-01-03 05:33:00 +08: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 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2009-01-03 05:33:00 +08:00
|
|
|
#include <linux/delay.h>
|
2013-08-07 03:32:18 +08:00
|
|
|
#include <linux/hdmi.h>
|
2012-10-03 01:01:07 +08:00
|
|
|
#include <drm/drmP.h>
|
2015-01-23 08:50:32 +08:00
|
|
|
#include <drm/drm_atomic_helper.h>
|
2012-10-03 01:01:07 +08:00
|
|
|
#include <drm/drm_crtc.h>
|
|
|
|
#include <drm/drm_edid.h>
|
drm/i915: enable scrambling
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
in intel_enable_ddi() before enabling the port.
V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
so that the implementation could be close to the language of
HDMI spec.
V4: Addressed review comment from Maarten
- scrambling -> hdmi_scrambling
- high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
V5: Addressed review comments from Ville and Ander
- Do not modifiy the crtc_state after compute_config. Move all
scrambling and tmds_clock_ratio calcutations to compute_config.
- While setting scrambling for source/sink, do not check the
conditions again, just go by the crtc_state flags. This will
simplyfy the condition checks.
V6: Addressed review comments from Ville
- Do not add IS_GLK check in disable/enable function, instead add it
in compute_config, while setting state flags.
- Remove unnecessary paranthesis.
- Simplyfy handle_sink_scrambling function as suggested.
- Add readout code for scrambling status in get_ddi_config and add a
check for the same in pipe_config_compare.
V7: Addressed review comments from Ander/Ville
- No separate function for source scrambling, make it inline
- Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
- Do not add platform check while setting source scrambling
- Use pipe_config instead of crtc->config to set sink scrambling
- To readout scrambling status, Compare with SCRAMBLING_MASK
not any of its bits
- Remove platform check in intel_pipe_config_compare while checking
scrambling status
V8: Fixed mege conflict, Addressed review comments from Ander
- Remove the desciption/comment about scrambling fom the caller, move
it to the function
- Move the IS_GLK check into scrambling function
- Fix alignment
V9: Fixed review comments from Ville, Ander
- Pass the scrambling state variables as bool input to the sink_scrambling
function and let the disable call be unconditional.
- Fix alignments in function calls and debug messages.
- Add kernel doc for function intel_hdmi_handle_sink_scrambling
V10: Rebase
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-6-git-send-email-shashank.sharma@intel.com
2017-03-13 19:24:03 +08:00
|
|
|
#include <drm/drm_scdc_helper.h>
|
2009-01-03 05:33:00 +08:00
|
|
|
#include "intel_drv.h"
|
2012-10-03 01:01:07 +08:00
|
|
|
#include <drm/i915_drm.h>
|
2017-01-25 06:57:50 +08:00
|
|
|
#include <drm/intel_lpe_audio.h>
|
2009-01-03 05:33:00 +08:00
|
|
|
#include "i915_drv.h"
|
|
|
|
|
2012-10-27 05:05:45 +08:00
|
|
|
static struct drm_device *intel_hdmi_to_dev(struct intel_hdmi *intel_hdmi)
|
|
|
|
{
|
2012-10-27 05:05:46 +08:00
|
|
|
return hdmi_to_dig_port(intel_hdmi)->base.base.dev;
|
2012-10-27 05:05:45 +08:00
|
|
|
}
|
|
|
|
|
2012-06-12 22:36:45 +08:00
|
|
|
static void
|
|
|
|
assert_hdmi_port_disabled(struct intel_hdmi *intel_hdmi)
|
|
|
|
{
|
2012-10-27 05:05:45 +08:00
|
|
|
struct drm_device *dev = intel_hdmi_to_dev(intel_hdmi);
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2012-06-12 22:36:45 +08:00
|
|
|
uint32_t enabled_bits;
|
|
|
|
|
2016-10-13 18:02:52 +08:00
|
|
|
enabled_bits = HAS_DDI(dev_priv) ? DDI_BUF_CTL_ENABLE : SDVO_ENABLE;
|
2012-06-12 22:36:45 +08:00
|
|
|
|
2013-02-19 06:00:26 +08:00
|
|
|
WARN(I915_READ(intel_hdmi->hdmi_reg) & enabled_bits,
|
2012-06-12 22:36:45 +08:00
|
|
|
"HDMI port enabled, expecting disabled\n");
|
|
|
|
}
|
|
|
|
|
2012-05-10 02:37:30 +08:00
|
|
|
struct intel_hdmi *enc_to_intel_hdmi(struct drm_encoder *encoder)
|
2010-08-04 20:50:23 +08:00
|
|
|
{
|
2012-10-27 05:05:46 +08: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 20:50:23 +08:00
|
|
|
}
|
|
|
|
|
2010-09-09 23:20:55 +08:00
|
|
|
static struct intel_hdmi *intel_attached_hdmi(struct drm_connector *connector)
|
|
|
|
{
|
2012-10-27 05:05:46 +08:00
|
|
|
return enc_to_intel_hdmi(&intel_attached_encoder(connector)->base);
|
2010-09-09 23:20:55 +08:00
|
|
|
}
|
|
|
|
|
2017-10-14 03:40:51 +08:00
|
|
|
static u32 g4x_infoframe_index(unsigned int type)
|
2010-09-25 03:44:32 +08:00
|
|
|
{
|
2013-08-07 03:32:18 +08:00
|
|
|
switch (type) {
|
|
|
|
case HDMI_INFOFRAME_TYPE_AVI:
|
2012-05-15 04:12:50 +08:00
|
|
|
return VIDEO_DIP_SELECT_AVI;
|
2013-08-07 03:32:18 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_SPD:
|
2012-05-15 04:12:50 +08:00
|
|
|
return VIDEO_DIP_SELECT_SPD;
|
2013-08-19 23:59:04 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_VENDOR:
|
|
|
|
return VIDEO_DIP_SELECT_VENDOR;
|
2011-08-04 00:22:55 +08:00
|
|
|
default:
|
2015-12-17 00:10:00 +08:00
|
|
|
MISSING_CASE(type);
|
2012-05-15 04:12:50 +08:00
|
|
|
return 0;
|
2011-08-04 00:22:55 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-14 03:40:51 +08:00
|
|
|
static u32 g4x_infoframe_enable(unsigned int type)
|
2011-08-04 00:22:55 +08:00
|
|
|
{
|
2013-08-07 03:32:18 +08:00
|
|
|
switch (type) {
|
|
|
|
case HDMI_INFOFRAME_TYPE_AVI:
|
2012-05-15 04:12:50 +08:00
|
|
|
return VIDEO_DIP_ENABLE_AVI;
|
2013-08-07 03:32:18 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_SPD:
|
2012-05-15 04:12:50 +08:00
|
|
|
return VIDEO_DIP_ENABLE_SPD;
|
2013-08-19 23:59:04 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_VENDOR:
|
|
|
|
return VIDEO_DIP_ENABLE_VENDOR;
|
2012-05-05 04:18:20 +08:00
|
|
|
default:
|
2015-12-17 00:10:00 +08:00
|
|
|
MISSING_CASE(type);
|
2012-05-15 04:12:50 +08:00
|
|
|
return 0;
|
2012-05-05 04:18:20 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-10-14 03:40:51 +08:00
|
|
|
static u32 hsw_infoframe_enable(unsigned int type)
|
2012-05-15 04:12:51 +08:00
|
|
|
{
|
2013-08-07 03:32:18 +08:00
|
|
|
switch (type) {
|
2017-10-14 03:40:51 +08:00
|
|
|
case DP_SDP_VSC:
|
|
|
|
return VIDEO_DIP_ENABLE_VSC_HSW;
|
2013-08-07 03:32:18 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_AVI:
|
2012-05-15 04:12:51 +08:00
|
|
|
return VIDEO_DIP_ENABLE_AVI_HSW;
|
2013-08-07 03:32:18 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_SPD:
|
2012-05-15 04:12:51 +08:00
|
|
|
return VIDEO_DIP_ENABLE_SPD_HSW;
|
2013-08-19 23:59:04 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_VENDOR:
|
|
|
|
return VIDEO_DIP_ENABLE_VS_HSW;
|
2012-05-15 04:12:51 +08:00
|
|
|
default:
|
2015-12-17 00:10:00 +08:00
|
|
|
MISSING_CASE(type);
|
2012-05-15 04:12:51 +08: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 21:33:26 +08:00
|
|
|
static i915_reg_t
|
|
|
|
hsw_dip_data_reg(struct drm_i915_private *dev_priv,
|
|
|
|
enum transcoder cpu_transcoder,
|
2017-10-14 03:40:51 +08:00
|
|
|
unsigned int 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 21:33:26 +08:00
|
|
|
int i)
|
2012-05-15 04:12:51 +08:00
|
|
|
{
|
2013-08-07 03:32:18 +08:00
|
|
|
switch (type) {
|
2017-10-14 03:40:51 +08:00
|
|
|
case DP_SDP_VSC:
|
|
|
|
return HSW_TVIDEO_DIP_VSC_DATA(cpu_transcoder, i);
|
2013-08-07 03:32:18 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_AVI:
|
2015-09-19 01:03:37 +08:00
|
|
|
return HSW_TVIDEO_DIP_AVI_DATA(cpu_transcoder, i);
|
2013-08-07 03:32:18 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_SPD:
|
2015-09-19 01:03:37 +08:00
|
|
|
return HSW_TVIDEO_DIP_SPD_DATA(cpu_transcoder, i);
|
2013-08-19 23:59:04 +08:00
|
|
|
case HDMI_INFOFRAME_TYPE_VENDOR:
|
2015-09-19 01:03:37 +08:00
|
|
|
return HSW_TVIDEO_DIP_VS_DATA(cpu_transcoder, i);
|
2012-05-15 04:12:51 +08:00
|
|
|
default:
|
2015-12-17 00:10:00 +08: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 21:33:26 +08:00
|
|
|
return INVALID_MMIO_REG;
|
2012-05-15 04:12:51 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-05-08 21:19:06 +08:00
|
|
|
static void g4x_write_infoframe(struct drm_encoder *encoder,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
2017-10-14 03:40:51 +08:00
|
|
|
unsigned int type,
|
2013-12-10 21:19:08 +08:00
|
|
|
const void *frame, ssize_t len)
|
2011-08-04 00:22:55 +08:00
|
|
|
{
|
2013-12-10 21:19:08 +08:00
|
|
|
const uint32_t *data = frame;
|
2010-09-25 03:44:32 +08:00
|
|
|
struct drm_device *dev = encoder->dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2012-05-05 04:18:17 +08:00
|
|
|
u32 val = I915_READ(VIDEO_DIP_CTL);
|
2013-08-07 03:32:18 +08:00
|
|
|
int i;
|
2010-09-25 03:44:32 +08:00
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
|
|
|
|
|
2012-05-05 04:18:18 +08:00
|
|
|
val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
|
2013-08-07 03:32:18 +08:00
|
|
|
val |= g4x_infoframe_index(type);
|
2012-05-05 04:18:17 +08:00
|
|
|
|
2013-08-07 03:32:18 +08:00
|
|
|
val &= ~g4x_infoframe_enable(type);
|
2011-08-04 00:22:55 +08:00
|
|
|
|
2012-05-05 04:18:17 +08:00
|
|
|
I915_WRITE(VIDEO_DIP_CTL, val);
|
2010-09-25 03:44:32 +08:00
|
|
|
|
2012-05-29 03:43:00 +08:00
|
|
|
mmiowb();
|
2011-08-04 00:22:55 +08:00
|
|
|
for (i = 0; i < len; i += 4) {
|
2010-09-25 03:44:32 +08:00
|
|
|
I915_WRITE(VIDEO_DIP_DATA, *data);
|
|
|
|
data++;
|
|
|
|
}
|
2012-09-26 00:23:34 +08: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 03:43:00 +08:00
|
|
|
mmiowb();
|
2010-09-25 03:44:32 +08:00
|
|
|
|
2013-08-07 03:32:18 +08:00
|
|
|
val |= g4x_infoframe_enable(type);
|
2012-05-05 04:18:22 +08:00
|
|
|
val &= ~VIDEO_DIP_FREQ_MASK;
|
2012-05-08 20:41:00 +08:00
|
|
|
val |= VIDEO_DIP_FREQ_VSYNC;
|
2011-08-04 00:22:55 +08:00
|
|
|
|
2012-05-05 04:18:17 +08:00
|
|
|
I915_WRITE(VIDEO_DIP_CTL, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(VIDEO_DIP_CTL);
|
2010-09-25 03:44:32 +08:00
|
|
|
}
|
|
|
|
|
2015-11-27 00:27:07 +08:00
|
|
|
static bool g4x_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 06:26:08 +08:00
|
|
|
{
|
2015-11-27 00:27:07 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2014-11-21 05:24:13 +08:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
2014-11-06 06:26:08 +08:00
|
|
|
u32 val = I915_READ(VIDEO_DIP_CTL);
|
|
|
|
|
2015-05-05 22:06:25 +08:00
|
|
|
if ((val & VIDEO_DIP_ENABLE) == 0)
|
|
|
|
return false;
|
2014-11-21 05:24:13 +08:00
|
|
|
|
2015-05-05 22:06:25 +08: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 06:26:08 +08:00
|
|
|
}
|
|
|
|
|
2012-05-05 04:18:24 +08:00
|
|
|
static void ibx_write_infoframe(struct drm_encoder *encoder,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
2017-10-14 03:40:51 +08:00
|
|
|
unsigned int type,
|
2013-12-10 21:19:08 +08:00
|
|
|
const void *frame, ssize_t len)
|
2012-05-05 04:18:24 +08:00
|
|
|
{
|
2013-12-10 21:19:08 +08:00
|
|
|
const uint32_t *data = frame;
|
2012-05-05 04:18:24 +08:00
|
|
|
struct drm_device *dev = encoder->dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.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 21:33:26 +08:00
|
|
|
i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
2012-05-05 04:18:24 +08: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 21:33:26 +08:00
|
|
|
int i;
|
2012-05-05 04:18:24 +08:00
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
|
|
|
|
|
2012-05-05 04:18:24 +08:00
|
|
|
val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
|
2013-08-07 03:32:18 +08:00
|
|
|
val |= g4x_infoframe_index(type);
|
2012-05-05 04:18:24 +08:00
|
|
|
|
2013-08-07 03:32:18 +08:00
|
|
|
val &= ~g4x_infoframe_enable(type);
|
2012-05-05 04:18:24 +08:00
|
|
|
|
|
|
|
I915_WRITE(reg, val);
|
|
|
|
|
2012-05-29 03:43:00 +08:00
|
|
|
mmiowb();
|
2012-05-05 04:18:24 +08:00
|
|
|
for (i = 0; i < len; i += 4) {
|
|
|
|
I915_WRITE(TVIDEO_DIP_DATA(intel_crtc->pipe), *data);
|
|
|
|
data++;
|
|
|
|
}
|
2012-09-26 00:23:34 +08: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 03:43:00 +08:00
|
|
|
mmiowb();
|
2012-05-05 04:18:24 +08:00
|
|
|
|
2013-08-07 03:32:18 +08:00
|
|
|
val |= g4x_infoframe_enable(type);
|
2012-05-05 04:18:24 +08:00
|
|
|
val &= ~VIDEO_DIP_FREQ_MASK;
|
2012-05-08 20:41:00 +08:00
|
|
|
val |= VIDEO_DIP_FREQ_VSYNC;
|
2012-05-05 04:18:24 +08:00
|
|
|
|
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(reg);
|
2012-05-05 04:18:24 +08:00
|
|
|
}
|
|
|
|
|
2015-11-27 00:27:07 +08:00
|
|
|
static bool ibx_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 06:26:08 +08:00
|
|
|
{
|
2015-11-27 00:27:07 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2015-04-29 20:30:07 +08:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
2015-11-27 00:27:07 +08:00
|
|
|
enum pipe pipe = to_intel_crtc(pipe_config->base.crtc)->pipe;
|
|
|
|
i915_reg_t reg = TVIDEO_DIP_CTL(pipe);
|
2014-11-06 06:26:08 +08:00
|
|
|
u32 val = I915_READ(reg);
|
|
|
|
|
2015-05-05 22:06:25 +08: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 20:30:07 +08:00
|
|
|
|
2015-05-05 22:06:25 +08: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 06:26:08 +08:00
|
|
|
}
|
|
|
|
|
2012-05-05 04:18:24 +08:00
|
|
|
static void cpt_write_infoframe(struct drm_encoder *encoder,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
2017-10-14 03:40:51 +08:00
|
|
|
unsigned int type,
|
2013-12-10 21:19:08 +08:00
|
|
|
const void *frame, ssize_t len)
|
2011-07-09 02:31:57 +08:00
|
|
|
{
|
2013-12-10 21:19:08 +08:00
|
|
|
const uint32_t *data = frame;
|
2011-07-09 02:31:57 +08:00
|
|
|
struct drm_device *dev = encoder->dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.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 21:33:26 +08:00
|
|
|
i915_reg_t reg = TVIDEO_DIP_CTL(intel_crtc->pipe);
|
2012-05-05 04:18:17 +08: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 21:33:26 +08:00
|
|
|
int i;
|
2011-07-09 02:31:57 +08:00
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
|
|
|
|
|
2011-09-22 13:46:00 +08:00
|
|
|
val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
|
2013-08-07 03:32:18 +08:00
|
|
|
val |= g4x_infoframe_index(type);
|
2011-08-04 00:22:55 +08:00
|
|
|
|
2012-05-05 04:18:21 +08:00
|
|
|
/* The DIP control register spec says that we need to update the AVI
|
|
|
|
* infoframe without clearing its enable bit */
|
2013-08-07 03:32:18 +08:00
|
|
|
if (type != HDMI_INFOFRAME_TYPE_AVI)
|
|
|
|
val &= ~g4x_infoframe_enable(type);
|
2012-05-05 04:18:21 +08:00
|
|
|
|
2012-05-05 04:18:17 +08:00
|
|
|
I915_WRITE(reg, val);
|
2011-08-04 00:22:55 +08:00
|
|
|
|
2012-05-29 03:43:00 +08:00
|
|
|
mmiowb();
|
2011-08-04 00:22:55 +08:00
|
|
|
for (i = 0; i < len; i += 4) {
|
2011-07-09 02:31:57 +08:00
|
|
|
I915_WRITE(TVIDEO_DIP_DATA(intel_crtc->pipe), *data);
|
|
|
|
data++;
|
|
|
|
}
|
2012-09-26 00:23:34 +08: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 03:43:00 +08:00
|
|
|
mmiowb();
|
2011-07-09 02:31:57 +08:00
|
|
|
|
2013-08-07 03:32:18 +08:00
|
|
|
val |= g4x_infoframe_enable(type);
|
2012-05-05 04:18:22 +08:00
|
|
|
val &= ~VIDEO_DIP_FREQ_MASK;
|
2012-05-08 20:41:00 +08:00
|
|
|
val |= VIDEO_DIP_FREQ_VSYNC;
|
2011-08-04 00:22:55 +08:00
|
|
|
|
2012-05-05 04:18:17 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(reg);
|
2011-08-04 00:22:55 +08:00
|
|
|
}
|
2012-03-29 04:39:32 +08:00
|
|
|
|
2015-11-27 00:27:07 +08:00
|
|
|
static bool cpt_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 06:26:08 +08:00
|
|
|
{
|
2015-11-27 00:27:07 +08: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 06:26:08 +08:00
|
|
|
|
2015-05-05 22:06:25 +08: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 06:26:08 +08:00
|
|
|
}
|
|
|
|
|
2012-03-29 04:39:32 +08:00
|
|
|
static void vlv_write_infoframe(struct drm_encoder *encoder,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
2017-10-14 03:40:51 +08:00
|
|
|
unsigned int type,
|
2013-12-10 21:19:08 +08:00
|
|
|
const void *frame, ssize_t len)
|
2012-03-29 04:39:32 +08:00
|
|
|
{
|
2013-12-10 21:19:08 +08:00
|
|
|
const uint32_t *data = frame;
|
2012-03-29 04:39:32 +08:00
|
|
|
struct drm_device *dev = encoder->dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.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 21:33:26 +08:00
|
|
|
i915_reg_t reg = VLV_TVIDEO_DIP_CTL(intel_crtc->pipe);
|
2012-05-05 04:18:17 +08: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 21:33:26 +08:00
|
|
|
int i;
|
2012-03-29 04:39:32 +08:00
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
WARN(!(val & VIDEO_DIP_ENABLE), "Writing DIP with CTL reg disabled\n");
|
|
|
|
|
2012-03-29 04:39:32 +08:00
|
|
|
val &= ~(VIDEO_DIP_SELECT_MASK | 0xf); /* clear DIP data offset */
|
2013-08-07 03:32:18 +08:00
|
|
|
val |= g4x_infoframe_index(type);
|
2012-05-05 04:18:17 +08:00
|
|
|
|
2013-08-07 03:32:18 +08:00
|
|
|
val &= ~g4x_infoframe_enable(type);
|
2012-03-29 04:39:32 +08:00
|
|
|
|
2012-05-05 04:18:17 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-03-29 04:39:32 +08:00
|
|
|
|
2012-05-29 03:43:00 +08:00
|
|
|
mmiowb();
|
2012-03-29 04:39:32 +08:00
|
|
|
for (i = 0; i < len; i += 4) {
|
|
|
|
I915_WRITE(VLV_TVIDEO_DIP_DATA(intel_crtc->pipe), *data);
|
|
|
|
data++;
|
|
|
|
}
|
2012-09-26 00:23:34 +08: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 03:43:00 +08:00
|
|
|
mmiowb();
|
2012-03-29 04:39:32 +08:00
|
|
|
|
2013-08-07 03:32:18 +08:00
|
|
|
val |= g4x_infoframe_enable(type);
|
2012-05-05 04:18:22 +08:00
|
|
|
val &= ~VIDEO_DIP_FREQ_MASK;
|
2012-05-08 20:41:00 +08:00
|
|
|
val |= VIDEO_DIP_FREQ_VSYNC;
|
2012-03-29 04:39:32 +08:00
|
|
|
|
2012-05-05 04:18:17 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(reg);
|
2012-03-29 04:39:32 +08:00
|
|
|
}
|
|
|
|
|
2015-11-27 00:27:07 +08:00
|
|
|
static bool vlv_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 06:26:08 +08:00
|
|
|
{
|
2015-11-27 00:27:07 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2015-04-16 07:52:29 +08:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
2015-11-27 00:27:07 +08:00
|
|
|
enum pipe pipe = to_intel_crtc(pipe_config->base.crtc)->pipe;
|
|
|
|
u32 val = I915_READ(VLV_TVIDEO_DIP_CTL(pipe));
|
2014-11-06 06:26:08 +08:00
|
|
|
|
2015-05-05 22:06:25 +08: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 07:52:29 +08:00
|
|
|
|
2015-05-05 22:06:25 +08: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 06:26:08 +08:00
|
|
|
}
|
|
|
|
|
2012-05-10 21:18:02 +08:00
|
|
|
static void hsw_write_infoframe(struct drm_encoder *encoder,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
2017-10-14 03:40:51 +08:00
|
|
|
unsigned int type,
|
2013-12-10 21:19:08 +08:00
|
|
|
const void *frame, ssize_t len)
|
2012-05-10 21:18:02 +08:00
|
|
|
{
|
2013-12-10 21:19:08 +08:00
|
|
|
const uint32_t *data = frame;
|
2012-05-15 04:12:51 +08:00
|
|
|
struct drm_device *dev = encoder->dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-11-23 22:57:00 +08:00
|
|
|
enum transcoder cpu_transcoder = crtc_state->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 21:33:26 +08:00
|
|
|
i915_reg_t ctl_reg = HSW_TVIDEO_DIP_CTL(cpu_transcoder);
|
|
|
|
i915_reg_t data_reg;
|
2017-10-14 03:40:51 +08:00
|
|
|
int data_size = type == DP_SDP_VSC ?
|
|
|
|
VIDEO_DIP_VSC_DATA_SIZE : VIDEO_DIP_DATA_SIZE;
|
2013-08-07 03:32:18 +08:00
|
|
|
int i;
|
2012-05-15 04:12:51 +08:00
|
|
|
u32 val = I915_READ(ctl_reg);
|
2012-05-10 21:18:02 +08:00
|
|
|
|
2015-09-19 01:03:37 +08:00
|
|
|
data_reg = hsw_dip_data_reg(dev_priv, cpu_transcoder, type, 0);
|
2012-05-15 04:12:51 +08:00
|
|
|
|
2013-08-07 03:32:18 +08:00
|
|
|
val &= ~hsw_infoframe_enable(type);
|
2012-05-15 04:12:51 +08:00
|
|
|
I915_WRITE(ctl_reg, val);
|
|
|
|
|
2012-05-29 03:43:00 +08:00
|
|
|
mmiowb();
|
2012-05-15 04:12:51 +08:00
|
|
|
for (i = 0; i < len; i += 4) {
|
2015-09-19 01:03:37 +08:00
|
|
|
I915_WRITE(hsw_dip_data_reg(dev_priv, cpu_transcoder,
|
|
|
|
type, i >> 2), *data);
|
2012-05-15 04:12:51 +08:00
|
|
|
data++;
|
|
|
|
}
|
2012-09-26 00:23:34 +08:00
|
|
|
/* Write every possible data byte to force correct ECC calculation. */
|
2017-10-14 03:40:51 +08:00
|
|
|
for (; i < data_size; i += 4)
|
2015-09-19 01:03:37 +08:00
|
|
|
I915_WRITE(hsw_dip_data_reg(dev_priv, cpu_transcoder,
|
|
|
|
type, i >> 2), 0);
|
2012-05-29 03:43:00 +08:00
|
|
|
mmiowb();
|
2012-05-10 21:18:02 +08:00
|
|
|
|
2013-08-07 03:32:18 +08:00
|
|
|
val |= hsw_infoframe_enable(type);
|
2012-05-15 04:12:51 +08:00
|
|
|
I915_WRITE(ctl_reg, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(ctl_reg);
|
2012-05-10 21:18:02 +08:00
|
|
|
}
|
|
|
|
|
2015-11-27 00:27:07 +08:00
|
|
|
static bool hsw_infoframe_enabled(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *pipe_config)
|
2014-11-06 06:26:08 +08:00
|
|
|
{
|
2015-11-27 00:27:07 +08: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 06:26:08 +08:00
|
|
|
|
2015-05-05 22:06:25 +08: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 06:26:08 +08:00
|
|
|
}
|
|
|
|
|
2013-08-07 03:32:19 +08: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 03:32:24 +08:00
|
|
|
static void intel_write_infoframe(struct drm_encoder *encoder,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
2013-08-07 03:32:24 +08:00
|
|
|
union hdmi_infoframe *frame)
|
2011-08-04 00:22:55 +08:00
|
|
|
{
|
2017-08-18 21:49:54 +08:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
2013-08-07 03:32:19 +08:00
|
|
|
uint8_t buffer[VIDEO_DIP_DATA_SIZE];
|
|
|
|
ssize_t len;
|
2011-08-04 00:22:55 +08:00
|
|
|
|
2013-08-07 03:32:19 +08: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-04 00:22:55 +08:00
|
|
|
|
2017-08-18 21:49:54 +08:00
|
|
|
intel_dig_port->write_infoframe(encoder, crtc_state, frame->any.type, buffer, len);
|
2011-08-04 00:22:55 +08:00
|
|
|
}
|
|
|
|
|
2012-05-29 03:42:48 +08:00
|
|
|
static void intel_hdmi_set_avi_infoframe(struct drm_encoder *encoder,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state)
|
2011-08-04 00:22:55 +08:00
|
|
|
{
|
2013-01-17 22:31:31 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
|
2017-01-11 20:57:24 +08:00
|
|
|
const struct drm_display_mode *adjusted_mode =
|
|
|
|
&crtc_state->base.adjusted_mode;
|
drm: handle HDMI 2.0 VICs in AVI info-frames
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
- VIC for 4K modes for HDMI 1.4 sinks
- S3D information for S3D modes
As CEA-861-F has already defined VICs for 4K videomodes, this
patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
until the mode is 3D.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
- Do not send VICs in both AVI-IF and HDMI-IF
send only one of it.
V4: Rebase
V5: Added r-b from Neil.
Addressed review comments from Ville
- Do not block HDMI vendor IF, instead check for VIC while
handling AVI infoframes
V6: Rebase
V7: Rebase
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-13 23:33:07 +08:00
|
|
|
struct drm_connector *connector = &intel_hdmi->attached_connector->base;
|
|
|
|
bool is_hdmi2_sink = connector->display_info.hdmi.scdc.supported;
|
2013-08-07 03:32:19 +08:00
|
|
|
union hdmi_infoframe frame;
|
|
|
|
int ret;
|
2011-08-04 00:22:55 +08:00
|
|
|
|
2013-08-07 03:32:19 +08:00
|
|
|
ret = drm_hdmi_avi_infoframe_from_display_mode(&frame.avi,
|
drm: handle HDMI 2.0 VICs in AVI info-frames
HDMI 1.4b support the CEA video modes as per range of CEA-861-D (VIC 1-64).
For any other mode, the VIC filed in AVI infoframes should be 0.
HDMI 2.0 sinks, support video modes range as per CEA-861-F spec, which is
extended to (VIC 1-107).
This patch adds a bool input variable, which indicates if the connected
sink is a HDMI 2.0 sink or not. This will make sure that we don't pass a
HDMI 2.0 VIC to a HDMI 1.4 sink.
This patch touches all drm drivers, who are callers of this function
drm_hdmi_avi_infoframe_from_display_mode but to make sure there is
no change in current behavior, is_hdmi2 is kept as false.
In case of I915 driver, this patch:
- checks if the connected display is HDMI 2.0.
- HDMI infoframes carry one of this two type of information:
- VIC for 4K modes for HDMI 1.4 sinks
- S3D information for S3D modes
As CEA-861-F has already defined VICs for 4K videomodes, this
patch doesn't allow sending HDMI infoframes for HDMI 2.0 sinks,
until the mode is 3D.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Jose Abreu <jose.abreu@synopsys.com>
Cc: Andrzej Hajda <a.hajda@samsung.com>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
PS: This patch touches a few lines in few files, which were
already above 80 char, so checkpatch gives 80 char warning again.
- gpu/drm/omapdrm/omap_encoder.c
- gpu/drm/i915/intel_sdvo.c
V2: Rebase, Added r-b from Andrzej
V3: Addressed review comment from Ville:
- Do not send VICs in both AVI-IF and HDMI-IF
send only one of it.
V4: Rebase
V5: Added r-b from Neil.
Addressed review comments from Ville
- Do not block HDMI vendor IF, instead check for VIC while
handling AVI infoframes
V6: Rebase
V7: Rebase
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1499960000-9232-2-git-send-email-shashank.sharma@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2017-07-13 23:33:07 +08:00
|
|
|
adjusted_mode,
|
|
|
|
is_hdmi2_sink);
|
2013-08-07 03:32:19 +08:00
|
|
|
if (ret < 0) {
|
|
|
|
DRM_ERROR("couldn't fill AVI infoframe\n");
|
|
|
|
return;
|
|
|
|
}
|
2012-04-14 03:31:41 +08:00
|
|
|
|
2017-07-21 23:25:08 +08:00
|
|
|
if (crtc_state->ycbcr420)
|
|
|
|
frame.avi.colorspace = HDMI_COLORSPACE_YUV420;
|
|
|
|
else
|
|
|
|
frame.avi.colorspace = HDMI_COLORSPACE_RGB;
|
|
|
|
|
2017-01-11 20:57:24 +08:00
|
|
|
drm_hdmi_avi_infoframe_quant_range(&frame.avi, adjusted_mode,
|
2017-01-11 20:57:23 +08:00
|
|
|
crtc_state->limited_color_range ?
|
|
|
|
HDMI_QUANTIZATION_RANGE_LIMITED :
|
|
|
|
HDMI_QUANTIZATION_RANGE_FULL,
|
|
|
|
intel_hdmi->rgb_quant_range_selectable);
|
2013-01-17 22:31:31 +08:00
|
|
|
|
2017-07-21 23:25:08 +08:00
|
|
|
/* TODO: handle pixel repetition for YCBCR420 outputs */
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_write_infoframe(encoder, crtc_state, &frame);
|
2011-07-09 02:31:57 +08:00
|
|
|
}
|
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
static void intel_hdmi_set_spd_infoframe(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *crtc_state)
|
2011-08-04 00:22:56 +08:00
|
|
|
{
|
2013-08-07 03:32:19 +08: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-04 00:22:56 +08:00
|
|
|
|
2013-08-07 03:32:19 +08:00
|
|
|
frame.spd.sdi = HDMI_SPD_SDI_PC;
|
2011-08-04 00:22:56 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_write_infoframe(encoder, crtc_state, &frame);
|
2011-08-04 00:22:56 +08:00
|
|
|
}
|
|
|
|
|
2013-08-19 23:59:04 +08:00
|
|
|
static void
|
|
|
|
intel_hdmi_set_hdmi_infoframe(struct drm_encoder *encoder,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state)
|
2013-08-19 23:59:04 +08:00
|
|
|
{
|
|
|
|
union hdmi_infoframe frame;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = drm_hdmi_vendor_infoframe_from_display_mode(&frame.vendor.hdmi,
|
2016-11-23 22:57:00 +08:00
|
|
|
&crtc_state->base.adjusted_mode);
|
2013-08-19 23:59:04 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return;
|
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_write_infoframe(encoder, crtc_state, &frame);
|
2013-08-19 23:59:04 +08:00
|
|
|
}
|
|
|
|
|
2012-05-29 03:42:48 +08:00
|
|
|
static void g4x_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 05:54:47 +08:00
|
|
|
bool enable,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2012-05-29 03:42:48 +08:00
|
|
|
{
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2013-01-24 21:29:26 +08: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 21:33:26 +08: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 03:42:49 +08:00
|
|
|
u32 val = I915_READ(reg);
|
2014-01-24 05:15:34 +08: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 03:42:49 +08:00
|
|
|
|
2012-06-12 22:36:45 +08: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 03:42:49 +08: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 05:54:47 +08: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 03:42:49 +08:00
|
|
|
if (!(val & VIDEO_DIP_ENABLE))
|
|
|
|
return;
|
2015-05-05 22:06:24 +08: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 03:42:49 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08: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 03:42:49 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-05-29 03:42:54 +08:00
|
|
|
if (port != (val & VIDEO_DIP_PORT_MASK)) {
|
|
|
|
if (val & VIDEO_DIP_ENABLE) {
|
2015-05-05 22:06:24 +08:00
|
|
|
DRM_DEBUG_KMS("video DIP already enabled on port %c\n",
|
|
|
|
(val & VIDEO_DIP_PORT_MASK) >> 29);
|
|
|
|
return;
|
2012-05-29 03:42:54 +08:00
|
|
|
}
|
|
|
|
val &= ~VIDEO_DIP_PORT_MASK;
|
|
|
|
val |= port;
|
|
|
|
}
|
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
val |= VIDEO_DIP_ENABLE;
|
2015-05-05 22:06:24 +08:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_AVI |
|
|
|
|
VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_SPD);
|
2012-05-29 03:42:51 +08:00
|
|
|
|
2012-05-29 03:42:50 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 03:42:50 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state);
|
2012-05-29 03:42:48 +08:00
|
|
|
}
|
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
static bool hdmi_sink_is_deep_color(const struct drm_connector_state *conn_state)
|
2015-05-05 22:06:20 +08:00
|
|
|
{
|
2016-11-23 22:57:00 +08:00
|
|
|
struct drm_connector *connector = conn_state->connector;
|
2015-05-05 22:06:20 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
return connector->display_info.bpc > 8;
|
2015-05-05 22:06:20 +08:00
|
|
|
}
|
|
|
|
|
2015-05-05 22:06:21 +08: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);
|
|
|
|
}
|
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
static bool intel_hdmi_set_gcp_infoframe(struct drm_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *crtc_state,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2015-05-05 22:06:20 +08:00
|
|
|
{
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.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 21:33:26 +08:00
|
|
|
i915_reg_t reg;
|
|
|
|
u32 val = 0;
|
2015-05-05 22:06:20 +08:00
|
|
|
|
|
|
|
if (HAS_DDI(dev_priv))
|
2016-11-23 22:57:00 +08:00
|
|
|
reg = HSW_TVIDEO_DIP_GCP(crtc_state->cpu_transcoder);
|
2015-12-10 04:29:35 +08:00
|
|
|
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
|
2015-05-05 22:06:20 +08:00
|
|
|
reg = VLV_TVIDEO_DIP_GCP(crtc->pipe);
|
2016-04-07 16:08:05 +08:00
|
|
|
else if (HAS_PCH_SPLIT(dev_priv))
|
2015-05-05 22:06:20 +08:00
|
|
|
reg = TVIDEO_DIP_GCP(crtc->pipe);
|
|
|
|
else
|
|
|
|
return false;
|
|
|
|
|
|
|
|
/* Indicate color depth whenever the sink supports deep color */
|
2016-11-23 22:57:00 +08:00
|
|
|
if (hdmi_sink_is_deep_color(conn_state))
|
2015-05-05 22:06:20 +08:00
|
|
|
val |= GCP_COLOR_INDICATION;
|
|
|
|
|
2015-05-05 22:06:21 +08:00
|
|
|
/* Enable default_phase whenever the display mode is suitably aligned */
|
2016-11-23 22:57:00 +08:00
|
|
|
if (gcp_default_phase_possible(crtc_state->pipe_bpp,
|
|
|
|
&crtc_state->base.adjusted_mode))
|
2015-05-05 22:06:21 +08:00
|
|
|
val |= GCP_DEFAULT_PHASE_ENABLE;
|
|
|
|
|
2015-05-05 22:06:20 +08:00
|
|
|
I915_WRITE(reg, val);
|
|
|
|
|
|
|
|
return val != 0;
|
|
|
|
}
|
|
|
|
|
2012-05-29 03:42:48 +08:00
|
|
|
static void ibx_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 05:54:47 +08:00
|
|
|
bool enable,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2012-05-29 03:42:48 +08:00
|
|
|
{
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
|
2013-01-24 21:29:26 +08: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 21:33:26 +08: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 03:42:49 +08:00
|
|
|
u32 val = I915_READ(reg);
|
2014-01-24 05:15:34 +08: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 03:42:49 +08:00
|
|
|
|
2012-06-12 22:36:45 +08: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 03:42:49 +08:00
|
|
|
/* See the big comment in g4x_set_infoframes() */
|
|
|
|
val |= VIDEO_DIP_SELECT_AVI | VIDEO_DIP_FREQ_VSYNC;
|
|
|
|
|
2014-04-25 05:54:47 +08: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 03:42:49 +08:00
|
|
|
if (!(val & VIDEO_DIP_ENABLE))
|
|
|
|
return;
|
2015-05-05 22:06:24 +08: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 03:42:49 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08: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 03:42:49 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-05-29 03:42:54 +08:00
|
|
|
if (port != (val & VIDEO_DIP_PORT_MASK)) {
|
2015-05-05 22:06:24 +08:00
|
|
|
WARN(val & VIDEO_DIP_ENABLE,
|
|
|
|
"DIP already enabled on port %c\n",
|
|
|
|
(val & VIDEO_DIP_PORT_MASK) >> 29);
|
2012-05-29 03:42:54 +08:00
|
|
|
val &= ~VIDEO_DIP_PORT_MASK;
|
|
|
|
val |= port;
|
|
|
|
}
|
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
val |= VIDEO_DIP_ENABLE;
|
2015-05-05 22:06:24 +08: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 03:42:51 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
if (intel_hdmi_set_gcp_infoframe(encoder, crtc_state, conn_state))
|
2015-05-05 22:06:20 +08:00
|
|
|
val |= VIDEO_DIP_ENABLE_GCP;
|
|
|
|
|
2012-05-29 03:42:50 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 03:42:50 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state);
|
2012-05-29 03:42:48 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void cpt_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 05:54:47 +08:00
|
|
|
bool enable,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2012-05-29 03:42:48 +08:00
|
|
|
{
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
|
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 03:42:49 +08:00
|
|
|
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 21:33:26 +08: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 03:42:49 +08:00
|
|
|
u32 val = I915_READ(reg);
|
|
|
|
|
2012-06-12 22:36:45 +08: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 03:42:49 +08:00
|
|
|
/* See the big comment in g4x_set_infoframes() */
|
|
|
|
val |= VIDEO_DIP_SELECT_AVI | VIDEO_DIP_FREQ_VSYNC;
|
|
|
|
|
2014-04-25 05:54:47 +08: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 03:42:49 +08:00
|
|
|
if (!(val & VIDEO_DIP_ENABLE))
|
|
|
|
return;
|
2015-05-05 22:06:24 +08: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 03:42:49 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08: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 03:42:49 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
/* Set both together, unset both together: see the spec. */
|
|
|
|
val |= VIDEO_DIP_ENABLE | VIDEO_DIP_ENABLE_AVI;
|
2012-05-29 03:42:53 +08:00
|
|
|
val &= ~(VIDEO_DIP_ENABLE_VENDOR | VIDEO_DIP_ENABLE_GAMUT |
|
2015-05-05 22:06:24 +08:00
|
|
|
VIDEO_DIP_ENABLE_SPD | VIDEO_DIP_ENABLE_GCP);
|
2012-05-29 03:42:51 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
if (intel_hdmi_set_gcp_infoframe(encoder, crtc_state, conn_state))
|
2015-05-05 22:06:20 +08:00
|
|
|
val |= VIDEO_DIP_ENABLE_GCP;
|
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 03:42:51 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state);
|
2012-05-29 03:42:48 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void vlv_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 05:54:47 +08:00
|
|
|
bool enable,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2012-05-29 03:42:48 +08:00
|
|
|
{
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
2014-04-03 01:08:51 +08:00
|
|
|
struct intel_digital_port *intel_dig_port = enc_to_dig_port(encoder);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
|
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 03:42:49 +08:00
|
|
|
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 21:33:26 +08: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 03:42:49 +08:00
|
|
|
u32 val = I915_READ(reg);
|
2014-04-03 01:08:51 +08: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 03:42:49 +08:00
|
|
|
|
2012-06-12 22:36:45 +08: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 03:42:49 +08:00
|
|
|
/* See the big comment in g4x_set_infoframes() */
|
|
|
|
val |= VIDEO_DIP_SELECT_AVI | VIDEO_DIP_FREQ_VSYNC;
|
|
|
|
|
2014-04-25 05:54:47 +08: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 03:42:49 +08:00
|
|
|
if (!(val & VIDEO_DIP_ENABLE))
|
|
|
|
return;
|
2015-05-05 22:06:24 +08: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 03:42:49 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08: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 03:42:49 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2014-04-03 01:08:51 +08:00
|
|
|
if (port != (val & VIDEO_DIP_PORT_MASK)) {
|
2015-05-05 22:06:24 +08:00
|
|
|
WARN(val & VIDEO_DIP_ENABLE,
|
|
|
|
"DIP already enabled on port %c\n",
|
|
|
|
(val & VIDEO_DIP_PORT_MASK) >> 29);
|
2014-04-03 01:08:51 +08:00
|
|
|
val &= ~VIDEO_DIP_PORT_MASK;
|
|
|
|
val |= port;
|
|
|
|
}
|
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
val |= VIDEO_DIP_ENABLE;
|
2015-05-05 22:06:24 +08: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 03:42:51 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
if (intel_hdmi_set_gcp_infoframe(encoder, crtc_state, conn_state))
|
2015-05-05 22:06:20 +08:00
|
|
|
val |= VIDEO_DIP_ENABLE_GCP;
|
|
|
|
|
2012-05-29 03:42:51 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 03:42:51 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state);
|
2012-05-29 03:42:48 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static void hsw_set_infoframes(struct drm_encoder *encoder,
|
2014-04-25 05:54:47 +08:00
|
|
|
bool enable,
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct intel_crtc_state *crtc_state,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2012-05-29 03:42:48 +08:00
|
|
|
{
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->dev);
|
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 03:42:49 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
|
2016-11-23 22:57:00 +08:00
|
|
|
i915_reg_t reg = HSW_TVIDEO_DIP_CTL(crtc_state->cpu_transcoder);
|
2012-05-29 03:42:53 +08: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 03:42:49 +08:00
|
|
|
|
2012-06-12 22:36:45 +08:00
|
|
|
assert_hdmi_port_disabled(intel_hdmi);
|
|
|
|
|
2015-05-05 22:06:24 +08: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 05:54:47 +08:00
|
|
|
if (!enable) {
|
2015-05-05 22:06:24 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08: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 03:42:49 +08:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
if (intel_hdmi_set_gcp_infoframe(encoder, crtc_state, conn_state))
|
2015-05-05 22:06:20 +08:00
|
|
|
val |= VIDEO_DIP_ENABLE_GCP_HSW;
|
|
|
|
|
2012-05-29 03:42:53 +08:00
|
|
|
I915_WRITE(reg, val);
|
2012-05-29 03:43:00 +08:00
|
|
|
POSTING_READ(reg);
|
2012-05-29 03:42:53 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_hdmi_set_avi_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_spd_infoframe(encoder, crtc_state);
|
|
|
|
intel_hdmi_set_hdmi_infoframe(encoder, crtc_state);
|
2012-05-29 03:42:48 +08:00
|
|
|
}
|
|
|
|
|
2016-05-03 03:08:24 +08: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);
|
|
|
|
}
|
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
static void intel_hdmi_prepare(struct intel_encoder *encoder,
|
|
|
|
const struct intel_crtc_state *crtc_state)
|
2009-01-03 05:33:00 +08:00
|
|
|
{
|
2013-07-22 03:37:04 +08:00
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
|
2013-07-22 03:37:04 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
2016-11-23 22:57:00 +08:00
|
|
|
const struct drm_display_mode *adjusted_mode = &crtc_state->base.adjusted_mode;
|
2013-02-19 06:00:26 +08:00
|
|
|
u32 hdmi_val;
|
2009-01-03 05:33:00 +08:00
|
|
|
|
2016-05-03 03:08:24 +08:00
|
|
|
intel_dp_dual_mode_set_tmds_output(intel_hdmi, true);
|
|
|
|
|
2013-02-19 06:00:26 +08:00
|
|
|
hdmi_val = SDVO_ENCODING_HDMI;
|
2016-11-23 22:57:00 +08:00
|
|
|
if (!HAS_PCH_SPLIT(dev_priv) && crtc_state->limited_color_range)
|
2015-07-06 20:10:00 +08:00
|
|
|
hdmi_val |= HDMI_COLOR_RANGE_16_235;
|
2010-07-17 02:46:31 +08:00
|
|
|
if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
|
2013-02-19 06:00:26 +08:00
|
|
|
hdmi_val |= SDVO_VSYNC_ACTIVE_HIGH;
|
2010-07-17 02:46:31 +08:00
|
|
|
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
|
2013-02-19 06:00:26 +08:00
|
|
|
hdmi_val |= SDVO_HSYNC_ACTIVE_HIGH;
|
2009-01-03 05:33:00 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
if (crtc_state->pipe_bpp > 24)
|
2013-02-20 03:21:47 +08:00
|
|
|
hdmi_val |= HDMI_COLOR_FORMAT_12bpc;
|
2011-06-25 03:19:25 +08:00
|
|
|
else
|
2013-02-20 03:21:47 +08:00
|
|
|
hdmi_val |= SDVO_COLOR_FORMAT_8bpc;
|
2011-06-25 03:19:25 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
if (crtc_state->has_hdmi_sink)
|
2013-02-20 03:21:46 +08:00
|
|
|
hdmi_val |= HDMI_MODE_SELECT_HDMI;
|
2010-09-10 10:39:40 +08:00
|
|
|
|
2016-10-13 18:02:53 +08:00
|
|
|
if (HAS_PCH_CPT(dev_priv))
|
2013-07-22 03:37:04 +08:00
|
|
|
hdmi_val |= SDVO_PIPE_SEL_CPT(crtc->pipe);
|
2016-10-14 17:13:44 +08:00
|
|
|
else if (IS_CHERRYVIEW(dev_priv))
|
2014-04-09 18:28:21 +08:00
|
|
|
hdmi_val |= SDVO_PIPE_SEL_CHV(crtc->pipe);
|
2013-02-20 03:21:46 +08:00
|
|
|
else
|
2013-07-22 03:37:04 +08:00
|
|
|
hdmi_val |= SDVO_PIPE_SEL(crtc->pipe);
|
2009-01-03 05:33:00 +08:00
|
|
|
|
2013-02-19 06:00:26 +08:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, hdmi_val);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2009-01-03 05:33:00 +08:00
|
|
|
}
|
|
|
|
|
2012-07-02 19:27:29 +08:00
|
|
|
static bool intel_hdmi_get_hw_state(struct intel_encoder *encoder,
|
|
|
|
enum pipe *pipe)
|
2009-01-03 05:33:00 +08:00
|
|
|
{
|
2012-07-02 19:27:29 +08:00
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2012-07-02 19:27:29 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
u32 tmp;
|
2016-02-13 00:55:20 +08:00
|
|
|
bool ret;
|
2012-07-02 19:27:29 +08:00
|
|
|
|
2017-02-22 14:34:27 +08:00
|
|
|
if (!intel_display_power_get_if_enabled(dev_priv,
|
|
|
|
encoder->power_domain))
|
2014-03-05 22:20:54 +08:00
|
|
|
return false;
|
|
|
|
|
2016-02-13 00:55:20 +08:00
|
|
|
ret = false;
|
|
|
|
|
2013-02-19 06:00:26 +08:00
|
|
|
tmp = I915_READ(intel_hdmi->hdmi_reg);
|
2012-07-02 19:27:29 +08:00
|
|
|
|
|
|
|
if (!(tmp & SDVO_ENABLE))
|
2016-02-13 00:55:20 +08:00
|
|
|
goto out;
|
2012-07-02 19:27:29 +08:00
|
|
|
|
2016-10-13 18:02:53 +08:00
|
|
|
if (HAS_PCH_CPT(dev_priv))
|
2012-07-02 19:27:29 +08:00
|
|
|
*pipe = PORT_TO_PIPE_CPT(tmp);
|
2016-10-14 17:13:44 +08:00
|
|
|
else if (IS_CHERRYVIEW(dev_priv))
|
2014-04-09 18:28:55 +08:00
|
|
|
*pipe = SDVO_PORT_TO_PIPE_CHV(tmp);
|
2012-07-02 19:27:29 +08:00
|
|
|
else
|
|
|
|
*pipe = PORT_TO_PIPE(tmp);
|
|
|
|
|
2016-02-13 00:55:20 +08:00
|
|
|
ret = true;
|
|
|
|
|
|
|
|
out:
|
2017-02-22 14:34:27 +08:00
|
|
|
intel_display_power_put(dev_priv, encoder->power_domain);
|
2016-02-13 00:55:20 +08:00
|
|
|
|
|
|
|
return ret;
|
2012-07-02 19:27:29 +08:00
|
|
|
}
|
|
|
|
|
2013-05-15 08:08:26 +08:00
|
|
|
static void intel_hdmi_get_config(struct intel_encoder *encoder,
|
2015-01-15 20:55:21 +08:00
|
|
|
struct intel_crtc_state *pipe_config)
|
2013-05-15 08:08:26 +08:00
|
|
|
{
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
2017-08-18 21:49:54 +08:00
|
|
|
struct intel_digital_port *intel_dig_port = hdmi_to_dig_port(intel_hdmi);
|
2014-09-12 20:46:29 +08:00
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2013-05-15 08:08:26 +08:00
|
|
|
u32 tmp, flags = 0;
|
2013-09-13 21:00:08 +08:00
|
|
|
int dotclock;
|
2013-05-15 08:08:26 +08: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 05:54:47 +08:00
|
|
|
if (tmp & HDMI_MODE_SELECT_HDMI)
|
|
|
|
pipe_config->has_hdmi_sink = true;
|
|
|
|
|
2017-08-18 21:49:54 +08:00
|
|
|
if (intel_dig_port->infoframe_enabled(&encoder->base, pipe_config))
|
2014-11-06 06:26:08 +08:00
|
|
|
pipe_config->has_infoframe = true;
|
|
|
|
|
2014-09-17 20:34:58 +08:00
|
|
|
if (tmp & SDVO_AUDIO_ENABLE)
|
2014-04-25 05:54:52 +08:00
|
|
|
pipe_config->has_audio = true;
|
|
|
|
|
2016-10-13 18:02:53 +08:00
|
|
|
if (!HAS_PCH_SPLIT(dev_priv) &&
|
2014-09-12 20:46:29 +08:00
|
|
|
tmp & HDMI_COLOR_RANGE_16_235)
|
|
|
|
pipe_config->limited_color_range = true;
|
|
|
|
|
2015-01-15 20:55:22 +08:00
|
|
|
pipe_config->base.adjusted_mode.flags |= flags;
|
2013-09-13 21:00:08 +08: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 22:06:26 +08:00
|
|
|
if (pipe_config->pixel_multiplier)
|
|
|
|
dotclock /= pipe_config->pixel_multiplier;
|
|
|
|
|
2015-01-15 20:55:22 +08:00
|
|
|
pipe_config->base.adjusted_mode.crtc_clock = dotclock;
|
2016-04-27 20:44:16 +08:00
|
|
|
|
|
|
|
pipe_config->lane_count = 4;
|
2013-05-15 08:08:26 +08:00
|
|
|
}
|
|
|
|
|
2016-11-08 20:55:37 +08:00
|
|
|
static void intel_enable_hdmi_audio(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2015-05-05 22:06:19 +08:00
|
|
|
{
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *crtc = to_intel_crtc(pipe_config->base.crtc);
|
2015-05-05 22:06:19 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
WARN_ON(!pipe_config->has_hdmi_sink);
|
2015-05-05 22:06:19 +08:00
|
|
|
DRM_DEBUG_DRIVER("Enabling HDMI audio on pipe %c\n",
|
|
|
|
pipe_name(crtc->pipe));
|
2016-11-08 20:55:38 +08:00
|
|
|
intel_audio_codec_enable(encoder, pipe_config, conn_state);
|
2015-05-05 22:06:19 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void g4x_enable_hdmi(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2009-01-03 05:33:00 +08:00
|
|
|
{
|
2012-06-30 14:59:56 +08:00
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2012-06-30 14:59:56 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
2009-01-03 05:33:00 +08:00
|
|
|
u32 temp;
|
|
|
|
|
2013-02-19 06:00:26 +08:00
|
|
|
temp = I915_READ(intel_hdmi->hdmi_reg);
|
2009-11-02 15:52:30 +08:00
|
|
|
|
2015-05-05 22:06:23 +08:00
|
|
|
temp |= SDVO_ENABLE;
|
2016-11-08 20:55:37 +08:00
|
|
|
if (pipe_config->has_audio)
|
2015-05-05 22:06:23 +08:00
|
|
|
temp |= SDVO_AUDIO_ENABLE;
|
2012-06-05 17:03:39 +08:00
|
|
|
|
2015-05-05 22:06:23 +08:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
|
|
|
|
2016-11-08 20:55:37 +08:00
|
|
|
if (pipe_config->has_audio)
|
|
|
|
intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
|
2015-05-05 22:06:23 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void ibx_enable_hdmi(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2015-05-05 22:06:23 +08:00
|
|
|
{
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2015-05-05 22:06:23 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
u32 temp;
|
|
|
|
|
|
|
|
temp = I915_READ(intel_hdmi->hdmi_reg);
|
2009-11-02 15:52:30 +08:00
|
|
|
|
2015-05-05 22:06:23 +08:00
|
|
|
temp |= SDVO_ENABLE;
|
2016-11-23 22:57:00 +08:00
|
|
|
if (pipe_config->has_audio)
|
2015-05-05 22:06:23 +08:00
|
|
|
temp |= SDVO_AUDIO_ENABLE;
|
2012-06-30 14:59:56 +08:00
|
|
|
|
2015-05-05 22:06:23 +08: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 06:00:26 +08:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2012-06-30 14:59:56 +08:00
|
|
|
|
2015-05-05 22:06:23 +08: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 14:59:56 +08:00
|
|
|
*/
|
2016-11-08 20:55:37 +08:00
|
|
|
if (pipe_config->pipe_bpp > 24 &&
|
|
|
|
pipe_config->pixel_multiplier > 1) {
|
2015-05-05 22:06:23 +08:00
|
|
|
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 06:00:26 +08:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2009-01-03 05:33:00 +08:00
|
|
|
}
|
2014-10-27 22:26:56 +08:00
|
|
|
|
2016-11-08 20:55:37 +08:00
|
|
|
if (pipe_config->has_audio)
|
|
|
|
intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
|
2015-05-05 22:06:19 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void cpt_enable_hdmi(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2015-05-05 22:06:19 +08:00
|
|
|
{
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *crtc = to_intel_crtc(pipe_config->base.crtc);
|
2015-05-05 22:06:19 +08:00
|
|
|
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;
|
2016-11-08 20:55:37 +08:00
|
|
|
if (pipe_config->has_audio)
|
2015-05-05 22:06:19 +08:00
|
|
|
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
|
|
|
|
*/
|
|
|
|
|
2016-11-08 20:55:37 +08:00
|
|
|
if (pipe_config->pipe_bpp > 24) {
|
2015-05-05 22:06:19 +08:00
|
|
|
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 22:26:56 +08:00
|
|
|
}
|
2015-05-05 22:06:19 +08:00
|
|
|
|
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
|
|
|
|
2016-11-08 20:55:37 +08:00
|
|
|
if (pipe_config->pipe_bpp > 24) {
|
2015-05-05 22:06:19 +08:00
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2016-11-08 20:55:37 +08:00
|
|
|
if (pipe_config->has_audio)
|
|
|
|
intel_enable_hdmi_audio(encoder, pipe_config, conn_state);
|
2013-07-30 17:20:31 +08:00
|
|
|
}
|
2013-04-19 05:51:36 +08:00
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void vlv_enable_hdmi(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2013-07-30 17:20:31 +08:00
|
|
|
{
|
2012-06-30 14:59:56 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void intel_disable_hdmi(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *old_crtc_state,
|
|
|
|
const struct drm_connector_state *old_conn_state)
|
2012-06-30 14:59:56 +08:00
|
|
|
{
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2012-06-30 14:59:56 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
2017-08-18 21:49:54 +08:00
|
|
|
struct intel_digital_port *intel_dig_port =
|
|
|
|
hdmi_to_dig_port(intel_hdmi);
|
2016-11-23 22:57:00 +08:00
|
|
|
struct intel_crtc *crtc = to_intel_crtc(old_crtc_state->base.crtc);
|
2012-06-30 14:59:56 +08:00
|
|
|
u32 temp;
|
|
|
|
|
2013-02-19 06:00:26 +08:00
|
|
|
temp = I915_READ(intel_hdmi->hdmi_reg);
|
2012-06-30 14:59:56 +08:00
|
|
|
|
2015-05-05 22:17:34 +08:00
|
|
|
temp &= ~(SDVO_ENABLE | SDVO_AUDIO_ENABLE);
|
2013-02-19 06:00:26 +08:00
|
|
|
I915_WRITE(intel_hdmi->hdmi_reg, temp);
|
|
|
|
POSTING_READ(intel_hdmi->hdmi_reg);
|
2015-05-05 22:17:34 +08: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.
|
|
|
|
*/
|
2016-10-13 18:02:53 +08:00
|
|
|
if (HAS_PCH_IBX(dev_priv) && crtc->pipe == PIPE_B) {
|
2015-10-31 01:23:22 +08: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 22:17:34 +08: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 01:23:22 +08:00
|
|
|
|
2016-11-01 04:37:06 +08:00
|
|
|
intel_wait_for_vblank_if_active(dev_priv, PIPE_A);
|
2015-10-31 01:23:22 +08:00
|
|
|
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 22:17:34 +08:00
|
|
|
}
|
2015-05-05 22:06:20 +08:00
|
|
|
|
2017-08-18 21:49:54 +08:00
|
|
|
intel_dig_port->set_infoframes(&encoder->base, false,
|
|
|
|
old_crtc_state, old_conn_state);
|
2016-05-03 03:08:24 +08:00
|
|
|
|
|
|
|
intel_dp_dual_mode_set_tmds_output(intel_hdmi, false);
|
2009-01-03 05:33:00 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void g4x_disable_hdmi(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *old_crtc_state,
|
|
|
|
const struct drm_connector_state *old_conn_state)
|
2015-05-05 22:17:35 +08:00
|
|
|
{
|
2016-11-08 20:55:37 +08:00
|
|
|
if (old_crtc_state->has_audio)
|
2015-05-05 22:17:35 +08:00
|
|
|
intel_audio_codec_disable(encoder);
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
intel_disable_hdmi(encoder, old_crtc_state, old_conn_state);
|
2015-05-05 22:17:35 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void pch_disable_hdmi(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *old_crtc_state,
|
|
|
|
const struct drm_connector_state *old_conn_state)
|
2015-05-05 22:17:35 +08:00
|
|
|
{
|
2016-11-08 20:55:37 +08:00
|
|
|
if (old_crtc_state->has_audio)
|
2015-05-05 22:17:35 +08:00
|
|
|
intel_audio_codec_disable(encoder);
|
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void pch_post_disable_hdmi(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *old_crtc_state,
|
|
|
|
const struct drm_connector_state *old_conn_state)
|
2015-05-05 22:17:35 +08:00
|
|
|
{
|
2016-08-09 23:04:04 +08:00
|
|
|
intel_disable_hdmi(encoder, old_crtc_state, old_conn_state);
|
2015-05-05 22:17:35 +08:00
|
|
|
}
|
|
|
|
|
2016-05-03 03:08:23 +08:00
|
|
|
static int intel_hdmi_source_max_tmds_clock(struct drm_i915_private *dev_priv)
|
2013-07-23 00:02:39 +08:00
|
|
|
{
|
2016-05-03 03:08:23 +08:00
|
|
|
if (IS_G4X(dev_priv))
|
2013-07-23 00:02:39 +08:00
|
|
|
return 165000;
|
2017-03-13 19:24:04 +08:00
|
|
|
else if (IS_GEMINILAKE(dev_priv))
|
|
|
|
return 594000;
|
2016-05-03 03:08:23 +08:00
|
|
|
else if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
|
2013-07-23 00:02:39 +08:00
|
|
|
return 300000;
|
|
|
|
else
|
|
|
|
return 225000;
|
|
|
|
}
|
|
|
|
|
2016-05-03 03:08:23 +08:00
|
|
|
static int hdmi_port_clock_limit(struct intel_hdmi *hdmi,
|
2017-05-01 21:38:02 +08:00
|
|
|
bool respect_downstream_limits,
|
|
|
|
bool force_dvi)
|
2016-05-03 03:08:23 +08:00
|
|
|
{
|
|
|
|
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) {
|
2016-09-28 21:51:43 +08:00
|
|
|
struct intel_connector *connector = hdmi->attached_connector;
|
|
|
|
const struct drm_display_info *info = &connector->base.display_info;
|
|
|
|
|
2016-05-03 03:08:23 +08:00
|
|
|
if (hdmi->dp_dual_mode.max_tmds_clock)
|
|
|
|
max_tmds_clock = min(max_tmds_clock,
|
|
|
|
hdmi->dp_dual_mode.max_tmds_clock);
|
2016-09-28 21:51:43 +08:00
|
|
|
|
|
|
|
if (info->max_tmds_clock)
|
|
|
|
max_tmds_clock = min(max_tmds_clock,
|
|
|
|
info->max_tmds_clock);
|
2017-05-01 21:38:02 +08:00
|
|
|
else if (!hdmi->has_hdmi_sink || force_dvi)
|
2016-05-03 03:08:23 +08:00
|
|
|
max_tmds_clock = min(max_tmds_clock, 165000);
|
|
|
|
}
|
|
|
|
|
|
|
|
return max_tmds_clock;
|
|
|
|
}
|
|
|
|
|
2015-07-01 00:23:59 +08:00
|
|
|
static enum drm_mode_status
|
|
|
|
hdmi_port_clock_valid(struct intel_hdmi *hdmi,
|
2017-05-01 21:38:02 +08:00
|
|
|
int clock, bool respect_downstream_limits,
|
|
|
|
bool force_dvi)
|
2015-07-01 00:23:59 +08:00
|
|
|
{
|
2016-10-13 18:03:04 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(intel_hdmi_to_dev(hdmi));
|
2015-07-01 00:23:59 +08:00
|
|
|
|
|
|
|
if (clock < 25000)
|
|
|
|
return MODE_CLOCK_LOW;
|
2017-05-01 21:38:02 +08:00
|
|
|
if (clock > hdmi_port_clock_limit(hdmi, respect_downstream_limits, force_dvi))
|
2015-07-01 00:23:59 +08:00
|
|
|
return MODE_CLOCK_HIGH;
|
|
|
|
|
2015-07-06 19:44:11 +08:00
|
|
|
/* BXT DPLL can't generate 223-240 MHz */
|
2016-12-02 16:23:49 +08:00
|
|
|
if (IS_GEN9_LP(dev_priv) && clock > 223333 && clock < 240000)
|
2015-07-06 19:44:11 +08:00
|
|
|
return MODE_CLOCK_RANGE;
|
|
|
|
|
|
|
|
/* CHV DPLL can't generate 216-240 MHz */
|
2016-10-13 18:03:04 +08:00
|
|
|
if (IS_CHERRYVIEW(dev_priv) && clock > 216000 && clock < 240000)
|
2015-07-01 00:23:59 +08:00
|
|
|
return MODE_CLOCK_RANGE;
|
|
|
|
|
|
|
|
return MODE_OK;
|
|
|
|
}
|
|
|
|
|
2013-11-28 23:29:18 +08:00
|
|
|
static enum drm_mode_status
|
|
|
|
intel_hdmi_mode_valid(struct drm_connector *connector,
|
|
|
|
struct drm_display_mode *mode)
|
2009-01-03 05:33:00 +08:00
|
|
|
{
|
2015-07-01 00:23:59 +08:00
|
|
|
struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
|
|
|
|
struct drm_device *dev = intel_hdmi_to_dev(hdmi);
|
2016-10-13 18:02:54 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2015-07-01 00:23:59 +08:00
|
|
|
enum drm_mode_status status;
|
|
|
|
int clock;
|
2016-02-02 21:16:39 +08:00
|
|
|
int max_dotclk = to_i915(connector->dev)->max_dotclk_freq;
|
2017-05-01 21:38:02 +08:00
|
|
|
bool force_dvi =
|
|
|
|
READ_ONCE(to_intel_digital_connector_state(connector->state)->force_audio) == HDMI_AUDIO_OFF_DVI;
|
2015-07-01 00:23:59 +08:00
|
|
|
|
|
|
|
if (mode->flags & DRM_MODE_FLAG_DBLSCAN)
|
|
|
|
return MODE_NO_DBLESCAN;
|
2014-09-03 08:03:36 +08:00
|
|
|
|
2015-07-01 00:23:59 +08:00
|
|
|
clock = mode->clock;
|
2016-02-02 21:16:39 +08: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 08:03:36 +08:00
|
|
|
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
|
|
|
|
clock *= 2;
|
|
|
|
|
2017-07-24 21:49:32 +08:00
|
|
|
if (drm_mode_is_420_only(&connector->display_info, mode))
|
|
|
|
clock /= 2;
|
|
|
|
|
2015-07-01 00:23:59 +08:00
|
|
|
/* check if we can do 8bpc */
|
2017-05-01 21:38:02 +08:00
|
|
|
status = hdmi_port_clock_valid(hdmi, clock, true, force_dvi);
|
2009-01-03 05:33:00 +08:00
|
|
|
|
2015-07-01 00:23:59 +08:00
|
|
|
/* if we can't do 8bpc we may still be able to do 12bpc */
|
2017-05-01 21:38:02 +08:00
|
|
|
if (!HAS_GMCH_DISPLAY(dev_priv) && status != MODE_OK && hdmi->has_hdmi_sink && !force_dvi)
|
|
|
|
status = hdmi_port_clock_valid(hdmi, clock * 3 / 2, true, force_dvi);
|
2009-01-03 05:33:00 +08:00
|
|
|
|
2015-07-01 00:23:59 +08:00
|
|
|
return status;
|
2009-01-03 05:33:00 +08:00
|
|
|
}
|
|
|
|
|
2017-08-18 21:49:58 +08:00
|
|
|
static bool hdmi_12bpc_possible(const struct intel_crtc_state *crtc_state)
|
2014-03-03 22:15:29 +08:00
|
|
|
{
|
2017-02-14 01:58:18 +08:00
|
|
|
struct drm_i915_private *dev_priv =
|
|
|
|
to_i915(crtc_state->base.crtc->dev);
|
|
|
|
struct drm_atomic_state *state = crtc_state->base.state;
|
|
|
|
struct drm_connector_state *connector_state;
|
|
|
|
struct drm_connector *connector;
|
|
|
|
int i;
|
2014-03-03 22:15:29 +08:00
|
|
|
|
2017-02-14 01:58:18 +08:00
|
|
|
if (HAS_GMCH_DISPLAY(dev_priv))
|
2014-03-03 22:15:29 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* HDMI 12bpc affects the clocks, so it's only possible
|
|
|
|
* when not cloning with other encoder types.
|
|
|
|
*/
|
2017-02-14 01:58:18 +08:00
|
|
|
if (crtc_state->output_types != 1 << INTEL_OUTPUT_HDMI)
|
|
|
|
return false;
|
|
|
|
|
2017-07-12 16:13:34 +08:00
|
|
|
for_each_new_connector_in_state(state, connector, connector_state, i) {
|
2017-02-14 01:58:18 +08:00
|
|
|
const struct drm_display_info *info = &connector->display_info;
|
|
|
|
|
|
|
|
if (connector_state->crtc != crtc_state->base.crtc)
|
|
|
|
continue;
|
|
|
|
|
2017-07-21 23:25:04 +08:00
|
|
|
if (crtc_state->ycbcr420) {
|
|
|
|
const struct drm_hdmi_info *hdmi = &info->hdmi;
|
|
|
|
|
|
|
|
if (!(hdmi->y420_dc_modes & DRM_EDID_YCBCR420_DC_36))
|
|
|
|
return false;
|
|
|
|
} else {
|
|
|
|
if (!(info->edid_hdmi_dc_modes & DRM_EDID_HDMI_DC_36))
|
|
|
|
return false;
|
|
|
|
}
|
2017-02-14 01:58:18 +08:00
|
|
|
}
|
|
|
|
|
2017-04-24 18:47:18 +08:00
|
|
|
/* Display Wa #1139 */
|
|
|
|
if (IS_GLK_REVID(dev_priv, 0, GLK_REVID_A1) &&
|
|
|
|
crtc_state->base.adjusted_mode.htotal > 5460)
|
|
|
|
return false;
|
|
|
|
|
2017-02-14 01:58:18 +08:00
|
|
|
return true;
|
2014-03-03 22:15:29 +08:00
|
|
|
}
|
|
|
|
|
2017-07-21 23:25:04 +08:00
|
|
|
static bool
|
|
|
|
intel_hdmi_ycbcr420_config(struct drm_connector *connector,
|
|
|
|
struct intel_crtc_state *config,
|
|
|
|
int *clock_12bpc, int *clock_8bpc)
|
|
|
|
{
|
2017-07-21 23:25:05 +08:00
|
|
|
struct intel_crtc *intel_crtc = to_intel_crtc(config->base.crtc);
|
|
|
|
|
2017-07-21 23:25:04 +08:00
|
|
|
if (!connector->ycbcr_420_allowed) {
|
|
|
|
DRM_ERROR("Platform doesn't support YCBCR420 output\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* YCBCR420 TMDS rate requirement is half the pixel clock */
|
|
|
|
config->port_clock /= 2;
|
|
|
|
*clock_12bpc /= 2;
|
|
|
|
*clock_8bpc /= 2;
|
|
|
|
config->ycbcr420 = true;
|
2017-07-21 23:25:05 +08:00
|
|
|
|
|
|
|
/* YCBCR 420 output conversion needs a scaler */
|
|
|
|
if (skl_update_scaler_crtc(config)) {
|
|
|
|
DRM_DEBUG_KMS("Scaler allocation for output failed\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
intel_pch_panel_fitting(intel_crtc, config,
|
|
|
|
DRM_MODE_SCALE_FULLSCREEN);
|
|
|
|
|
2017-07-21 23:25:04 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-03-27 07:44:55 +08:00
|
|
|
bool intel_hdmi_compute_config(struct intel_encoder *encoder,
|
2016-08-09 23:04:05 +08:00
|
|
|
struct intel_crtc_state *pipe_config,
|
|
|
|
struct drm_connector_state *conn_state)
|
2009-01-03 05:33:00 +08:00
|
|
|
{
|
2013-03-27 07:44:55 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
2016-10-13 18:02:52 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
|
2015-01-15 20:55:22 +08:00
|
|
|
struct drm_display_mode *adjusted_mode = &pipe_config->base.adjusted_mode;
|
2017-07-21 23:25:04 +08:00
|
|
|
struct drm_connector *connector = conn_state->connector;
|
|
|
|
struct drm_scdc *scdc = &connector->display_info.hdmi.scdc;
|
2017-05-01 21:38:02 +08:00
|
|
|
struct intel_digital_connector_state *intel_conn_state =
|
|
|
|
to_intel_digital_connector_state(conn_state);
|
2015-07-01 00:23:59 +08: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 07:00:16 +08:00
|
|
|
int desired_bpp;
|
2017-05-01 21:38:02 +08:00
|
|
|
bool force_dvi = intel_conn_state->force_audio == HDMI_AUDIO_OFF_DVI;
|
2013-01-17 22:31:28 +08:00
|
|
|
|
2017-05-01 21:38:02 +08:00
|
|
|
pipe_config->has_hdmi_sink = !force_dvi && intel_hdmi->has_hdmi_sink;
|
2014-04-25 05:54:47 +08:00
|
|
|
|
2014-11-06 06:26:08 +08:00
|
|
|
if (pipe_config->has_hdmi_sink)
|
|
|
|
pipe_config->has_infoframe = true;
|
|
|
|
|
2017-05-01 21:38:02 +08:00
|
|
|
if (intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_AUTO) {
|
2013-01-17 22:31:29 +08:00
|
|
|
/* See CEA-861-E - 5.1 Default Encoding Parameters */
|
2015-07-06 20:10:00 +08:00
|
|
|
pipe_config->limited_color_range =
|
|
|
|
pipe_config->has_hdmi_sink &&
|
2017-01-11 22:18:35 +08:00
|
|
|
drm_default_rgb_quant_range(adjusted_mode) ==
|
|
|
|
HDMI_QUANTIZATION_RANGE_LIMITED;
|
2015-07-06 20:10:00 +08:00
|
|
|
} else {
|
|
|
|
pipe_config->limited_color_range =
|
2017-05-01 21:38:02 +08:00
|
|
|
intel_conn_state->broadcast_rgb == INTEL_BROADCAST_RGB_LIMITED;
|
2013-01-17 22:31:29 +08:00
|
|
|
}
|
|
|
|
|
2014-09-03 08:03:36 +08:00
|
|
|
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK) {
|
|
|
|
pipe_config->pixel_multiplier = 2;
|
2015-07-01 00:23:59 +08:00
|
|
|
clock_8bpc *= 2;
|
2015-05-05 22:06:27 +08:00
|
|
|
clock_12bpc *= 2;
|
2014-09-03 08:03:36 +08:00
|
|
|
}
|
|
|
|
|
2017-07-21 23:25:04 +08:00
|
|
|
if (drm_mode_is_420_only(&connector->display_info, adjusted_mode)) {
|
|
|
|
if (!intel_hdmi_ycbcr420_config(connector, pipe_config,
|
|
|
|
&clock_12bpc, &clock_8bpc)) {
|
|
|
|
DRM_ERROR("Can't support YCBCR420 output\n");
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-10-13 18:02:52 +08:00
|
|
|
if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv))
|
2013-03-27 07:44:55 +08:00
|
|
|
pipe_config->has_pch_encoder = true;
|
|
|
|
|
2017-05-01 21:38:02 +08:00
|
|
|
if (pipe_config->has_hdmi_sink) {
|
|
|
|
if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
|
|
|
|
pipe_config->has_audio = intel_hdmi->has_audio;
|
|
|
|
else
|
|
|
|
pipe_config->has_audio =
|
|
|
|
intel_conn_state->force_audio == HDMI_AUDIO_ON;
|
|
|
|
}
|
2014-04-25 05:54:52 +08:00
|
|
|
|
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 07:44:58 +08: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 17:24:33 +08: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 07:44:58 +08:00
|
|
|
*/
|
2017-05-01 21:38:02 +08:00
|
|
|
if (pipe_config->pipe_bpp > 8*3 && pipe_config->has_hdmi_sink && !force_dvi &&
|
|
|
|
hdmi_port_clock_valid(intel_hdmi, clock_12bpc, true, force_dvi) == MODE_OK &&
|
2015-06-30 20:33:54 +08: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 07:00:16 +08:00
|
|
|
DRM_DEBUG_KMS("picking bpc to 12 for HDMI output\n");
|
|
|
|
desired_bpp = 12*3;
|
2013-04-19 17:24:33 +08:00
|
|
|
|
|
|
|
/* Need to adjust the port link by 1.5x for 12bpc. */
|
2013-06-01 23:16:21 +08: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 07:44:58 +08: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 07:00:16 +08:00
|
|
|
DRM_DEBUG_KMS("picking bpc to 8 for HDMI output\n");
|
|
|
|
desired_bpp = 8*3;
|
2015-07-01 00:23:59 +08: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 07:00:16 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!pipe_config->bw_constrained) {
|
2017-04-05 02:16:05 +08:00
|
|
|
DRM_DEBUG_KMS("forcing pipe bpp to %i for HDMI\n", desired_bpp);
|
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 07:00:16 +08:00
|
|
|
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 07:44:58 +08:00
|
|
|
}
|
|
|
|
|
2015-07-01 00:23:59 +08:00
|
|
|
if (hdmi_port_clock_valid(intel_hdmi, pipe_config->port_clock,
|
2017-05-01 21:38:02 +08:00
|
|
|
false, force_dvi) != MODE_OK) {
|
2015-07-01 00:23:59 +08:00
|
|
|
DRM_DEBUG_KMS("unsupported HDMI clock, rejecting mode\n");
|
2013-04-19 17:24:33 +08:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2015-09-08 18:40:48 +08:00
|
|
|
/* Set user selected PAR to incoming mode's member */
|
2017-05-01 21:37:53 +08:00
|
|
|
adjusted_mode->picture_aspect_ratio = conn_state->picture_aspect_ratio;
|
2015-09-08 18:40:48 +08:00
|
|
|
|
2016-04-27 20:44:16 +08:00
|
|
|
pipe_config->lane_count = 4;
|
|
|
|
|
drm/i915: enable scrambling
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
in intel_enable_ddi() before enabling the port.
V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
so that the implementation could be close to the language of
HDMI spec.
V4: Addressed review comment from Maarten
- scrambling -> hdmi_scrambling
- high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
V5: Addressed review comments from Ville and Ander
- Do not modifiy the crtc_state after compute_config. Move all
scrambling and tmds_clock_ratio calcutations to compute_config.
- While setting scrambling for source/sink, do not check the
conditions again, just go by the crtc_state flags. This will
simplyfy the condition checks.
V6: Addressed review comments from Ville
- Do not add IS_GLK check in disable/enable function, instead add it
in compute_config, while setting state flags.
- Remove unnecessary paranthesis.
- Simplyfy handle_sink_scrambling function as suggested.
- Add readout code for scrambling status in get_ddi_config and add a
check for the same in pipe_config_compare.
V7: Addressed review comments from Ander/Ville
- No separate function for source scrambling, make it inline
- Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
- Do not add platform check while setting source scrambling
- Use pipe_config instead of crtc->config to set sink scrambling
- To readout scrambling status, Compare with SCRAMBLING_MASK
not any of its bits
- Remove platform check in intel_pipe_config_compare while checking
scrambling status
V8: Fixed mege conflict, Addressed review comments from Ander
- Remove the desciption/comment about scrambling fom the caller, move
it to the function
- Move the IS_GLK check into scrambling function
- Fix alignment
V9: Fixed review comments from Ville, Ander
- Pass the scrambling state variables as bool input to the sink_scrambling
function and let the disable call be unconditional.
- Fix alignments in function calls and debug messages.
- Add kernel doc for function intel_hdmi_handle_sink_scrambling
V10: Rebase
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-6-git-send-email-shashank.sharma@intel.com
2017-03-13 19:24:03 +08:00
|
|
|
if (scdc->scrambling.supported && IS_GEMINILAKE(dev_priv)) {
|
|
|
|
if (scdc->scrambling.low_rates)
|
|
|
|
pipe_config->hdmi_scrambling = true;
|
|
|
|
|
|
|
|
if (pipe_config->port_clock > 340000) {
|
|
|
|
pipe_config->hdmi_scrambling = true;
|
|
|
|
pipe_config->hdmi_high_tmds_clock_ratio = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-01-03 05:33:00 +08:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-09-03 03:04:01 +08:00
|
|
|
static void
|
|
|
|
intel_hdmi_unset_edid(struct drm_connector *connector)
|
2009-04-02 13:13:26 +08:00
|
|
|
{
|
2010-09-09 23:20:55 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
2009-04-02 13:13:26 +08:00
|
|
|
|
2014-09-03 03:04:01 +08:00
|
|
|
intel_hdmi->has_hdmi_sink = false;
|
|
|
|
intel_hdmi->has_audio = false;
|
|
|
|
intel_hdmi->rgb_quant_range_selectable = false;
|
|
|
|
|
2016-05-03 03:08:23 +08:00
|
|
|
intel_hdmi->dp_dual_mode.type = DRM_DP_DUAL_MODE_NONE;
|
|
|
|
intel_hdmi->dp_dual_mode.max_tmds_clock = 0;
|
|
|
|
|
2014-09-03 03:04:01 +08:00
|
|
|
kfree(to_intel_connector(connector)->detect_edid);
|
|
|
|
to_intel_connector(connector)->detect_edid = NULL;
|
|
|
|
}
|
|
|
|
|
2016-05-03 03:08:23 +08:00
|
|
|
static void
|
2016-05-04 19:45:22 +08:00
|
|
|
intel_hdmi_dp_dual_mode_detect(struct drm_connector *connector, bool has_edid)
|
2016-05-03 03:08:23 +08:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = to_i915(connector->dev);
|
|
|
|
struct intel_hdmi *hdmi = intel_attached_hdmi(connector);
|
2016-05-04 19:45:22 +08:00
|
|
|
enum port port = hdmi_to_dig_port(hdmi)->port;
|
2016-05-03 03:08:23 +08: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 19:45:22 +08: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 03:08:23 +08: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 03:04:01 +08:00
|
|
|
static bool
|
2016-08-17 20:47:48 +08:00
|
|
|
intel_hdmi_set_edid(struct drm_connector *connector)
|
2014-09-03 03:04:01 +08:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = to_i915(connector->dev);
|
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
2016-08-17 20:47:48 +08:00
|
|
|
struct edid *edid;
|
2014-09-03 03:04:01 +08:00
|
|
|
bool connected = false;
|
2013-07-21 03:27:08 +08:00
|
|
|
|
2016-08-17 20:47:48 +08:00
|
|
|
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
|
2014-03-05 22:20:53 +08:00
|
|
|
|
2016-08-17 20:47:48 +08: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 17:23:09 +08:00
|
|
|
|
2016-08-17 20:47:48 +08:00
|
|
|
intel_hdmi_dp_dual_mode_detect(connector, edid != NULL);
|
2016-05-03 03:08:23 +08:00
|
|
|
|
2016-08-17 20:47:48 +08:00
|
|
|
intel_display_power_put(dev_priv, POWER_DOMAIN_GMBUS);
|
2009-06-05 15:38:43 +08:00
|
|
|
|
2014-09-03 03:04:01 +08: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);
|
2017-05-01 21:38:02 +08:00
|
|
|
intel_hdmi->has_hdmi_sink = drm_detect_hdmi_monitor(edid);
|
2014-09-03 03:04:01 +08:00
|
|
|
|
|
|
|
connected = true;
|
2010-09-19 16:29:33 +08:00
|
|
|
}
|
|
|
|
|
2014-09-03 03:04:01 +08:00
|
|
|
return connected;
|
|
|
|
}
|
|
|
|
|
2015-10-09 03:50:57 +08:00
|
|
|
static enum drm_connector_status
|
|
|
|
intel_hdmi_detect(struct drm_connector *connector, bool force)
|
2014-09-03 03:04:01 +08:00
|
|
|
{
|
2015-10-09 03:50:57 +08:00
|
|
|
enum drm_connector_status status;
|
|
|
|
struct drm_i915_private *dev_priv = to_i915(connector->dev);
|
2014-09-03 03:04:01 +08:00
|
|
|
|
2015-10-09 03:50:57 +08:00
|
|
|
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
|
|
|
|
connector->base.id, connector->name);
|
|
|
|
|
2015-11-20 02:55:01 +08:00
|
|
|
intel_display_power_get(dev_priv, POWER_DOMAIN_GMBUS);
|
|
|
|
|
2015-10-09 03:50:57 +08: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 19:13:15 +08:00
|
|
|
|
2016-08-17 20:47:48 +08:00
|
|
|
if (intel_hdmi_set_edid(connector)) {
|
2014-09-03 03:04:01 +08: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 03:50:57 +08:00
|
|
|
} else
|
2014-09-03 03:04:01 +08:00
|
|
|
status = connector_status_disconnected;
|
2014-03-05 22:20:53 +08:00
|
|
|
|
2015-11-20 02:55:01 +08: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 17:23:09 +08:00
|
|
|
return status;
|
2009-01-03 05:33:00 +08:00
|
|
|
}
|
|
|
|
|
2014-09-03 03:04:01 +08:00
|
|
|
static void
|
|
|
|
intel_hdmi_force(struct drm_connector *connector)
|
2009-01-03 05:33:00 +08:00
|
|
|
{
|
2014-09-03 03:04:01 +08:00
|
|
|
struct intel_hdmi *intel_hdmi = intel_attached_hdmi(connector);
|
2009-01-03 05:33:00 +08:00
|
|
|
|
2014-09-03 03:04:01 +08:00
|
|
|
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
|
|
|
|
connector->base.id, connector->name);
|
2009-01-03 05:33:00 +08:00
|
|
|
|
2014-09-03 03:04:01 +08:00
|
|
|
intel_hdmi_unset_edid(connector);
|
2014-03-05 22:20:53 +08:00
|
|
|
|
2014-09-03 03:04:01 +08:00
|
|
|
if (connector->status != connector_status_connected)
|
|
|
|
return;
|
2014-03-05 22:20:53 +08:00
|
|
|
|
2016-08-17 20:47:48 +08:00
|
|
|
intel_hdmi_set_edid(connector);
|
2014-09-03 03:04:01 +08:00
|
|
|
hdmi_to_dig_port(intel_hdmi)->base.type = INTEL_OUTPUT_HDMI;
|
|
|
|
}
|
2014-03-05 22:20:53 +08:00
|
|
|
|
2014-09-03 03:04:01 +08: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 22:20:53 +08:00
|
|
|
|
2014-09-03 03:04:01 +08:00
|
|
|
return intel_connector_update_modes(connector, edid);
|
2009-01-03 05:33:00 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void intel_hdmi_pre_enable(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2014-04-06 02:51:35 +08:00
|
|
|
{
|
2017-08-18 21:49:54 +08:00
|
|
|
struct intel_digital_port *intel_dig_port =
|
|
|
|
enc_to_dig_port(&encoder->base);
|
2014-04-06 02:51:35 +08:00
|
|
|
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_hdmi_prepare(encoder, pipe_config);
|
2014-04-25 05:54:56 +08:00
|
|
|
|
2017-08-18 21:49:54 +08:00
|
|
|
intel_dig_port->set_infoframes(&encoder->base,
|
|
|
|
pipe_config->has_infoframe,
|
|
|
|
pipe_config, conn_state);
|
2014-04-06 02:51:35 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void vlv_hdmi_pre_enable(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2013-04-19 05:51:36 +08:00
|
|
|
{
|
|
|
|
struct intel_digital_port *dport = enc_to_dig_port(&encoder->base);
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-04-27 20:44:24 +08:00
|
|
|
|
|
|
|
vlv_phy_pre_encoder_enable(encoder);
|
2013-07-30 17:20:31 +08:00
|
|
|
|
2016-04-27 20:44:22 +08:00
|
|
|
/* HDMI 1.0V-2dB */
|
|
|
|
vlv_set_phy_signal_level(encoder, 0x2b245f5f, 0x00002000, 0x5578b83a,
|
|
|
|
0x2b247878);
|
|
|
|
|
2017-08-18 21:49:54 +08:00
|
|
|
dport->set_infoframes(&encoder->base,
|
|
|
|
pipe_config->has_infoframe,
|
|
|
|
pipe_config, conn_state);
|
2014-04-06 02:51:35 +08:00
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
g4x_enable_hdmi(encoder, pipe_config, conn_state);
|
2013-07-30 17:20:31 +08:00
|
|
|
|
2015-04-10 23:21:31 +08:00
|
|
|
vlv_wait_port_ready(dev_priv, dport, 0x0);
|
2013-04-19 05:51:36 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void vlv_hdmi_pre_pll_enable(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2013-04-19 05:51:36 +08:00
|
|
|
{
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_hdmi_prepare(encoder, pipe_config);
|
2014-04-25 05:54:56 +08:00
|
|
|
|
2016-04-27 20:44:23 +08:00
|
|
|
vlv_phy_pre_pll_enable(encoder);
|
2013-04-19 05:51:36 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void chv_hdmi_pre_pll_enable(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2014-04-09 18:29:05 +08:00
|
|
|
{
|
2016-11-23 22:57:00 +08:00
|
|
|
intel_hdmi_prepare(encoder, pipe_config);
|
2014-06-28 07:04:02 +08:00
|
|
|
|
2016-04-27 20:44:19 +08:00
|
|
|
chv_phy_pre_pll_enable(encoder);
|
2014-04-09 18:29:05 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void chv_hdmi_post_pll_disable(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *old_crtc_state,
|
|
|
|
const struct drm_connector_state *old_conn_state)
|
2015-07-09 04:45:49 +08:00
|
|
|
{
|
2016-04-27 20:44:21 +08:00
|
|
|
chv_phy_post_pll_disable(encoder);
|
2015-07-09 04:45:49 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void vlv_hdmi_post_disable(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *old_crtc_state,
|
|
|
|
const struct drm_connector_state *old_conn_state)
|
2013-04-19 05:51:36 +08:00
|
|
|
{
|
|
|
|
/* Reset lanes to avoid HDMI flicker (VLV w/a) */
|
2016-04-27 20:44:25 +08:00
|
|
|
vlv_phy_reset_lanes(encoder);
|
2013-04-19 05:51:36 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void chv_hdmi_post_disable(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *old_crtc_state,
|
|
|
|
const struct drm_connector_state *old_conn_state)
|
2014-04-09 18:29:00 +08:00
|
|
|
{
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2014-04-09 18:29:00 +08:00
|
|
|
|
2015-05-27 01:42:30 +08:00
|
|
|
mutex_lock(&dev_priv->sb_lock);
|
2014-04-09 18:29:00 +08:00
|
|
|
|
2015-07-10 01:14:11 +08:00
|
|
|
/* Assert data lane reset */
|
|
|
|
chv_data_lane_soft_reset(encoder, true);
|
2014-04-09 18:29:00 +08:00
|
|
|
|
2015-05-27 01:42:30 +08:00
|
|
|
mutex_unlock(&dev_priv->sb_lock);
|
2014-04-09 18:29:00 +08:00
|
|
|
}
|
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
static void chv_hdmi_pre_enable(struct intel_encoder *encoder,
|
2017-08-18 21:49:58 +08:00
|
|
|
const struct intel_crtc_state *pipe_config,
|
|
|
|
const struct drm_connector_state *conn_state)
|
2014-04-09 18:28:20 +08:00
|
|
|
{
|
|
|
|
struct intel_digital_port *dport = enc_to_dig_port(&encoder->base);
|
|
|
|
struct drm_device *dev = encoder->base.dev;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2015-04-10 23:21:27 +08:00
|
|
|
|
2016-04-27 20:44:20 +08:00
|
|
|
chv_phy_pre_encoder_enable(encoder);
|
2014-08-18 19:42:45 +08:00
|
|
|
|
2014-04-09 18:28:20 +08:00
|
|
|
/* FIXME: Program the support xxx V-dB */
|
|
|
|
/* Use 800mV-0dB */
|
2016-04-27 20:44:17 +08:00
|
|
|
chv_set_phy_signal_level(encoder, 128, 102, false);
|
2014-04-09 18:28:20 +08:00
|
|
|
|
2017-08-18 21:49:54 +08:00
|
|
|
dport->set_infoframes(&encoder->base,
|
|
|
|
pipe_config->has_infoframe,
|
|
|
|
pipe_config, conn_state);
|
2014-11-22 03:13:02 +08:00
|
|
|
|
2016-08-09 23:04:04 +08:00
|
|
|
g4x_enable_hdmi(encoder, pipe_config, conn_state);
|
2014-04-09 18:28:20 +08:00
|
|
|
|
2015-04-10 23:21:31 +08: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 04:45:55 +08:00
|
|
|
|
|
|
|
/* Second common lane will stay alive on its own now */
|
2016-04-27 20:44:20 +08:00
|
|
|
chv_phy_release_cl2_override(encoder);
|
2014-04-09 18:28:20 +08:00
|
|
|
}
|
|
|
|
|
2009-01-03 05:33:00 +08:00
|
|
|
static void intel_hdmi_destroy(struct drm_connector *connector)
|
|
|
|
{
|
2014-09-05 04:43:45 +08:00
|
|
|
kfree(to_intel_connector(connector)->detect_edid);
|
2009-01-03 05:33:00 +08:00
|
|
|
drm_connector_cleanup(connector);
|
2010-03-29 15:57:42 +08:00
|
|
|
kfree(connector);
|
2009-01-03 05:33:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct drm_connector_funcs intel_hdmi_connector_funcs = {
|
|
|
|
.detect = intel_hdmi_detect,
|
2014-09-03 03:04:01 +08:00
|
|
|
.force = intel_hdmi_force,
|
2009-01-03 05:33:00 +08:00
|
|
|
.fill_modes = drm_helper_probe_single_connector_modes,
|
2017-05-01 21:38:02 +08:00
|
|
|
.atomic_get_property = intel_digital_connector_atomic_get_property,
|
|
|
|
.atomic_set_property = intel_digital_connector_atomic_set_property,
|
2016-06-24 21:00:15 +08:00
|
|
|
.late_register = intel_connector_register,
|
2016-06-17 18:40:33 +08:00
|
|
|
.early_unregister = intel_connector_unregister,
|
2009-01-03 05:33:00 +08:00
|
|
|
.destroy = intel_hdmi_destroy,
|
2015-01-23 08:50:32 +08:00
|
|
|
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
|
2017-05-01 21:38:02 +08:00
|
|
|
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
|
2009-01-03 05:33:00 +08: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,
|
2017-05-01 21:38:02 +08:00
|
|
|
.atomic_check = intel_digital_connector_atomic_check,
|
2009-01-03 05:33:00 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static const struct drm_encoder_funcs intel_hdmi_enc_funcs = {
|
2010-08-04 20:50:23 +08:00
|
|
|
.destroy = intel_encoder_destroy,
|
2009-01-03 05:33:00 +08:00
|
|
|
};
|
|
|
|
|
2010-09-19 16:29:33 +08:00
|
|
|
static void
|
|
|
|
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector *connector)
|
|
|
|
{
|
2011-05-13 05:17:24 +08:00
|
|
|
intel_attach_force_audio_property(connector);
|
2011-02-22 06:23:52 +08:00
|
|
|
intel_attach_broadcast_rgb_property(connector);
|
2014-06-11 13:36:01 +08:00
|
|
|
intel_attach_aspect_ratio_property(connector);
|
2017-05-01 21:37:53 +08:00
|
|
|
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_NONE;
|
2010-09-19 16:29:33 +08:00
|
|
|
}
|
|
|
|
|
drm/i915: enable scrambling
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendates scrambling for these higher clocks, for reduced RF footprint.
This patch checks if the monitor supports scrambling, and if required,
enables it during the modeset.
V2: Addressed review comments from Ville:
- Do not track scrambling status in DRM layer, track somewhere in
driver like in intel_crtc_state.
- Don't talk to monitor at such a low layer, set monitor scrambling
in intel_enable_ddi() before enabling the port.
V3: Addressed review comments from Jani
- In comments, function names, use "sink" instead of "monitor",
so that the implementation could be close to the language of
HDMI spec.
V4: Addressed review comment from Maarten
- scrambling -> hdmi_scrambling
- high_tmds_clock_ratio -> hdmi_high_tmds_clock_ratio
V5: Addressed review comments from Ville and Ander
- Do not modifiy the crtc_state after compute_config. Move all
scrambling and tmds_clock_ratio calcutations to compute_config.
- While setting scrambling for source/sink, do not check the
conditions again, just go by the crtc_state flags. This will
simplyfy the condition checks.
V6: Addressed review comments from Ville
- Do not add IS_GLK check in disable/enable function, instead add it
in compute_config, while setting state flags.
- Remove unnecessary paranthesis.
- Simplyfy handle_sink_scrambling function as suggested.
- Add readout code for scrambling status in get_ddi_config and add a
check for the same in pipe_config_compare.
V7: Addressed review comments from Ander/Ville
- No separate function for source scrambling, make it inline
- Align the last line of the macro TRANS_DDI_HDMI_SCRAMBLING_MASK
- Do not add platform check while setting source scrambling
- Use pipe_config instead of crtc->config to set sink scrambling
- To readout scrambling status, Compare with SCRAMBLING_MASK
not any of its bits
- Remove platform check in intel_pipe_config_compare while checking
scrambling status
V8: Fixed mege conflict, Addressed review comments from Ander
- Remove the desciption/comment about scrambling fom the caller, move
it to the function
- Move the IS_GLK check into scrambling function
- Fix alignment
V9: Fixed review comments from Ville, Ander
- Pass the scrambling state variables as bool input to the sink_scrambling
function and let the disable call be unconditional.
- Fix alignments in function calls and debug messages.
- Add kernel doc for function intel_hdmi_handle_sink_scrambling
V10: Rebase
Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1489404244-16608-6-git-send-email-shashank.sharma@intel.com
2017-03-13 19:24:03 +08:00
|
|
|
/*
|
|
|
|
* intel_hdmi_handle_sink_scrambling: handle sink scrambling/clock ratio setup
|
|
|
|
* @encoder: intel_encoder
|
|
|
|
* @connector: drm_connector
|
|
|
|
* @high_tmds_clock_ratio = bool to indicate if the function needs to set
|
|
|
|
* or reset the high tmds clock ratio for scrambling
|
|
|
|
* @scrambling: bool to Indicate if the function needs to set or reset
|
|
|
|
* sink scrambling
|
|
|
|
*
|
|
|
|
* This function handles scrambling on HDMI 2.0 capable sinks.
|
|
|
|
* If required clock rate is > 340 Mhz && scrambling is supported by sink
|
|
|
|
* it enables scrambling. This should be called before enabling the HDMI
|
|
|
|
* 2.0 port, as the sink can choose to disable the scrambling if it doesn't
|
|
|
|
* detect a scrambled clock within 100 ms.
|
|
|
|
*/
|
|
|
|
void intel_hdmi_handle_sink_scrambling(struct intel_encoder *encoder,
|
|
|
|
struct drm_connector *connector,
|
|
|
|
bool high_tmds_clock_ratio,
|
|
|
|
bool scrambling)
|
|
|
|
{
|
|
|
|
struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(&encoder->base);
|
|
|
|
struct drm_i915_private *dev_priv = connector->dev->dev_private;
|
|
|
|
struct drm_scrambling *sink_scrambling =
|
|
|
|
&connector->display_info.hdmi.scdc.scrambling;
|
|
|
|
struct i2c_adapter *adptr = intel_gmbus_get_adapter(dev_priv,
|
|
|
|
intel_hdmi->ddc_bus);
|
|
|
|
bool ret;
|
|
|
|
|
|
|
|
if (!sink_scrambling->supported)
|
|
|
|
return;
|
|
|
|
|
|
|
|
DRM_DEBUG_KMS("Setting sink scrambling for enc:%s connector:%s\n",
|
|
|
|
encoder->base.name, connector->name);
|
|
|
|
|
|
|
|
/* Set TMDS bit clock ratio to 1/40 or 1/10 */
|
|
|
|
ret = drm_scdc_set_high_tmds_clock_ratio(adptr, high_tmds_clock_ratio);
|
|
|
|
if (!ret) {
|
|
|
|
DRM_ERROR("Set TMDS ratio failed\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Enable/disable sink scrambling */
|
|
|
|
ret = drm_scdc_set_scrambling(adptr, scrambling);
|
|
|
|
if (!ret) {
|
|
|
|
DRM_ERROR("Set sink scrambling failed\n");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
DRM_DEBUG_KMS("sink scrambling handled\n");
|
|
|
|
}
|
|
|
|
|
2017-08-17 07:45:14 +08:00
|
|
|
static u8 chv_port_to_ddc_pin(struct drm_i915_private *dev_priv, enum port port)
|
2016-10-12 01:52:46 +08:00
|
|
|
{
|
|
|
|
u8 ddc_pin;
|
|
|
|
|
2017-08-17 07:45:14 +08:00
|
|
|
switch (port) {
|
|
|
|
case PORT_B:
|
|
|
|
ddc_pin = GMBUS_PIN_DPB;
|
|
|
|
break;
|
|
|
|
case PORT_C:
|
|
|
|
ddc_pin = GMBUS_PIN_DPC;
|
|
|
|
break;
|
|
|
|
case PORT_D:
|
|
|
|
ddc_pin = GMBUS_PIN_DPD_CHV;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
MISSING_CASE(port);
|
|
|
|
ddc_pin = GMBUS_PIN_DPB;
|
|
|
|
break;
|
2016-10-12 01:52:46 +08:00
|
|
|
}
|
2017-08-17 07:45:14 +08:00
|
|
|
return ddc_pin;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u8 bxt_port_to_ddc_pin(struct drm_i915_private *dev_priv, enum port port)
|
|
|
|
{
|
|
|
|
u8 ddc_pin;
|
2016-10-12 01:52:46 +08:00
|
|
|
|
|
|
|
switch (port) {
|
|
|
|
case PORT_B:
|
2017-08-17 07:45:14 +08:00
|
|
|
ddc_pin = GMBUS_PIN_1_BXT;
|
2016-10-12 01:52:46 +08:00
|
|
|
break;
|
|
|
|
case PORT_C:
|
2017-08-17 07:45:14 +08:00
|
|
|
ddc_pin = GMBUS_PIN_2_BXT;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
MISSING_CASE(port);
|
|
|
|
ddc_pin = GMBUS_PIN_1_BXT;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return ddc_pin;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u8 cnp_port_to_ddc_pin(struct drm_i915_private *dev_priv,
|
|
|
|
enum port port)
|
|
|
|
{
|
|
|
|
u8 ddc_pin;
|
|
|
|
|
|
|
|
switch (port) {
|
|
|
|
case PORT_B:
|
|
|
|
ddc_pin = GMBUS_PIN_1_BXT;
|
|
|
|
break;
|
|
|
|
case PORT_C:
|
|
|
|
ddc_pin = GMBUS_PIN_2_BXT;
|
2016-10-12 01:52:46 +08:00
|
|
|
break;
|
|
|
|
case PORT_D:
|
2017-08-17 07:45:14 +08:00
|
|
|
ddc_pin = GMBUS_PIN_4_CNP;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
MISSING_CASE(port);
|
|
|
|
ddc_pin = GMBUS_PIN_1_BXT;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return ddc_pin;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u8 g4x_port_to_ddc_pin(struct drm_i915_private *dev_priv,
|
|
|
|
enum port port)
|
|
|
|
{
|
|
|
|
u8 ddc_pin;
|
|
|
|
|
|
|
|
switch (port) {
|
|
|
|
case PORT_B:
|
|
|
|
ddc_pin = GMBUS_PIN_DPB;
|
|
|
|
break;
|
|
|
|
case PORT_C:
|
|
|
|
ddc_pin = GMBUS_PIN_DPC;
|
|
|
|
break;
|
|
|
|
case PORT_D:
|
|
|
|
ddc_pin = GMBUS_PIN_DPD;
|
2016-10-12 01:52:46 +08:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
MISSING_CASE(port);
|
|
|
|
ddc_pin = GMBUS_PIN_DPB;
|
|
|
|
break;
|
|
|
|
}
|
2017-08-17 07:45:14 +08:00
|
|
|
return ddc_pin;
|
|
|
|
}
|
|
|
|
|
|
|
|
static u8 intel_hdmi_ddc_pin(struct drm_i915_private *dev_priv,
|
|
|
|
enum port port)
|
|
|
|
{
|
|
|
|
const struct ddi_vbt_port_info *info =
|
|
|
|
&dev_priv->vbt.ddi_port_info[port];
|
|
|
|
u8 ddc_pin;
|
|
|
|
|
|
|
|
if (info->alternate_ddc_pin) {
|
|
|
|
DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (VBT)\n",
|
|
|
|
info->alternate_ddc_pin, port_name(port));
|
|
|
|
return info->alternate_ddc_pin;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (IS_CHERRYVIEW(dev_priv))
|
|
|
|
ddc_pin = chv_port_to_ddc_pin(dev_priv, port);
|
|
|
|
else if (IS_GEN9_LP(dev_priv))
|
|
|
|
ddc_pin = bxt_port_to_ddc_pin(dev_priv, port);
|
|
|
|
else if (HAS_PCH_CNP(dev_priv))
|
|
|
|
ddc_pin = cnp_port_to_ddc_pin(dev_priv, port);
|
|
|
|
else
|
|
|
|
ddc_pin = g4x_port_to_ddc_pin(dev_priv, port);
|
2016-10-12 01:52:46 +08:00
|
|
|
|
|
|
|
DRM_DEBUG_KMS("Using DDC pin 0x%x for port %c (platform default)\n",
|
|
|
|
ddc_pin, port_name(port));
|
|
|
|
|
|
|
|
return ddc_pin;
|
|
|
|
}
|
|
|
|
|
2017-08-18 21:49:55 +08:00
|
|
|
void intel_infoframe_init(struct intel_digital_port *intel_dig_port)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv =
|
|
|
|
to_i915(intel_dig_port->base.base.dev);
|
|
|
|
|
|
|
|
if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)) {
|
|
|
|
intel_dig_port->write_infoframe = vlv_write_infoframe;
|
|
|
|
intel_dig_port->set_infoframes = vlv_set_infoframes;
|
|
|
|
intel_dig_port->infoframe_enabled = vlv_infoframe_enabled;
|
|
|
|
} else if (IS_G4X(dev_priv)) {
|
|
|
|
intel_dig_port->write_infoframe = g4x_write_infoframe;
|
|
|
|
intel_dig_port->set_infoframes = g4x_set_infoframes;
|
|
|
|
intel_dig_port->infoframe_enabled = g4x_infoframe_enabled;
|
|
|
|
} else if (HAS_DDI(dev_priv)) {
|
|
|
|
intel_dig_port->write_infoframe = hsw_write_infoframe;
|
|
|
|
intel_dig_port->set_infoframes = hsw_set_infoframes;
|
|
|
|
intel_dig_port->infoframe_enabled = hsw_infoframe_enabled;
|
|
|
|
} else if (HAS_PCH_IBX(dev_priv)) {
|
|
|
|
intel_dig_port->write_infoframe = ibx_write_infoframe;
|
|
|
|
intel_dig_port->set_infoframes = ibx_set_infoframes;
|
|
|
|
intel_dig_port->infoframe_enabled = ibx_infoframe_enabled;
|
|
|
|
} else {
|
|
|
|
intel_dig_port->write_infoframe = cpt_write_infoframe;
|
|
|
|
intel_dig_port->set_infoframes = cpt_set_infoframes;
|
|
|
|
intel_dig_port->infoframe_enabled = cpt_infoframe_enabled;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-10-27 05:05:52 +08:00
|
|
|
void intel_hdmi_init_connector(struct intel_digital_port *intel_dig_port,
|
|
|
|
struct intel_connector *intel_connector)
|
2009-01-03 05:33:00 +08:00
|
|
|
{
|
2012-10-27 05:05:47 +08: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;
|
2016-07-04 18:34:36 +08:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2012-10-27 05:05:50 +08:00
|
|
|
enum port port = intel_dig_port->port;
|
2010-09-15 19:03:59 +08:00
|
|
|
|
2016-06-03 17:17:43 +08:00
|
|
|
DRM_DEBUG_KMS("Adding HDMI connector on port %c\n",
|
|
|
|
port_name(port));
|
|
|
|
|
2015-12-09 01:59:38 +08: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 05:33:00 +08:00
|
|
|
drm_connector_init(dev, connector, &intel_hdmi_connector_funcs,
|
2009-09-24 03:08:29 +08:00
|
|
|
DRM_MODE_CONNECTOR_HDMIA);
|
2009-01-03 05:33:00 +08:00
|
|
|
drm_connector_helper_add(connector, &intel_hdmi_connector_helper_funcs);
|
|
|
|
|
2012-01-28 21:49:26 +08:00
|
|
|
connector->interlace_allowed = 1;
|
2009-01-03 05:33:00 +08:00
|
|
|
connector->doublescan_allowed = 0;
|
2013-09-25 23:45:40 +08:00
|
|
|
connector->stereo_allowed = 1;
|
2012-07-13 02:08:18 +08:00
|
|
|
|
2017-07-21 23:25:09 +08:00
|
|
|
if (IS_GEMINILAKE(dev_priv))
|
|
|
|
connector->ycbcr_420_allowed = true;
|
|
|
|
|
2016-10-12 01:52:46 +08:00
|
|
|
intel_hdmi->ddc_bus = intel_hdmi_ddc_pin(dev_priv, port);
|
|
|
|
|
2017-08-12 02:26:50 +08:00
|
|
|
if (WARN_ON(port == PORT_A))
|
2016-10-12 01:52:46 +08:00
|
|
|
return;
|
2017-08-12 02:26:50 +08:00
|
|
|
intel_encoder->hpd_pin = intel_hpd_pin(port);
|
2009-01-03 05:33:00 +08:00
|
|
|
|
2016-10-13 18:02:52 +08:00
|
|
|
if (HAS_DDI(dev_priv))
|
2012-10-27 05:05:51 +08: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 05:05:47 +08:00
|
|
|
|
|
|
|
intel_hdmi_add_properties(intel_hdmi, connector);
|
|
|
|
|
|
|
|
intel_connector_attach_encoder(intel_connector, intel_encoder);
|
2015-09-04 21:26:11 +08:00
|
|
|
intel_hdmi->attached_connector = intel_connector;
|
2012-10-27 05:05:47 +08: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.
|
|
|
|
*/
|
2016-10-13 18:02:58 +08:00
|
|
|
if (IS_G4X(dev_priv) && !IS_GM45(dev_priv)) {
|
2012-10-27 05:05:47 +08:00
|
|
|
u32 temp = I915_READ(PEG_BAND_GAP_DATA);
|
|
|
|
I915_WRITE(PEG_BAND_GAP_DATA, (temp & ~0xf) | 0xd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-11-23 22:21:44 +08:00
|
|
|
void intel_hdmi_init(struct drm_i915_private *dev_priv,
|
drm/i915: Type safe register read/write
Make I915_READ and I915_WRITE more type safe by wrapping the register
offset in a struct. This should eliminate most of the fumbles we've had
with misplaced parens.
This only takes care of normal mmio registers. We could extend the idea
to other register types and define each with its own struct. That way
you wouldn't be able to accidentally pass the wrong thing to a specific
register access function.
The gpio_reg setup is probably the ugliest thing left. But I figure I'd
just leave it for now, and wait for some divine inspiration to strike
before making it nice.
As for the generated code, it's actually a bit better sometimes. Eg.
looking at i915_irq_handler(), we can see the following change:
lea 0x70024(%rdx,%rax,1),%r9d
mov $0x1,%edx
- movslq %r9d,%r9
- mov %r9,%rsi
- mov %r9,-0x58(%rbp)
- callq *0xd8(%rbx)
+ mov %r9d,%esi
+ mov %r9d,-0x48(%rbp)
callq *0xd8(%rbx)
So previously gcc thought the register offset might be signed and
decided to sign extend it, just in case. The rest appears to be
mostly just minor shuffling of instructions.
v2: i915_mmio_reg_{offset,equal,valid}() helpers added
s/_REG/_MMIO/ in the register defines
mo more switch statements left to worry about
ring_emit stuff got sorted in a prep patch
cmd parser, lrc context and w/a batch buildup also in prep patch
vgpu stuff cleaned up and moved to a prep patch
all other unrelated changes split out
v3: Rebased due to BXT DSI/BLC, MOCS, etc.
v4: Rebased due to churn, s/i915_mmio_reg_t/i915_reg_t/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
2015-11-18 21:33:26 +08:00
|
|
|
i915_reg_t hdmi_reg, enum port port)
|
2012-10-27 05:05:47 +08:00
|
|
|
{
|
|
|
|
struct intel_digital_port *intel_dig_port;
|
|
|
|
struct intel_encoder *intel_encoder;
|
|
|
|
struct intel_connector *intel_connector;
|
|
|
|
|
2013-09-19 18:18:32 +08:00
|
|
|
intel_dig_port = kzalloc(sizeof(*intel_dig_port), GFP_KERNEL);
|
2012-10-27 05:05:47 +08:00
|
|
|
if (!intel_dig_port)
|
|
|
|
return;
|
|
|
|
|
2015-04-10 15:59:10 +08:00
|
|
|
intel_connector = intel_connector_alloc();
|
2012-10-27 05:05:47 +08:00
|
|
|
if (!intel_connector) {
|
|
|
|
kfree(intel_dig_port);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
intel_encoder = &intel_dig_port->base;
|
|
|
|
|
2016-11-23 22:21:44 +08:00
|
|
|
drm_encoder_init(&dev_priv->drm, &intel_encoder->base,
|
|
|
|
&intel_hdmi_enc_funcs, DRM_MODE_ENCODER_TMDS,
|
|
|
|
"HDMI %c", port_name(port));
|
2012-10-27 05:05:52 +08:00
|
|
|
|
2013-03-27 07:44:55 +08:00
|
|
|
intel_encoder->compute_config = intel_hdmi_compute_config;
|
2016-10-13 18:02:53 +08:00
|
|
|
if (HAS_PCH_SPLIT(dev_priv)) {
|
2015-05-05 22:17:35 +08:00
|
|
|
intel_encoder->disable = pch_disable_hdmi;
|
|
|
|
intel_encoder->post_disable = pch_post_disable_hdmi;
|
|
|
|
} else {
|
|
|
|
intel_encoder->disable = g4x_disable_hdmi;
|
|
|
|
}
|
2012-10-27 05:05:52 +08:00
|
|
|
intel_encoder->get_hw_state = intel_hdmi_get_hw_state;
|
2013-05-15 08:08:26 +08:00
|
|
|
intel_encoder->get_config = intel_hdmi_get_config;
|
2016-10-14 17:13:44 +08:00
|
|
|
if (IS_CHERRYVIEW(dev_priv)) {
|
2014-04-09 18:29:05 +08:00
|
|
|
intel_encoder->pre_pll_enable = chv_hdmi_pre_pll_enable;
|
2014-04-09 18:28:20 +08:00
|
|
|
intel_encoder->pre_enable = chv_hdmi_pre_enable;
|
|
|
|
intel_encoder->enable = vlv_enable_hdmi;
|
2014-04-09 18:29:00 +08:00
|
|
|
intel_encoder->post_disable = chv_hdmi_post_disable;
|
2015-07-09 04:45:49 +08:00
|
|
|
intel_encoder->post_pll_disable = chv_hdmi_post_pll_disable;
|
2016-10-13 18:03:08 +08:00
|
|
|
} else if (IS_VALLEYVIEW(dev_priv)) {
|
2013-10-16 17:07:41 +08:00
|
|
|
intel_encoder->pre_pll_enable = vlv_hdmi_pre_pll_enable;
|
|
|
|
intel_encoder->pre_enable = vlv_hdmi_pre_enable;
|
2013-07-30 17:20:31 +08:00
|
|
|
intel_encoder->enable = vlv_enable_hdmi;
|
2013-10-16 17:07:41 +08:00
|
|
|
intel_encoder->post_disable = vlv_hdmi_post_disable;
|
2013-07-30 17:20:31 +08:00
|
|
|
} else {
|
2014-04-06 02:51:35 +08:00
|
|
|
intel_encoder->pre_enable = intel_hdmi_pre_enable;
|
2016-10-13 18:02:53 +08:00
|
|
|
if (HAS_PCH_CPT(dev_priv))
|
2015-05-05 22:06:19 +08:00
|
|
|
intel_encoder->enable = cpt_enable_hdmi;
|
2016-10-13 18:02:53 +08:00
|
|
|
else if (HAS_PCH_IBX(dev_priv))
|
2015-05-05 22:06:23 +08:00
|
|
|
intel_encoder->enable = ibx_enable_hdmi;
|
2015-05-05 22:06:19 +08:00
|
|
|
else
|
2015-05-05 22:06:23 +08:00
|
|
|
intel_encoder->enable = g4x_enable_hdmi;
|
2013-04-19 05:51:36 +08:00
|
|
|
}
|
2012-06-30 14:59:56 +08:00
|
|
|
|
2012-10-27 05:05:47 +08:00
|
|
|
intel_encoder->type = INTEL_OUTPUT_HDMI;
|
2017-02-22 14:34:27 +08:00
|
|
|
intel_encoder->power_domain = intel_port_to_power_domain(port);
|
2016-09-20 09:24:38 +08:00
|
|
|
intel_encoder->port = port;
|
2016-10-14 17:13:44 +08:00
|
|
|
if (IS_CHERRYVIEW(dev_priv)) {
|
2014-04-28 19:07:43 +08:00
|
|
|
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 22:15:30 +08:00
|
|
|
intel_encoder->cloneable = 1 << INTEL_OUTPUT_ANALOG;
|
2014-03-03 22:15:31 +08: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.
|
|
|
|
*/
|
2016-10-13 18:03:06 +08:00
|
|
|
if (IS_G4X(dev_priv))
|
2014-03-03 22:15:31 +08:00
|
|
|
intel_encoder->cloneable |= 1 << INTEL_OUTPUT_HDMI;
|
2009-01-03 05:33:00 +08:00
|
|
|
|
2012-10-27 05:05:50 +08:00
|
|
|
intel_dig_port->port = port;
|
2013-02-19 06:00:26 +08: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 21:33:26 +08:00
|
|
|
intel_dig_port->dp.output_reg = INVALID_MMIO_REG;
|
2015-12-09 01:59:38 +08:00
|
|
|
intel_dig_port->max_lanes = 4;
|
2010-09-19 16:29:33 +08:00
|
|
|
|
2017-08-18 21:49:55 +08:00
|
|
|
intel_infoframe_init(intel_dig_port);
|
|
|
|
|
2012-10-27 05:05:47 +08:00
|
|
|
intel_hdmi_init_connector(intel_dig_port, intel_connector);
|
2009-01-03 05:33:00 +08:00
|
|
|
}
|