- 19 11月, 2015 4 次提交
-
-
由 Daniel Vetter 提交于
We don't need 2 separate unions. Note that this was done intentinoally Author: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Date: Wed May 6 14:35:38 2015 +0300 drm/i915: Add a partial GGTT view type on Tvrtko's request, but without a clear justification. Rotated views are also not checking for matching paramters in i915_ggtt_view_equal, which seems like a bug. But this patch here doesn't change that. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1444834266-12689-2-git-send-email-daniel.vetter@ffwll.chReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
It can't fail and there's even a WARN_ON suggesting that if it would, it would be a disaster. Correct this to make things less confusing. Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1444834266-12689-1-git-send-email-daniel.vetter@ffwll.chReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
MISSING_CASE() would have been useful to track down a recent problem in intel_display_port_aux_power_domain(), so add it there and a few related helpers. This was also suggested by Ville in his review of the latest DMC/DC changes, we forgot to address that. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447855045-7109-2-git-send-email-imre.deak@intel.com
-
由 Imre Deak 提交于
Due to the current sharing of the DDI encoder between DP and HDMI connectors we can run the DP detection after the HDMI detection has already set the shared encoder's type. For now solve this keeping the current behavior and running the detection in this case too. For a proper solution Ville suggested to split the encoder into an HDMI and DP one, that can be done as a follow-up. This issue triggers the WARN in intel_display_port_aux_power_domain() and was introduced in: commit 25f78f58 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Nov 16 15:01:04 2015 +0100 drm/i915: Clean up AUX power domain handling CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447855045-7109-1-git-send-email-imre.deak@intel.com
-
- 18 11月, 2015 10 次提交
-
-
由 Ville Syrjälä 提交于
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: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1447853606-2751-1-git-send-email-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
When register type safety happens, we can't just try to emit the register itself to the ring. Instead we'll need to extract the offset from it first. Add some convenience functions that will do that. v2: Convert MOCS setup too Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446672017-24497-20-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Ville Syrjälä 提交于
Replace the is_sdvob bool and some sdvo_reg checks with enum port. This makes the SDVO code look more modern, and gets rid of explicit register offset checks in the code which will hamper register type checking. v2: Add assert_sdvo_port_valid() (Chris) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/1446838199-3666-1-git-send-email-ville.syrjala@linux.intel.com
-
由 Patrik Jakobsson 提交于
Handle DC off as a power well where enabling the power well will prevent the DMC to enter selected DC states (required around modesets and Aux A). Disabling the power well will allow DC states again. For now the highest DC state is DC6 for Skylake and DC5 for Broxton but will be configurable for Skylake in a later patch. v2: Check both DC5 and DC6 bits in power well enabled function (Ville) v3: - Remove unneeded DC_OFF case in skl_set_power_well() (Imre) - Add PW2 dependency to DC_OFF (Imre) v4: Put DC_OFF before PW2 in BXT power well array Signed-off-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> [fixed line over 80 and parenthesis alignment checkpatch warns (imre)] Link: http://patchwork.freedesktop.org/patch/msgid/1447687201-24759-1-git-send-email-patrik.jakobsson@linux.intel.com
-
由 Patrik Jakobsson 提交于
We never make use of the distinction between 2 vs 4 lanes so combine them into a per port domain instead. This saves us a few bits in the power domain mask. Change suggested by Ville. Signed-off-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447084107-8521-7-git-send-email-patrik.jakobsson@linux.intel.com
-
由 Ville Syrjälä 提交于
Introduce intel_display_port_aux_power_domain() which simply returns the appropriate AUX power domain for a specific port, and then replace the intel_display_port_power_domain() with calls to the new function in the DP code. As long as we're not actually enabling the port we don't need the lane power domains, and those are handled now purely from modeset_update_crtc_power_domains(). My initial motivation for this was to see if I could keep the DPIO power wells powered down while doing AUX on CHV, but turns out I can't so this doesn't change anything for CHV at least. But I think it's still a worthwile change. v2: Add case for PORT E. Default to POWER_DOMAIN_AUX_D for now. (Ville) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447682467-6237-1-git-send-email-patrik.jakobsson@linux.intel.com
-
由 Imre Deak 提交于
Suppressing LCPLL disabling was added to avoid interfering with the DMC firmware. It is not needed any more since we uninit CDCLK now with the DMC deactivated (DC states disabled). We also must disable it during system suspend as part of the Bspec "Display uninit sequence". Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-10-git-send-email-imre.deak@intel.com
-
由 Imre Deak 提交于
We need to initialize the display core part early, before initializing the rest of the display power state. This is also described in the bspec termed "Display initialization sequence". Atm we run this sequence during driver loading after power domain HW state initialization which is too late and during runtime suspend/resume which is unneeded and can interere with DMC functionality which handles HW resources toggled by this init/uninit sequence automatically. The init sequence must be run as the first step of HW power state initialization and during system resume. The uninit sequence must be run during system suspend. To address the above move the init sequence to the initial HW power state setup and the uninit sequence to a new power domains suspend function called during system suspend. As part of the init sequence we also have to reprogram the DMC firmware as it's lost across a system suspend/resume cycle. After this change CD clock initialization during driver loading will happen only later after other dependent HW/SW parts are initialized, while during system resume it will get initialized as the last step of the init sequence. This distinction can be removed by some refactoring of platform independent parts. I left this refactoring out from this series since I didn't want to change non-SKL parts. This is a TODO for later. v2: - fix error path in i915_drm_suspend_late() - don't try to re-program the DMC firmware if it failed to load Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPatrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1447774433-20834-1-git-send-email-imre.deak@intel.com
-
由 Damien Lespiau 提交于
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: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NPatrik 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=92605Signed-off-by: NImre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446657859-9598-4-git-send-email-imre.deak@intel.com
-
- 10 11月, 2015 10 次提交
-
-
由 Ville Syrjälä 提交于
ironlake_enaable_pch_transcoder() checks for CPT to see if it should enable the timing override chicken bit, but ironlake_disable_pch_transcoder() checks for !IBX to see if it should clear the same bit. Change ironlake_disable_pch_transcoder() to check for CPT as well to keep the two sides consistent. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-8-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Ville Syrjälä 提交于
Due to the shared error interrupt on IVB/HSW and CPT/PPT we may not always get an interrupt on a FIFO underrun. But we can always do an explicit check (like we do on GMCH platforms that have no underrun interrupt). v2: Drop stale kerneldoc for i9xx_check_fifo_underruns() (Daniel) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1446225741-11070-1-git-send-email-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
Some hardware (IVB/HSW and CPT/PPT) have a shared error interrupt for all the relevant underrun bits, so in order to keep the error interrupt enabled, we need to have underrun reporting enabled on all PCH transocders. Currently we leave the underrun reporting disabled when the pipe is off, which means we won't get any underrun interrupts when only a subset of the pipes are active. Fix the problem by re-enabling the underrun reporting after the pipe has been disabled. And to avoid the spurious underruns during pipe enable, disable the underrun reporting before embarking on the pipe enable sequence. So this way we have the error reporting disabled while running through the modeset sequence. v2: Re-enable PCH FIFO underrun reporting unconditionally on pre-HSW Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1446225691-10928-1-git-send-email-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
As we did for ILK/SNB/IVB, move the PCH FIFO underrun enable to happen after the encoder enable on HSW+. And again, for symmetry, move the the disable to happen before encoder disable. I've left out the vblank wait before the enable here because I don't know if it's needed or not. Actually I don't know if this entire change is needed as I don't have a HSW/BDW with VGA output. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-5-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Ville Syrjälä 提交于
We get spurious PCH FIFO underruns if we enable the reporting too soon after enabling the crtc. Move it to be the last step, after the encoder enable. Additionally we need an extra vblank wait, otherwise we still get the underruns. Presumably the pipe/fdi isn't yet fully up and running otherwise. For symmetry, disable the PCH underrun reporting as the first thing, just before encoder disable, when shutting down the crtc. v2: Do the PCH underrun enable unconditionally (Jani, Daniel) Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1446225627-10809-1-git-send-email-ville.syrjala@linux.intel.com
-
由 Ville Syrjälä 提交于
Rather than looking at crtc->mode (which is the user mode) dig up the sync polarity settings from the adjusted_mode when programming TRANS_DP_CTL on CPT/PPT. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-3-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Ville Syrjälä 提交于
No point in doing the crtc->pipe->crtc->config->cpu_transcoder dance when we can just do crtc->config->cpu_transcoder. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446146763-31821-2-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org>
-
由 Paulo Zanoni 提交于
Make sure we deactivate FBC at intel_fbc_init(), so we can remove the call from intel_display.c. Currently we only have the "enabled" software state, but later we'll have both "enabled" and "active", and we'll add assertions to them, so just calling intel_fbc_disable() from intel_modeset_init() won't work. It's better to make sure intel_fbc_init() already puts the hardware in the expected state, so we can put nice assertions in the other functions. v2: Keep/improve the comment (Chris). v3: Improve the commit message a little bit. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446664257-32012-9-git-send-email-paulo.r.zanoni@intel.comSigned-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
-
由 Ville Syrjälä 提交于
Currently there's no trace in dmesg when the gen2/3 dotclock checks reject the modeset. Add some to avoid further head scratching. While at it refactor the code a bit to look nicer. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446241178-432-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
-
由 Mika Kuoppala 提交于
VMA offsets are 64 bits. Plane surface offsets are in ggtt and the hardware register to set this is thus 32 bits. Be explicit about these and convert carefully to from vma to final size. This will make sparse happy by not creating 32bit pointers out of 64bit vma offsets. Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446204375-29831-1-git-send-email-mika.kuoppala@intel.comReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
-
- 09 11月, 2015 1 次提交
-
-
由 Lukas Wunner 提交于
Currently when allocating a framebuffer fails, the gem object gets unrefed at the bottom of the call stack in __intel_framebuffer_create, not where it gets refed, which is in intel_framebuffer_create_for_mode (via i915_gem_alloc_object) and in intel_user_framebuffer_create (via drm_gem_object_lookup). This invites mistakes: __intel_framebuffer_create is also called from intelfb_alloc, and as discovered by Tvrtko Ursulin, a double unref was introduced there with a8bb6818 ("drm/i915: Fix error path leak in fbdev fb allocation"). As suggested by Ville Syrjälä, fix the double unref and improve code clarity by moving the unref away from __intel_framebuffer_create to where the gem object gets refed. Based on Tvrtko Ursulin's original v2. v3: On fb alloc failure, unref gem object where it gets refed, fix double unref in separate commit (Ville Syrjälä) v4: Lock struct_mutex on unref (Chris Wilson) v5: Rebase on drm-intel-nightly 2015y-09m-01d-09h-06m-08s UTC, rephrase commit message (Jani Nicula) Tested-by: NPierre Moreau <pierre.morrow@free.fr> [MBP 5,3 2009 nvidia MCP79 + G96 pre-retina] Tested-by: NPaul Hordiienko <pvt.gord@gmail.com> [MBP 6,2 2010 intel ILK + nvidia GT216 pre-retina] Tested-by: NWilliam Brown <william@blackhats.net.au> [MBP 8,2 2011 intel SNB + amd turks pre-retina] Tested-by: NLukas Wunner <lukas@wunner.de> [MBP 9,1 2012 intel IVB + nvidia GK107 pre-retina] Tested-by: NBruno Bierbaumer <bruno@bierbaumer.net> [MBP 11,3 2013 intel HSW + nvidia GK107 retina] Fixes: a8bb6818 ("drm/i915: Fix error path leak in fbdev fb allocation") Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NLukas Wunner <lukas@wunner.de> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/2161c5062ef5d6458f8ae14d924a26d4d1dba317.1446892879.git.lukas@wunner.deSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 05 11月, 2015 1 次提交
-
-
由 Shobhit Kumar 提交于
SWF18 is set if the display has been initialized by the pre-os. It also gives what configuration is enabled on which pipe. In skl_sanitize_cdclk, the DPLL sanity check can pass even if GOP/VBIOS is not loaded as BIOS enables DPLL for integrated audio codec related programming. So fisrt check if SWF18 is set and then follow through with other DPLL and CDCLK verification. If not set then for sure we need to sanitize the cdclock. v2: Update the commit message for clarity (Siva) v3: Correct the mask to check for bits[23:0] instead of only bits[16:0]. Had missed checking for PIPE C altogether. Remaining are reserved (Siva) v4: Use ILK_SWF macro for SWF register definitions. Taken from Ville's patch http://lists.freedesktop.org/archives/intel-gfx/2015-November/079480.html Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: NSivakumar Thulasimani <sivakumar.thulasimani@intel.com> Acked-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1446726932-14078-1-git-send-email-shobhit.kumar@intel.comSigned-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 02 11月, 2015 3 次提交
-
-
由 Maarten Lankhorst 提交于
Make pinning and waiting a separate step, and wait for object idle without struct_mutex held. Changes since v1: - Do not wait when a reset is in progress. - Remove call to i915_gem_object_wait_rendering for intel_overlay_do_put_image (Chris Wilson) Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Maarten Lankhorst 提交于
struct_mutex is being locked for every plane in intel_prepare_plane_fb and intel_cleanup_plane_fb. Require the caller to hold the mutex, and only acquire the mutex for each helper call. This way the lock only needs to be acquired twice in ->atomic_commit(). Once for pinning new framebuffers at the start, the second time for unpinning old framebuffer. Changes since v1: - Use mutex_lock_interruptible instead of i915 variant, to prevent a deadlock when called from the reset code. Changes since v2: - Clarify struct_mutex is locked by the caller. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> #v1 Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
由 Maarten Lankhorst 提交于
Move it from intel_crtc_atomic_commit to prepare_plane_fb. Waiting is done before committing, otherwise it's too late to undo the changes. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: NAnder Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
-
- 29 10月, 2015 1 次提交
-
-
由 Rodrigo Vivi 提交于
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: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 26 10月, 2015 1 次提交
-
-
由 Ville Syrjälä 提交于
v2: Rebase due to SKL_DPLLx usage Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1442595836-23981-21-git-send-email-ville.syrjala@linux.intel.comReviewed-by: NJani Nikula <jani.nikula@intel.com>
-
- 22 10月, 2015 5 次提交
-
-
由 Matt Roper 提交于
v2: Don't forget to actually check the cstate->active value when tallying up the number of active CRTC's. (Ander) Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/59561/
-
由 Matt Roper 提交于
We already ensure that pstate->visible = false when crtc->active = false during runtime programming; make sure we follow the same logic when reading out initial hardware state. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/59564/
-
由 Matt Roper 提交于
Calculate pipe watermarks during atomic calculation phase, based on the contents of the atomic transaction's state structure. We still program the watermarks at the same time we did before, but the computation now happens much earlier. While this patch isn't too exciting by itself, it paves the way for future patches. The eventual goal (which will be realized in future patches in this series) is to calculate multiple sets up watermark values up front, and then program them at different times (pre- vs post-vblank) on the platforms that need a two-step watermark update. While we're at it, s/intel_compute_pipe_wm/ilk_compute_pipe_wm/ since this function only applies to ILK-style watermarks and we have a completely different function for SKL-style watermarks. Note that the original code had a memcmp() in ilk_update_wm() to avoid calling ilk_program_watermarks() if the watermarks hadn't changed. This memcmp vanishes here, which means we may do some unnecessary result generation and merging in cases where watermarks didn't change, but the lower-level function ilk_write_wm_values already makes sure that we don't actually try to program the watermark registers again. v2: Squash a few commits from the original series together; no longer leave pre-calculated wm's in a separate temporary structure since it's easier to follow the logic if we just cut over to using the pre-calculated values directly. v3: - Pass intel_crtc instead of drm_crtc to .compute_pipe_wm() entrypoint and use intel_atomic_get_crtc_state() to avoid need for extra casting. (Ander) - Drop unused intel_check_crtc() function prototype. (Ander) Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/60363/
-
由 Matt Roper 提交于
The only platform that still has an update_sprite_wm entrypoint is SKL; on SKL, intel_update_sprite_watermarks just updates intel_plane->wm and then performs a regular watermark update. However intel_plane->wm is only used to update a couple fields in intel_wm_config, and those fields are never used by the SKL code, so on SKL an update_sprite_wm is effectively identical to an update_wm call. Since we're already ensuring that the regular intel_update_wm is called any time we'd try to call intel_update_sprite_watermarks, the whole call is redundant and can be dropped. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/60372/
-
由 Matt Roper 提交于
Determine whether we need to apply this workaround at atomic check time and just set a flag that will be used by the main watermark update routine. Moving this workaround into the atomic framework reduces ilk_update_sprite_wm() to just a standard watermark update, so drop it completely and just ensure that ilk_update_wm() is called whenever a sprite plane is updated in a way that would affect watermarks. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Smoke-tested-by: NPaulo Zanoni <przanoni@gmail.com> Link: http://patchwork.freedesktop.org/patch/60367/
-
- 21 10月, 2015 4 次提交
-
-
由 Maarten Lankhorst 提交于
intel_crtc_disable_noatomic is called from hw readout during init, resume and possibly reset. During init it's too early to have a page flip queued, before suspending all page flips should be finished and during hw reset all page flips should be removed. It's a bug when there are pending flips here, complain with WARN_ON instead of handling it. Signed-off-by: NMaarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/562507A3.3080901@linux.intel.comReviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Tvrtko Ursulin 提交于
Previously rotation was ignored and wrong stride programmed into the plane registers resulting in a corrupt image on screen. v2: Do not access potentialy old plane state at flip time, but store the rotation value at the time of queing the flip. (Ville) v3: No need to pass rotation to intel_queue_mmio_flip since it is available in the crtc. (Ville) Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Testcase: igt/kms_rotation_crc/primary-rotation-90-flip-stress (SKL) Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Tvrtko Ursulin 提交于
Cdclk < crtc_clock is not allowed and suggests a different problem elsewhere in the code. It is more robust and safe to assume no scaling is possible in this case with no other downsides since it will also WARN_ON_ONCE so that this definitely gets noticed. Call it an assert to help new platform bring-up in simulation. v2: Better commit msg and use WARN_ON_ONCE to signify the unexpectedness. v3: Move zero crtc_clock check under the warn. (Ville) Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Shobhit Kumar 提交于
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: NShobhit Kumar <shobhit.kumar@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445344992-14658-1-git-send-email-shobhit.kumar@intel.comReviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-