So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
index = 3, one of which has been kindly provided to me by Jan Brummer,
where not working with the i915 driver, giving a black screen on the
first modeset.
The problem with at least these Dells is that their VBT defines a MIPI
ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
reset in their INIT_OTP sequence, but the deassert must be done before
calling intel_dsi_device_ready(), so that is too late.
Simply doing the INIT_OTP sequence earlier is not enough to fix this,
because the INIT_OTP sequence also sends various MIPI packets to the
panel, which can only happen after calling intel_dsi_device_ready().
This commit fixes this by splitting the INIT_OTP sequence into everything
before the first DSI packet and everything else, including the first DSI
packet. The first part (everything before the first DSI packet) is then
used as deassert sequence.
Changed in v2:
-Split the init OTP sequence into a deassert reset and the actual init
OTP sequence, instead of calling it earlier and then having the first
mipi_exec_send_packet() call call intel_dsi_device_ready().
Changes in v3:
-Move the whole shebang to intel_bios.c
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82880
References: https://bugs.freedesktop.org/show_bug.cgi?id=101205
Cc: Jan-Michael Brummer <jan.brummer@tabos.org>
Reported-by: Jan-Michael Brummer <jan.brummer@tabos.org>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214082151.25015-3-hdegoede@redhat.com
(cherry picked from commit fb38e7ade9)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
colors, showing that the panel controller is starting with sampling the
datastream somewhere mid-line. This happens after the first blanking and
re-init of the panel.
After looking at drm.debug output I noticed that initially we inherit the
cdclk of 333333 KHz set by the GOP, but after the re-init we picked 266667
KHz, which turns out to be the cause of this problem, a quick hack to hard
code the cdclk to 333333 KHz makes the problem go away.
I've tested this on various Bay Trail devices, to make sure this not does
cause regressions on other devices and the higher cdclk does not cause
any problems on the following devices:
-GP-electronic T701 1024x600 333333 KHz cdclk after this patch
-PEAQ C1010 1920x1200 333333 KHz cdclk after this patch
-PoV mobii-wintab-800w 800x1280 333333 KHz cdclk after this patch
-Asus Transformer-T100TA 1368x768 320000 KHz cdclk after this patch
Also interesting wrt this is the comment in vlv_calc_cdclk about the
existing workaround to avoid 200 Mhz as clock because that causes issues
in some cases.
This commit extends the "do not use 200 Mhz" workaround with an extra
check to require atleast 320000 KHz (avoiding 266667 KHz) when a DSI
panel is active.
Changes in v2:
-Change the commit message and the code comment to not treat the GOP as
a reference, the GOP should not be treated as a reference
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171220105017.11259-1-hdegoede@redhat.com
(cherry picked from commit c8dae55a8c)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drivers/gpu/drm/i915/intel_display.c:569: warning: Function parameter or member 'dev_priv' not described in 'intel_PLL_is_valid'
drivers/gpu/drm/i915/intel_display.c:569: warning: Function parameter or member 'limit' not described in 'intel_PLL_is_valid'
drivers/gpu/drm/i915/intel_display.c:569: warning: Function parameter or member 'clock' not described in 'intel_PLL_is_valid'
drivers/gpu/drm/i915/intel_display.c:4769: warning: Function parameter or member 'crtc_state' not described in 'skl_update_scaler_plane'
drivers/gpu/drm/i915/intel_display.c:4769: warning: Excess function parameter 'state' description in 'skl_update_scaler_plane'
drivers/gpu/drm/i915/intel_display.c:4967: warning: Function parameter or member 'new_crtc_state' not described in 'intel_post_enable_primary'
drivers/gpu/drm/i915/intel_display.c:12650: warning: Function parameter or member 'new_state' not described in 'intel_prepare_plane_fb'
drivers/gpu/drm/i915/intel_display.c:12650: warning: Excess function parameter 'fb' description in 'intel_prepare_plane_fb'
drivers/gpu/drm/i915/intel_display.c:12763: warning: Function parameter or member 'old_state' not described in 'intel_cleanup_plane_fb'
drivers/gpu/drm/i915/intel_display.c:12763: warning: Excess function parameter 'fb' description in 'intel_cleanup_plane_fb'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214134922.28761-2-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/intel_atomic.c:198: warning: Function parameter or member 'state' not described in 'intel_crtc_destroy_state'
drivers/gpu/drm/i915/intel_atomic.c:222: warning: Function parameter or member 'intel_crtc' not described in 'intel_atomic_setup_scalers'
drivers/gpu/drm/i915/intel_atomic.c:222: warning: Excess function parameter 'crtc' description in 'intel_atomic_setup_scalers'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214134922.28761-1-chris@chris-wilson.co.uk
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
During the recent upheaval to uc, the parameters to huc_ucode_xfer
were changed, but the kerneldoc left behind.
drivers/gpu/drm/i915/intel_huc.c:128: warning: Function parameter or member 'huc_fw' not described in 'huc_ucode_xfer'
drivers/gpu/drm/i915/intel_huc.c:128: warning: Function parameter or member 'vma' not described in 'huc_ucode_xfer'
drivers/gpu/drm/i915/intel_huc.c:128: warning: Excess function parameter 'dev_priv' description in 'huc_ucode_xfer'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214104040.4532-1-chris@chris-wilson.co.uk
Remove the kerneldoc markup applied to non-kerneldoc comments and
convert the multiline comments to the canonical style.
drivers/gpu/drm/i915/intel_lvds.c:313: warning: Function parameter or member 'encoder' not described in 'intel_enable_lvds'
drivers/gpu/drm/i915/intel_lvds.c:313: warning: Function parameter or member 'pipe_config' not described in 'intel_enable_lvds'
drivers/gpu/drm/i915/intel_lvds.c:313: warning: Function parameter or member 'conn_state' not described in 'intel_enable_lvds'
drivers/gpu/drm/i915/intel_lvds.c:453: warning: Function parameter or member 'connector' not described in 'intel_lvds_detect'
drivers/gpu/drm/i915/intel_lvds.c:453: warning: Function parameter or member 'force' not described in 'intel_lvds_detect'
drivers/gpu/drm/i915/intel_lvds.c:471: warning: Function parameter or member 'connector' not described in 'intel_lvds_get_modes'
drivers/gpu/drm/i915/intel_lvds.c:932: warning: Function parameter or member 'dev_priv' not described in 'intel_lvds_init'
drivers/gpu/drm/i915/intel_lvds.c:932: warning: Excess function parameter 'dev' description in 'intel_lvds_init'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214092909.27040-4-chris@chris-wilson.co.uk
Remove the kerneldoc markup applied to non-kerneldoc comments and
convert the multiline comments to the canonical style.
drivers/gpu/drm/i915/intel_dvo.c:303: warning: Function parameter or member 'connector' not described in 'intel_dvo_detect'
drivers/gpu/drm/i915/intel_dvo.c:303: warning: Function parameter or member 'force' not described in 'intel_dvo_detect'
drivers/gpu/drm/i915/intel_dvo.c:382: warning: Function parameter or member 'encoder' not described in 'intel_dvo_get_current_mode'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214092909.27040-3-chris@chris-wilson.co.uk
Regular comments where being marked up for kerneldoc, but were not
formatted properly. Remove the markup to remove the warnings.
drivers/gpu/drm/i915/dvo_ivch.c:192: warning: Function parameter or member 'dvo' not described in 'ivch_read'
drivers/gpu/drm/i915/dvo_ivch.c:192: warning: Function parameter or member 'addr' not described in 'ivch_read'
drivers/gpu/drm/i915/dvo_ivch.c:192: warning: Function parameter or member 'data' not described in 'ivch_read'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214092909.27040-2-chris@chris-wilson.co.uk
Drop the kerneldoc markup from the non-kerneldoc comments and convert
the multi-line comments to the canonical format.
drivers/gpu/drm/i915/intel_sdvo.c:223: warning: Function parameter or member 'intel_sdvo' not described in 'intel_sdvo_write_sdvox'
drivers/gpu/drm/i915/intel_sdvo.c:223: warning: Function parameter or member 'val' not described in 'intel_sdvo_write_sdvox'
drivers/gpu/drm/i915/intel_sdvo.c:653: warning: Function parameter or member 'intel_sdvo' not described in 'intel_sdvo_get_trained_inputs'
drivers/gpu/drm/i915/intel_sdvo.c:653: warning: Function parameter or member 'input_1' not described in 'intel_sdvo_get_trained_inputs'
drivers/gpu/drm/i915/intel_sdvo.c:653: warning: Function parameter or member 'input_2' not described in 'intel_sdvo_get_trained_inputs'
drivers/gpu/drm/i915/intel_sdvo.c:2311: warning: Function parameter or member 'dev_priv' not described in 'intel_sdvo_select_ddc_bus'
drivers/gpu/drm/i915/intel_sdvo.c:2311: warning: Function parameter or member 'sdvo' not described in 'intel_sdvo_select_ddc_bus'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214090905.4747-1-chris@chris-wilson.co.uk
The ages old kerneldoc-esque comments still refer to the original stubs
and not the more complete functions. As they were only describing the
external entry points (or at least thought themselves to be, they had
drifted!), they don't provide any commentary for the code flow.
drivers/gpu/drm/i915/intel_tv.c:379: warning: cannot understand function prototype: 'const struct tv_mode tv_modes[] = '
drivers/gpu/drm/i915/intel_tv.c:1133: warning: bad line:
drivers/gpu/drm/i915/intel_tv.c:1140: warning: Function parameter or member 'intel_tv' not described in 'intel_tv_detect_type'
drivers/gpu/drm/i915/intel_tv.c:1140: warning: Function parameter or member 'connector' not described in 'intel_tv_detect_type'
drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'connector' not described in 'intel_tv_detect'
drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'ctx' not described in 'intel_tv_detect'
drivers/gpu/drm/i915/intel_tv.c:1272: warning: Function parameter or member 'force' not described in 'intel_tv_detect'
drivers/gpu/drm/i915/intel_tv.c:1351: warning: Function parameter or member 'connector' not described in 'intel_tv_get_modes'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214085814.2565-1-chris@chris-wilson.co.uk
So far models of the Dell Venue 8 Pro, with a panel with MIPI panel
index = 3, one of which has been kindly provided to me by Jan Brummer,
where not working with the i915 driver, giving a black screen on the
first modeset.
The problem with at least these Dells is that their VBT defines a MIPI
ASSERT sequence, but not a DEASSERT sequence. Instead they DEASSERT the
reset in their INIT_OTP sequence, but the deassert must be done before
calling intel_dsi_device_ready(), so that is too late.
Simply doing the INIT_OTP sequence earlier is not enough to fix this,
because the INIT_OTP sequence also sends various MIPI packets to the
panel, which can only happen after calling intel_dsi_device_ready().
This commit fixes this by splitting the INIT_OTP sequence into everything
before the first DSI packet and everything else, including the first DSI
packet. The first part (everything before the first DSI packet) is then
used as deassert sequence.
Changed in v2:
-Split the init OTP sequence into a deassert reset and the actual init
OTP sequence, instead of calling it earlier and then having the first
mipi_exec_send_packet() call call intel_dsi_device_ready().
Changes in v3:
-Move the whole shebang to intel_bios.c
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82880
References: https://bugs.freedesktop.org/show_bug.cgi?id=101205
Cc: Jan-Michael Brummer <jan.brummer@tabos.org>
Reported-by: Jan-Michael Brummer <jan.brummer@tabos.org>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180214082151.25015-3-hdegoede@redhat.com
Fix one typo of render_mmio trace, exchange the mmio value of old and new.
Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
GGTT is in BAR0 with 8 bytes aligned. With a qemu patch (commit:
38d49e8c1523d97d2191190d3f7b4ce7a0ab5aa3), VFIO can use 8-byte reads/
writes to access it.
This patch is to support the 8-byte GGTT reads/writes.
Ideally, we would like to support 8-byte reads/writes for the total BAR0.
But it needs more work for handling 8-byte MMIO reads/writes.
This patch can fix the issue caused by partial updating GGTT entry, during
guest booting up.
v3:
- Use intel_vgpu_get_bar_gpa() stead. (Zhenyu)
- Include all the GGTT checking logic in gtt_entry(). (Zhenyu)
v2:
- Limit to GGTT entry. (Zhenyu)
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Guest may set this register on KBL platform, it can impact hardware
behavior, so add it into the gen9 render list. Otherwise gpu hang issue may
happen during different vgpu switch.
v2: separate it from patch set.
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
We can implement limited RC6 counter wrap-around protection under the
assumption that clients will be reading this value more frequently than
the wrap period on a given platform.
With the typical wrap-around period being ~90 minutes, even with the
exception of Baytrail which wraps every 13 seconds, this sounds like a
reasonable assumption.
Implementation works by storing a 64-bit software copy of a hardware RC6
counter, along with the previous HW counter snapshot. This enables it to
detect wrap is polled frequently enough and keep the software copy
monotonically incrementing.
v2:
* Missed GEN6_GT_GFX_RC6_LOCKED when considering slot sizing and
indexing.
* Fixed off-by-one in wrap-around handling. (Chris Wilson)
v3:
* Simplify index checking by using unsigned int. (Chris Wilson)
* Expand the comment to explain why indexing works.
v4:
* Use __int128 if supported.
v5:
* Use mul_u64_u32_div. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94852
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v3
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208160036.29919-1-tvrtko.ursulin@linux.intel.com
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
ICL has 2 slices of DBuf, enable both the slices during display init.
Ideally we should only enable the second slice when needed in order to
save power, but while we're not there yet, adopt the simpler solution
to keep us bug-free.
v2 (from Paulo):
- Add the TODO comment.
- Reorganize where things are defined.
- Fix indentation.
- Remove unnecessary POSTING_READ() calls.
- Improve the commit message.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-5-paulo.r.zanoni@intel.com
This code is similar enough to the CNL code that I considered just
adding ICL support to the CNL function, but I think it's still
different enough, and having a function specific to ICL allows us to
more easily adapt code in case the spec changes more later.
We're still missing the power wells and the mbus code, so leave those
pieces with a FIXME comment while they're not here yet.
v2: Don't use _PICK, don't WARN_ON(1), don't forget the chicken bits.
v3: Use _MMIO_PORT() (Ville).
Reviewed-by: James Ausmus <james.ausmus@intel.com> (v2)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-4-paulo.r.zanoni@intel.com
This commit adds the basic CDCLK functions, but it's still missing
pieces of the display initialization sequence.
v2:
- Implement the voltage levels.
- Rebase.
v3:
- Adjust to the new "bypass" clock (Imre).
- Call intel_dump_cdclk_state() too.
- Rename a variable to avoid confusion.
- Simplify the DVFS part.
v4:
- Remove wrong bit definition (James).
- Also drive-by fix the coding style for the register definition we
touched.
v5:
- Comment style (checkpatch).
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180206193346.18272-1-paulo.r.zanoni@intel.com
On ICL we have two sets of registers: one for port A and another for
port B. The set of port A registers is the same as the CNL registers.
Since the procmon table on ICL is the same we want to reuse the CNL
function. To do that we add a port argument and make CNL always call
the function passing port A. This way, we'll be able to easily reuse
the function on ICL when we add icl_display_core_init().
v2: Don't use _PICK() when you can use a ternary operator.
v3: Don't use a ternary operation when you can use _MMIO_PORT (Ville).
Add an extra comment about why we're passing PORT_A (James).
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180205154046.11485-2-paulo.r.zanoni@intel.com
On BXT/GLK GEN6_PCODE_READ_RC6VIDS fails with
MAILBOX_P24C_CC_ILLEGAL_CMD, so don't try to do the query on these
platforms. Do it only on SNB, IVB and HSW, where we use this command
anyway for RC6 enabling.
Based on my tests the command also succeeds on all LLC platforms, but
it's not clear if it's really supported on those (it returns 0 aka 245mv
for all RC6 states everywhere except on SNB). BSpec lists the command as
supported on SKL+ (see P24C_PCODE_MAILBOX_INTERFACE) but that's clearly
incorrect, since on SKL/KBL the same command ID is used for
SKL_PCODE_LOAD_HDCP_KEYS. Since the command fails on BXT/GLK, the BSpec
command list is also incorrect for those platforms (see
P_CR_P24C_PCODE_MAILBOX_INTERFACE_0_2_0_GTTMMADR).
I filed a request to update that info in Bspec, but for now let's
assume a minimal set of platforms where the command is supported.
References: https://bugs.freedesktop.org/show_bug.cgi?id=103337
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180208174102.10240-1-imre.deak@intel.com
