summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-07-22drm: Add modeset object iteratorsDaniel Vetter6-39/+49
And roll them out across drm_* files. The point here isn't code prettification (it helps with that too) but that some of these lists aren't static any more. And having macros will gives us a convenient place to put locking checks into. I didn't add an iterator for props since that's only used by a list_for_each_entry_safe in the driver teardown code. Search&replace was done with the below cocci spatch. Note that there's a bunch more places that didn't match and which would need some manual changes, but I've intentially left these out for this mostly automated patch. iterator name drm_for_each_crtc; struct drm_crtc *crtc; struct drm_device *dev; expression head; @@ - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) { + drm_for_each_crtc (crtc, dev) { ... } @@ iterator name drm_for_each_encoder; struct drm_encoder *encoder; struct drm_device *dev; expression head; @@ - list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) { + drm_for_each_encoder (encoder, dev) { ... } @@ iterator name drm_for_each_fb; struct drm_framebuffer *fb; struct drm_device *dev; expression head; @@ - list_for_each_entry(fb, &dev->mode_config.fb_list, head) { + drm_for_each_fb (fb, dev) { ... } @@ iterator name drm_for_each_connector; struct drm_connector *connector; struct drm_device *dev; expression head; @@ - list_for_each_entry(connector, &dev->mode_config.connector_list, head) { + drm_for_each_connector (connector, dev) { ... } Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-22drm: Simplify drm_for_each_legacy_plane argumentsDaniel Vetter3-4/+4
No need to pass the planelist when everyone just uses dev->mode_config.plane_list anyway. I want to add a pile more of iterators with unified (obj, dev) arguments. This is just prep. Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-17drm/i915: Update DRIVER_DATE to 20150717Daniel Vetter1-1/+1
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-17drm/i915/skl: Drop the preliminary_hw_support flagDamien Lespiau1-2/+0
Time to light a candle and remove the preliminary_hw_support flag. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-17drm/i915/skl: Don't expose the top most plane on gen9 displayDamien Lespiau1-4/+12
on SKL/BXT, the top most plane hardware is shared between the legacy cursor registers and an actual plane. Daniel and Ville don't want to expose 2 DRM planes and would rather expose a CURSOR plane that has all the usual plane properties, and that's a blocker for lifting the prelimary_hw_support flag. Unfortunately noone has had the time to finish this yet, but lifting the prelimary_hw_support flag is long overdue. As an intermediate solution we can merely not expose the top most plane Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-17drm/i915: Fix divide by zero on watermark updateMika Kuoppala1-1/+3
Fix divide by zero if we end up updating the watermarks with zero dotclock. This is a stop gap measure to allow module load in cases where our state keeping fails. v2: WARN_ON added (Paulo) Cc: Paulo Zanoni <przanoni@gmail.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Invert fastboot checkDaniel Vetter1-11/+14
Fastboot should only downgrade a modeset if we have a match, not be used to upgrade to a full modeset. Otherwise we can only use it in a very restricted way: Initial modeset when the request mode is the preferred one of the panel and there's still a pfit active. And that only works because our mode_from_pipe_config fills in the wrong mode (it takes the adjusted mode, not the requested one). But we want fast modesets everywhere even after boot-up (especially for testing, but not only there). Hence we need to be able to make any modeset a fast one, which means we need to invert the logic and optionally downgrade a modeset. Note that this needs ->connector_changed split out from ->mode_changed otherwise it's not going to work (because we might loose a modeset because connectors changed but otherwise the config matches). As soon as that's merged we can drop the i915.fastboot check from this code. Also make sure that we don't accidentally clear any_ms and that we add the planes for any kind of modeset. Finally rename fastboot to fastset (yeah it's a silly name) since this really isn't about booting all that much. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Clarify logic for initial modesetDaniel Vetter2-23/+15
Currently we both set mode->private_flags to some value and also use the pipe_config quirk. But since the pipe_config quirk isn't tied to the lifetime of the mode object we need to check both. Simplify this by only using mode.private_flags and stop using the INHERITED_MODE quirk. Also for clarity add an explicit #define for that driver priavete mode flag. By using crtc_state->mode_changed we can also remove the recalc local variable. Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Unconditionally check gmch pfit stateDaniel Vetter1-15/+5
Now that we recompute the pipe config for all CRTCs that have changed we don't have problems with stale configuration data for the global pfit and can remove this hack. Yay! Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15Merge tag 'drm-intel-fixes-2015-07-15' into drm-intel-next-queuedDaniel Vetter9825-227403/+578808
Backmerge fixes since it's getting out of hand again with the massive split due to atomic between -next and 4.2-rc. All the bugfixes in 4.2-rc are addressed already (by converting more towards atomic instead of minimal duct-tape) so just always pick the version in next for the conflicts in modeset code. All the other conflicts are just adjacent lines changed. Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem_gtt.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h drivers/gpu/drm/i915/intel_ringbuffer.h Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-15drm/i915: always disable irqs in intel_pipe_update_startMaarten Lankhorst3-25/+14
This can only fail because of a bug in the code. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> [danvet: Squash in follow-up to also remove start_vbl_count from intel_crtc->atomic and put it into the intel_crtc directly - it's not precomputed state.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Remove use of runtime pm in atomic commit functionsMaarten Lankhorst1-7/+0
We needed this originally for updating pagetables in plane commit functions. But that's extracted into prepare/cleanup now. The other issue was running updates when the pipe was off. That's also now fixed. Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Call plane update functions directly from intel_atomic_commit.Maarten Lankhorst1-6/+8
Now that there's only a single path for all atomic updates we can call intel_(pre/post)_plane_update from intel_atomic_commit directly. This makes the intention more clear. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Use full atomic modeset.Maarten Lankhorst6-372/+43
Huzzah! \o/ Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915/gen9: Add WaSetDisablePixMaskCammingAndRhwoInCommonSliceChickenArun Siluvery2-2/+15
In Indirect context w/a batch buffer, +WaSetDisablePixMaskCammingAndRhwoInCommonSliceChicken v2: SKL revision id was used for BXT, copy paste error found during internal review (Bob Beckett). v3: explain why part of the WA is in Per ctx batch (Mika) Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915/gen9: Add WaFlushCoherentL3CacheLinesAtContextSwitch workaroundArun Siluvery2-0/+19
In Indirect context w/a batch buffer, +WaFlushCoherentL3CacheLinesAtContextSwitch:skl,bxt v2: address static checker warning where unsigned value was checked for less than zero which is never true (Dan Carpenter). v3: The WA uses default value of GEN8_L3SQCREG4 during flush but that disables some other WA; update default value to retain it and document dependency (Mika). Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915/gen9: Add WaDisableCtxRestoreArbitration workaroundArun Siluvery1-2/+11
In Indirect and Per context w/a batch buffer, +WaDisableCtxRestoreArbitration v2: SKL revision id was used for BXT, copy paste error found during internal review (Bob Beckett). v3: use updated macro. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Robert Beckett <robert.beckett@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Enable WA batch buffers for Gen9Arun Siluvery1-3/+47
This patch only enables support for Gen9, the actual WA will be initialized in subsequent patches. The WARN that we use to warn user if WA batch support is not available for a particular Gen is replaced with DRM_ERROR as warning here doesn't really add much value. v2: include all infrastructure bits in this patch so that subsequent changes only correspond the WA added (Chris) v3: use updated macro. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915/gen9: Implement WaDisableKillLogic for gen 9Nick Hoath2-0/+5
v2: Patch leakage fixed Signed-off-by: Nick Hoath <nicholas.hoath@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Use expcitly fixed type in compat32 structsDaniel Vetter2-5/+14
I was confused shortly whether the compat was needed for the int, until I noticed the pointer in the original. Also remove typedef. v2: Review from Chris. - Add comments. - Also change the int param in the original structure. Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: Fix noatomic crtc disabling, v2.Maarten Lankhorst1-0/+1
This fixes the breakage caused by commit eddfcbcdc27fbecb33bff098967bbdd7ca75bfa6 Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Mon Jun 15 12:33:53 2015 +0200 drm/i915: Update less state during modeset. No need to repeatedly call update_watermarks, or update_fbc. Down to a single call to update_watermarks in .crtc_enable Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Add missing shared dpll disable to the noatomic disable function. This function will be replaced by its atomic counterpart soon. Changes since v1: - intel_crtc->active and watermarks are fixed by a patch from Patrik Jakobsson Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-15drm/i915: fill in more mode membersMaarten Lankhorst1-0/+5
Fill in driver type, hsync, vrefresh and name. Those members are not read out but can be calculated from the mode. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Added BXT check in HAS_CORE_RING_FREQ macroAkash Goel1-1/+1
Updated the HAS_CORE_RING_FREQ macro to add the broxton check, so as to disallow the programming & read of ring frequency table for it. Issue: VIZ-5144 Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Add HAS_CORE_RING_FREQ macroAkash Goel3-2/+5
Added a new HAS_CORE_RING_FREQ macro, currently used in gen6_update_ring_freq & i915_ring_freq_table debugfs function. The programming & read of ring frequency table is needed for newer GEN(>=6) platforms, except VLV/CHV. Issue: VIZ-5144 Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Akash Goel <akash.goel@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Make intel_display_suspend atomic, try 2.Maarten Lankhorst2-4/+50
Calculate all state using a normal transition, but afterwards fudge crtc->state->active back to its old value. This should still allow state restore in setup_hw_state to work properly. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Always force a modeset in intel_crtc_restore_mode, v2.Maarten Lankhorst1-42/+16
And get rid of things that are no longer true. This function is only used for forcing a modeset when encoder properties are changed. Because this is not yet done atomically, assume a full modeset is needed and force a modeset on the crtc. Changes since v1: - s/reset/force modeset/ Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Update power domains on readout.Maarten Lankhorst1-26/+50
This allows us to get rid of the set_init_power in modeset_update_crtc_domains. The state should be sanitized enough after setup_hw_state to not need the init power. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Get rid of unused transitional members.Maarten Lankhorst2-74/+18
The previous commit converted hw readout to atomic, all the new_* members were used for restoring the old state, but with the conversion of suspend to atomic there's no use left for them. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Convert resume to atomic.Maarten Lankhorst4-24/+60
Instead of all the ad-hoc updating, duplicate the old state first before reading out the hw state, then restore it. intel_display_resume is a new function that duplicates the sw state, then reads out the hw state, and commits the old state. intel_display_setup_hw_state now only reads out the atomic state. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Readout initial hw mode.Maarten Lankhorst2-29/+44
drm/i915: Readout initial hw mode, v2. Atomic requires a mode blob when crtc_state->enable is true, or you get a huge warn_on. With a few tweaks the mode we read out from hardware could be used as the real mode without a modeset, but this requires too much testing, so for now force a modeset the first time the mode blob's updated. This preserves the old behavior, because previously we never set the initial mode, which always meant that a modeset happened when the mode was first set. Changes since v1: - Add a description in intel_modeset_readout_hw_state of how the recalculation is done. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Calculate vblank timestamping constants before enabling vblank.Maarten Lankhorst1-0/+1
This is required to properly initialize vblanks on the active crtc. Without it drm_calc_vbltimestamp_from_scanoutpos can fail with crtc 0: Noop due to uninitialized mode. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Zero the mode in intel_sanitize_crtc when force disabling.Maarten Lankhorst1-1/+1
There is a WARN_ON in drm_atomic_crtc_check for this when exposing the atomic property. If the mode_blob still exists, but enable = false then all updates are rejected with -EINVAL. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Fix reference leak in intel_modeset_readout_hw_state.Maarten Lankhorst1-0/+1
Unreference the old mode_blob by calling the crtc_destroy_state helper before zeroing the crtc_state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Rework plane readout.Maarten Lankhorst3-86/+8
All non-primary planes get disabled during hw readout, this reduces complexity and means not having to do some plane visibility checks during the first commit. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Added Programming of the MOCSPeter Antoine6-2/+413
This change adds the programming of the MOCS registers to the gen 9+ platforms. The set of MOCS configuration entries introduced by this patch is intended to be minimal but sufficient to cover the needs of current userspace - i.e. a good set of defaults. It is expected to be extended in the future to provide further default values or to allow userspace to redefine its private MOCS tables based on its demand for additional caching configurations. In this setup, userspace should only utilize the first N entries, higher entries are reserved for future use. It creates a fixed register set that is programmed across the different engines so that all engines have the same table. This is done as the main RCS context only holds the registers for itself and the shared L3 values. By trying to keep the registers consistent across the different engines it should make the programming for the registers consistent. v2: -'static const' for private data structures and style changes.(Matt Turner) v3: - Make the tables "slightly" more readable. (Damien Lespiau) - Updated tables fix performance regression. v4: - Code formatting. (Chris Wilson) - re-privatised mocs code. (Daniel Vetter) v5: - Changed the name of a function. (Chris Wilson) v6: - re-based - Added Mesa table entry (skylake & broxton) (Francisco Jerez) - Tidied up the readability defines (Francisco Jerez) - NUMBER of entries defines wrong. (Jim Bish) - Added comments to clear up the meaning of the tables (Jim Bish) Signed-off-by: Peter Antoine <peter.antoine@intel.com> v7 (Francisco Jerez): - Don't write L3-specific MOCS_ESC/SCC values into the e/LLC control tables. Prefix L3-specific defines consistently with L3_ and e/LLC-specific defines with LE_ to avoid this kind of confusion in the future. - Change L3CC WT define back to RESERVED (matches my hardware documentation and the original patch, probably a misunderstanding of my own previous comment). - Drop Android tables, define new minimal tables more suitable for the open source stack. - Add comment that the MOCS tables are part of the kernel ABI. - Move intel_logical_ring_begin() and _advance() calls one level down (Chris Wilson). - Minor formatting and style fixes. v8 (Francisco Jerez): - Add table size sanity check to emit_mocs_control/l3cc_table() (Chris Wilson). - Add comment about undefined entries being implicitly set to uncached for forwards compatibility. v9 (Francisco Jerez): - Minor style fixes. Signed-off-by: Francisco Jerez <currojerez@riseup.net> Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Remove unused compat32 codeDaniel Vetter1-125/+0
Totatlly forgotten that we have these when nuking all the UMS code. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Remove plane_config from struct intel_crtc, v2.Maarten Lankhorst2-10/+10
Nothing depends on this outside initial hw readout, so keep this struct on the stack instead. Changes since v1: - Remove unrelated changes. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Update missing properties in find_initial_plane_objMaarten Lankhorst1-2/+11
The src and crtc rectangles were never set, resulting in the primary plane being made invisible on first atomic update. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Allow fuzzy matching in pipe_config_compare, v2.Maarten Lankhorst1-61/+157
Instead of doing ad-hoc checks we already have a way of checking if the state is compatible or not. Use this to force a modeset. Only during modesets, or with PIPE_CONFIG_QUIRK_INHERITED_MODE we should check if a full modeset is really needed. Fastboot will allow the adjust parameter to ignore some stuff too, and it will fix up differences in state that are ignored by the compare function. Changes since v1: - Increase the value of the lowest m/n to prevent truncation. - Dump pipe config when fastboot's used, without a modeset. - Add adjust parameter to intel_compare_link_m_n, which is used to adjust m2_n2 if it's a multiple of m_n. - Add exact parameter intel_compare_m_n. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Do not use plane_config in intel_fbdev.cMaarten Lankhorst1-8/+6
Use the atomic state instead, this allows removing plane_config from the crtc after the full hw readout is completed. The size can be found in the fb, no need for the plane_config. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Do not update pfit state when toggling crtc enabled.Maarten Lankhorst4-38/+48
There's not much point for calculating the changes for the old state. Instead just disable all scalers when disabling. It's probably good enough to just disable the crtc_scaler, but just in case there's a bug disable all scalers. This means intel_atomic_setup_scalers is only called in the crtc check function now, so all the transitional code can be removed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Only update state on crtc's that are part of the atomic state.Maarten Lankhorst1-1/+2
This is probably hard to hit right now because in most cases all atomic locks are taken, but after conversion to atomic this will make it more likely to corrupt the crtc->config pointer, resulting in hard to find bugs. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Do not call intel_crtc_disable if the crtc is already disabled.Maarten Lankhorst1-4/+2
When resuming with dpms off, the following warn can happen: [ 118.334082] ------------[ cut here ]------------ [ 118.334105] WARNING: CPU: 2 PID: 2274 at drivers/gpu/drm/i915/intel_display.c:6319 __intel_set_mode+0xae5/0xb90 [i915]() [ 118.334106] WARN_ON(!crtc->state->enable) [ 118.334137] Modules linked in: i915 [ 118.334139] CPU: 2 PID: 2274 Comm: kworker/u16:117 Not tainted 4.2.0-rc2-fixes+ #4148 [ 118.334140] Hardware name: LENOVO 2349AV8/2349AV8, BIOS G1ETA5WW (2.65 ) 04/15/2014 [ 118.334144] Workqueue: events_unbound async_run_entry_fn [ 118.334147] ffffffffc017eef0 ffff8800ada93998 ffffffff817aa62a 0000000080000001 [ 118.334149] ffff8800ada939e8 ffff8800ada939d8 ffffffff810807e1 ffff8800ada939c8 [ 118.334151] ffff8800cea3b3d8 0000000000000000 ffff8800ad86b008 ffff880117705668 [ 118.334151] Call Trace: [ 118.334155] [<ffffffff817aa62a>] dump_stack+0x4f/0x7b [ 118.334157] [<ffffffff810807e1>] warn_slowpath_common+0x81/0xc0 [ 118.334158] [<ffffffff81080861>] warn_slowpath_fmt+0x41/0x50 [ 118.334173] [<ffffffffc0120375>] __intel_set_mode+0xae5/0xb90 [i915] [ 118.334188] [<ffffffffc0121312>] ? intel_modeset_compute_config+0x52/0xb40 [i915] [ 118.334191] [<ffffffff8144de53>] ? drm_atomic_set_fb_for_plane+0x63/0x80 [ 118.334205] [<ffffffffc01269d9>] intel_set_mode+0x29/0x60 [i915] [ 118.334219] [<ffffffffc012730a>] intel_crtc_restore_mode+0x13a/0x1f0 [i915] [ 118.334232] [<ffffffffc0101160>] ? gen6_write16+0x250/0x250 [i915] [ 118.334246] [<ffffffffc01283ec>] intel_modeset_setup_hw_state+0x89c/0xcd0 [i915] [ 118.334248] [<ffffffff8137d260>] ? pci_pm_thaw+0x90/0x90 [ 118.334255] [<ffffffffc00ac11b>] i915_drm_resume+0xcb/0x160 [i915] [ 118.334262] [<ffffffffc00ac1d2>] i915_pm_resume+0x22/0x30 [i915] [ 118.334263] [<ffffffff8137d2c3>] pci_pm_resume+0x63/0xa0 [ 118.334266] [<ffffffff81467550>] dpm_run_callback+0x70/0x420 [ 118.334267] [<ffffffff81467cbd>] device_resume+0x9d/0x1c0 [ 118.334269] [<ffffffff814673d0>] ? initcall_debug_start+0x60/0x60 [ 118.334270] [<ffffffff81467dfc>] async_resume+0x1c/0x50 [ 118.334271] [<ffffffff810a6a94>] async_run_entry_fn+0x34/0xd0 [ 118.334273] [<ffffffff8109d4ad>] process_one_work+0x1dd/0x7e0 [ 118.334275] [<ffffffff8109d41a>] ? process_one_work+0x14a/0x7e0 [ 118.334276] [<ffffffff8109daf9>] worker_thread+0x49/0x450 [ 118.334278] [<ffffffff8109dab0>] ? process_one_work+0x7e0/0x7e0 [ 118.334280] [<ffffffff810a3cb9>] kthread+0xf9/0x110 [ 118.334282] [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90 [ 118.334284] [<ffffffff817b414f>] ret_from_fork+0x3f/0x70 [ 118.334286] [<ffffffff810a3bc0>] ? insert_kthread_work+0x90/0x90 [ 118.334287] ---[ end trace 01f2cf6371b82d7a ]--- This warn is harmless, and can be fixed by not calling intel_crtc_disable when the crtc is already disabled. Reported-and-Tested-by: Jörg Otte <jrg.otte@gmail.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14Revert "drm/i915: Declare the swizzling unknown for L-shaped configurations"Daniel Vetter1-11/+1
This reverts commit 19ee835cdb0b5a8eb11a68f25a51b8039d564488. It breaks existing old userspace which doesn't handle UNKNOWN swizzling correct. Yes UNKNOWN was a thing back in 2009 and probably still is on some other platforms, but it still pretty clearly broke the testers machine. If we want this we need to extend the ioctl with new paramters that only new userspace looks at. Cc: Harald Arnesen <harald@skogtun.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: Harald Arnesen <harald@skogtun.org> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-14drm/i915/skl: Restrict the ring frequency table programming to SKLAkash Goel1-1/+2
Ring frequency table programming is not required on BXT. Added separate checks to enable the programming only for SKL & skip for BXT. v2: Removed the BXT check from gen6_update_ring_freq function Issue: VIZ-5144 Signed-off-by: Akash Goel <akash.goel@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi at intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-14drm/i915: Forward all core DRM ioctls to core compat handlingTvrtko Ursulin1-1/+1
Previously only core DRM ioctls under the DRM_COMMAND_BASE were being forwarded, but the drm.h header suggests (and reality confirms) ones after (and including) DRM_COMMAND_END should be forwarded as well. We need this to correctly forward the compat ioctl for the botched-up addfb2.1 extension. Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: stable@vger.kernel.org # 4.1+ [danvet: Explain why this is suddenly needed and add cc: stable.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-13drm/i915: fix oops in primary_check_planeDaniel Vetter1-1/+1
On Sun, Jul 12, 2015 at 09:52:51AM -0700, Linus Torvalds wrote: > On Sun, Jul 12, 2015 at 1:03 AM, Jörg Otte <jrg.otte@gmail.com> wrote: > > BUG: unable to handle kernel NULL pointer dereference at 0000000000000009 > > IP: [<ffffffffbd3447bb>] 0xffffffffbd3447bb > > Ugh. Please enable KALLSYMS to get sane symbols. > > But yes, "crtc_state->base.active" is at offset 9 from "crtc_state", > so it's pretty clearly just that change frm > > - if (intel_crtc->active) { > + if (crtc_state->base.active) { > > and "crtc_state" is NULL. > > And the code very much knows that crtc_state can be NULL, since it's > initialized with > > crtc_state = state->base.state ? > intel_atomic_get_crtc_state(state->base.state, > intel_crtc) : NULL; > > Tssk. Daniel? Should I just revert that commit dec4f799d0a4 > ("drm/i915: Use crtc_state->active in primary check_plane func") for > now, or is there a better fix? Like just checking crtc_state for NULL? Indeed embarrassing. I've missed that we still have 1 caller left that's using the transitional helpers, and those don't fill out plane_state->state backpointers to the global atomic update since there is no global atomic update for transitional helpers. Below diff should fix this - we need to preferentially check crts_state->active and if that's not set intel_crtc->active should yield the right result for the one remaining caller (it's in the crtc_disable paths). This fixes a regression introduced in commit dec4f799d0a4c9edae20512fa60b0a36f3299ca2 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 7 11:15:47 2015 +0200 drm/i915: Use crtc_state->active in primary check_plane func which was quickly reverted in commit 01e2d0627a9a6edb24c37db45db5ecb31e9de808 Author: Linus Torvalds <torvalds@linux-foundation.org> Date: Sun Jul 12 15:00:20 2015 -0700 Revert "drm/i915: Use crtc_state->active in primary check_plane func" Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Jörg Otte <jrg.otte@gmail.com> Reported-and-tested-by: Jörg Otte <jrg.otte@gmail.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-13drm/i915: remove unused has_dma_mapping flagImre Deak5-15/+2
After the previous patch this flag will check always clear, as it's never set for shmem backed and userptr objects, so we can remove it. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Yeah this isn't really fixes but it's a nice cleanup to clarify the code but not really worth the hassle of backmerging. So just add to -fixes, we're still early in -rc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-07-13drm/i915: Fix missing return warning for !CONFIG_DEBUGFSDaniel Vetter1-1/+2
This broken code was introduced in commit aa7471d228eb6dfddd0d201ea9746d6a2020972a Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 1 11:15:21 2015 +0300 drm/i915: add i915 specific connector debugfs file for DPCD v2: Drop hunk that accidentally crept in. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: François Valenduc <francoisvalenduc@gmail.com> Reported-by: François Valenduc <francoisvalenduc@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
2015-07-13drm/i915: avoid leaking DMA mappingsImre Deak2-17/+43
We have 3 types of DMA mappings for GEM objects: 1. physically contiguous for stolen and for objects needing contiguous memory 2. DMA-buf mappings imported via a DMA-buf attach operation 3. SG DMA mappings for shmem backed and userptr objects For 1. and 2. the lifetime of the DMA mapping matches the lifetime of the corresponding backing pages and so in practice we create/release the mapping in the object's get_pages/put_pages callback. For 3. the lifetime of the mapping matches that of any existing GPU binding of the object, so we'll create the mapping when the object is bound to the first vma and release the mapping when the object is unbound from its last vma. Since the object can be bound to multiple vmas, we can end up creating a new DMA mapping in the 3. case even if the object already had one. This is not allowed by the DMA API and can lead to leaked mapping data and IOMMU memory space starvation in certain cases. For example HW IOMMU drivers (intel_iommu) allocate a new range from their memory space whenever a mapping is created, silently overriding a pre-existing mapping. Fix this by moving the creation/removal of DMA mappings to the object's get_pages/put_pages callbacks. These callbacks already check for and do an early return in case of any nested calls. This way objects of the 3. case also become more like the other object types. I noticed this issue by enabling DMA debugging, which got disabled after a while due to its internal mapping tables getting full. It also reported errors in connection to random other drivers that did a DMA mapping for an address that was previously mapped by i915 but was never released. Besides these diagnostic messages and the memory space starvation problem for IOMMUs, I'm not aware of this causing a real issue. The fix is based on a patch from Chris. v2: - move the DMA mapping create/remove calls to the get_pages/put_pages callbacks instead of adding new callbacks for these (Chris) v3: - also fix the get_page cache logic on the userptr async path (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit v1.2.3 (git 2.39.0) at 2025-02-05 18:02:43 +0300