- 20 May, 2014 30 commits
-
-
Ville Syrjälä authored
On CHV pipe C can driver only port D, and pipes A and B can drivbe only ports B and C. Configure the crtc_mask appropriately to reflect that. v2: Moar braces (Jani) Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Rafael Barbalho authored
Add support for the third pipe in cherrview v2: Don't use spaces for indentation (Jani) Wrap long lines Reviewed-by:Imre Deak <imre.deak@intel.com> Signed-off-by:
Rafael Barbalho <rafael.barbalho@intel.com> [vsyrjala: slightly massaged the patch] Signed-off-by:
-
Rafael Barbalho authored
Cherryview also needs this WA. Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
We implement the following workarounds: * WaDisableAsyncFlipPerfMode:chv * WaProgramMiArbOnOffAroundMiSetContext:chv v2: Drop WaDisableSemaphoreAndSyncFlipWait note Signed-off-by:
-
Ville Syrjälä authored
Reviewed-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ville Syrjälä authored
This workaround is listed for CHV, but not for BDW. However BSpec notes that on BDW CSunit clock gating is always disabled irrespective of the relevant bit in the GEN6_UGCTL1 registers. For CHV however, such text is not present in BSpec, so it seems safer to just set the bit. Reviewed-by:
-
Ville Syrjälä authored
BDW has the same requirement but the w/a database doens't list this w/a for BDW. Seems to be another one of those "stick a bunch of known workarounds into this bag and write something on the label" type of things. Reviewed-by:
-
Ville Syrjälä authored
drm/i915/chv: Implement WaVSRefCountFullforceMissDisable:chv and WaDSRefCountFullforceMissDisable:chv Reviewed-by:
-
Ville Syrjälä authored
Reviewed-by:
-
Ville Syrjälä authored
Reviewed-by:
-
Daniel Vetter authored
Besides the fairly useless BUG_ON the logic is completely generic and cane be used on any platform what wants to reuse the shared dpll support code. Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Daniel Vetter authored
This is the last piece of code which write state to the hardware in the ironalake ->crtc_mode_set callback. I think we could merge this with the pll->enable hook, but otoh the ordering requirements with the ldvs port are really tricky. Doing the FP0/1 writes up-front before we even prepare the lvds port (in the pre_pll_enable hook) like on i9xx seems safest. With this ilk+ platforms are now ready for runtime PM with DPMS. Since hsw/bdw also support runtime pm besides snb we need to first make the haswell code save before we can touch the core code. Reviewed-by:
-
Daniel Vetter authored
Instead of every time it isn't active: We only need to do that when the pll is currently unused, i.e. when pll->refcount == 0. For paranoia add a warning for the ibx case where plls have a fixed mapping and hence should always be unused after the call to intel_put_shared_dpll. v2: Simplify control flow and use struct assignment instead of memcpy as suggested by Damien. Reviewed-by:
-
Daniel Vetter authored
With this all hw writes are also gone from the ->crtc_mode_set hook on vlv. I wondered whether we should track more of the pll state in the pipe config, but otoh as long as we don't have shared plls that's not really useful - the cross-checking of the port clock should be sufficient. While at it also de-magic some of the pipe checks, this has been irking me since a long time. Whit this vlv is now ready for runtime PM on dpms. If we'd have runtime PM support in general ... Reviewed-by:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
Daniel Vetter authored
These two writes are the very last hw writes from the ->crtc_modeset_callback on pre-gen5 hardware. As usual vlv is a bit different, so this here is just warm-up. Reviewed-by:
-
Daniel Vetter authored
Again the same story: This code just transform sw state from the pipe config into hardware state. And again we can't move the pll code, but this time around because the state isn't properly tracked in the pipe config. Reviewed-by:
-
Daniel Vetter authored
Again this code just transforms sw state from the pipe config into hardware state, so we can just move it around. Unfortunately again a few forward declarations since intel_display.c is becoming a bit of a mess. Note that both for i9xx and ironlake code the only things remaining in the ->crtc_mode_set hook is now the clock state computation and sharing code. That needs to be moved into the compute config stage so that we can catch impossible configurations earlier. Also note that some of the DPLL hw setup code is still run from within ->crtc_mode_set, namele the pll->mode_set callback. We need to move that first before we can do fancy things like enable runtime PM for dpms off. v2: Make it compile again after the rebase, bisectability issue reported by Wu Fengguang. Reviewed-by:
-
Daniel Vetter authored
Now this really should be in the pipe config somewhere, but till now it isn't. We can at least move it up a bit next to all the other pll code since intel_dp_set_m_n really doesn't depend upon this. This is just prep work so that moving all the hw frobbing code from ->crtc_mode_set to ->crtc_enable is clean. v2: Do the same for haswell while at it, not just for ivb. Reviewed-by:
-
Daniel Vetter authored
All these functions simply convert sw state as encoded in the pipe config or primary framebuffer into hardware state. So we can move them all into the crtc enable hook. Unfortunately this means a little bit of duplication between the i9xx and vlv functions, but since we already have highly refactored code I think this is acceptable. Also a pile of forward declarations unfortunately. Note also that the various <platform>_update_pll functions are still called from within the ->crtc_mode_set hook. Mostly they compute the clock state for the pipe config, but unfortunately there are some random register writes interspersed. Those need to be moved out first before we can enable runtime PM for DPMS. Reviewed-by:
-
Chris Wilson authored
Before the process killer is invoked, oom-notifiers are executed for one last try at recovering pages. We can hook into this callback to be sure that everything that can be is purged from our page lists, and to give a summary of how much memory is still pinned by the GPU in the case of an oom. This should be really valuable for debugging OOM issues. Note that the last-ditch effort call to shrink_all we've previously called from our normal shrinker when we could free as much as the vm demaned is moved into the oom notifier. Since the shrinker accounting races against bind/unbind operations we might have called shrink_all prematurely, which this approach with an oom notifier avoids. References: https://bugs.freedesktop.org/show_bug.cgi?id=72742Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Tested-by:
lu hua <huax.lu@intel.com> [danvet: Bikeshed logical | into || and pimp commit message.] Signed-off-by:
-
Ville Syrjälä authored
We're using the reset domains bits for g4x on ilk. But on ilk those bits actually shifted by one bit. Fix it up so that we use the correct bits. We were actually always writing 0x2 to the reset domain bits, which is a reserved value. In practice it looks like the hardware ignores that value since nothing happens if I write that value when there's a 3D workload running. Writing the _correct_ render domain value actually makes the GPU stop. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
We should be waiting for the reset bit to clear, not remain set. Signed-off-by:
-
Ville Syrjälä authored
There are comments in the gen4-5 reset functions stating that we can't reset render and media without also doing a display reset. But that's exactly what the code does, ie. we don't perform a display reset. Drop the bogus comments. Signed-off-by:
-
Chris Wilson authored
Try to flush out dirty pages into the swapcache (and from there into the swapfile) when under memory pressure and forced to drop GEM objects from memory. In effect, this should just allow us to discard unused pages for memory reclaim and to start writeback earlier. v2: Hugh Dickins warned that explicitly starting writeback from shrink_slab was prone to deadlocks within shmemfs. Cc: Hugh Dickins <hughd@google.com> Signed-off-by:
Robert Beckett <robert.beckett@intel.com> Reviewed-by:
-
Chris Wilson authored
We can share a few lines of tricky lock handling we need to use for both shrinker routines and in the process fix the return value for count() when reporting a deadlock. Signed-off-by:
-
Chris Wilson authored
When the machine is under a lot of memory pressure and being stressed by multiple GPU threads, we quite often report fewer than shrinker->batch (i.e. SHRINK_BATCH) pages to be freed. This causes the shrink_control to skip calling into i915.ko to release pages, despite the GPU holding onto most of the physical pages in its active lists. References: https://bugs.freedesktop.org/show_bug.cgi?id=72742Signed-off-by:
-
Chris Wilson authored
shmemfs first checks if there is enough memory to allocate the page and reports ENOSPC should there be insufficient, along with the usual ENOMEM for a genuine allocation failure. We use ENOSPC in our driver to mean that we have run out of aperture space and so want to translate the error from shmemfs back to our usual understanding of ENOMEM. None of the the other GEM users appear to distinguish between ENOMEM and ENOSPC in their error handling, hence it is easiest to do the fixup in i915.ko Cc: Hugh Dickins <hughd@google.com> Signed-off-by:
-
- 19 May, 2014 10 commits
-
-
Shashank Sharma authored
This patch adds a mmio base address variable for DSI display, to make the DSI code generic, so that, if required, the same code can be re-used for future platforms with different mmio base. Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
-
Daniel Vetter authored
We can apperently miss them, but breaking the entire driver hampers testing. So bail out after one minute, our customerary "this is a lost cause" timeout. References: https://bugs.freedesktop.org/show_bug.cgi?id=78383Reviewed-by:
-
Imre Deak authored
So far we used the wrong opcodes to access the DSI registers, so the register writes during DSI programming didn't actually succeed and left the registers unchanged. This wasn't a problem for the initial modeset, where the BIOS-programmed values happened to work, but after resuming from s0ix these registers are reset and failing to program them results in a blank screen. Signed-off-by:
-
Imre Deak authored
These opcodes are not specific for an endpoint, but are the same for all endpoints. So rename them accordingly, using the name the VLV2 sideband HAS uses. Also move the macros to the .c file, since they aren't used anywhere else. Signed-off-by:
-
Robin Schroer authored
Fixed several switch statements, curly braces, dereference operators and keywords. Signed-off-by:
Robin Schroer <sulamiification@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Our two ->crtc_mode_set callbacks really don't care whether the fb is pinned and set up already or not - all the state computation and handling which originally looked at the framebuffer is already using the indirection through the pipe configuration. Eventually we want to move this up a bit more, but as long as the crtc mode_set callback still exists (and as long as we don't need to pin an entire pile of planes due to atomic modesets) there's not much point in it. So I'll let this be for now. v2: Don't forget about haswell ... Reviewed-by:
Akash Goel <akash.goel@intel.com> Signed-off-by:
-
Daniel Vetter authored
A lot of the code in set_base is uncessary when the crtc is off, so we can get rid of it all. Also, we don't need to call the fbc/psr update functions since the crtc enable/disable hooks do that already. The only things we really need are: - Pin the new framebuffer and potentially unpin the old framebuffer (if the crtc has been on and we only change the configuration). - Update the plane registers. The first step will move out of platform code with the very next patch. v2: Don't forget about haswell ... Reviewed-by:
-
Daniel Vetter authored
My plan here is to split up set_base into a prepare step, which does the pinning, and a commit stage, which updates the hw state. Eventually we should be able to move the prepare step at the beginning of any atomic update. For now I only want to move the commit step into the crtc_enable callbacks. As a prep step sprinkle intel_edp_psr_update all over the place so that we don't have to concern ourselves with that in the commit step. v2: Rebase on top of Ville's enable/disable functions for all planes. v3: Rebase more. Reviewed-by: Akash Goel <akash.goel@intel.com> (v2) Signed-off-by: -
Daniel Vetter authored
Just for consistency, this patch won't fix anything really. v2: Rebase over all the recent plane enabling shuffling. Reviewed-by: Akash Goel <akash.goel@intel.com> (v1) Signed-off-by: -
Daniel Vetter authored
Way back we've used this to reject framebuffers with unsupported pixel formats. But since the modesetting reorg with the compute config stage we reject those much earlier and just BUG() in this callback. So switch to a void return type. Reviewed-by:
-
