aboutsummaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAge
* drm/i915: Provide a cheap ggtt vma lookupBen Widawsky2013-10-01
| | | | | | | | | | | | | | "We do fairly often lookup the ggtt vma for an obj." - Chris Wilson. As such, provide a function to offer slightly cheaper access to the vma. Not performance tested. By my quick estimation it saves at least 3 pointer dereferences from the existing mechanism. This patch mostly matches code from Chris in <20130911221430.GB7825@nuc-i3427.alporthouse.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: trace vm eviction instead of everythingBen Widawsky2013-10-01
| | | | | | | | | | | | Tracing vm eviction is really the event we care about. For the cases we evict everything, we still will get the trace. v2: Add the drm device to the trace since we might not be the only device in the system. (Chris) Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: remove "extern" keywords from intel_drv.h functionsPaulo Zanoni2013-10-01
| | | | | | | | | | | | Since I already reorganized the header file, Daniel requested me to remove those keywords. It seems "checkpath.pl --strict" also doesn't like "extern" on header files. At least now we're consistent :) Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make hsw_{disable, restore}_lcpll staticPaulo Zanoni2013-10-01
| | | | | | | | These functions were added before the final PC8 implementation, and their callers moved to intel_display.c during the code review. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make intel_crtc_fb_gamma_{set, get} staticPaulo Zanoni2013-10-01
| | | | | | | By moving them to intel_fb.c. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make intel_crtc_load_lut staticPaulo Zanoni2013-10-01
| | | | | | | And move it so it doesn't need a forward declaration. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make intel_pipe_has_type staticPaulo Zanoni2013-10-01
| | | | | | | | Also move it to the top of the file so we can remove the forward declaration. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: reorganize intel_drv.hPaulo Zanoni2013-10-01
| | | | | | | | | | | | | | | | | | Daniel complained that we keep adding stuff to the bottom of the file, so we constantly have conflicts. So reorganize everything and split them file-by-file, also sorting the files in alphabetical order. This way, patches touching different files will have a smaller chance of conflicting. Of course, this commit will conflict with everybody on the list :) Also remove a few useless comments and make some things fit into 80 lines. v2: - Conflict with intel_ddi_get_config Requested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: backlight combination mode bit is gen4 onlyJani Nikula2013-10-01
| | | | | | | | Not valid for later non-PCH split platforms such as VLV. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add HSW CRT output readout supportVille Syrjälä2013-10-01
| | | | | | | | | | | | | | | Call intel_ddi_get_config() to get the pipe_bpp settings from DDI. The sync polarity settings from DDI are irrelevant for CRT output, so override them with data from the ADPA register. v2: Extract intel_crt_get_flags() Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69691 Tested-by: Qingshuai Tian <qingshuai.tian@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: clean up and simplify i9xx_crtc_mode_set wrt PLL handlingJani Nikula2013-10-01
| | | | | | | | | | | Flat out skip anything to do with PLL if we have a DSI encoder (and thus DSI PLL). Also skip PLL computation if the encoder has already set clocks. This allows for some tidying up of the code, including a superfluous call to intel_limit() for LVDS downclock path. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add some debug spam for intialising SDVOChris Wilson2013-10-01
| | | | | | | | | During SDVO initialisation it would be useful to a have a record of the individual devices we try to enable and later probe - in particular to be able to see which fail. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Delay the release of the forcewake by a jiffieChris Wilson2013-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | Obtaining the forcwake requires expensive and time consuming serialisation. And we often try to obtain the forcewake multiple times in very quick succession. We can reduce the overhead of these sequences by delaying the forcewake release, and so not hammer the hw quite so hard. I was hoping this would help with the spurious [drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear. found on Haswell. Alas not. v2: Fix teardown ordering - unmap the regs after turning off forcewake, and make sure we do turn off forcewake - both found by Ville. v3: As we introduce intel_uncore_fini(), use it to make sure everything is disabled before we hand back to the BIOS. Note: I have no claims for improved performance, stablity or power comsumption for this patch. We should not be hitting the registers often enough for this to improve benchmarks, but given the nature of our hw it is likely to improve long term stability. Signed-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>
* drm/i915: precendence bug in GT_PARITY_ERROR()Dan Carpenter2013-10-01
| | | | | | | | | | | | The | operation has higher precedence than "?:" so the macro always returns GT_RENDER_L3_PARITY_ERROR_INTERRUPT_S1. This regression has been introduce in "drm/i915: Add second slice l3 remapping". Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Fix intel_crtc_mode_get() mode clockVille Syrjälä2013-10-01
| | | | | | | | | | | | | | | | | | | i9xx_crtc_clock_get() no longer populates adjusted_mode.clock, so we must get the pixel clock from port_clock in intel_crtc_mode_get(). This bug caused Chris's 845g machine to lockup during boot, and it was introduced in: commit 18442d08786472c63a0a80c27f92b033dffc26de Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Sep 13 16:00:08 2013 +0300 drm/i915: Fix port_clock and adjusted_mode.clock readout all over Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=69713 Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Calculate PSR register offsets from base + genBen Widawsky2013-10-01
| | | | | | | | | | | | | | | | | Future generations will be changing these registers (thanks to design for giving us an early heads up). To help abstract, create the definition of the base of the register block, and define all registers relative to that. Design has promised to not change the offsets relative to the base. v2: Also change IS_HASWELL checks to HAS_PSR CC: Rodrigo Vivi <rodrigo.vivi@gmail.com> CC: Intel GFX <intel-gfx@lists.freedesktop.org> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/dp: read DPCD PSR capability only on eDPJani Nikula2013-10-01
| | | | | | | | Reduce AUX transactions for non-eDP. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Drop explicit plane restoration during resumeVille Syrjälä2013-10-01
| | | | | | | | | We already restore planes during the modeset operation, so no need to do another loop over the planes and try to restore them again. 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>
* drm/i915: Call intel_uncore_early_sanitize() during resumeVille Syrjälä2013-10-01
| | | | | | | | | Call intel_uncore_early_sanitize() first thing during resume to prevent stale BIOS leftovers from being reported as unclaimed register access. 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>
* drm/i915: Move power well resume earlierVille Syrjälä2013-10-01
| | | | | | | | | | i915_restore_state() -> i915_restore_display() will attempt to re-disable VGA during resume. So the power well needs to be powered on before that. 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>
* drm/i915: Move power well init earlier during driver loadVille Syrjälä2013-10-01
| | | | | | | | | | intel_modeset_init() will already attempt to disable VGA. In order to do that, it needs the power well to be on. So move the power well init to happen before intel_modeset_init() during driver load. 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>
* drm/i915: Redisable VGA before the modeset on resumeVille Syrjälä2013-10-01
| | | | | | | | | | | | | | The VGA plane needs to be disabled before we start doing any modeset operations on resume. This should also guarantee that the power well will be enabled when we call i915_redisable_vga() since it gets explicitly powered on during resume, and will get powered back off during the modeset operation if no longer needed. 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>
* drm/i915: Fix unclaimed register access due to delayed VGA memory disableVille Syrjälä2013-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VGA registers live inside the power well on HSW, so in order to write the VGA MSR register we need the power well to be on. We really must write to the register to properly clear the VGA_MSR_MEM_EN enable bit, even if all VGA registers get zeroed when the power well is down. It seems that the implicit zeroing done by the power well is not enough to propagate the VGA_MSR_MEM_EN bit to whomever is actually responsible for the memory decode ranges. If we leave VGA memory decode enabled, and then turn off the power well, all VGA memory reads will return zeroes. But if we first disable VGA memory deocde and then turn off the power well, VGA memory reads return all ones, indicating that the access wasn't claimed by anyone. For the vga arbiter to function correctly the IGD must not claim the VGA memory accesses. Previously we were doing the VGA_MSR register access while the power well was excplicitly powered up during driver init. But ever since commit 6e1b4fdad5157bb9e88777d525704aba24389bee Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu Sep 5 20:40:52 2013 +0300 drm/i915: Delay disabling of VGA memory until vgacon->fbcon handoff is done we delay the VGA memory disable until fbcon has initialized, and so there's a possibility that the power well got turned off during the fbcon modeset. Also vgacon_save_screen() will need the power well to be on to be able to read the VGA memory. So immediately after enabling the power well during init grab a refence for VGA purposes, and after all the VGA handling is done, release it. v2: Add intel_display_power_put() for the num_pipes==0 case Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> [danvet: Fix up the patch wiggle screw-up that I've done and which Paulo catched. Also polish spelling in the patch headline.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rip out SUPPORTS_EDPDaniel Vetter2013-10-01
| | | | | | | | | | | | | | | | It only controls the setting of the vbt.edp_support variable, which in turn only controls one debug output plus can also force-disable the lvds output. Since the value only restricted this logic to mobile ilk there's the slight risk that this will break lvds on desktop ilk or on snb/ivb platforms. But with the vbt it's better when we know what's going on here, so let's rip it out and see what happens. Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: don't init DP or HDMI when not supported by DDI portPaulo Zanoni2013-10-01
| | | | | | | | | | | | | | | | There's no reason to init a DP connector if the encoder just supports HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP AUX transactions to detect if there's something there. Same goes for a DP connector that doesn't support HDMI, but I'm not sure these actually exist. v2: - Use bit fields - Remove useless identation level - Replace DRM_ERROR with DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add some assertions about VBT DDI port typesPaulo Zanoni2013-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | Our code makes a lot of assumptions regarding what each DDI port actually supports, and the VBT should tell us what is really happening in the hardware. So parse the information provided by the VBT and check if any of our assumptions is wrong. Our driver also has a history of not really trusting the VBT, so a WARN here could mean that: a) our coding assumptions are wrong b) the VBT is wrong c) we're incorrectly parsing the VBT d) the checks are wrong But I really hope we won't ever trigger any of those WARNs. v2: Don't check the redundant "Capabilities" field from byte 24 since it doesn't seem to be used. v3: Rebase v4: Replace WARN with DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: check the DDC and AUX bits of the VBT on DDI machinesPaulo Zanoni2013-10-01
| | | | | | | | | | | | | | | | Our code currently assumes that port X will use the DP AUX channel X and the DDC pin X. The VBT should tell us how things are mapped, so add some WARNs in case we discover our assumptions are wrong (or in case the VBT is just wrong, which is also perfectly possible). Why would someone wire port B to AUX C and DDC D? v2: Rebase v3: Convert WARNs to DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use the HDMI DDI buffer translations from VBTPaulo Zanoni2013-10-01
| | | | | | | | | | | | | | | | | | | | | We currently use the recommended values from BSpec, but the VBT specifies the correct value to use for the hardware we have, so use it. We also fall back to the recommended value in case we can't find the VBT. In addition, this code also provides some infrastructure to parse more information about the DDI ports. There's a lot more information we could extract and use in the future. v2: - Move some code to init_vbt_defaults. v3: - Rebase - Clarify the "DVO Port" matching code v4: - Use I915_MAX_PORTS - Change the HAS_DDI checks - Replace DRM_ERROR with DRM_DEBUG_KMS Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: VBT's child_device_config changes over timePaulo Zanoni2013-10-01
| | | | | | | | | | | | | | | | | | We currently treat the child_device_config as a simple struct, but this is not correct: new BDB versions change the meaning of some offsets, so the struct needs to be adjusted for each version. Since there are too many changes (today we're in version 170!), making a big versioned union would be too complicated, so child_device_config is now a union of 3 things: (i) a "raw" byte array that's safe to use anywhere; (ii) an "old" structure that's the one we've been using and should be safe to keep in the SDVO and TV code; and (iii) a "common" structure that should contain only fields that are common for all the known VBT versions. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Do not unlock upon error in i915_gem_idle()Chris Wilson2013-10-01
| | | | | | | | | | | | | | | | We never took the lock ourselves and all callers expect the struct_mutex to be locked upon return (be it success or error), thereore dropping the lock along the error paths looks to be a vestigial error from commit db1b76ca6a79c774074ae87bee7afc0825a478f5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Jul 9 16:51:37 2013 +0200 drm/i915: don't frob mm.suspended when not using ums Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use unsigned for overflow checks in execbufDaniel Vetter2013-10-01
| | | | | | | | | | | | | | | | | | | | | | | | There's actually no real risk since we already check for stricter constraints earlier (using UINT_MAX / sizeof (struct drm_i915_gem_exec_object2) as the limit). But in eb_create we use signed integers, which steals a factor of 2. Luckily struct drm_i915_gem_exec_object2 for this to not matter. Still, be consistent and use unsigned integers. Similar use unsinged integers when checking for overflows in the relocation entry processing. I've also added a new subtests to igt/gem_reloc_overflow to also test for overflowing args->buffer_count values. v2: Give the variables again tighter scope to make it clear that the computation is purely local and doesn't leak out to the 2nd block. Requested by Chris Wilson. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Ditch INTELFB_CONN_LIMITDaniel Vetter2013-10-01
| | | | | | | | | | | | | | | And the gratious overallocation of crtcs. Seems to go back to the ums days of yonder ... We also still need it to make the fbdev emulation happy, but I don't think there's really a need. Especially since the current fbdev emulation doesn't actually support cloning. v2: Use sizeof(*pointer) pattern (Jani). Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use kcalloc moreDaniel Vetter2013-10-01
| | | | | | | | | | | | | | | | | | No buffer overflows here, but better safe than sorry. v2: - Fixup the sizeof conversion, I've missed the pointer deref (Jani). - Drop the redundant GFP_ZERO, kcalloc alreads memsets (Jani). - Use kmalloc_array for the execbuf fastpath to avoid the memset (Chris). I've opted to leave all other conversions as-is since they aren't in a fastpath and dealing with cleared memory instead of random garbage is just generally nicer. Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jani Nikula <jani.nikula@intel.com> [danvet: Drop the contentious kmalloc_array hunk in execbuf.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: use pointer = k[cmz...]alloc(sizeof(*pointer), ...) patternDaniel Vetter2013-10-01
| | | | | | | | | | | Done while reviewing all our allocations for fubar. Also a few errant cases of lacking () for the sizeof operator - just a bit of OCD. I've left out all the conversions that also should use kcalloc from this patch (it's only 2). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'drm-intel-next-2013-09-21-merged' of ↵Dave Airlie2013-09-30
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next drm-intel-next-2013-09-21: - clock state handling rework from Ville - l3 parity handling fixes for hsw from Ben - some more watermark improvements from Ville - ban badly behaved context from Mika - a few vlv improvements from Jesse - VGA power domain handling from Ville drm-intel-next-2013-09-06: - Basic mipi dsi support from Jani. Not yet converted over to drm_bridge since that was too fresh, but the porting is in progress already. - More vma patches from Ben, this time the code to convert the execbuffer code. Now that the shrinker recursion bug is tracked down we can move ahead here again. Yay! - Optimize hw context switching to not generate needless interrupts (Chris Wilson). Also some shuffling for the oustanding request allocation. - Opregion support for SWSCI, although not yet fully wired up (we need a bit of runtime D3 support for that apparently, due to Windows design deficiencies), from Jani Nikula. - A few smaller changes all over. [airlied: merge conflict fix in i9xx_set_pipeconf] * tag 'drm-intel-next-2013-09-21-merged' of git://people.freedesktop.org/~danvet/drm-intel: (119 commits) drm/i915: assume all GM45 Acer laptops use inverted backlight PWM drm/i915: cleanup a min_t() cast drm/i915: Pull intel_init_power_well() out of intel_modeset_init_hw() drm/i915: Add POWER_DOMAIN_VGA drm/i915: Refactor power well refcount inc/dec operations drm/i915: Add intel_display_power_{get, put} to request power for specific domains drm/i915: Change i915_request power well handling drm/i915: POSTING_READ IPS_CTL before waiting for the vblank drm/i915: don't disable ERR_INT on the IRQ handler drm/i915/vlv: disable rc6p and rc6pp residency reporting on BYT drm/i915/vlv: honor i915_enable_rc6 boot param on VLV drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPF drm/i915: Do remaps for all contexts drm/i915: Keep a list of all contexts drm/i915: Make l3 remapping use the ring drm/i915: Add second slice l3 remapping drm/i915: Fix HSW parity test drm/i915: dump crtc timings from the pipe config drm/i915: register backlight device also when backlight class is a module drm/i915: write D_COMP using the mailbox ... Conflicts: drivers/gpu/drm/i915/intel_display.c
| * Merge tag 'v3.12-rc2' into drm-intel-nextDaniel Vetter2013-09-24
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge Linux 3.12-rc2 to prep for a bunch of -next patches: - Header cleanup in intel_drv.h, both changed in -fixes and my current -next pile. - Cursor handling cleanup for -next which depends upon the cursor handling fix merged into -rc2. All just trivial conflicts of the "changed adjacent lines" type: drivers/gpu/drm/i915/i915_gem.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: assume all GM45 Acer laptops use inverted backlight PWMJani Nikula2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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=54171 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: cleanup a min_t() castDan Carpenter2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Pull intel_init_power_well() out of intel_modeset_init_hw()Ville Syrjälä2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add POWER_DOMAIN_VGAVille Syrjälä2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | VGA registers/memory live inside the the display power well. Add a power domain for VGA. 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>
| * | drm/i915: Refactor power well refcount inc/dec operationsVille Syrjälä2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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ä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Add intel_display_power_{get, put} to request power for specific ↵Ville Syrjälä2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | domains 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ä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Change i915_request power well handlingVille Syrjälä2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: 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>
| * | drm/i915: POSTING_READ IPS_CTL before waiting for the vblankPaulo Zanoni2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | Make sure we write to IPS before we actually wait. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: don't disable ERR_INT on the IRQ handlerPaulo Zanoni2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/vlv: disable rc6p and rc6pp residency reporting on BYTJesse Barnes2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915/vlv: honor i915_enable_rc6 boot param on VLVJesse Barnes2013-09-20
| | | | | | | | | | | | | | | | | | | | | | | | Disabling it isn't really an option on these platforms, but having it available for power comparisons is useful. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: s/HAS_L3_GPU_CACHE/HAS_L3_DPFBen Widawsky2013-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Do remaps for all contextsBen Widawsky2013-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: Keep a list of all contextsBen Widawsky2013-09-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <ben@bwidawsk.net> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>