- 27 Jan, 2015 40 commits
-
-
Vandana Kannan authored
Add DRRS work function to trigger a switch to low refresh rate, when no activity is detected on screen till 1 sec duration. v2: [By Ram]: drrs.dp also protected with drrs.mutex and worker function is renamed to intel_edp_drrs_downclock_work [Chris] Signed-off-by:
Vandana Kannan <vandana.kannan@intel.com> Signed-off-by:
Ramalingam C <ramalingam.c@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Self-explanatory code is better code. Cc: Dave Airlie <airlied@redhat.com> Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Jani Nikula authored
Const is good for you. No functional changes. Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by:
-
Jani Nikula authored
Remove all the trivial and/or dummy callbacks from intel dsi device ops. Merge send_otp_cmds into panel_reset as they're called back to back. This will be helpful for switching to use drm_panel for the callbacks. If we ever need the additional callbacks, we should add them to drm_panel funcs. Signed-off-by:
-
Jani Nikula authored
Add port parameter to wait_for_dsi_fifo_empty, and call it for each dsi port. We can now remove the transitional intel_dsi_pipe_to_port() function. Signed-off-by:
-
Jani Nikula authored
wait_for_dsi_fifo_empty can be static in intel_dsi.c. No functional changes. Signed-off-by:
-
Jani Nikula authored
This seems like the right thing to do. This also gets rid of a call to intel_dsi_pipe_to_port() which we want to remove eventually. v2: add braces to fix else logic (Shobhit) Signed-off-by:
-
Jani Nikula authored
Instead of having the for each dsi port loop within dpi_send_cmd(), add a port parameter to the function and call it for each port instead. This is a rewrite of commit 4510cd77 Author: Gaurav K Singh <gaurav.k.singh@intel.com> Date: Thu Dec 4 10:58:51 2014 +0530 drm/i915: Dual link needs Shutdown and Turn on packet for both ports to add more flexibility in using dpi_send_cmd() for just one port as necessary. No functional changes. Signed-off-by:
-
Ville Syrjälä authored
We set the WIZ hashing mode to 16x4 for all the other gen6+ platfotrms, so let's follow suit on VLV. My VLV is AWOL currently so I didn't test this, but since the results for all the other platforms agree that 16x4 is the fastest we might assume the same holds for VLV. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
I ran a few tests with xonotic and synmark2 trying out the different WIZ hashing modes on CHV. The results seem to match the results I got with IVB/HSW when I did the similar tests on them in the past. That is 16x4 is generally the fastest mode, 8x8 comes next and finally 8x4. On CHV the difference between the modes is at most ~1% in most tests. IIRC on IVB/HSW the difference was a little bigger, but as there doesn't seem to be any real downside to 16x4 let's use it by default. Signed-off-by:
-
Ville Syrjälä authored
Drop WaDisablePwrmtrEvent:chv as it's no longer needed. Also remove the WaSetMaskForGfxBusyness:chv note, but we still leave the GEN6_RP_MEDIA_IS_GFX bit enabled as that's still the recommended setting. Signed-off-by:
-
Ville Syrjälä authored
Wa4x4STCOptimizationDisable got only implemented for BDW, but according to the w/a database CHV needs it too, so add it. Signed-off-by:
-
Daniel Vetter authored
We can push down the decision whether to force flushing into the implementation since in all places that matter obj->pin_display is accurate already. The only place where the optimization really matters is the sw_finish_ioctl, and that already checks for obj->pin_display on its own. I suspect that this was simply an artifact of how commit 2c22569b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri Aug 9 12:26:45 2013 +0100 drm/i915: Update rules for writing through the LLC with the cpu evolved - only v2 added the pin_display tracking. Note that we still retain the gist of this logic from the above commit with the explicit force argument for the low-level clflush function. Ville noted in his review that there's a slight behavioural change in the set_to_gtt_domain function, which now also will flush display plane data. This opens-open the potential for userspace to start doing buggy things by omitting the sw_finish_ioctl, which is why I've rejected a functional equivalent patch from Ville a while ago: http://lists.freedesktop.org/archives/intel-gfx/2013-November/036421.html But on second consideration it's not that evil, and in any case the justification here is more clarity, not allowing crazy userspace. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
Damien Lespiau authored
Suggested-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Damien Lespiau authored
Smatch doesn't like: struct drm_framebuffer *fb; fb = kzalloc(sizeof(struct intel_framebuffer), GFP_KERNEL); and warns with: warn: struct type mismatch 'drm_framebuffer vs intel_framebuffer' This implicit cast was correct as struct intel_framebuffer has struct drm_framebuffer as its first member, but in case someone want to reorder the fields for some reason, it's slightly safer to access the underlying drm_framebuffer through intel_fb->base. Also, having fewer static analysis warnings is a worthy goal. Cc: kbuild@01.org Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Chris Wilson authored
Currently we are hitting the WARN inside i915_gem_object_set_cache_level() as we can now have an unbound object in the GTT write domain (due to 43566ded "drm/i915: Broaden application of set-domain(GTT)"). To avoid the warning, we need to track when we elided the clflush on a cacheable object and then evict the cache for the object when we move the object out of a cacheable domain. Reported-by:
Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by:
-
Mika Kuoppala authored
We increase it when we pin, so for the casual reader rename it to cause less confusion. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Thomas Daniel <thomas.daniel@intel.com> Signed-off-by:
-
Mika Kuoppala authored
We pin when we submit to execlist queue. Balance the pinning when the submitted queue is cleaned on reset. Cc: Dave Gordon <david.s.gordon@intel.com> Signed-off-by:
-
Zhipeng Gong authored
This will let userland only try to use the new ring when the appropriate kernel is present v2: change the number to be consistent with upstream (Zhipeng) Signed-off-by:
Zhipeng Gong <zhipeng.gong@intel.com> Reviewed--by:
-
Zhipeng Gong authored
On Skylake GT3 we have 2 Video Command Streamers (VCS), which is asymmetrical. For example, HEVC GPU commands can be only dispatched to VCS1 ring. But userspace has no control when using VCS1 or VCS2. This patch introduces a mechanism to avoid the default ping-pong mode and use one specific ring through execution flag. This mechanism is usable for all the platforms with 2 VCS rings. The open source usage is from these two commits in vaapi/intel: commit 702050f04131a44ef8ac16651708ce8a8d98e4b8 Author: Zhao, Yakui <yakui.zhao@intel.com> Date: Mon Nov 17 12:44:19 2014 +0800 Allow the batchbuffer to be submitted with override flag commit a56efcdf27d11ad9b21664b4a2cda72d7f90f5a8 Author: Zhao Yakui <yakui.zhao@intel.com> Date: Mon Nov 17 12:44:22 2014 +0800 Add the override flag to assure that HEVC video command always uses BSD ring0 for SKL GT3 machine v2: fix whitespace (Rodrigo) v3: remove incorrect chunk that came on -collector rebase. (Rodrigo) v4: change the comment (Zhipeng) v5: address Daniel's comment (Zhipeng) Signed-off-by:
-
Damien Lespiau authored
This vfunc and related structure are only used for fast boot, so let's rename them to not take them as general purpose ones. v2: Fix conflicts caused by the introduction of struct intel_crtc_state Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Suggested-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
Damien Lespiau authored
Universal planes have changed a bit the register organization. v2: Rebase on top of the latest drm-intel-nightly v3: Use PLANE_SIZE to retrieve the fb size (Tvrtko) Don't use BUG() (Tvrtko) v4: Use MISSING_CASE (Daniel) Reviewed-By:Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Damien Lespiau authored
We will have a skl_ version shortly! Reviewed-By:
-
Damien Lespiau authored
v2: Fix conflict caused by the introduction of struct intel_crtc_state Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Signed-off-by:
-
Damien Lespiau authored
We may as well try to be consistent everywhere and know the pipes by their name. Reviewed-By:
-
Damien Lespiau authored
crtc->plane can only be different from crtc->pipe pre-Gen4. Don't use it in new-ish code. Reviewed-By:
-
Damien Lespiau authored
crtc->base.primary->fb was used everywhere. Use fb to temporarily point there and don't forget to assign fb to its final destination at the end. v2: Rebase on top of misc changes (mask of DSPSURF, PAGE_ALIGN) Reviewed-By:
-
Damien Lespiau authored
If we need to change the fb height constraints, it sounds like a good idea to have to do it in one place only. v2: v2: Rebase on top of Ander's "Make intel_crtc->config a pointer" Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Signed-off-by:
-
Damien Lespiau authored
Rather than having "tiled" meaning "is it X-tiled?" convert the field to explicitely store the tiling mode. The code doesn't have to change much as 1 is conveniently I915_TILING_X. This is to accommodate future changes around tiling modes and scannout buffers. v2: Rebase on top of Ander's "Make intel_crtc->config a pointer" Reviewed-By: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v1) Signed-off-by:
-
Zhe Wang authored
Enable coarse power gating for Gen9. This feature allows render and media engine to enter RC6 independently. Policies are configured together with RC6. This feature will only be enabled when RC6 is enabled. v2: Rebase after Chris'/Mika's forcewake change (Damien) Reviewed-by:
Zhe Wang <zhe1.wang@intel.com> Signed-off-by:
-
Damien Lespiau authored
v2: Use the new function, gen6_init_rps_frequencies() (Damien) Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (v1) Signed-off-by:
-
Jesse Barnes authored
Per latest PM programming guide. v2: the wrong flavour of the function updating the ring frequency was called, leading to dead locks (Tvrtko) v3: Add GEN6_RP_MEDIA_IS_GFX to RP_CONTROL (Imre, done by Damien) Signed-off-by:Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Satheeshakrishna M authored
Adding new power doamins for AUX controllers v2: Added new power domains in power_domain_str per Imre's comment v3: Added AUX power domains to older platforms v4: Rebase on top of POWER_DOMAIN_PLLS. v5: Modified to address review comments from Imre Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
Satheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> (v3) Signed-off-by:
-
Mika Kuoppala authored
There are multiple forcewake domains in newer architectures. Rename 'i915_gen6_forcewake_count_info' debugfs entry to 'i915_forcewake_domains' to reflect this. Signed-off-by:
-
Mika Kuoppala authored
Make the domains and domain identifiers enums. To emphasize the difference in order to avoid mistakes. v2: s/fw_domain/forcewake_domain (Jani) v3: rebase Suggested-by:
-
Mika Kuoppala authored
We have multiple forcewake domains now on recent gens. Change the function naming to reflect this. v2: More verbose names (Chris) v3: Rebase v4: Rebase v5: Add documentation for forcewake_get/put Signed-off-by:
-
Mika Kuoppala authored
These two were using a fw dance logic where posting read was done after both domain bit were set. When in other gens, the posting read is done immediately after setting the forcewake bit for each domain. Now bring these in line with other gens. Signed-off-by:
Deepak S <deepak.s@linux.intel.com> Signed-off-by:
-
Mika Kuoppala authored
As we now have forcewake domains, take advantage of it by putting the differences in gen fw handling in data rather than in code. In past we have opencoded this quite extensively as the fw handling is in the fast path. There has also been a lot of cargo-culted copy'n'pasting from older gens to newer ones. Now when the releasing of the forcewake is done by deferred timer, it gives chance to consolidate more. Due to the frequency of actual hw access being significantly less. Take advantage of this and generalize the fw handling code as much as possible. But we still aim to keep the forcewake sequence particularities for each gen intact. So the access pattern to fw engines should remain the same. v2: - s/old_ack/clear_ack (Chris) - s/post_read/posting_read (Chris) - less polite commit msg (Chris) v3: - rebase - check and clear wake_count in init v4: - fix posting reads for gen8 (PRTS) Signed-off-by: -
Chris Wilson authored
Introduce a structure to track the individual forcewake domains and use that to eliminate duplicate logic. v2: - Rebase on latest dinq (Mika) - for_each_fw_domain macro (Mika) - Handle reset atomically, keeping the timer running (Mika) - for_each_fw_domain parameter ordering (Chris) - defer timer on new register access (Mika) v3: - Fix forcewake_reset/get race by waiting pending timers v4: - cond_resched and verbose warning on timer deletion (Chris) - need to run pending timers manually on reset Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: -
Chris Wilson authored
With gen < 6 we don't need to take uncore lock as we don't have anything to protect from concurrent access. v2: rebase and account for gen9 changes Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by:
-
