An error occurred fetching the project authors.
- 07 Mar, 2014 4 commits
-
-
Imre Deak authored
Based on an early draft from Jesse. Add support for powering on/off the dynamic power wells on VLV by registering its display and dpio dynamic power wells with the power domain framework. For now power on all PHY TX lanes regardless of the actual lane configuration. Later this can be optimized when the PHY side setup enables only the required lanes. Atm, it enables all lanes in all cases. v2: - undef function local COND macro after its last use (Ville) - Take dev_priv->irq_lock around the whole sequence of intel_set_cpu_fifo_underrun_reporting_nolock() and valleyview_disable_display_irqs(). They are short and releasing the lock in between only makes proving correctness more difficult. - sanitize local var names in vlv_power_well_enabled() v3: - rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Resolve conflict due to my changes in the previous patch. Also throw in an assert_spin_locked for safety. And finally appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
We can read out the pipe HW state only if the required power domain is on. If not we consider the pipe to be off. v2: - no change v3: - push down the power domain checks into the specific crtc get_pipe_config handlers (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
Parts that poke port specific HW blocks like the encoder HW state readout or connector hotplug detect code need a way to check whether required power domains are on or enable/disable these. For this purpose add a set of power domains that refer to the port HW blocks. Get the proper port power domains during modeset. For now when requesting the power domain for a DDI port get it for a 4 lane configuration. This can be optimized later to request only the 2 lane power domain, when proper support is added on the VLV PHY side for this. Atm, the PHY setup code assumes a 4 lane config in all cases. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
These functions will be needed by the valleyview specific power well update functionality added in an upcoming patch, so move them earlier. No functional change. v2: - no change v3: - rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 Mar, 2014 11 commits
-
-
Damien Lespiau authored
This macro is similar to for_each_pipe() we already have. Convert the two call sites we have at the same time. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
I recently fumbled a patch because I wrote twice num_sprites[i], and it was the right thing to do in only 50% of the cases. This patch ensures I need to write num_sprites[pipe], ie it should be self-documented that it's per-pipe number of sprites without having to look at what is 'i' this time around. It's all a lame excuse, but it does make it harder to redo the same mistake. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Ville Syrjälä authored
If we need precisely N lanes to satisfy the FDI bandwidth requirement, the code would still claim that we need N+1 lanes. Use DIV_ROUND_UP() to get a more accurate answer. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
After a hang and failed reset, we cannot use the GPU to execute the page flip instructions. Instead we can force a synchronous mmio flip. (Later, we can reduce the synchronicity of the mmio flip by moving some of the delays off to a worker, like the current page flip code; see vblank tasks.) References: https://bugs.freedesktop.org/show_bug.cgi?id=72631Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Since the addition of dev_priv->mm.busy, there's no more need for dev_priv->pc8.gpu_idle, so kill it. Notice that when you remove gpu_idle, hsw_package_c8_gpu_idle and hsw_package_c8_gpu_busy become identical to hsw_enable_package_c8 and hsw_disable_package_c8, so just use them. Also, when we boot the machine, dev_priv->mm.busy initially considers the machine as idle. This is opposed to dev_priv->pc8.gpu_idle, which considered it busy. So dev_priv->pc8.disable_count has to be initalized to 1 now. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Because intel_mark_idle still touches some registers: it needs the machine to be awake. If you set both the autosuspend and PC8 delays to zero, you can get a "Device suspended" WARN when gen6_rps_idle touches registers. This is not easy to reproduce, but happens once in a while when running pm_pc8. Testcase: igt/pm_pc8 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
We currently call intel_mark_idle() too often, as we do so as a side-effect of processing the request queue. However, we the calls to intel_mark_idle() are expected to be paired with a call to intel_mark_busy() (or else we try to idle the hardware by accessing registers that are already disabled). Make the idle/busy tracking explicit to prevent the multiple calls. v2: We can drop some of the complexity in __i915_add_request() as queue_delayed_work() already behaves as we want (not requeuing the item if it is already in the queue) and mark_busy/mark_idle imply that the idle task is inactive. v3: We do still need to cancel the pending idle task so that it is sent again after the current busy load completes (not in the middle of it). Reported-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
This way we can reuse the check on other platforms too. Also factor out a version of the function that doesn't check if the power is on, we'll need to call this from within the power domain framework. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
The power domains framework is internal to the i915 driver, so pass drm_i915_private instead of drm_device to its functions. Also remove a dangling intel_set_power_well() declaration. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
This should be impossible due to the wait for outstanding flips that the caller is meant to perform prior to updating the scanout base. Paranoia tells me to check anyway. References: https://bugs.freedesktop.org/show_bug.cgi?id=75502Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
To silence locking complaints. This was a rebase failure on my part in commit fa9fa083 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Feb 11 15:28:56 2014 -0800 drm/i915: read out hw state earlier v2 Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 04 Mar, 2014 1 commit
-
-
Paulo Zanoni authored
To modeset_update_crtc_power_domains, since this function is responsible for updating all the power domains of all CRTCs after a modeset. In the future we should also run this function on all platforms, not just Haswell. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 02 Mar, 2014 1 commit
-
-
Daniel Vetter authored
Apparently we've missed a few more than what Fengguang's 0-day tester recently reported in i915_irq.c ... Makes sparse happy again (ignore some spurious stuff about ksyms of exported functions). Cc: kbuild test robot <fengguang.wu@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 Feb, 2014 3 commits
-
-
Daniel Vetter authored
Spotted while auditing the code for fencing issues. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Looks like I've missed one of the potential NULL deref bugs in Jesse's fbdev->fb embedded struct to pointer conversions. Fix it up. This regression has been introduced in commit 8bcd4553 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Fri Feb 7 12:10:38 2014 -0800 drm/i915: alloc intel_fb in the intel_fbdev struct Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Imre Deak authored
Since commit d9255d57 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Thu Sep 26 20:05:59 2013 -0300 it became clear that we need to separate the unload sequence into two parts: 1. remove all interfaces through which new operations on some object (crtc, encoder, connector) can be started and make sure all pending operations are completed 2. do the actual tear down of the internal representation of the above objects The above commit achieved this separation for connectors by splitting out the sysfs removal part from the connector's destroy callback and doing this removal before calling drm_mode_config_cleanup() which does the actual tear-down of all the drm objects. Since we'll have to customize the interface removal part for different types of connectors in the upcoming patches, add a new unregister callback and move the interface removal part to it. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 12 Feb, 2014 20 commits
-
-
Daniel Vetter authored
We assign the sarea_priv pointer only in the dma ioctl, which is disallowed when kernel modesetting is enabled. So this is dead code. Cc: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
The BIOS or boot loader will generally create an initial display configuration for us that includes some set of active pipes and displays. This routine tries to figure out which pipes and connectors are active and stuffs them into the crtcs and modes array given to us by the drm_fb_helper code. The overall sequence is: intel_fbdev_init - from driver load intel_fbdev_init_bios - initialize the intel_fbdev using BIOS data drm_fb_helper_init - build fb helper structs drm_fb_helper_single_add_all_connectors - more fb helper structs intel_fbdev_initial_config - apply the config drm_fb_helper_initial_config - call ->probe then register_framebuffer() drm_setup_crtcs - build crtc config for fbdev intel_fb_initial_config - find active connectors etc drm_fb_helper_single_fb_probe - set up fbdev intelfb_create - re-use or alloc fb, build out fbdev structs v2: use BIOS connector config unconditionally if possible (Daniel) check for crtc cloning and reject (Daniel) fix up comments (Daniel) v3: use command line args and preferred modes first (Ville) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> [danvet: Re-add the WARN_ON for a missing encoder crtc - the state sanitizer should take care of this. And spell-ocd the comments.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
We want to reuse this in the fbdev initial config code independently from any fastboot hacks. So allow a bit more flexibility. v2: Forgot to git add ... v3: make non-static (Jesse) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
We want to do this early on before we try to fetch the plane config, which depends on some of the pipe config state. Note that the important part is that we do this before we initialize gem, since otherwise we can't properly pre-reserve the stolen memory for framebuffers inherited from the bios. v2: split back out from get_plane_config change (Daniel) update for recent locking & reset changes (Jesse) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Explain a bit more why we need to move this.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
... and QUIRK_PIPEA_FORCE is not present. I initially thought that case was impossible and just added a WARN on it, but then I was told this case is possible due to QUIRK_PIPEA_FORCE. So let's add a WARN that serves two purposes: - tell us in case we have done something wrong; - document the only case where we expect this. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Add a nice comment explaining why we shouldn't wait for a vblank on all cases, wait based on the HW gen, and add a comment saying we should probably skip that wait on some of the previous HW gens. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Now that we pass struct intel_crtc as an argument, we can check for DSI inside the function, removing one more of those confusing boolean arguments. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Now that we pass struct intel_crtc as an argument, there's no need for it. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
We want to remove those 3 boolean arguments. This is the first step. The "pipe" passed as the argument is always intel_crtc->pipe. Also adjust the function documentation. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
When I forked haswell_crtc_enable I copied all the code from ironlake_crtc_enable. The last piece of the function contains a big comment with a call to intel_wait_for_vblank. After this fork, we rearranged the Haswell code so that it enables the planes as the very last step of the modeset sequence, so we're sure that we call intel_enable_primary_plane after the pipe is really running, so the vblank waiting functions work as expected. I really believe this is what fixes the problem described by the big comment, so let's give it a try and get rid of that intel_wait_for_vblank, saving around 16ms per modeset (and init/resume). We can always revert if needed :) Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Because on Haswell, the pipe is never running at this point, so we hit the 50ms timeout waiting for nothing. We already have two other places where we wait for vblanks on haswell_crtc_enable, so we're safe. This gets us rid of one instance of "vblank wait timed out" for each mode set, which means driver init and resume are also 50ms faster. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Depending on the HW gen and the connector type, the pipe won't start running right after we call intel_enable_pipe, so that intel_wait_for_vblank call we currently have will just sit there for the full 50ms timeout. So this patch adds an argument that will allow us to avoid the vblank wait in case we want. Currently all the callers still request for the vblank wait, so the behavior should still be the same. We also added a POSTING_READ on the register: previously intel_wait_for_vblank was acting as a POSTING_READ, but now if wait_for_vblank is false we'll stkip it, so we need an explicit POSTING_READ. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
For use by get_plane_config. v2: cleanup tile_height bits (Chris) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
In Jesse's patch to switch the fbdev framebuffer from an embedded struct to a pointer the kfree in case of an error was missed. Fix this up by using our own internal fb allocation helper directly instead of reinventing that wheel. We need a to_intel_framebuffer cast unfortunately since all the other callers of _create still look better whith using a drm_framebuffer as return pointer. v2: Add an unlocked __intel_framebuffer_create function since our dev->struct_mutex locking is too much a mess. With ppgtt we even need it to take a look at the global gtt offset of pinned objects, since the vma list might chance from underneath us. At least with the current global gtt lookup functions. Reported by Mika. Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Daniel Vetter authored
Now that it's a normally kmalloce buffer we can use the usual cleanup paths. The upside here is that if we get the refcounting wrong will be able to catch it, since the drm core will complain about leftover framebuffers and kref about underflows. v2: Kill intel_framebuffer_fini - no longer needed now that we refcount all fbs properly and only confusing. v3: We actually still need to call unregister_private to remove the fb from the idr and drop the idr reference - the final unref doesn't do that. So much for remembering my own fb liftime rules. Reported by Imre Deak. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
Touching the VGA registers risks a hard machine hang, at least on this ivb machine after removing a conflicting efifb. This is more than likely related to the discovery that VGA IO decode on the more recent PCH platforms is terminally broken. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Chris Wilson authored
This has very little effect other than log the errors in case of failure, and we then hope for the best. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Jesse Barnes authored
Allocate this struct instead, so we can re-use another allocated elsewhere if needed. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: WARN_ON if there's no backing storage attached to an fb, that's a bug.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
We had 2 set of defines for the same register, so make it one. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-
Damien Lespiau authored
And rename it to num_sprites as this value doesn't count the primary plane. This limit lives with num_pipes really, and now that dev_priv->info is writable we can put it there instead. While at it, introduce a intel_device_info_runtime_init() where we'll be able to gather the device info fields at run-time. v2: rename num_plane to num_sprites (Ville Syrjälä) v3: rebase on top of latest drm-nightly Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> (for v2) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (for v2) Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-