- 14 Aug, 2015 6 commits
-
-
Maarten Lankhorst authored
Connectors are updated atomically now, so the only interaction with the encoder is through base.crtc. If it's NULL the encoder's not part of any crtc, and if it's not NULL then active should be equal to crtc_state->active. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Maarten Lankhorst authored
This is handled by the atomic core now, no need to check this for ourself. Signed-off-by:
-
Maarten Lankhorst authored
Right now dpms callbacks can still fiddle with the connector state, but it can only turn connectors off. This is remediated by only checking crtc->state->active when the connector is active, and ignore crtc->state->active when the connector is off. connectors_active is no longer checked, and will be removed later in this series together with dpms. Another check for !encoder->crtc is performed by check_encoder_state too, so it can be removed. Changes since v1: - Add commit message. - rename state to old_state. - Move deletion of mst_port check to mst patch. Changes since v2: - Fix a null pointer dereference on MST now hw readout is fixed. Signed-off-by:
-
Maarten Lankhorst authored
Fully remove the MST connector from the atomic state, and remove the early returns in check_*_state for MST connectors. With atomic the state can be made consistent all the time. Thanks to Sivakumar Thulasimani for the idea of using drm_atomic_helper_set_config. Changes since v1: - Remove the MST check in intel_connector_check_state too. Changes since v2: - Use drm_atomic_helper_set_config. Signed-off-by:
Sivakumar Thulasimani <sivakumar.thulasimani@intel.com> Signed-off-by:
-
Maarten Lankhorst authored
First step in removing dpms and validating atomic state. There can still be a mismatch in the connector state because the dpms callbacks are still used, but this can not happen immediately after a modeset. Signed-off-by:
-
Maarten Lankhorst authored
Set connectors_changed to force a modeset if the panel fitter's force enabled on eDP. Changes since v1: - Use connectors_changed instead of active_changed because it's a routing update. Signed-off-by:
-
- 06 Aug, 2015 1 commit
-
-
Daniel Vetter authored
We need a few core drm patches to be able to merge Maarten's series to convert DPMS over to atomic. Signed-off-by:Daniel Vetter <daniel.vetter@intel.com>
-
- 05 Aug, 2015 14 commits
-
-
Jesse Barnes authored
Looks like 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. introduced the unconditional calling of disable_shared_dpll, but didn't fix up pre-gen5 to avoid the BUG_ON at the top of the function. So change the BUG_ON into a gen check (alternately we could move the BUG_ON until later, since we shouldn't have a pll struct here either, but this seems clearer to read). This fixes a crash on load on my x200s platform. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by:
-
Arun Siluvery authored
Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Tested-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Animesh Manna authored
This patch contains the changes to remove the byte swapping logic introduced with old dmc firmware. While debugging PC10 entry issue for skylake found with latest dmc firmware version 1.18 without byte swapping dmc is working fine and able to enter PC10. Note that apparently this was changed with dmc version 1.0 and earlier ones indeed are byteswapped like this ... v1: Initial version. v2: Corrected firmware size during memcpy(). (Suggested by Sunil) Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Sunil Kamath <sunil.kamath@intel.com> Signed-off-by:
Animesh Manna <animesh.manna@intel.com> Signed-off-by:
Vathsala Nagaraju <vathsala.nagaraju@intel.com> Reviewed-by:
A.Sunil Kamath <sunil.kamath@intel.com> [danvet: Add note that this only holds for released dmc firmware.] Signed-off-by:
-
Thulasimani,Sivakumar authored
BPP bits defined in VBT should be used only on panels whose edid version is 1.3 or older. EDID version 1.4 introduced offsets where bpp is defined and read into display_info, hence bpp from VBT will be used only when bpc in display_info is zero. v2: use display_info.bpc for deciding when to use vbt_bpp (Jani) Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
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:
-
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:
-
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 10 commits
-
-
Maarten Lankhorst authored
This is required for DPMS to work correctly, during a modeset the DPMS property should be turned off, unless the state is crtc is made active in which case it should be set to DPMS on. Changes since v1: - Set DPMS to off when a connector is removed from a crtc too. - Update the legacy dpms property too. - Add an exception for the legacy dpms paths, it updates its own state. Changes since v2: - Do not preserve dpms property. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Maarten Lankhorst authored
This is required to properly handle failing dpms calls. When making a wait in i915 interruptible, I've noticed that the dpms sequence could fail with -ERESTARTSYS because it was waiting interruptibly for flips. So from now on allow drivers to fail in their connector dpms callback. Encoder and crtc dpms callbacks are unaffected. Changes since v1: - Update kerneldoc for the drm helper functions. Signed-off-by:
-
Maarten Lankhorst authored
In intel it's useful to keep track of some state changes with old crtc state vs new state, for example to disable initial planes or when a modeset's prevented during fastboot. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
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:
-
Maarten Lankhorst authored
This can be a separate case from mode_changed, when connectors stay the same but only the mode is different. Drivers may choose to implement specific optimizations to prevent a full modeset for this case. Changes since v1: - Update kerneldocs slightly. Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
- 26 Jul, 2015 1 commit
-
-
Rodrigo Vivi authored
By Vesa's DP 1.2 Spec this counter has 4 bits [3:0]. This mask is wrong since when the counter was introduced by myself on commit ad9dc91b Author: Rodrigo Vivi <rodrigo.vivi@gmail.com> Date: Tue Sep 16 19:18:12 2014 -0400 drm/i915: Fix Sink CRC Signed-off-by:
-
- 24 Jul, 2015 1 commit
-
-
Dave Airlie authored
Merge tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel into drm-next connector hotplug locking cleanup and fixes to make it save against atomic. Note that because of depencies this is based on top of the drm-intel-next pull, so that one needs to go in before this one. I've also thrown in the mode_group removal on top since it's defunct, never worked really, no one seems to care and the code can be resurrected easily. * tag 'topic/connector-locking-2015-07-23' of git://anongit.freedesktop.org/drm-intel: drm: gc now dead mode_group code drm: Stop filtering according to mode_group in getresources drm: Roll out drm_for_each_{plane,crtc,encoder} drm/cma-helper: Fix locking in drm_fb_cma_debugfs_show drm: Roll out drm_for_each_connector more drm: Amend connector list locking rules drm/radeon: Take all modeset locks for DP MST hotplug drm/i915: Take all modeset locks for DP MST hotplug drm: Check locking in drm_for_each_fb drm/i915: Use drm_for_each_fb in i915_debugfs.c drm: Check locking in drm_for_each_connector drm/fbdev-helper: Grab mode_config.mutex in drm_fb_helper_single_add_all_connectors drm/probe-helper: Grab mode_config.mutex in poll_init/enable drm: Add modeset object iterators drm: Simplify drm_for_each_legacy_plane arguments
-
