summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_ddi.c
Commit message (Collapse)AuthorAgeFilesLines
* Merge drm-fixes into drm-next.Dave Airlie2016-03-141-1/+0
|\ | | | | | | Nouveau wanted this to avoid some worse conflicts when I merge that.
| * drm/i915: Fix bogus dig_port_map[] assignment for pre-HSWTakashi Iwai2016-03-071-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The recent commit [0bdf5a05647a: drm/i915: Add reverse mapping between port and intel_encoder] introduced a reverse mapping to retrieve intel_dig_port object from the port number. The code assumed that the port vs intel_dig_port are 1:1 mapping. But in reality, this was a too naive assumption. As Martin reported about the missing HDMI audio on his SNB machine, pre-HSW chips may have multiple intel_dig_port objects corresponding to the same port. Since we assign the mapping statically at the init time and the multiple objects override the map, it may not match with the actually enabled output. This patch tries to address the regression above. The reverse mapping is provided basically only for the audio callbacks, so now we set / clear the mapping dynamically at enabling and disabling HDMI/DP audio, so that we can always track the latest and correct object corresponding to the given port. Fixes: 0bdf5a05647a ('drm/i915: Add reverse mapping between port and intel_encoder') Reported-and-tested-by: Martin Kepplinger <martink@posteo.de> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456324522-21591-1-git-send-email-tiwai@suse.de (cherry picked from commit 9dfbffcf4ac0707097af9e6c1372192b9d03a357) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915/ddi: Ensure the HW is powered during HW state readoutImre Deak2016-02-221-33/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com (cherry picked from commit e27daab49718e3232318d8b539cb302521b4b724) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()Lyude2016-02-101-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a result we skip assigning a DPLL to any DP MST ports, which makes link training fail: [ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well [ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well [ 1442.933957] [drm:intel_mst_pre_enable_dp] 0 [ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000 [ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0 [ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 [ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000 [ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1 [ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1 [ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000 [ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2 … [ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up [ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting After which the pipe state goes completely out of sync: [ 70.075596] [drm:check_crtc_state] [CRTC:25] [ 70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001) [ 70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0) [ 70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021) [ 70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173) [ 70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5) [ 70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256) [ 70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500) And if you're especially lucky, it keeps going downhill: [ 83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler [ 83.309265] [ 83.309265] ================================= [ 83.309266] [ INFO: inconsistent lock state ] [ 83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted [ 83.309267] --------------------------------- [ 83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes: [ 83.309293] (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915] [ 83.309293] {IN-HARDIRQ-W} state was registered at: [ 83.309297] [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00 [ 83.309299] [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0 [ 83.309302] [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90 [ 83.309321] [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915] [ 83.309332] [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915] [ 83.309337] [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300 [ 83.309339] [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60 [ 83.309341] [<ffffffff811010b4>] handle_edge_irq+0x74/0x130 [ 83.309344] [<ffffffff81009073>] handle_irq+0x73/0x120 [ 83.309346] [<ffffffff817805f1>] do_IRQ+0x61/0x120 [ 83.309348] [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20 [ 83.309351] [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330 [ 83.309353] [<ffffffff815f5367>] cpuidle_enter+0x17/0x20 [ 83.309356] [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50 [ 83.309358] [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0 [ 83.309360] [<ffffffff817701da>] rest_init+0x13a/0x140 [ 83.309363] [<ffffffff81f2af8e>] start_kernel+0x475/0x482 [ 83.309365] [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c [ 83.309367] [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a Fixes: 82d354370189 ("drm/i915/skl: Implementation of SKL DPLL programming") Signed-off-by: Lyude <cpaul@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1454428183-994-1-git-send-email-cpaul@redhat.com (cherry picked from commit 78385cb398748debb7ea2e36d6d2001830c172bc) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915/ddi: Ensure the HW is powered during HW state readoutImre Deak2016-02-171-33/+79
| | | | | | | | | | | | | | | | | | | | | | | | | | The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com
* | drm/i915/skl: Explicitly check for eDP in skl_ddi_pll_select()Lyude2016-02-091-1/+3
| | | | | | | | | | | | | | | | | | Assuming any connector that isn't DP, MST, or HDMI is eDP definitely seems likely to cover up other bugs in the future. Signed-off-by: Lyude <cpaul@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1454423709-21882-2-git-send-email-cpaul@redhat.com
* | drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()Lyude2016-02-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a result we skip assigning a DPLL to any DP MST ports, which makes link training fail: [ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well [ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well [ 1442.933957] [drm:intel_mst_pre_enable_dp] 0 [ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000 [ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0 [ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0 [ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000 [ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1 [ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1 [ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000 [ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2 … [ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up [ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting After which the pipe state goes completely out of sync: [ 70.075596] [drm:check_crtc_state] [CRTC:25] [ 70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001) [ 70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0) [ 70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021) [ 70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173) [ 70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5) [ 70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256) [ 70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500) And if you're especially lucky, it keeps going downhill: [ 83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler [ 83.309265] [ 83.309265] ================================= [ 83.309266] [ INFO: inconsistent lock state ] [ 83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted [ 83.309267] --------------------------------- [ 83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage. [ 83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes: [ 83.309293] (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915] [ 83.309293] {IN-HARDIRQ-W} state was registered at: [ 83.309297] [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00 [ 83.309299] [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0 [ 83.309302] [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90 [ 83.309321] [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915] [ 83.309332] [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915] [ 83.309337] [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300 [ 83.309339] [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60 [ 83.309341] [<ffffffff811010b4>] handle_edge_irq+0x74/0x130 [ 83.309344] [<ffffffff81009073>] handle_irq+0x73/0x120 [ 83.309346] [<ffffffff817805f1>] do_IRQ+0x61/0x120 [ 83.309348] [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20 [ 83.309351] [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330 [ 83.309353] [<ffffffff815f5367>] cpuidle_enter+0x17/0x20 [ 83.309356] [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50 [ 83.309358] [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0 [ 83.309360] [<ffffffff817701da>] rest_init+0x13a/0x140 [ 83.309363] [<ffffffff81f2af8e>] start_kernel+0x475/0x482 [ 83.309365] [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c [ 83.309367] [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a Fixes: 82d354370189 ("drm/i915/skl: Implementation of SKL DPLL programming") Signed-off-by: Lyude <cpaul@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1454428183-994-1-git-send-email-cpaul@redhat.com
* | drm/i915: Check DDI max lanes after applying BXT workaroundMatt Roper2016-02-021-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit bfb9faab8 we added a workaround for some BXT BIOS that fail to properly initialize the DDI_A_4_LANES bit of the control register (4 lanes is the only valid configuration on BXT since there is no DDI E to share with). A recent patch added some additional checks on this register bit before the workaround gets applied; this breaks eDP on BXT in some settings. Some minor code shuffling is all we need to restore the workaround. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Fixes: 7cd87cb80 ("drm/i915: Check max number of lanes when registering DDI ports") Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1454022577-834-1-git-send-email-matthew.d.roper@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
* | Merge remote-tracking branch 'airlied/drm-next' into drm-intel-next-queuedDaniel Vetter2016-01-181-1/+1
|\ \ | |/ | | | | | | | | | | | | | | | | | | Pull in Dave's drm-next pull request to have a clean base for 4.6. Also, we need the various atomic state extensions Maarten recently created. Conflicts are just adjacent changes that all resolve to nothing in git diff. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * Merge tag 'drm-intel-next-2015-12-18' of ↵Dave Airlie2015-12-231-19/+36
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next - fix atomic watermark recomputation logic (Maarten) - modeset sequence fixes for LPT (Ville) - more kbl enabling&prep work (Rodrigo, Wayne) - first bits for mst audio - page dirty tracking fixes from Dave Gordon - new get_eld hook from Takashi, also included in the sound tree - fixup cursor handling when placed at address 0 (Ville) - refactor VBT parsing code (Jani) - rpm wakelock debug infrastructure ( Imre) - fbdev is pinned again (Chris) - tune the busywait logic to avoid wasting cpu cycles (Chris) * tag 'drm-intel-next-2015-12-18' of git://anongit.freedesktop.org/drm-intel: (81 commits) drm/i915: Update DRIVER_DATE to 20151218 drm/i915/skl: Default to noncoherent access up to F0 drm/i915: Only spin whilst waiting on the current request drm/i915: Limit the busy wait on requests to 5us not 10ms! drm/i915: Break busywaiting for requests on pending signals drm/i915: don't enable autosuspend on platforms without RPM support drm/i915/backlight: prefer dev_priv over dev pointer drm/i915: Disable primary plane if we fail to reconstruct BIOS fb (v2) drm/i915: Pin the ifbdev for the info->system_base GGTT mmapping drm/i915: Set the map-and-fenceable flag for preallocated objects drm/i915: mdelay(10) considered harmful drm/i915: check that we are in an RPM atomic section in GGTT PTE updaters drm/i915: add support for checking RPM atomic sections drm/i915: check that we hold an RPM wakelock ref before we put it drm/i915: add support for checking if we hold an RPM reference drm/i915: use assert_rpm_wakelock_held instead of opencoding it drm/i915: add assert_rpm_wakelock_held helper drm/i915: remove HAS_RUNTIME_PM check from RPM get/put/assert helpers drm/i915: get a permanent RPM reference on platforms w/o RPM support drm/i915: refactor RPM disabling due to RC6 being disabled ...
| * \ Merge tag 'drm-intel-next-2015-12-04-1' of ↵Dave Airlie2015-12-151-1/+1
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next This is the "fix igt basic test set issues" edition. - more PSR fixes from Rodrigo, getting closer - tons of fifo underrun fixes from Ville - runtime pm fixes from Imre, Daniel Stone - fix SDE interrupt handling properly (Jani Nikula) - hsw/bdw fdi modeset sequence fixes (Ville) - "don't register bad VGA connectors and fall over" fixes (Ville) - more fbc fixes from Paulo - and a grand total of exactly one feature item: Implement dma-buf/fence based cross-driver sync in the i915 pageflip path (Alex Goins) * tag 'drm-intel-next-2015-12-04-1' of git://anongit.freedesktop.org/drm-intel: (70 commits) drm/i915: Update DRIVER_DATE to 20151204 drm/i915/skl: Add SKL GT4 PCI IDs Revert "drm/i915: Extend LRC pinning to cover GPU context writeback" drm/i915: Correct the Ref clock value for BXT drm/i915: Restore skl_gt3 device info drm/i915: Fix RPS pointer passed from wait_ioctl to i915_wait_request Revert "drm/i915: Remove superfluous NULL check" drm/i915: Clean up device info structure definitions drm/i915: Remove superfluous NULL check drm/i915: Handle cdclk limits on broadwell. i915: wait for fence in prepare_plane_fb i915: wait for fence in mmio_flip_work_func drm/i915: Extend LRC pinning to cover GPU context writeback drm/i915/guc: Clean up locks in GuC drm/i915: only recompress FBC after flushing a drawing operation drm/i915: get rid of FBC {,de}activation messages drm/i915: kill fbc.uncompressed_size drm/i915: use a single intel_fbc_work struct drm/i915: check for FBC planes in the same place as the pipes drm/i915: alloc/free the FBC CFB during enable/disable ...
| * | | drm: Pass 'name' to drm_encoder_init()Ville Syrjälä2015-12-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Done with coccinelle for the most part. However, it thinks '...' is part of the semantic patch, so I put an 'int DOTDOTDOT' placeholder in its place and got rid of it with sed afterwards. @@ identifier dev, encoder, funcs; @@ int drm_encoder_init(struct drm_device *dev, struct drm_encoder *encoder, const struct drm_encoder_funcs *funcs, int encoder_type + ,const char *name, int DOTDOTDOT ) { ... } @@ identifier dev, encoder, funcs; @@ int drm_encoder_init(struct drm_device *dev, struct drm_encoder *encoder, const struct drm_encoder_funcs *funcs, int encoder_type + ,const char *name, int DOTDOTDOT ); @@ expression E1, E2, E3, E4; @@ drm_encoder_init(E1, E2, E3, E4 + ,NULL ) v2: Add ', or NULL...' to @name kernel doc (Jani) Annotate the function with __printf() attribute (Jani) Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449670818-2966-1-git-send-email-ville.syrjala@linux.intel.com
* | | | drm/i915: Only complain about n_edp_entries with eDP portsVille Syrjälä2016-01-121-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 10afa0b65fe2 ("drm/i915: Reject >9 ddi translation entried if port != A/E on SKL") added sanity checks to make sure we don't end up with too many ddi translation values for eDP ports, but it actually failed to check if the port is eDP. We still look up the edp translations for non-eDP ports, but don't use them, so we shouldn't be complaining about them either. Fixes: 10afa0b65fe2 ("drm/i915: Reject >9 ddi translation entried if port != A/E on SKL") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452612496-9201-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: Kill intel_prepare_ddi()Ville Syrjälä2016-01-121-71/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Move the ddi buffer translation programming to occur from the encoder .pre_enable() hook, for just the ddi port we are enabling. Previously we used to reprogram the translations for all ddi ports during init and during power well enabling. v2: s/intel_prepare_ddi_buffers/intel_prepare_ddi_buffer/ (Daniel) Resolve conflicts due to dev_priv->atomic_cdclk_freq Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: Reject >9 ddi translation entried if port != A/E on SKLVille Syrjälä2016-01-121-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Only DDI A and E support 10 translation entries in DP mode. For the other ports the tenth entry is reserved for HDMI. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449597590-6971-9-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: Pass around dev_priv for ddi buffer programmingVille Syrjälä2016-01-121-42/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the ddi buffer programming code a bit more neat by passing around dev_priv instead of dev. v2: Resolve conflicts due to KBL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
* | | | drm/i915: Eliminate duplicated skl_get_buf_trans_dp()Ville Syrjälä2016-01-121-16/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | skl_get_buf_trans_edp() effectively contains another copy of skl_get_buf_trans_dp(). Remove the duplication and just call skl_get_buf_trans_dp() from skl_get_buf_trans_edp(). v2: Resolve conflicts due to KBL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
* | | | drm/i915: Remove pointless 'ddi_translations' local variableVille Syrjälä2016-01-121-28/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | skl_get_buf_trans_*() don't need the 'ddi_translations' local variable since all they with is assign and return. Just return the right thing directly and get rid of the local variable. v2: Resolve conflicts due to KBL Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> (v1)
* | | | drm/i915: Store max lane count in intel_digital_portVille Syrjälä2016-01-121-9/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rather than having open coded checks for the DDI A/E configuration, just store the max supported lane count in intel_digital_port. We had an open coded check for DDI A, but not for DDI E. So we may have been vilating the DDI E max lane count. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: Check max number of lanes when registering DDI portsVille Syrjälä2016-01-121-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DDI A and E share some of the lanes, so check that we have enough lanes for the purpose we need before registering the encoders. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449597590-6971-3-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | drm/i915: Cleaning up DDI translation tablesRodrigo Vivi2016-01-071-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | No functional changes. That state the obvious and just duplicate the place we need to change whenever the table is updated. So let's clean it. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452021535-22641-1-git-send-email-rodrigo.vivi@intel.com
* | | | drm/i915: Update Skylake DDI translation table for DP.Rodrigo Vivi2016-01-071-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When reviewing DDI translation table I noticed few changes we haven't incorporated yet and it is always good to follow latest spec. Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452009511-15064-1-git-send-email-rodrigo.vivi@intel.com
* | | | drm/i915: Update Skylake DDI translation table for HDMI.Rodrigo Vivi2016-01-071-9/+9
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When debuging an intermittent corrupted screen I suspected on DDI translation table and checked we are out of date with the spec. I'm not sure this will fix my bug yet, but it is always good to follow the spec. v2: Ville caught a switched i-boost value. Thanks! Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1452021087-21673-1-git-send-email-rodrigo.vivi@intel.com
* | | Merge tag 'drm-i915-get-eld' of tiwai/sound into drm-intel-next-queuedDaniel Vetter2015-12-111-0/+1
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add get_eld audio component for i915/HD-audio Currently, the HDMI/DP audio status and ELD are notified and obtained via the hardware-level communication over HD-audio unsolicited event and verbs although the graphics driver holds the exactly same information. As we already have a notification via audio component, this is another step forward; namely, the audio driver may fetch directly the audio status and ELD via the new component op. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * | | drm/i915: Add reverse mapping between port and intel_encoderTakashi Iwai2015-12-101-0/+1
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds a reverse mapping from a digital port number to intel_encoder object containing the corresponding intel_digital_port. It simplifies the query of the encoder a lot. Note that, even if it's a valid digital port, the dig_port_map[] might point still to NULL -- usually it implies a DP MST port. Due to this fact, the NULL check in each place has no WARN_ON() and just skips the port. Once when the situation changes in future, we might introduce WARN_ON() for a more strict check. Signed-off-by: Takashi Iwai <tiwai@suse.de>
* | | drm/i915: start adding dp mst audioLibin Yang2015-12-101-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio flag is set. Another separated patches to support DP MST audio will be implemented in audio driver. Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Libin Yang <libin.yang@linux.intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449036584-105393-2-git-send-email-libin.yang@linux.intel.com
* | | drm/i915/kbl: Use propper ddi buffer translation table for Kabylake ULT and ULX.Rodrigo Vivi2015-12-081-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Let's introduce ULT and ULX Kabylake definitions and start using it for a propper DDI buffer translation. v2: Remove extra white space. (Paulo) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
* | | drm/i915: Leave FDI running after failed link training on LPT-HVille Syrjälä2015-12-081-9/+15
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we disable some parts of FDI setup after a failed link training. But despite that we continue with the modeset as if everything is fine. This results in tons of noise from the state checker, and it means we're not following the proper modeset sequence for the rest of crtc enabling, nor for crtc disabling. Ideally we should abort the modeset and follow the proper disable sequence to shut off everything we enabled so far, but that would require a big rework of the modeset code. So instead just leave FDI up and running in its untrained state, and log an error. This is what we do on older platforms too. v2: Fix a typo in the commit message Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449260570-14670-1-git-send-email-ville.syrjala@linux.intel.com
* | drm/i915: Don't use crtc->config when reading out infoframe stateVille Syrjälä2015-12-011-1/+1
|/ | | | | | | | | | | | | | | | | | | | | The .get_config() hooks should not reference anything in crtc->config, everything should be based on the passed in pipe_config instead. So don't dig out the cpu_transcoder from crtc->config on ddi platfforms, and also avoid using the encoder->crtc link and instead look up the pipe via pipe_config->base.crtc. I don't think this will actually fix anything since during the initial state readout we set up the encoder->crtc link prior to calling .get_config(), and during the modeset state check the encoder->crtc ought to be correct anyway since it's that state we just programmed. But this seems the right thing to do anyway. While at it, do some house cleaning on the local variables in the .infoframe_enabled() hooks. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448555227-31403-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v4.4-rc2' into drm-intel-next-queuedDaniel Vetter2015-11-231-10/+65
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 4.4-rc2 Backmerge to get at commit 1b0e3a049efe471c399674fd954500ce97438d30 Author: Imre Deak <imre.deak@intel.com> Date: Thu Nov 5 23:04:11 2015 +0200 drm/i915/skl: disable display side power well support for now so that we can proplery re-eanble skl power wells in -next. Conflicts are just adjacent lines changed, except for intel_fbdev.c where we need to interleave the changs. Nothing nefarious. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm/i915: Consider SPLL as another shared pll, v2.Maarten Lankhorst2015-11-181-10/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When diagnosing a unrelated bug for someone on irc, it would seem the hardware can be brought up by the BIOS with the embedded displayport using the SPLL for spread spectrum. Right now this is not handled well in i915, and it calculates the crtc needs to be reprogrammed on the first modeset without SSC, but the SPLL itself was kept active. Fix this by exposing SPLL as a shared pll that will not be returned by intel_get_shared_dpll; you have to know it exists to use it. Changes since v1: - Create a separate dpll_hw_state.spll for spll, and use separate pll functions for spll. Tested-by: Emil Renner Berthing <kernel@esmil.dk> Tested-by: Gabriel Feceoru <gabriel.feceoru@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447681332-6318-1-git-send-email-maarten.lankhorst@linux.intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Type safe register read/writeVille Syrjälä2015-11-181-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | drm/i915: Make turning on/off PW1 and Misc I/O part of the init/fini sequencesDamien Lespiau2015-11-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this patch, we used the intel_display_power_{get,put} functions to make sure the PW1 and Misc I/O power wells were enabled all the time while LCPLL was enabled. We called a get() at intel_ddi_pll_init() when we discovered that LCPLL was enabled, then we would call put/get at skl_{un,}init_cdclk(). The problem is that skl_uninit_cdclk() is indirectly called by intel_runtime_suspend(). So it will only release its power well _after_ we already decided to runtime suspend. But since we only decide to runtime suspend after all power wells and refcounts are released, that basically means we will never decide to runtime suspend. So what this patch does to fix that problem is move the PW1 + Misc I/O power well handling out of the runtime PM mechanism: instead of calling intel_display_power_{get_put} - functions that touch the refcount -, we'll call the low level intel_power_well_{en,dis}able, which don't change the refcount. This way, it is now possible for the refcount to actually reach zero, and we'll now start runtime suspending/resuming. v2 (from Paulo): - Write a commit message since the original patch left it empty. - Rebase after the intel_power_well_{en,dis}able rename. - Use lookup_power_well() instead of hardcoded indexes. Testcase: igt/pm_rpm/rte (and every other rpm test) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92211 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92605 Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-4-git-send-email-imre.deak@intel.com
* | drm/i915/skl: Update DDI translation tables for SKLjim.bride@linux.intel.com2015-11-131-11/+11
| | | | | | | | | | | | | | | | | | | | | | While comparing the B-Spec with the code I noticed that several values in these tables have been updated in the spec, so I changed the code to match.. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446852654-883-1-git-send-email-jim.bride@linux.intel.com
* | drm/i915: Fix SKL i_boost levelAnder Conselvan de Oliveira2015-11-131-3/+3
| | | | | | | | | | | | | | | | | | | | | | The i_boost level in the DDI translation tables are stored per level. However, skl_ddi_set_iboos() would choose an entry of that table based on the port argument. Cc: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Jim Bride <jim.bride@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447247754-802-1-git-send-email-ander.conselvan.de.oliveira@intel.com
* | drm/i915: Setup DDI clk for MST on SKLVille Syrjälä2015-11-101-20/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Set up the DDI->PLL mapping on SKL also for MST links. Might help make MST operational on SKL. v2: Rebased due to KBL Improve the patch subject, Jesse provided the new one Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1439826380-18403-1-git-send-email-ville.syrjala@linux.intel.com References: https://bugs.freedesktop.org/show_bug.cgi?id=91791 Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
* | drm/i915/bxt: Force port A DDI to use 4 lanesMatt Roper2015-11-091-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bspec indicates that DDI A using four lanes is the only valid configuration for Broxton (Broxton doesn't have a DDI E to split these lanes with); the DDI_A_4_LANES bit of port A's DDI_BUF_CTL should always be set by the BIOS. However some BIOS versions seem to only be setting this bit if eDP is actually lit up at boot time; if the BIOS doesn't turn on the eDP panel because an external display is plugged in, then this bit is never properly initialized. The end result of this is that we wind up calculating a lower max data rate than we should and may wind up rejecting the native mode for panels that we should be able to drive. Let's workaround this BIOS bug by just turning the DDI_A_4_LANES bit on in our driver's internal state if we recognize that we're running on BXT where it should have been on anyway. Cc: Imre Deak <imre.deak@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Tested-by: Bob Paauwe <bob.j.paauwe@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446764012-27251-1-git-send-email-matthew.d.roper@intel.com
* | drm/i915: Create intel_dp->prepare_link_retrain() hookAnder Conselvan de Oliveira2015-11-051-4/+4
| | | | | | | | | | | | | | | | | | | | In order to prepare for a link training with DDI, the state machine would call intel_ddi_prepare_link_retrain(). To remove the dependency to the hardware information, replace that direct call with a callback. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445594525-7174-7-git-send-email-ander.conselvan.de.oliveira@intel.com
* | drm/i915/kbl: Introduce Kabylake platform defition.Rodrigo Vivi2015-10-281-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Kabylake is a Intel® Processor containing Intel® HD Graphics following Skylake. It is Gen9p5, so it inherits everything from Skylake. Let's start by adding the platform separated from Skylake but reusing most of all features, functions etc. Later we rebase the PCI-ID patch without is_skylake=1 so we don't replace what original Author did there. Few IS_SKYLAKEs if statements are not being covered by this patch on purpose: - Workarounds: Kabylake is derivated from Skylake H0 so no W/As apply here. - GuC: A following patch removes Kabylake support with an explanation: No firmware available yet. - DMC/CSR: Done in a separated patch since we need to be carefull and load the version for revision 7 since Kabylake is Skylake H0. v2: relative cleaner commit message and added the missed IS_KABYLAKE to intel_i2c.c as pointed out by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Use paramtrized WRPLL_CTL()Ville Syrjälä2015-10-261-4/+4
| | | | | | | | | | | | | | | | v2: Rebase due to SKL_DPLLx usage Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1442595836-23981-21-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: add helpers for platform specific revision id range checksJani Nikula2015-10-211-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revision checks are almost always accompanied by a platform check. (The exceptions are platform specific code.) Add helpers to check for a platform and a revision range: IS_SKL_REVID() and IS_BXT_REVID(). In most places this simplifies and clarifies the code. It will be obvious that revid macros are used for the correct platform. This should make it easier to find all the revision checks for workarounds for each platform, and make it easier to remove them once we drop support for early hardware revisions. This should also make it easier to differentiate between Skylake and Kabylake revision checks when Kabylake support is added. v2: rebase Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445343722-3312-3-git-send-email-jani.nikula@intel.com
* | drm/i915/bxt: add revision id for A1 stepping and use itJani Nikula2015-10-211-1/+1
| | | | | | | | | | | | | | | | | | | | Prefer inclusive ranges for revision checks rather than "below B0". Per specs A2 is not used, so revid <= A1 matches revid < B0. Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1445343722-3312-2-git-send-email-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915/skl: If needed sanitize bios programmed cdclkShobhit Kumar2015-10-211-2/+2
|/ | | | | | | | | | | | | | | | | | | | | | | Especially in cases where pre-os does not enable display, cdclk might not be in sane state. During sanitization initialize cdclk with maximum value till we get dynamic cdclk support. v2: Check if BIOS programmed correctly rather than always calling init - Do validation of programmed cdctl and what it is expected - Only do slk_init_cdclk if validation failed else reuse BIOS programmed value v3: Move the validation logic in a separate sanitize function (Ville) v4: No need to check LCPLL after sanitize and use max_cdclk_freq instead of hardcoded value (Ville) Cc: Imre Deak <imre.deak@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Shobhit Kumar <shobhit.kumar@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445344992-14658-1-git-send-email-shobhit.kumar@intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rename DP link training functionsAnder Conselvan de Oliveira2015-10-061-1/+0
| | | | | | | | | | | | The link training functions had confusing names. The start function actually does the clock recovery phase of the link training, and the complete function does the channel equalization. So call them that instead. Also, every call to intel_dp_start_link_train() was followed by a call to intel_dp_complete_link_train(), so add a new start function that calls clock_recory and channel_equalization. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bxt: DSI encoder support in CRTC modesetShashank Sharma2015-10-021-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset functions are re-used for modeset sequence. But DDI interface doesn't include support for DSI. This patch adds: 1. cases for DSI encoder, in those modeset functions and allows a CRTC modeset 2. Adds call to pre_pll enabled from CRTC modeset function. Nothing needs to be done as such in CRTC for DSI encoder, as PLL, clock and and transcoder programming will be taken care in encoder's pre_enable and pre_pll_enable function. v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI encoder like DSI for platforms having HAS_DDI as true. v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid encoder. v4: WARN_ON for invalid encoder is refactored as per Jani's suggestion. Fixed the sequence for pre_pll_enable. v5: Protected DDI code paths in case of DSI encoder calls. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: s/GET_CFG_CR1_REG/DPLL_CFGCR1/ etc.Ville Syrjälä2015-10-011-8/+8
| | | | | | | | v2: Use SKL_DPLLx symbolic names instead of raw numbers Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: s/_FDI_RXA_.../FDI_RX_...(PIPE_A)/Ville Syrjälä2015-09-301-23/+23
| | | | | | Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/ddi: use switch case instead of if ladder for ddi_get_encoder_portJani Nikula2015-09-301-7/+13
| | | | | | | Make the alternatives stand out better. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/ddi: warn instead of oops on invalid ddi encoder typeJani Nikula2015-09-301-2/+1
| | | | | | | | | It's more useful to limp on than bring the kernel down. Hitting this is a more likely event with BXT DSI, although care should be taken not to call the function for DSI. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bxt: Set oscaledcompmethod to enable scale valueSonika Jindal2015-09-301-2/+6
| | | | | | | | | | | | | Bspec update tells that we have to enable oscaledcompmethod instead of ouniqetrangenmethod for enabling scale value during swing programming. v2: Adding back 'don't care' values to bxt_ddi_translations_dp and add error message if ouniquetrangemethod was set (Imre) Signed-off-by: Sonika Jindal <sonika.jindal@intel.com> Reviewed-by: Sivakumar Thulasimani <sivakumar.thulasimani@intel.com>(v1) Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud