- 27 Jul, 2015 1 commit
-
-
Daniel Vetter authored
Sorting became confused and a few new files ended up in strange places. Also move i915_irq.c to core since with the recent-ish extraction of i915_gpu_error.c and intel_hotplug.c it's more and more really just basic irq handling code. When adding new files please don't put them somewhere randomly. Acked-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
- 22 Jul, 2015 3 commits
-
-
Imre Deak authored
This is a requirement for enabling display port HPD support on the port A HPD pin. This support is to be added by follow-up patches. Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
Currently HPD_PORT_A is used as an alias for HPD_NONE to mean that the given port doesn't support long/short HPD pulse detection. SDVO and CRT ports are like this and for these ports we only want to know whether an hot plug event was detected on the corresponding pin. Since at least on BXT we need long/short pulse detection on PORT A as well (added by the next patch) remove this aliasing of HPD_PORT_A/HPD_NONE and let the return value of intel_hpd_pin_to_port() show whether long/short pulse detection is supported on the passed in pin. No functional change. v2: - rebase on top of -nightly (Daniel) - make the check for intel_hpd_pin_to_port() return value more readable (Sivakumar) Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
-
Imre Deak authored
These functions are quite similar, so combine them with the use of a new argument for a function that detects long pulses. This will be also needed by an upcoming patch adding support for BXT long pulse detection. No functional change. v2: - rebase on top -nightly (Daniel) Signed-off-by:
-
- 21 Jul, 2015 7 commits
-
-
Sudip Mukherjee authored
The extra check for connector_type is not required as we are already checking for connector_type != DRM_MODE_CONNECTOR_DisplayPort. The check was added by commit eb3394fa ("drm/i915: Add debugfs test control files for Displayport compliance testing") Signed-off-by:
Sudip Mukherjee <sudip@vectorindia.org> Signed-off-by:
-
Sudip Mukherjee authored
While creating the debugfs file we are setting the inode->i_private to dev. That same dev is passed to these functions as private of struct seq_file via single_open(). Moreover single_open is setting file->private_data->private to dev. So at this point it can never be NULL. This check was added by commit eb3394fa ("drm/i915: Add debugfs test control files for Displayport compliance testing") Signed-off-by:
-
Arun Siluvery authored
The Golden batch carries 3D state at the beginning so that HW starts with a known state. It is carried as a binary blob which is auto-generated from source. The idea was it would be easier to maintain and keep the complexity out of the kernel which makes sense as we don't really touch it. However if you really need to update it then you need to update generator source and keep the binary blob in sync with it. There is a need to patch this in bxt to send one additional command to enable a feature. A solution was to patch the binary data with some additional data structures (included as part of auto-generator source) but it was unnecessarily complicated. Chris suggested the idea of having a secondary batch and execute two batch buffers. It has clear advantages as we needn't touch the base golden batch, can customize secondary/auxiliary batch depending on Gen and can be carried in the driver with no dependencies. This patch adds support for this auxiliary batch which is inserted at the end of golden batch and is completely independent from it. Thanks to Mika for the preliminary review. v2: Strictly conform to the batch size requirements to cover Gen2 and add comments to clarify overflow check in macro (Chris, Mika). v3: aux_batch_offset was declared as u64, change it to u32 (Chris) Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Mika Kuoppala authored
Kunmap the renderstate page on error path. Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Dave Gordon authored
intel_guc_fwif.h contains the subset of the GuC interface that we will need for submission of commands through the GuC. These MUST be kept in sync with the definitions used by the GuC firmware, and updates to this file will (or should) be autogenerated from the source files used to build the firmware. Editing this file is therefore not recommended. i915_guc_reg.h contains definitions of GuC-related hardware: registers, bitmasks, etc. These should match the BSpec. v2: Files renamed & resliced per review comments by Chris Wilson v4: Added DON'T-EDIT-ME warning [Tom O'Rourke] Issue: VIZ-4884 Signed-off-by:Alex Dai <yu.dai@intel.com> Signed-off-by:
Dave Gordon <david.s.gordon@intel.com> Reviewed-by:
Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by:
-
Alex Dai authored
Two new module parameters: "enable_guc_submission" which will turn on submission of batchbuffers via the GuC (when implemented), and "guc_log_level" which controls the level of debugging logged by the GuC and captured by the host. Signed-off-by:
-
Dave Gordon authored
i915_gem_object_create_from_data() is a generic function to save data from a plain linear buffer in a new pageable gem object that can later be accessed by the CPU and/or GPU. We will need this for the microcontroller firmware loading support code. Derived from i915_gem_object_write(), originally by Alex Dai v2: Change of function: now allocates & fills a new object, rather than writing to an existing object New name courtesy of Chris Wilson Explicit domain-setting and other improvements per review comments by Chris Wilson & Daniel Vetter v4: Rebased Issue: VIZ-4884 Signed-off-by:
-
- 20 Jul, 2015 1 commit
-
-
Daniel Vetter authored
This reverts commit 6adfb1ef. Ironlake RPS code runs under an irqsave spinlock and hence sleeping isn't allowed. Not a this long delay while blocking irqs isn't great at all, but fixing the locking scheme is a lot more involved. So just revert for now. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by:
kernel test robot <ying.huang@intel.com> Signed-off-by:
-
- 17 Jul, 2015 4 commits
-
-
Daniel Vetter authored
Signed-off-by: -
Damien Lespiau authored
Time to light a candle and remove the preliminary_hw_support flag. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
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:
-
Mika Kuoppala authored
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:
Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by:
-
- 15 Jul, 2015 16 commits
-
-
Daniel Vetter authored
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:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
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 authored
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 authored
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: -
Maarten Lankhorst authored
This can only fail because of a bug in the code. Suggested-by:
-
Maarten Lankhorst authored
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 Stone <daniels@collabora.com> Signed-off-by:
-
Maarten Lankhorst authored
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 authored
Huzzah! \o/ Signed-off-by:
-
Arun Siluvery authored
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 authored
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 authored
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:
-
Arun Siluvery authored
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:
-
Nick Hoath authored
v2: Patch leakage fixed Signed-off-by:
Nick Hoath <nicholas.hoath@intel.com> Reviewed-by:
-
Daniel Vetter authored
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:
-
Maarten Lankhorst authored
This fixes the breakage caused by commit eddfcbcd 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:
Matt Roper <matthew.d.roper@intel.com> Tested-by(IVB): Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
Fill in driver type, hsync, vrefresh and name. Those members are not read out but can be calculated from the mode. Signed-off-by:
-
- 14 Jul, 2015 8 commits
-
-
Akash Goel authored
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:
Akash Goel <akash.goel@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Akash Goel authored
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:
-
Maarten Lankhorst authored
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 authored
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 authored
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 authored
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 authored
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=90396Signed-off-by:
-
Maarten Lankhorst authored
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:
-
