- 10 Oct, 2013 40 commits
-
-
Ville Syrjälä authored
Make sure our primary_disabled matches our expectations after driver init. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70270Tested-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by:
shui yangwei <yangweix.shui@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Paulo Zanoni authored
Regression introduced by: commit 311a2094 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> drm/i915: don't init DP or HDMI when not supported by DDI port Since the commit above it is possible to have a DDI encoder that has the HDMI connector but not the DP connector (in case the port doesn't support DP). In this case, we must properly free the DP connector. We just leak this once, so it's not a big deal. Reported by kmemleak. Signed-off-by: -
Jani Nikula authored
The DP spec allows this, and requires it when full link training is started with non-minimum voltage swing and/or non-zero pre-emphasis. Signed-off-by:
-
Ben Widawsky authored
For future platforms we'll need to initialize our MMIO function pointers even earlier. Specifically, we'll need to be able to have register reads/writes at GTT initialization (in i915_gem_gtt_init). Similarly, these platforms also have MMIO differences based on the PCH id, so while moving stuff around, also move the PCH initialization. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Ben Widawsky <ben@bwidawsk.net> [danvet: Mention the function where we need register access.] Signed-off-by:
-
Paulo Zanoni authored
At the end of haswell_crtc_enable we have an intel_wait_for_vblank with a big comment, and the message suggests it's a workaround for something we don't really understand. So I removed that wait and started getting HW state readout error messages saying that the IPS state is not what we expected. I investigated and concluded that after you write IPS_ENABLE to IPS_CTL, the bit will only actually become 1 on the next vblank. So add code to wait for the IPS_ENABLE bit. We don't really need this wait right now due to the wait I already mentioned, but at least this one has a reason to be there, while the other one is just to workaround some problem: we may remove it in the future. The wait also acts as a POSTING_READ which we missed. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Vetter authored
Something already got misplaced (although it's from a patch from before Paulo's cleanup). Move it to the right spot. v2: Remove the line to keep a neat block, requested by Paulo. Reported-by:
Paulo Zanoni <przanoni@gmail.com> Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
-
Ben Widawsky authored
Now that MMIO has been split up into gen specific functions it is obvious when HAS_FPGA_DBG_UNCLAIMED, HAS_FORCE_WAKE are needed. As such, we can remove this extraneous condition. As a result of this, as well as previously existing function pointers for forcewake, we no longer need the has_force_wake member in the device specific data structure. Signed-off-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Ben Widawsky authored
Similar to the previous patch which implemented GEN specific reads; this patch does the same for writes. Writes have a bit of adding complexity due to the FPGA_DBG feature of HSW plus: gen[2-4]: nothing special gen5: ILK dummy write gen[6-7]: forcewake shenanigans gen[HSW}: forcewake shenanigans + FPGA_DBG I was a bit torn about whether or not to combine 6-HSW as one function, since the FPGA_DBG is cleanly separated, and it wouldn't make the 6-7 MMIO too messy. In the end, I chose the clearest possible solution which splits out HSW. Signed-off-by:
-
Ben Widawsky authored
Extracting the MMIO read functionality makes per gen handling a bit simpler, and the overall function a lot easier to read. The increasing complexity of reads doesn't get too bad as the generation number increases: gen[2-4]: Nothing special gen5: ILK dummy write workaround gen6+: forcewake shenanigans Signed-off-by:
-
Ben Widawsky authored
Just to make the churn and code duplication in upcoming patches a bit less, turn code which is common to all GEN MMIO functions into a macro. v2: Fix typo in subject Signed-off-by:
-
Ben Widawsky authored
In preparation for having per GEN MMIO functions, create, and start using MMIO functions in our uncore data structure. This simply makes the transition easier by allowing us to just plug in the per GEN stuff later. For simplicity, I moved the intel_uncore_init() function down since those rely on static functions defined lower in the file. This is most of the churn in this patch. I made one unrelated change here by using off_t datatype for the offset of the register to write. I like the clarity that this brings to the code. If I did it as a separate patch, I am pretty certain it would get bikeshedded to oblivion. Requested-by:
-
Ben Widawsky authored
In order to be able to have virtual functions for the MMIO, we need to use the raw access function. To keep things simple, just move this to our early_sanitize code in uncore. Signed-off-by:
-
Ben Widawsky authored
For upcoming patches which will have GEN specific MMIO functions, we'll need to initialize the uncore data structure earlier than we do today. If we do not do this, the following will be problematic: intel_uncore_sanitize intel_disable_gt_powersave gen6_disable_rps I915_WRITE(GEN6_RC_CONTROL, 0); <--- MMIO intel_uncore_init // initializes MMIO By initializing the function pointers first, we should be safe. Signed-off-by:
-
Daniel Vetter authored
At least on my i830M here it reliably results in hard system hangs nowadays. This is much worse than falling back to software rendering, so I think we should simply rip this out. After all we don't have any gpu reset for gen3 either, and there are a lot more of those still around. Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by:
-
Daniel Vetter authored
In truly crazy circumstances shmem might give us the wrong type of page. So be a bit paranoid and double check this. Reviewer: Damien Lespiau <damien.lespiau@intel.com> Cc: Rob Clark <robdclark@gmail.com> References: http://lkml.org/lkml/2011/7/11/238Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
Chris Wilson authored
The PIPEA quirk is specifically for the issue with the PIPEB PLL on 830gm being slaved to the PIPEA PLL, and so to use PIPEB requires PIPEA running. i845 doesn't even have the second PLL or pipe, and enabling the quirk results in a blank DVO LVDS. Signed-off-by:
-
Ben Widawsky authored
The policy's max frequency is not equal to the CPU's max frequency. The ring frequency is derived from the CPU frequency, and not the policy frequency. One example of how this may differ through sysfs. If the sysfs max frequency is modified, that will be used for the max ring frequency calculation. (/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq). As far as I know, no current governor uses anything but max as the default, but in theory, they could. Similarly distributions might set policy as part of their init process. It's ideal to use the real frequency because when we're currently scaled up on the GPU. In this case we likely want to race to idle, and using a less than max ring frequency is non-optimal for this situation. AFAIK, this patch should have no impact on a majority of people. This behavior hasn't been changed since it was first introduced: commit 23b2f8bb Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Tue Jun 28 13:04:16 2011 -0700 drm/i915: load a ring frequency scaling table v3 CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
Flush the primary plane changes when enabling/disabling the primary plane in response to sprite visibility. Signed-off-by:
-
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
The new names make it clearer which plane we're talking about. Signed-off-by:
-
Ville Syrjälä authored
The intel_flush_primary_plane name actually tells us which plane we're talking about. Also reorganize the internals a bit and add a missing POSTING_READ() to make sure the hardware has seen the changes by the time we return from the function. Signed-off-by:
-
Ville Syrjälä authored
IPS should be OK as long as one plane is enabled on the pipe, but it does seem to cause problems when going between primary only and sprite only. This needs more investigations, but for now just disable IPS whenever the primary plane is disabled. Signed-off-by:
-
Ville Syrjälä authored
Disable fbc before disabling the primary plane, and enable fbc after the primary plane has been enabled again. Also use intel_disable_fbc() to disable FBC to avoid the pointless overhead of intel_update_fbc(), and especially avoid having to clean up and set up the stolen mem compressed buffer again. Signed-off-by:
-
Ville Syrjälä authored
If the setplane operation fails, we shouldn't save the user's requested plane coordinates. Since we adjust the coordinates during the clipping process, make a copy of the originals, and once the operation has succeeded save them for later reuse when the plane gets re-enabled. Signed-off-by:
-
Ville Syrjälä authored
Move the variable initialization to where the variables are declared, and kill a pointless to_intel_crtc() cast when we already have the casted pointer. Signed-off-by:
-
Ville Syrjälä authored
Let's not use goto when a simple if suffices. This is not error handling code or anything, so the goto looks out of place. Signed-off-by:
-
Ville Syrjälä authored
We used to call the entire intel specific update_plane hook while holding struct_mutex. Actually we only need to hold struct_mutex while pinning/unpinning the obj. The plane state itself is protected by the kms locks, and as the object is pinned we can dig out the offset and tiling information from it without fearing that it would change underneath us. So now we don't need to drop and reacquire the lock around the wait_for_vblank. Also we will need another wait_for_vblank in the IVB specific update_plane hook, and this way we don't need to worry about struct_mutex there either. Also move the intel_plane->obj=NULL assignment outside strut_mutex in disable_plane to make it clear that it's not protected by struct_mutex. Signed-off-by:
-
Ville Syrjälä authored
We allow cursors to be set up when the pipe is disabled. Do the same for sprites as well. We need to be somewhat careful with the primary disable logic as we don't want to accidentally enable the primary plane on a disabled pipe. v2: Skip primary enable/disable and plane registers writes on disabled pipe Signed-off-by: -
Ville Syrjälä authored
If the primary gets marked as disabled while the pipe is off for instance, we should still re-enable it when the pipe is turned on, unless the sprite covers it fully also in that configuration. Unfortunately we do the plane visibility checks only in the sprite code, which is executed after the primary enabling when turning the pipe off. Ideally we should compute the plane visibility before touching the hardware at all, but for now just set the primary_disabld flag in intel_{enable,disable}_plane. Signed-off-by: -
Jani Nikula authored
If channel equalization succeeds, there's no indication something went wrong in clock recovery (unless debug is enabled). We should shout about the failures and fix them instead of hiding them under the carpet. This has allowed bugs like [1] stay dormant for a long time. [1] https://bugs.freedesktop.org/show_bug.cgi?id=70117Signed-off-by:
-
Ville Syrjälä authored
The VGACNTRL register contains a bunch of other stuff besides the VGA_DISP_DISABLE bit. When we write the register we always set those other bits to zero, so normally the current check would work. However on HSW disabling and re-enabling the power well will reset the VGACNTRL register to its default value, which has several of the other bits set as well. So only look at the VGA_DISP_DISABLE bit when checking whether the VGA plane needs re-disabling. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
Everyone else uses intel_PLL_is_valid(), so make VLV use it as well. We don't have any special p and m limits on VLV, so skip those tests, and we also need to skip the m1<=m2 test line PNV. Reorganize the function a bit to move the n check alongside the rest of the test for the non-derived dividers, and check the derived values afterwards. Note that this changes vlv_find_best_dpll() in two ways: - The .vco comparison is now >max instead of >=max, and since we round down when calculating that stuff, we may now allow frequencies slightly above the max as we do on other platforms. The previous method disallowed exactly max and anything above it. - We now check the .dot frequency against the data rate limits, which we didn't do before. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ville Syrjälä authored
If vlv_find_best_dpll() couldn't find suitable PLL settings, just say so instead of lying to caller. Signed-off-by:
-
Ville Syrjälä authored
After aligning the p1 divider limits, and removing the unused p and m limits, intel_limits_vlv_dac and intel_limits_vlv_hdmi are identical. Signed-off-by:
-
Ville Syrjälä authored
We don't use .dot_limit for anything on VLV, so don't populate it. Signed-off-by:
-
Ville Syrjälä authored
We never check the p and m limits (which according to comments are based on someone's guesswork), so just remove them. VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm has no p and m limits listed. Signed-off-by:
-
Ville Syrjälä authored
VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm tells us that the minimum p2 divider is 2. Use that limit on the code. Signed-off-by:
-
Ville Syrjälä authored
According to VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm p1 can be 2-3 always. Signed-off-by:
-
Ville Syrjälä authored
For some reason there's a sort of off by one issue with the p1 divider. The actual p1 limits according to VLV2_DPLL_mphy_hsdpll_frequency_table_ww6_rev1p1.xlsm is 2-3, so we should just say that instead of saying 1-3 and avoiding the 1 via the choice of comparison operator. I don't know why we're using different p1 limits for intel_limits_vlv_dac and intel_limits_vlv_hdmi, but let's preserve that for now. Signed-off-by:
-
Ville Syrjälä authored
We limit the maximum n divider value in order to make sure the PLL's reference inout is at least 19.2 MHz. I assume that is done to satisfy some hardware requirement. However we never check whether that calculated limit is below the maximum supoorted N divider value (7). In practice that is always true since we only support 100 MHz reference clock, but making the code safe against higher reference clocks seems like a reasoanble thing to do. Signed-off-by:
-
