- 09 2月, 2015 3 次提交
-
-
由 Mika Kuoppala 提交于
We added this WARN_ON to guard against using uninitialized forcewake domains. But forgot blissfully that not all gens have forcewake domains in the first place. v2: Move WARN_ON to fw_domains_init (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88911 Tested-by: Ding Heng <hengx.ding@intel.com> (v1) Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> [Jani: add comment above WARN_ON as suggested by Chris] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Mika Kuoppala 提交于
We read the coherent current seqno and actual head from ring. For hardware access we need to take runtime_pm reference. Get hardware specific values with runtime reference held and print them first to emphasize hw state vs bookkeepping. v2: Reorder output according to hw access (Chris) remove superfluous locking (Daniel) Testcase: igt/pm_rpm/debugfs-read Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88910 Tested-by: Ding Heng <hengx.ding@intel.com> (v1) Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
由 Shobhit Kumar 提交于
As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target device and not the source. So PCI_DEVFN(2,0) is not correct. Further the port ID should be enough to identify devices unless they are MFD. The SB_DevFn was intended to remove ambiguity in case of these MFD devices. For non MFD devices the recommendation for the target device IP was to ignore these fields, but not all of them followed the recommendation. Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0). It turned out that this did not follow the recommendation and expected 0 in this field. In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for all devices except target PCI devices. Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 05 2月, 2015 1 次提交
-
-
由 Michał Winiarski 提交于
It's possible for invalidate_range_start mmu notifier callback to race against userptr object release. If the gem object was released prior to obtaining the spinlock in invalidate_range_start we're hitting null pointer dereference. Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMichał Winiarski <michal.winiarski@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org [Jani: added code comment suggested by Chris] Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 31 1月, 2015 7 次提交
-
-
由 Daniel Vetter 提交于
Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
The get_config() functions for ddi and dp_mst, used to read the value of cpu_transcoder from the crtc->config instead of the state passed as an argument. On the hardware state readout path, that happens to work since the proper value is written to it before encoder->get_config() is called. However, in the check_crtc() path, the state will be read from the cpu_transcoder in the software tracking, instead of the one just read out from hw. Using the field in the supplied intel_crtc_state should do the right thing in both cases. v2: Fix intel_ddi_get_config() too. (Ander) Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Nick Hoath 提交于
Remove request from list before unreferencing it, in case it's actually the only reference. (Found by Tvrtko Ursulin) This issue has been most likely introduced in commit 6d3d8274 Author: Nick Hoath <nicholas.hoath@intel.com> Date: Thu Jan 15 13:10:39 2015 +0000 drm/i915: Subsume intel_ctx_submit_request in to drm_i915_gem_request Signed-off-by: NNick Hoath <nicholas.hoath@intel.com> Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
This simplifies __intel_set_mode() a little. Signed-off-by: NAnder Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
The checking for ack and also any subsequent mmio access will serialize with setting the forcewake bit. Drop the posting read as superfluous. Note that in the put side we still want to keep the posting read as it will ensure that the hw sees our forcewake release in a timely manner and doesn't keep the hw powered up. Comment from Chris: On Wed, Jan 28, 2015 at 05:54:14PM +0200, Mika Kuoppala wrote: > Ville Syrjälä <ville.syrjala@linux.intel.com> writes: > > IIRC the posting read from same cache line actually fixed real bugs. So > > I'm a bit worried about dropping them. But I suppose it's possible only > > the _put side was important for those bugs. > > I found these: > > commit 6af2d180 > Author: Daniel Vetter <daniel.vetter@ffwll.ch> > Date: Thu Jul 26 16:24:50 2012 +0200 > > drm/i915: fix forcewake related hangs on snb > > commit 8dee3eea > Author: Ben Widawsky <ben@bwidawsk.net> > Date: Sat Sep 1 22:59:50 2012 -0700 > > drm/i915: Never read FORCEWAKE > > https://bugs.freedesktop.org/show_bug.cgi?id=51738 > https://bugs.freedesktop.org/show_bug.cgi?id=52424 > > The snb here seems to survive gem_dummy_reloc_loop and > gem_ring_sync_loop in here with the get side posting removed. Note that we kept the once associated with #52424, but judging by my comments in #51738 the posting read is just a band aid anyway as a full mb() itself was not adequate. Suggested-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: paste relevant review discussion in.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
intel_uncore_early_sanitize() will reset the forcewake registers. When forcewake domains were introduced, the domain init was done after the sanitization of the forcewake registers. And as the resetting of registers use the domain accessors, we tried to reset the forcewake registers with unitialized forcewake domains and failed. Fix this by sanitizing after all the domains have been initialized. Do per domain clearing of forcewake register on domain init so that IVB can do early access to ECOBUS do determine the final configuration. This regression was introduced in commit 05a2fb15 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Mon Jan 19 16:20:43 2015 +0200 drm/i915: Consolidate forcewake code v2: Carve out ellc detect, fw_domain_reset for ivb/ecobus (Chris) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88805 Cc: Chris Wilson <chris@chris-wilson.co.uk> Reported-by: NOlof Johansson <olof@lixom.net> Tested-by: Darren Hart <dvhart@linux.intel.com> (v1) Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Move the CHV check into vlv_set_rps_idle() to simplify the caller a bit. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 30 1月, 2015 2 次提交
-
-
由 Mika Kuoppala 提交于
Now when we declare gpu errors only through our own dedicated hangcheck workqueue there is no need to have a separate workqueue for handling the resetting and waking up the clients as the deadlock concerns are no more. The only exception is i915_debugfs::i915_set_wedged, which triggers error handling through process context. However as this is only used through test harness it is responsibility for test harness not to introduce hangs through both debug interface and through hangcheck mechanism at the same time. Remove gpu_error.work and let the hangcheck work do the tasks it used to. v2: Add a big warning sign into i915_debugfs::i915_set_wedged (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
Include intel_uncore.c in template for it to include d documentation for intel_uncore_forcewake_get and *_put. Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 29 1月, 2015 11 次提交
-
-
由 Jani Nikula 提交于
The removed functions can be resurrected in intel_dsi.c as need arises. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
No functional changes. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
All of these are replaced by the drm core mipi dsi functions. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Use the drm core interfaces in preparation of removing our homebrew. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Add basic support for using the drm mipi dsi framework for DSI. We don't use device tree which is pretty much required by mipi_dsi_host_register and friends, and we don't have the kind of device model the functions expect either. So we cheat and use it as a library to abstract what we need: a nice, clean interface for DSI transfers. This means we will have to be careful with what functions we call, as the driver model devices in mipi_dsi_host and mipi_dsi_device will *not* be initialized. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jani Nikula 提交于
Replace intel_dsi_device and intel_dsi_dev_ops with drm_panel and drm_panel_funcs. They are adequate for what we have now, and if we end up needing more than this we should improve drm_panel. This will keep us better aligned with the drm core infrastructure. The panel driver initialization changes a bit. It still remains hideous, but fixing that is beyond the scope here. v2: extend mode config mutex to cover drm_panel_get_modes (Shobhit) vbt_panel->intel_dsi = intel_dsi in vbt panel init (Shobhit) Signed-off-by: NJani Nikula <jani.nikula@intel.com> Reviewed-By: NShobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Sonika Jindal 提交于
Mainly taking care of some register offsets, otherwise things are similar to hsw. Also, programming ddi aux to use hardcoded values for psr data select. v2: introduce EDP_PSR_AUX_BASE macro (Chris) v3: Moving to HW tracking for SKL+ platforms, so activating source psr during psr_enabling and then avoiding psr entries and exits for each frontbuffer updates. v4: Using SKL DDI AUX regs instead of changing PSR_AUX regs definition (Rodrigo) Signed-off-by: NSonika Jindal <sonika.jindal@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> [danvet: Drop the hunks to short-circuit sw tracking: We'd need to push this down one level, and I don't fully trust the test coverage yet to do so. So much prefer we pick a whitelist approach for the cases we know work correctly.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
The core fix was applied in commit a63b03e2 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Tue Jan 6 10:29:35 2015 +0000 mutex: Always clear owner field upon mutex_unlock() (note the absence of stable@ tag) so we can now revert our band-aid commit 226e5ae9 for -next. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Mika Kuoppala 提交于
We have had %x and %u intermixed. Bring everything in line and use %x Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
For example, /sys/kernel/debug/dri/0/i915_hangcheck_info: Hangcheck active, fires in 15887800ms render ring: seqno = -4059 [current -583] action = 2 score = 0 ACTHD = 1ee8 [current 21f980] max ACTHD = 0 v2: Include expiration ETA. Can anyone spot a problem? v3: Convert for workqueued hangcheck (Mika) v4: Print seqnos as unsigned ints (Ville) v5: Print seqnos as hex (Chris) Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) (v2) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
When run as a timer, i915_hangcheck_elapsed() must adhere to all the rules of running in a softirq context. This is advantageous to us as we want to minimise the risk that a driver bug will prevent us from detecting a hung GPU. However, that is irrelevant if the driver bug prevents us from resetting and recovering. Still it is prudent not to rely on mutexes inside the checker, but given the coarseness of dev->struct_mutex doing so is extremely hard. Give in and run from a work queue, i.e. outside of softirq. v2: Use own workqueue to avoid deadlocks (Daniel) Cleanup commit msg and add comment to i915_queue_hangcheck() (Chris) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <dnaiel.vetter@ffwll.chm> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: NMika Kuoppala <mika.kuoppala@intel.com> [danvet: Remove accidental kerneldoc comment starter, to appease the 0 day builder.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 28 1月, 2015 1 次提交
-
-
由 Chris Wilson 提交于
An interesting bug occurs on Pineview through which the root cause is that the writes of the PTE values into the GTT is not serialised with subsequent memory access through the GTT (when using WC updates of the PTE values). This is despite there being a posting read after the GTT update. However, by changing the address of the posting read, the memory access is indeed serialised correctly. Whilst we are manipulating the memory barriers, we can remove the compiler :memory restraint on the intermediate PTE writes knowing that we explicitly perform a posting read afterwards. v2: Replace posting reads with explicit write memory barriers - in particular this is advantages in case of single page objects. Update comments to mention this issue is only with WC writes. Testcase: igt/gem_exec_big #pnv Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=88191 Tested-by: huax.lu@intel.com (v1) Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 1月, 2015 15 次提交
-
-
由 Kumar Amit Mehta 提交于
The comment for intel_cpu_fifo_underrun_irq_handler() is not consistent with the code and the rest of the comment for this routine. This patch fixes this typo in comment. Signed-off-by: NKumar Amit Mehta <gmate.amit@gmail.com> Reviewed-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Matt Roper 提交于
We don't have full atomic modeset support yet, but the "nuclear pageflip" subset of functionality (i.e., plane operations only) should be ready. Allow the user to force atomic on for debug purposes, or for fixed-purpose embedded devices that will only use atomic for plane updates. The term 'nuclear' is used here instead of 'atomic' to make it clear that this doesn't allow full atomic modeset support, just a (very useful) subset of the atomic functionality. We'll drop the kernel parameter and unconditionally enable atomic in a future patch once all of the necessary pieces are in. v2: - Use module_param_named_unsafe() (Daniel) - Simplify comment on DRIVER_ATOMIC guard (Daniel) v3: - Make the parameter "nuclear_pageflip" rather than just "nuclear" for clarity. (Ander) v4: - Make the internal variable "nuclear_pageflip" as well as the command-line option. (Ander) Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Matt Roper 提交于
This will exercise our atomic pipeline for legacy property updates. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Matt Roper 提交于
The atomic helpers need these to prepare a new state object when starting a new atomic operation. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Matt Roper 提交于
Even though we only support atomic plane updates at the moment, we still need to add an .atomic_get_property() entrypoint for connectors before we allow the driver to flip on the DRIVER_ATOMIC bit. As soon as that bit gets set, the DRM core will start adding atomic connector properties (in addition to the plane properties we care about at the moment), so we need to be able to handle the new way the DRM core will interact with us. For simplicity, we just lookup driver-specific connector properties in the usual shadow array maintained by the core. Once we get real atomic modeset support for crtc's and planes, this code should be re-written to pull the data out of crtc/connector state structures. v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander) Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Matt Roper 提交于
We want to enable/test plane updates via the atomic interface, but as soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic codepaths to lookup properties during drmModeGetConnector() and some of those codepaths unconditionally dereference connector->state (specifically when looking up the CRTC ID property in drm_atomic_connector_get_property()). Create a dummy connector state for each connector at init time to ensure the DRM core doesn't try to dereference a NULL connector->state. The actual connector properties will never be updated or contain useful information, but since we're doing this specifically for testing/debug of the plane operations (and only when a specific kernel module option is given), that shouldn't really matter. Once we start creating connector states, the DRM core will want to be able to clean them up for us. We also need to hook up the destruction entrypoint to the core's helper. v2: Squash in the patch to set the state destruction hook (Ander & Bob) v3: Only create dummy connector states when we're actually faking atomic support. (Ander) Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Matt Roper 提交于
Add the top-level atomic entrypoints for check/commit. These won't get called yet; we still need to either enable the atomic ioctl or switch to using the non-transitional atomic helpers for legacy operations. v2: - Use plane->pipe rather than plane->possible_crtcs while ensuring that only a single CRTC is in use. Either way will work fine since i915 drm_plane's are always tied to a single CRTC, but plane->pipe is slightly more intuitive. (Ander) - Simplify crtc/connector checking logic. (Ander) Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Matt Roper 提交于
When we flip on the DRIVER_ATOMIC bit, the DRM core will start calling this entrypoint to set and lookup driver-specific plane property values, rather than maintaining a shadow copy in object->properties. Note that although we add these functions to the plane vtable, they will not yet be called. Future patches that switch our .set_property() handler and/or enable full atomic functionality are required before these code paths will be executed. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Matt Roper 提交于
All of the previous refactoring/consolidation of plane code has resulted in intel_primary_plane_funcs, intel_cursor_plane_funcs, and intel_sprite_plane_funcs being identical. Replace all of these with a single 'intel_plane_funcs' vtable for simplicity. Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Matt Roper 提交于
Runtime state that can be manipulated via properties should now go in intel_plane_state/drm_plane_state so that it can be tracked as part of an atomic transaction. We add a new 'intel_create_plane_state' function so that the proper initial value for this property (and future properties) doesn't have to be repeated at each plane initialization site. v2: - Stick rotation in common drm_plane_state rather than intel_plane_state. (Daniel) - Add intel_create_plane_state() to consolidate the places where we have to set initial state values. (Ander) Signed-off-by: NMatt Roper <matthew.d.roper@intel.com> Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Replace all the vlv_gpu_freq(), vlv_freq_opcode(), *GT_FREQUENCY_MULTIPLIER, and /GT_FREQUENCY_MULTIPLIER instances with intel_gpu_freq() and intel_freq_opcode() calls. Most of the change was performed with the following semantic patch: @@ expression E; @@ ( - E * GT_FREQUENCY_MULTIPLIER + intel_gpu_freq(dev_priv, E) | - E *= GT_FREQUENCY_MULTIPLIER + E = intel_gpu_freq(dev_priv, E) | - E /= GT_FREQUENCY_MULTIPLIER + E = intel_freq_opcode(dev_priv, E) | - do_div(E, GT_FREQUENCY_MULTIPLIER) + E = intel_freq_opcode(dev_priv, E) ) @@ expression E1, E2; @@ ( - vlv_gpu_freq(E1, E2) + intel_gpu_freq(E1, E2) | - vlv_freq_opcode(E1, E2) + intel_freq_opcode(E1, E2) ) @@ expression E1, E2, E3, E4; @@ ( - if (IS_VALLEYVIEW(E1)) { - E2 = intel_gpu_freq(E3, E4); - } else { - E2 = intel_gpu_freq(E3, E4); - } + E2 = intel_gpu_freq(E3, E4); | - if (IS_VALLEYVIEW(E1)) { - E2 = intel_freq_opcode(E3, E4); - } else { - E2 = intel_freq_opcode(E3, E4); - } + E2 = intel_freq_opcode(E3, E4); ) One hunk was manually undone as intel_gpu_freq() ended up calling itself. Supposedly it would be possible to exclude certain functions via !=~, but I couldn't get that to work. Also the removal of vlv_gpu_freq() and vlv_opcode_freq() compat wrappers was done manually. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Rename the vlv_gpu_freq() and vlv_freq_opecode() functions to have an intel_ prefix, and handle non-VLV/CHV platforms in them as well. Leave the vlv_ names around for now since they're currently used. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Currently the 'gt_cur_freq_mhz' file shows the actual GPU frequency on VLV/CHV, and the last requested frequency on other platforms. Change the meaning of the file on VLV/CHV to follow the the other platforms, and introduce a new file 'gt_act_freq_mhz' which shows the actual frequency on all platforms. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
Currently we don't call valleyview_set_rps() when changing the min/max limits through sysfs if the current frequency is still within the new limits. However that means we sometimes forget to update PMINTRMSK. Eg. if the current frequency is at the old minimum, and then we reduce the minum further we should then enable the 'down' interrupts in PMINTRMSK but currently we don't. Fix it up by always calling valleyview_set_rps() (just like we do for !vlv/chv platforms). This also allows the code to be simplified a bit. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Vandana Kannan 提交于
Calls have been added to invalidate/flush DRRS whenever invalidate/flush is called as part of frontbuffer tracking. Apart from calls as a result of GEM tracking to fb invalidate/flush, a call has been added to invalidate fb obj from crtc_page_flip as well. This is to track busyness through flip calls. The call to fb_obj_invalidate (in flip) is placed before queuing flip for this obj. drrs_invalidate() and drrs_flush() check for drrs.dp which would be NULL if it was setup in drrs_enable(). This covers for the condition when DRRS is not supported. v2: Removing the call to invalidate_drrs from page_flip. This has not been tested on Android yet, but, in case DRRS transtions do not work as expected, check by adding back this call in page_flip. Signed-off-by: NVandana Kannan <vandana.kannan@intel.com> Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-