- 05 Aug, 2015 10 commits
-
-
Paulo Zanoni authored
I was told that the "repurposed D1 definition" is still valid for SKL. It is BDW that is special due to its hotplug bug, so let's special-case BDW instead of HSW. Cc: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
Similar to the ->enable vfunc in patch "drm/i915: Extract a intel_power_well_enable() function". v2 (from Paulo): - Same s/i915_/intel_/ bikeshed as the previous patch. - Update the commit hash. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
Damien Lespiau authored
We need a bit book keeping around power wells' ops->enable(), namely a nice debug message and updating hw_enabled. Let's introduce a intel_power_well_enable() function to make sure all the callers do the same things. v2 (from Paulo): - s/i915_power_well_enable/intel_power_well_enable/ since everything else on this file uses intel_ instead of i915_. - Fix typo in commit message. Signed-off-by: -
Marc Herbert authored
With this simple git diff command one can see that skl_init_workarounds() got two copies of WaBarrierPerformanceFixDisable:skl: git diff -U21 ca6e4405^1 ca6e4405 drivers/gpu/drm/i915/intel_ringbuffer.c This happened when the backmerge of drm-intel-fixes-2015-07-15 Merged the same fix on both sides. Same fix but not identical enough for git: with a different surrounding context; hence the code duplication. This commit merely reverts the output of the git command above = the duplication introduced in the backmerge. (This duplication was found while running git sanity checks on a _linearized_ i915 forklift for ChromeOS.) Signed-off-by:
Marc Herbert <marc.herbert@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
Since active function on VLV immediately activate PSR let's give more time for idleness. Different from core platforms where we have idle_frames count. Also kms_psr_sink_crc now is automated and always get this: [drm:intel_enable_pipe] enabling pipe A [drm:intel_edp_backlight_on] [drm:intel_panel_enable_backlight] pipe [drm:intel_panel_enable_backlight] pipe A [drm:intel_panel_actually_set_backlight] set backlight PWM = 7812 PSR gets enabled somewhere here after backlight. [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x0 [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp PSR gets flushed around here by intel_atomic_commit [drm:vlv_pipe_set_fifo_size] Pipe A FIFO split 511 / 511 / 511 [drm:vlv_update_wm] Setting FIFO watermarks - A: plane=391, cursor=63, sp [drm:intel_set_memory_cxsr] memory self-refresh is enabled [drm:intel_connector_check_state] [CONNECTOR:39:eDP-1] [drm:check_encoder_state] [ENCODER:30:DAC-30] [drm:check_encoder_state] [ENCODER:31:TMDS-31] [drm:check_encoder_state] [ENCODER:36:TMDS-36] [drm:check_encoder_state] [ENCODER:38:TMDS-38] [drm:check_crtc_state] [CRTC:21] [drm:check_crtc_state] [CRTC:26] [drm:intel_psr_activate [i915]] *ERROR* PSR Active [drm:intel_get_hpd_pins] hotplug event received, stat 0x00000000, dig 0x [drm:intel_set_cpu_fifo_underrun_reporting [i915]] *ERROR* pipe A underrun [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe A FIFO Underrun. It is true that in a product we won't keep disabling and enabling planes so frequently, but for safeness let's stay conservative. It is also true that 500ms is an etternity. But PSR is anyway a power saving feature for idle scenario. So if it is idle feature stays on and 500ms to get it reanabled is not that insane. v2: Rebase over intel_psr.c and fix typo. v3: Revival: Manual tests indicated that this is needed. With a short delay there is a huge risk of getting blank screens when planes are being enabled. v4: Revival 2 with reasonable delay. 1/2 sec instead of 5. VBT is 10 sec but actually time for link training what we aren't doing, but with only 100 sec in some cases kms_psr_sink_crc manual was showing blank screen, so let's use this for now. Also changed comment by a FIXME. v5: Rebase after a long time, remove FIXME and update comment above. v6: msecs_to_jiffies is already on delay. remove duplication. v7: use msecs_to_jiffies on schedule_delayed_work call. Reviewed-by: Durgadoss R <durgadoss.r@intel.com> (v4) Signed-off-by: -
Rodrigo Vivi authored
This is just a preparation patch to make clear what operation we are performing. There is no functional change on the sink crc logic. hsw_disable_ips has been moved a bit further in the start function to avoid disabling ips when sink crc is not going to be started. and to avoid goto on this function. v2: explain why hsw_disable_ips() call place has changed. Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
Rafael Antognolli <rafael.antognolli@intel.com> Signed-off-by:
-
Paulo Zanoni authored
First, an introduction. We currently have two types of GTT mmaps: the "normal" old mmap, and the WC mmap. For frontbuffer-related features that have automatic hardware tracking, only the non-WC mmap writes are detected by the hardware. Since inside the Kernel both are treated as ORIGIN_GTT, any features ignoring ORIGIN_GTT because of the hardware tracking are destined to fail. One of the special rules defined for the WC mmaps is that the user should call the dirtyfb IOCTL after he is done using the pointers, so that results in an intel_fb_obj_flush() call. The problem is that the dirtyfb is passing ORIGIN_GTT, so it is being ignored by FBC - even though the hardware tracking is not detecing the WC mmap operations. So in order to fix that without having to give up the automatic hardware tracking for GTT mmaps we transform the flush operation from dirtyfb into a special operation: ORIGIN_DIRTYFB. This commit fixes all the kms_frontbuffer_tracking subtests that contain "fbc" and "mmap-wc" in their names and are currently failing (for a total of 16 subtests). Signed-off-by:
-
Paulo Zanoni authored
Use the appropriate call. I know there's a discussion about whether we need this call here at all, but removing the call means we'll only update FBC after we get the page flip IRQ. So the user may only see the new frame a little after it should. Let's wait just a little bit more before removing this call since we can rely in the HW tracking for accurate flips. Signed-off-by:
-
Paulo Zanoni authored
Because intel_unpin_work_fn() already calls intel_frontbuffer_flip_complete() which will call intel_fbc_flush() which will call intel_fbc_update() when needed. We couldn't fix this previously due to the fact that FBC was not properly behaving as intended on frontbuffer flushes, but now that this is fixed, we can remove the additional call. Signed-off-by:
-
Paulo Zanoni authored
Due to the way busy_bits was handled, we were not doing any flushes if we didn't previously get an invalidate. Since it's possible to get flushes without an invalidate first, remove the busy_bits early return. So now that we don't have the busy_bits guard anymore we'll need the origin check for the GTT tracking (we were not doing anything on GTT flushes due to the GTT check at invalidate()). As a last detail, since we can get multiple consecutive flushes, disable FBC before updating it, otherwise intel_fbc_update() will just keep FBC enabled instead of restarting it. Notice that this does not fix any of the current IGT tests due to the fact that we still have a few intel_fbc() calls at points where we also have the frontbuffer tracking calls: we didn't fully convert to frontbuffer tracking yet. Once we remove those calls and start relying only on the frontbuffer tracking infrastructure we'll need this patch. Signed-off-by:
-
- 31 Jul, 2015 1 commit
-
-
Daniel Vetter authored
Signed-off-by:
-
- 29 Jul, 2015 4 commits
-
-
Hanno Böck authored
As we may like to use a bisection search on the tables in future, we need them to be ordered. For convenience we expect the compiled tables to be order and check on initialisation. However, the validator used the wrong iterators failed to spot the misordered MI tables and instead walked off into the unknown (as spotted by kasan). Signed-off-by:
Hanno Boeck <hanno@hboeck.de> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> [danvet: Again hand-assemble patch ...] Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com>
-
Hanno Böck authored
In the future, we may want to speed up command/register searching using a bisection and so we require them to be in ascending order respectively by command value or register address. However, this was not true for one pair in the MI table; make it so. Signed-off-by:
-
Rodrigo Vivi authored
If we got to the point where we are trying to stop sink CRC the main output of this function was already gotten properly, so don't return the error and let userspace use the crc data. Let's replace the errnos returns with some log messages. Signed-off-by:
-
Rodrigo Vivi authored
Right now if we face any kind of error sink crc calculation stays enabled. So, let's give a shot and try to stop it anyway if it got enabled. Signed-off-by:
-
- 28 Jul, 2015 2 commits
-
-
Chris Wilson authored
When we shrink our working sets, we want to avoid stealing pages from objects that likely to be reused in the near future. We first look at inactive objects before processing active objects - but what about a recently active object that is about to be used again. That object's position in the bound_list is ordered by the time of binding, not the time of last use, so the most recently used inactive object could well be at the head of the shrink list. To compensate, give the object a bump to MRU when it becomes inactive (thus transitioning to the end of the first pass in shrink lists). Conversely, bumping on inactive makes bumping on active useless, since when we do have to reap from the active working set, everything is going to become inactive very quickly and the order pretty much random - just hope for the best at that point, as once we start stalling on active objects, we can hope that the rebinding neatly orders vital objects. Suggested-by:
-
Daniel Vetter authored
Remove the leftovers, yay! AGP for i915 kms died long ago with commit 3bb6ce66 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Nov 13 22:14:16 2013 +0100 drm/i915: Kill legeacy AGP for gen3 kms and with ums now gone to there's really no users any more. Note that device_is_agp is only called when DRIVER_USE_AGP is set and since we've unconditionally cleared that since a while there are really no users left for i915_driver_device_is_agp. Reviewed-by:
-
- 27 Jul, 2015 6 commits
-
-
Daniel Vetter authored
Chris rightfully suggested that documenting fences without documenting the BO tiling tracking doesn't make much sense, so fix that. The important bit to stress here (since it lead to some confusion) is the GEM doesn't really care about tiling. Except for a few select cases where the kernel needs to manage something that userspace can't take care of: Namely the limited number of fences and fixing up swizzling, although we still fail at the later. v2: Move the low-level tiling/swizzling functions and kerneldoc to i915_gem_fence.c and leave only the userspace interface here. Suggested by Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
It fits more with the low-level fence code, and this move leaves only the userspace tiling ioctl handling in i915_gem_tiling.c. Suggested-by:
-
Daniel Vetter authored
Afaict intel_irq_fini never existed. No idea how that one came about. Note: Chris thinks that an irq_fini would be nice and I agree, but this is just to remove some ugly from generated docs. Signed-off-by: -
Daniel Vetter authored
v2: Clarify that this is about fence _registers_. Also clarify that the fence code revokes cpu ptes and not gtt ptes. Both suggested by Chris. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Daniel Vetter authored
No code changes, just moving all the fence related code into a separate file (and avoiding a bunch of forward declarations while at it). Acked-by:
-
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:
-
- 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:
-
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 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:
-
- 15 Jul, 2015 2 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:
-
