- 16 Oct, 2013 2 commits
-
-
Ben Widawsky authored
I had this lying around from he original PPGTT series, and thought we might try to get it in by itself. With the introduction of context refcounting we never explicitly ref/unref the backing object. As such, the previous fix was a bit wonky. Aside from fixing the above, this patch also puts us in good shape for an upcoming patch which allows a failure to occur in between context_init and the first do_switch. CC: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ben Widawsky authored
I had this lying around from he original PPGTT series, and thought we might try to get it in by itself. It's convenient to just call i915_gem_init_hw at reset because we'll be adding new things to that function, and having just one function to call instead of reimplementing it in two places is nice. In order to accommodate we cleanup ringbuffers in order to bring them back up cleanly. Optionally, we could also teardown/re initialize the default context but this was causing some problems on reset which I wasn't able to fully debug, and is unnecessary with the previous context init/enable split. This essentially reverts: commit 8e88a2bd Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jun 19 18:40:00 2012 +0200 drm/i915: don't call modeset_init_hw in i915_reset It seems to work for me on ILK now. Perhaps it's due to: commit 8a5c2ae7 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Mar 28 13:57:19 2013 -0700 drm/i915: fix ILK GPU reset for render Signed-off-by:
-
- 15 Oct, 2013 17 commits
-
-
Ville Syrjälä authored
Using the 5/6 DDB split make sense only when sprites are enabled. So check that before we waste any cycles computing the merged watermarks with the 5/6 DDB split. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Makes the behaviour of the function more clear. Signed-off-by:
-
Ville Syrjälä authored
Makes the intention more clear. Signed-off-by:
-
Ville Syrjälä authored
We want to be able to use the masks to decode the register contents regardless of the hardware generation. So just expand the masks to cover all available bits, even if those are reserved on some generations. v2: Don't extend WM1_LP_SR_MASK so far, for the *future* Signed-off-by:
-
Ville Syrjälä authored
This debug print just adds overhead to the watermark merging process, and doesn't really give enough information to be useful. Just kill and let's add something much better a bit later. Signed-off-by:
-
Ville Syrjälä authored
Fill out the HSW watermark s/w tracking structures with the current hardware state in intel_modeset_setup_hw_state(). This allows us to skip the HW state readback during watermark programming and just use the values we keep around in dev_priv->wm. Reduces the overhead of the watermark programming quite a bit. v2: s/init_wm/wm_get_hw_state Remove stale comment about sprites Make DDB partitioning readout safer Signed-off-by: -
Ville Syrjälä authored
Currently hsw_write_vm_values() may write to certain watermark registers needlessly. For instance if only, say, LP3 changes, the current code will again disable all LP1+ watermarks even though only LP3 needs to be reconfigured. Add an easy to read function that will compute the dirtyness of the watermarks, and use that information to further optimize the watermark programming. v2: Disable LP1+ watermarks around changing LP0 watermarks for Paulo Signed-off-by:
-
Ville Syrjälä authored
To make it easier to check what watermark updates are actually necessary, keep copies of the relevant bits that match the current hardware state. Also add DDB partitioning into hsw_wm_values as that's another piece of state we want to track. We don't read out the hardware state on init yet, so we can't really start using this yet, but it will be used later. Signed-off-by:
-
Ville Syrjälä authored
The fbc_wm_enabled member in intel_wm_config is useless for the time being. The original idea for it was that we'd pre-compute it and so that the WM merging process could know whether it needs to worry about FBC watermarks at all. But we don't have a convenient way to pre-check for the possibility of FBC being used. intel_update_fbc() should be split up for that. Signed-off-by:
-
Ville Syrjälä authored
On HSW the LP1,LP2,LP3 levels are either 1,2,3 or 1,3,4. We make the conversion from LPn to to the level at one point current. Later we're going to do it in a few places, so move it to a separate function. Signed-off-by:
-
Ville Syrjälä authored
Using the 5/6 DDB split make sense only when sprites are enabled. So check that before we waste any cycles computing the merged watermarks with the 5/6 DDB split. Signed-off-by:
-
Ville Syrjälä authored
Move the watermark max computations into haswell_update_wm(). This allows keeping the 1/2 vs. 5/6 split code in one place, and avoid having to pass around so many things. We also save a bit of stack space by only requiring one copy of struct hsw_wm_maximums. Also move the intel_wm_config out from hsw_compute_wm_parameters() and pass it it. We'll have some need for it in haswell_update_wm() later. Signed-off-by:
-
Ville Syrjälä authored
Let's try to keep using the intermediate intel_pipe_wm representation for as long as possible. It avoids subtle knowledge about the internals of the hardware registers when trying to choose the best watermark configuration. While at it replace the memset() w/ zero initialization. Signed-off-by:
-
Ville Syrjälä authored
I want to convert hsw_find_best_result() to use intel_pipe_wm, so we need to move the merging to happen outside hsw_compute_wm_results(). Signed-off-by:
-
Ville Syrjälä authored
No point in re-computing the watermarks for all pipes, when only one pipe has changed. The watermarks stored under intel_crtc.wm.active are still valid for the other pipes. We just need to redo the merging. We can also skip the merge/update procedure completely if the new watermarks for the affected pipe come out unchanged. Signed-off-by:
-
Ville Syrjälä authored
Introduce a new struct intel_pipe_wm which contains all the watermarks for a single pipe. Use it to unify the LP0 and LP1+ watermark computations so that we can just iterate through the watermark levels neatly and call ilk_compute_wm_level() for each. Also add another tool ilk_wm_merge() that merges the LP1+ watermarks from all pipes. For that, embed one intel_pipe_wm inside intel_crtc that contains the currently valid watermarks for each pipe. This is mainly preparatory work for pre-computing the watermarks for each pipe and merging them at a later time. For now the merging still happens immediately. v2: Add some comments about level 0 DDB split and intel_wm_config Add WARN_ON for level 0 being disabled s/lp_wm/merged Signed-off-by: -
Jani Nikula authored
Follow-up to commit 0aec2881 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Sep 27 19:01:01 2013 +0300 drm/dp: constify DP DPCD helpers Requested-by:
Jani Nikula <jani.nikula@intel.com> Reviewed-by:
-
- 14 Oct, 2013 8 commits
-
-
Ville Syrjälä authored
Gen2 doesn't have a hardware frame counter that can be read out. Just provide a stub .get_vblank_counter() that always returns 0 instead of trying to read non-existing registers. Signed-off-by:
-
Ville Syrjälä authored
Gen2 doesn't have the pixelcount register that gen3 and gen4 have. Instead we must use the scanline counter like we do for ctg+. Signed-off-by:
-
Ville Syrjälä authored
The DSL register increments at the start of horizontal sync, so it manages to miss the entire active portion of the current line. Improve the get_scanoutpos accuracy a bit when the scanout position is close to the start or end of vblank. We can do that by double checking the DSL value against the vblank status bit from ISR. Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by:
-
Ville Syrjälä authored
The reported scanout position must be relative to the end of vblank. Currently we manage to fumble that in a few ways. First we don't consider the case when vtotal != vbl_end. While that isn't very common (happens maybe only w/ old panel fitting hardware), we can fix it easily enough. The second issue is that on pre-CTG hardware we convert the pixel count to horizontal/vertical components at the very beginning, and then forget to adjust the horizontal component to be relative to vbl_end. So instead we should keep our numbers in the pixel count domain while we're adjusting the position to be relative to vbl_end. Then when we do the conversion in the end, both vertical _and_ horizontal components will come out correct. v2: Change position to int from u32 to avoid sign issues Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by:
-
Ville Syrjälä authored
We have all the information we need in the mode structure, so going and reading it from the hardware is pointless, and slower. We never populated ->get_vblank_timestamp() in the UMS case, and as that is the only way we'd ever call ->get_scanout_position(), we can completely ignore UMS in i915_get_crtc_scanoutpos(). Also reorganize intel_irq_init() a bit to clarify the KMS vs. UMS situation. v2: Drop UMS code Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by:
-
Ville Syrjälä authored
Avoid some code duplication. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
Rounding down when calculating the dot/vco frequencies doesn't make much sense. Round to closest should give slightly nicer answers. Signed-off-by:
-
Chris Wilson authored
At the moment we have 3 paths that lead to actually_set_backlight(), from modesetting, ACPI/OpRegion requests and our very own intel_backlight interface, and we have no way of distinguishing them in the debug log. So add a debug breadcrumb to explain the source of the backlight changes. Signed-off-by:
-
- 11 Oct, 2013 9 commits
-
-
Ville Syrjälä authored
The old style frame counter increments at the start of active video. However for i915_get_vblank_counter() we want a counter that increments at the start of vblank. Fortunately the low frame counter register also contains the pixel counter for the current frame. We can can compare that against the vblank start pixel count to determine if we need to increment the frame counter by 1 to get the correct answer. Also reorganize the function pointer assignments in intel_irq_init() a bit to avoid confusing people. Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by:
Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Signed-off-by:
-
Daniel Vetter authored
This file is all about the legacy fbdev support. If we want to extract framebuffer functions, we better put those into a separate file. Also rename functions accordingly, only two have used the intel_fb_ prefix anyway. Reviewed-by:
Chon Ming Lee <chon.ming.lee@intel.com> Signed-off-by:
-
Daniel Vetter authored
Boots Just Fine (tm)! The only glitch seems to be that at least on Fedora the boot splash gets confused and doesn't display much at all. And since there's no ugly console flickering anymore in between, the flicker while switching between X servers (VT support is still enabled) is even more jarring. Also, I'm unsure whether we don't need to somehow kick out vgacon, now that nothing else gets in the way. But stuff seems to work, so I don't care. Also everything still works as well with VGA_CONSOLE=n Also the #ifdef mess needs a bit of a cleanup, follow-up patches will do just that. To keep the Kconfig tidy, extract all the i915 options into its own file. v2: - Rebase on top of the preliminary hw support option and the intel_drv.h cleanup. - Shut up warnings in i915_debugfs.c v3: Use the right CONFIG variable, spotted by Chon Ming. Cc: Lee, Chon Ming <chon.ming.lee@intel.com> Cc: David Herrmann <dh.herrmann@gmail.com> Reviewed-by:
-
Daniel Vetter authored
For drivers which might want to disable fbdev legacy support. Select the new option in all drivers for now, so this shouldn't result in any change. Drivers need some work anyway to make fbdev support optional (if they have it implemented, that is), so the recommended way to expose this is by adding per-driver options. At least as long as most drivers don't support disabling the fbdev support. v2: Update for new drm drivers msm and rcar-du. Note that Rob's msm driver can already take advantage of this, which allows us to build msm without any fbdev depencies in the kernel! v3: Move the MODULE_* stuff from the fbdev helper file to drm_crtc_helper.c. Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Acked-by:
Dave Airlie <airlied@linux.ie> Reviewed-by:
-
Ville Syrjälä authored
Supposedly VLV uses the CTG+ style frame counter registers instead of the old gen3/4 style. Add the magic offset to the correct registers. We should already be taking the correct codepaths for .get_vblank_counter() and .get_scanout_position(). Signed-off-by:
-
Jesse Barnes authored
So digging out the right ones is a little easier. Signed-off-by:
-
Jesse Barnes authored
On gen7+, CACHE_MODE_0 moved, so we're clobbering some other reg rather than restoring CACHE_MODE_0. Don't do that. Signed-off-by:
-
Ville Syrjälä authored
The current pre-gen4 pipe off code might break out of the loop due to the timeout, but then the fail to print the warning. Refactor the code a bit to use wait_for() to avoid the problem, and that we also re-check the condition after the timeout has expired. v2: Use wait_for() Signed-off-by:
-
Paulo Zanoni authored
The spec says the default timeout should be 2ms, but on my machine this doesn't seem to be enough. Sometimes it works, sometimes I get these messages when booting: - SWSCI request timed out - SWSCI request already in progress And my guess is that the "already in progress" message is because the first one is still happening. I did some experiments on my machine (that has CONFIG_HZ=1000) and the wait_for function usually takes 4-6 jiffies to finish, but I've seen up to 9. So increase the timeout to 50ms. We only expect to wait for the actual amount of time the operation takes, so even a huge timeout shouldn't delay us more than what the hardware actually requires. Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 10 Oct, 2013 4 commits
-
-
Chris Wilson authored
As we delay the initial RPS enabling (upon boot and after resume), there is a chance that we may start to render and trigger RPS boosts before we set up the punit. Any changes we make could result in inconsistent hardware state, with a danger of causing undefined behaviour. However, as the boosting is a optional tweak to RPS, we can simply ignore it whilst RPS is not yet enabled. Signed-off-by:
-
Jani Nikula authored
Educate the users why i915 won't load on gen6+ and nomodeset. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=61671Signed-off-by:
-
Daniel Vetter authored
Untangling me-too reports that actually aren't is really messy. And we need to make sure the blame is put where it should be right from the start ;-) v2: Improve the wording from Ben's suggestions. Cc: Ben Widawsky <ben@bwidawsk.net> Acked-by:
-
Tom O'Rourke authored
Enabling rps (turbo setup) was put in a work queue because it may take quite awhile. This change flushes the work queue to initialize rps values before use by sysfs or debugfs. Specifically, rps.delayed_resume_work is flushed before using rps.hw_max, rps.max_delay, rps.min_delay, or rps.cur_delay. This change fixes a problem in sysfs where show functions using uninitialized values show incorrect values and store functions using uninitialized values in range checks incorrectly fail to store valid input values. This change also addresses similar use before initialized problems in debugfs. Signed-off-by:
Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by:
-
