- 20 Sep, 2013 11 commits
-
-
Jani Nikula authored
There is plenty of evidence suggesting all of the GM45 based Acer laptops (including their eMachines and Packard Bell brands) use inverted backlight PWM. Assume this is really the case, and quirk them all. The old bugs that were fixed by subsystem device specific quirks: * https://bugs.freedesktop.org/show_bug.cgi?id=59628 * https://bugzilla.kernel.org/show_bug.cgi?id=31522#c35 * https://bugs.freedesktop.org/show_bug.cgi?id=44156 * https://bugzilla.kernel.org/show_bug.cgi?id=53881 See also this bug and the plethora of duplicates: * https://bugs.launchpad.net/ubuntu/+source/linux/+bug/765438 References: https://bugzilla.kernel.org/show_bug.cgi?id=54171Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Dan Carpenter authored
The lower layers of sysfs will not allow an "offset" of more than GEN7_L3LOG_SIZE and also l3_access_valid() caps it a second time. But it's a little easier to audit if we don't have to worry that the subtraction will result in negative values. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Ville Syrjälä authored
The init and resume codepaths want to handel the power well in slightly different ways, so pull the power well init out from intel_modeset_init_hw() which gets called in both cases. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Ville Syrjälä authored
VGA registers/memory live inside the the display power well. Add a power domain for VGA. Signed-off-by:
-
Ville Syrjälä authored
We increase/decrease the power well refcount in several places now, and all of those places need to do the same thing, so pull that code into a few small helper functions. v2: Rename the funcs to __intel_power_well_{get,put} Signed-off-by: -
Ville Syrjälä authored
Add APIs to get/put power well references for specific purposes. v2: Split the i915_request change to another patch Signed-off-by:
-
Ville Syrjälä authored
Reorganize the internal i915_request power well handling to use the reference count just like everyone else. This way all we need to do is check the reference count and we know whether the power well needs to be enabled of disabled. v2: Split he intel_display_power_{get,put} change to another patch. Add intel_resume_power_well() to make sure we enable the power well on resume Signed-off-by: -
Paulo Zanoni authored
Make sure we write to IPS before we actually wait. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Paulo Zanoni authored
We currently disable the ERR_INT interrupts while running the IRQ handler because we fear that if we do an unclaimed register access from inside the IRQ handler we'll keep triggering the IRQ handler forever. The problem is that since we always disable the ERR_INT interrupts at the IRQ handler, when we get a FIFO underrun we'll always print both messages: - "uncleared fifo underrun on pipe A" - "Pipe A FIFO underrun" Because the "was_enabled" variable from ivybridge_set_fifo_underrun_reporting will always be false (since we disable ERR int at the IRQ handler!). Instead of actually fixing ivybridge_set_fifo_underrun_reporting, let's just remove the "disable ERR_INT during the IRQ handler" code. As far as we know we shouldn't really be triggering ERR_INT interrupts from the IRQ handler, so if we ever get stuck in the endless loop of interrupts we can git-bisect and revert (and we can even bisect and revert this patch in case I'm just wrong). As a bonus, our IRQ handler is now simpler and a few nanoseconds faster. Signed-off-by:
-
Jesse Barnes authored
Byt doesn't have rc6p and rc6pp support and even more important the the offsets of the residency registers there's something else. So Just return a constant 0 to avoid upsetting userspace tools like powertop. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Explain a bit in the commit message what's going on.] Signed-off-by:
-
Jesse Barnes authored
Disabling it isn't really an option on these platforms, but having it available for power comparisons is useful. Signed-off-by:
-
- 19 Sep, 2013 9 commits
-
-
Ben Widawsky authored
We'd only ever used this define to denote whether or not we have the dynamic parity feature (DPF) and never to determine whether or not L3 exists. Baytrail is a good example of where L3 exists, and not DPF. This patch provides clarify in the code for future use cases which might want to actually query whether or not L3 exists. v2: Add /* DPF == dynamic parity feature */ Reviewed-by:
Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
-
Ben Widawsky authored
On both Ivybridge and Haswell, row remapping information is saved and restored with context. This means, we never actually properly supported the l3 remapping because our sysfs interface is asynchronous (and not tied to any context), and the known faulty HW would be reused by the next context to run. Not that due to the asynchronous nature of the sysfs entry, there is no point modifying the registers for the existing context. Instead we set a flag for all contexts to load the correct remapping information on the next run. Interested clients can use debugfs to determine whether or not the row has been remapped. One could propose at this point that we just do the remapping in the kernel. I guess since we have to maintain the sysfs interface anyway, I'm not sure how useful it is, and I do like keeping the policy in userspace; (it wasn't my original decision to make the interface the way it is, so I'm not attached). v2: Force a context switch when we have a remap on the next switch. (Ville) Don't let userspace use the interface with disabled contexts. v3: Don't force a context switch, just let it nop Improper context slice remap initialization, 1<<1 instead of 1<<i, but I rewrote it to avoid a second round of confusion. Error print moved to error path (All Ville) Added a comment on why the slice remap initialization happens. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Ben Widawsky authored
I have implemented this patch before without creating a separate list (I'm having trouble finding the links, but the messages ids are: <1364942743-6041-2-git-send-email-ben@bwidawsk.net> <1365118914-15753-9-git-send-email-ben@bwidawsk.net>) However, the code is much simpler to just use a list and it makes the code from the next patch a lot more pretty. As you'll see in the next patch, the reason for this is to be able to specify when a context needs to get L3 remapping. More details there. Signed-off-by:
-
Ben Widawsky authored
Using LRI for setting the remapping registers allows us to stream l3 remapping information. This is necessary to handle per context remaps as we'll see implemented in an upcoming patch. Using the ring also means we don't need to frob the DOP clock gating bits. v2: Add comment about lack of worry for concurrent register access (Daniel) Signed-off-by:
-
Ben Widawsky authored
Certain HSW SKUs have a second bank of L3. This L3 remapping has a separate register set, and interrupt from the first "slice". A slice is simply a term to define some subset of the GPU's l3 cache. This patch implements both the interrupt handler, and ability to communicate with userspace about this second slice. v2: Remove redundant check about non-existent slice. Change warning about interrupts of unknown slices to WARN_ON_ONCE Handle the case where we get 2 slice interrupts concurrently, and switch the tracking of interrupts to be non-destructive (all Ville) Don't enable/mask the second slice parity interrupt for ivb/vlv (even though all docs I can find claim it's rsvd) (Ville + Bryan) Keep BYT excluded from L3 parity v3: Fix the slice = ffs to be decremented by one (found by Ville). When I initially did my testing on the series, I was using 1-based slice counting, so this code was correct. Not sure why my simpler tests that I've been running since then didn't pick it up sooner. Reviewed-by:
-
Ben Widawsky authored
Haswell changed the log registers to be WO, so we can no longer read them to determine the programming (which sucks, see later note). For now, simply use the cached value, and hope HW doesn't screw us over. v2: Simplify the logic to avoid an extra !, remove last, and fix the buffer offset which broke along the rebase (Ville) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57441 CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Daniel Vetter authored
I always get royally confused how a modeline with all zeros could possible pass the paranoid pipe config checker. Until I realize again that we only check the crtc timings. So dump the crtc timings for the adjusted mode. This will be even more important for 3D support where the crtc timings are markedly different from the input modeline if we have frame-by-frame 3d output enabled. Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
Damien Lespiau <damien.lespiau@intel.com> Signed-off-by:
-
Jani Nikula authored
Ville and I were wondering why his laptop was missing the intel_backlight sysfs interface. Turns out we never register it when CONFIG_BACKLIGHT_CLASS_DEVICE=m. This has been broken ever since the i915 native backlight interface was added. CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Paulo Zanoni authored
You can't write it using the MCHBAR mirror, the write will just get dropped. This should make us BSpec-compliant, but there's no real bug I could reproduce that is fixed by this patch. Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by:
-
- 17 Sep, 2013 14 commits
-
-
Paulo Zanoni authored
Sometimes I see the "non asle set request??" message on my Haswell machine, so I decided to get the spec and see if some bits are missing from the mask. We do have some bits missing from the mask, so this patch adds them, and the corresponding code to print "unsupported" messages just like we do with the other bits we don't support. But I still see the "non asle set request??" message on my machine :( Also use the proper ASLC name to indicate the registers we're talking about. v2: - Properly set the new FAILED bits - Rename the old FAILED bits - Print everything we don't support Signed-off-by: -
Jani Nikula authored
This reduces dmesg noise when there's a glitch on the hpd line, or there are more than one connectors on the same hpd line and only one of them changes. While at it, switch to use the friendly status names instead of numbers. Signed-off-by:
-
Paulo Zanoni authored
So far we control everything and nothing exceeds the current limits, but (i) we never think about these limits when reviewing patches, (ii) not all the callers check the return values and (iii) if we ever hit any of these messages, we'll have to fix the code that added the bad message. The current limit for these messages is 20 since we only have 5 data registers on all the current gens. The checks inside intel_dp_aux_native_{write,read} are to prevent buffer overflows. The check inside intel_dp_aux_ch is to prevent writing past our 5 data registers. Signed-off-by: -
Ville Syrjälä authored
Signed-off-by:
-
Ville Syrjälä authored
Double wide mode is only available on pipe A, except on GDG where pipe B is also double wide capable. Signed-off-by:
-
Ville Syrjälä authored
Pipe horizontal source size must be even when either LVDS dual channel mode, DVO ganged mode, or pipe double wide mode is used. We must round it down since we can never increase the user specified viewport size. The actual error from an odd pipe source width looks like a diagonal shift, like you might get from a bad stride. v2: s/ganaged/ganged/ Signed-off-by:
-
Ville Syrjälä authored
We don't want to try to push the hardware beyond it's capabilities, so check the pixel clock against the display core clock limit. Do it for pre-gen4 for now since that's where we alread have the double wide pixel clock limit check. Let's assume that when double wide mode is enabled the max pixel clock limit is also doubled. FIXME: panel fitter downscaling probably affects the limit on non-pch platforms too, so we'd need another version of ilk_pipe_pixel_rate() to figure that out. FIXME: should check the limits on all platforms. Also sprites affect the max allowed pixel rate on some platforms, so we need to eventually tie all the planes and pipes into one check in the future. But we need plane state pre-compute before that can happen. Signed-off-by:
-
Ville Syrjälä authored
Read the double wide pipe information from hardware in i9xx_get_pipe_config(), and check it in intel_pipe_config_compare() For gen4+ double_wide is always false so the comparison can be done on all platforms. Signed-off-by:
-
Ville Syrjälä authored
Determine the need for double wide mode already in compute_config stage as we need that information to figure out if horizontal coordinates need to be adjusted. Signed-off-by:
-
Daniel Vetter authored
Simply inline the 100MHz default we're using. Having gunk around that has leftover LVDS support on a platform that just doesn't have this isn't of any use. Reviewed-by:
-
Ville Syrjälä authored
First of all we should not be looking at fb->{width,height} as those do not tell us what the actual pipe size is. Second of all we need to use >= for the comparison. So fix the comparison, and make use of the new pipe_src_{w,h} to determine the real pipe source dimensions. Reviewed-by: -
Ville Syrjälä authored
When the cursor x coordinate is exactly -cursor_width, the cursor is invisible. And obviously the same holds for the y coordinate and cursor_height. Reviewed-by:
-
Ville Syrjälä authored
Try to clarify the purpose of requested_mode. Signed-off-by:
-
Daniel Vetter authored
Especially intel_gmch_panel_fitting was shifting way too much over the right edge and also was way too long. So extract two helpers, one for gen4+ and one for gen2/3. Now the entire thing is again almost readable ... Spurred by checkpatch freaking out about a Ville's pipeconfig rework in intel_panel.c Otherwise just two lines that needed appropriate breaking. Not functional change in this patch. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by:
-
- 16 Sep, 2013 6 commits
-
-
Ville Syrjälä authored
Rather that mess about with hdisplay/vdisplay from requested_mode, add explicit pipe src size information to pipe config. Now requested_mode is only really relevant for dvo/sdvo output timings. For everything else either adjusted_mode or pipe src size should be used. In many places where we end up using pipe source size, we should actually use the primary plane size, but we don't currently store that information explicitly. As long as we treat primaries as full screen only, we can get away with this. Eventually when we move primaries over to drm_plane, we need to fix it all up. v2: Add a comment to explain what pipe_src_{w,h} are Add a note about primary planes to commit message Signed-off-by: -
Ville Syrjälä authored
adjusted_mode contains our real timings, not requested_mode. Use the correct thing in DSI PLL code. Also constify adjusted_mode since we don't change it. Signed-off-by:
-
Ville Syrjälä authored
Rather than dig up the pipe source size from crtc->mode, use intel_crtc->config.requested_mode. Signed-off-by:
-
Ville Syrjälä authored
Move intel_crtc_active() to intel_display.c and make it available elsewhere as well. intel_edp_psr_match_conditions() already has one open coded copy, so replace that one with a call to intel_crtc_active(). v2: Copy paste a big comment from danvet's mail explaining when we can ditch the extra checks Signed-off-by: -
Ville Syrjälä authored
intel_edp_psr_match_conditions() currently looks at crtc->mode when it really needs to look at adjusted_mode. Fix it. Signed-off-by:
-
Ville Syrjälä authored
The clock in crtc->mode doesn't necessarily mean anything. Let's look at the clock in adjusted_mode instead. Signed-off-by:
-
