- 14 Oct, 2013 4 commits
-
-
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ä <ville.syrjala@linux.intel.com> Reviewed-by: mario.kleiner.de@gmail.com Tested-by: mario.kleiner.de@gmail.com Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
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:
Chris Wilson <chris@chris-wilson.co.uk> 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:
Paulo Zanoni <paulo.r.zanoni@intel.com> 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:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 10 Oct, 2013 27 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:
Ben Widawsky <ben@bwidawsk.net> [danvet: Frob the message as suggested by Paulo on irc.] Signed-off-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:
-
Chris Wilson authored
We lost the ability to capture the first error for a stuck ring in the recent hangcheck robustification. Whilst both error states are interesting (why does the GPU not recover is also essential to debug), our primary goal is to fix the initial hang and so we need to capture the first error state upon taking hangcheck action. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Let's try to avoid these confusing negated booleans. Signed-off-by:
-
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:
shui yangwei <yangweix.shui@intel.com> Reviewed-by:
-
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:
-
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:
-
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:
-
