summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/intel_panel.c
AgeCommit message (Collapse)Author
2013-09-08drm/i915: Track pfit enable state separately from sizeChris Wilson
Detangle the additional state of whether or not the hw has the pfit enabled from whether it has zero size. This allows us to cleanly distinguish in the code when we expect the pfit to be enabled (for Haswell pc8), and when the BIOS is confused and needs sanitizing. Reported-by: shui yanwei <yangweix.shui@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=68251 Tested-by: shui yanwei <yangweix.shui@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-03drm/i915: Fix pipe config warnings when dealing with LVDS fixed modeVille Syrjälä
intel_fixed_panel_mode() overwrote the adjusted_mode with the fixed mode only partially. Notably it forgot to copy over the sync flags. The LVDS code however programmed the hardware with the sync flags from fixed mode, and then later the pipe config comparison obviously failed as we filled out the adjusted_mode in get_config from the real registers. Just call drm_mode_copy() in intel_fixed_panel_mode() to copy over the whole thing, and then just use adjusted_mode in the LVDS code to figure out which sync settings the hardware needs. Also constify the fixed_mode argument to intel_fixed_panel_mode(). Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-03drm/i915: fix lvds/dp panel fitter settingImre Deak
If need to enable the panel fitter, the crtc timings have to be programmed according to the panel's native (fixed) mode. This isn't the case atm, since after the encoder changes adjusted_mode to fixed mode the crtc_* timing fields of adjusted_mode will stay at their original non-native values that the user passed in. This results in a corrupted output. One exception is when we have a second pass of computing encoder configs due to bandwidth limitation, since then we'll set adjusted_mode.crtc_* fields to the fixed mode values set in the first pass; so in this case things will work out. Fix this by updating the adjusted_mode.crtc_* fields when we set the fixed panel mode. This regression has been introduced in commit 135c81b8c3c9a70d7b55758c9c2a247a4abb7b64 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jul 21 21:37:09 2013 +0200 drm/i915: clean up crtc timings computation Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-02Merge branch 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie
into drm-next Alex writes: This is the radeon drm-next request. Big changes include: - support for dpm on CIK parts - support for ASPM on CIK parts - support for berlin GPUs - major ring handling cleanup - remove the old 3D blit code for bo moves in favor of CP DMA or sDMA - lots of bug fixes [airlied: fix up a bunch of conflicts from drm_order removal] * 'drm-next-3.12' of git://people.freedesktop.org/~agd5f/linux: (898 commits) drm/radeon/dpm: make sure dc performance level limits are valid (CI) drm/radeon/dpm: make sure dc performance level limits are valid (BTC-SI) (v2) drm/radeon: gcc fixes for extended dpm tables drm/radeon: gcc fixes for kb/kv dpm drm/radeon: gcc fixes for ci dpm drm/radeon: gcc fixes for si dpm drm/radeon: gcc fixes for ni dpm drm/radeon: gcc fixes for trinity dpm drm/radeon: gcc fixes for sumo dpm drm/radeonn: gcc fixes for rv7xx/eg/btc dpm drm/radeon: gcc fixes for rv6xx dpm drm/radeon: gcc fixes for radeon_atombios.c drm/radeon: enable UVD interrupts on CIK drm/radeon: fix init ordering for r600+ drm/radeon/dpm: only need to reprogram uvd if uvd pg is enabled drm/radeon: check the return value of uvd_v1_0_start in uvd_v1_0_init drm/radeon: split out radeon_uvd_resume from uvd_v4_2_resume radeon kms: fix uninitialised hotplug work usage in r100_irq_process() drm/radeon/audio: set up the sads on DCE3.2 asics drm/radeon: fix handling of variable sized arrays for router objects ... Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/i915_gem_dmabuf.c drivers/gpu/drm/i915/intel_pm.c drivers/gpu/drm/radeon/cik.c drivers/gpu/drm/radeon/ni.c drivers/gpu/drm/radeon/r600.c
2013-08-07drm/i915: do not disable backlight on vgaswitcheroo switch offJani Nikula
On muxed systems, the other vgaswitcheroo client may depend on i915 to handle the backlight. We began switching off the backlight since commit a261b246ebd552fd5d5a8ed84cc931bb821c427f Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 26 19:21:47 2012 +0200 drm/i915: disable all crtcs at suspend time breaking backlight on discreet graphics in (some) muxed systems. Keep the backlight on when the state is changed through vgaswitcheroo. Note: The alternative would be to add a quirk table to achieve the same based on system identifiers, but AFAICS it would asymptotically approach effectively the same as this patch as more IDs are added, but with the maintenance burden of the quirk table. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55311 Tested-by: Fede <fedevx@yahoo.com> Tested-by: Aximab <laurent.debian@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59785 Tested-by: sfievet <sebastien.fievet@free.fr> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-07drm/i915: avoid brightness overflow when doing scaleAaron Lu
Some card's max brightness level is pretty large, e.g. on Acer Aspire 4732Z, the max level is 989910. If user space set a large enough level then the current scale done in intel_panel_set_backlight will cause an integer overflow and the scaled level will be mistakenly small, leaving user with an almost black screen. This patch fixes this problem. Signed-off-by: Aaron Lu <aaron.lu@intel.com> [danvet: Add a comment to explain what's going on.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-08-04drm/i915: clean up crtc timings computationDaniel Vetter
In the old days of the crtc helpers we've only had the encoder and crtc ->mode_fixup callbacks. So when the lvds connector wanted to adjust the crtc timings it had to set a driver-private mode flag to tell the crtc mode fixup code to not overwrite them with the generic ones. When converting things to the new infrastructure I've kept the entire logic and only moved the flag to pipe_config->timings_set. But this logic is pretty tricky and already caused regressions: commit 21d8a4756af5fdf4a42e79a77cf3b6f52678d443 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Jul 12 08:07:30 2013 +0200 drm/i915: fix pfit regression for non-autoscaled resolutions So take advantage of the flexibility our own modeset infrastructure affords us and prefill default crtc timings. This allows us to rip out ->timings_set. Note that we overwrite things again when retrying the pipe config computation due to bandwidth constraints to avoid bogus crtc timings if the encoder only does relative adjustments (which is how the pfit code works). Only a theoretical concern though since platforms where we retry (pch-split platforms) do not need adjustements (since only the old gmch pfit needs that). But let's better be safe than sorry. Since we now initialize the crtc timings before calling the encoder->compute_config functions the crtc initialization in the gmch pfit code is now redudant and so can be removed. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add a paragraph to the commit message to explain why we can ditch the crtc timings initialization call from the gmch pfit code, to answer a question from Rodrigo's review.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-20drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlightKamal Mostafa
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941 BugLink: https://bugs.launchpad.net/bugs/1163720 BugLink: https://bugs.launchpad.net/bugs/1162026 Some machines suffer from non-functional backlight controls if BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so. Apply this quirk to Dell XPS 13 models. Tested-by: Eric Griffith <EGriffith92@gmail.com> Tested-by: Kent Baxley <kent.baxley@canonical.com> Cc: <stable@vger.kernel.org> # v3.8+ Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-07-12drm/i915: fix pfit regression for non-autoscaled resolutionsDaniel Vetter
I.e. for letter/pillarboxing. For those cases we need to adjust the mode a bit, but Jesse gmch pfit refactoring in commit 2dd24552cab40ea829ba3fda890eeafd2c4816d8 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Apr 25 12:55:01 2013 -0700 drm/i915: factor out GMCH panel fitting code and use for eDP v3 broke that by reordering the computation of the gmch pfit state with the block of code that prepared the adjusted mode for it and told the modeset core not to overwrite the adjusted mode with default settings. We might want to switch around the core code to just fill in defaults, but this code predates the pipe_config modeset rework. And in the old crtc helpers we did not have a suitable spot to do this. Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Hans de Bruin <jmdebruin@xmsnet.nl> Reported-and-tested-by: Hans de Bruin <jmdebruin@xmsnet.nl> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-05-23drm/i915: Fix WARN_ON() on UP machinesVille Syrjälä
WARN_ON(!spin_is_locked()) is not a good idea on a UP system w/o spinlock debugging. Use WARN_ON_SMP() instead. This check has been added in commit 8ba2d18520ce380cf572e9902d9b3b91ece6c2c0 Author: Jani Nikula <jani.nikula@intel.com> Date: Fri Apr 12 15:18:37 2013 +0300 drm/i915: protect backlight registers and data with a spinlock Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-30drm/i915: rip out indirection for pfit pipe_config assignmentDaniel Vetter
This was still required a bit (on the cargo-cult side though) when the state was stored in dev_priv, and when the enable/disable sequence was botched a bit (to avoid too many updates). But with pipeconfig we always get a clean slate, so this is pointless. Rip it out. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-30drm/i915: move lvds_border_bits to pipe_configDaniel Vetter
pipe_config is the new dev_priv! More seriously, this is actually better since a pipe_config can be thrown away if the modeset compute config stage fails. Whereas any state stored in dev_prive needs to be painstakingly restored, since otherwise a dpms off/on will wreak massive havoc. Yes, that even applies to state only used in ->mode_set callbacks, since we need to call those even for dpms on when the Haswell power well cleared everything out. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-25drm/i915: warn about invalid pfit modesJesse Barnes
We prevent invalid ones from getting here in the first place, but it doesn't hurt to have an extra sanity check. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-25drm/i915: move PCH pfit controls into pipe_configJesse Barnes
And put the pfit stuff into substructs while we're at it. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-25drm/i915: factor out GMCH panel fitting code and use for eDP v3Jesse Barnes
This gets the panel fitter working on eDP on VLV, and should also apply to eDP panels on G4x chipsets (if we ever detect and mark an all-in-one panel as eDP anyway). A few cleanups are still possible on top of this, for example the LVDS border control could be placed in the LVDS encoder structure and updated based on the result of the panel fitter calculation. Multi-pipe fitting isn't handled correctly either if we ever get a config that wants to try the panel fitter on more than one output at a time. v2: use pipe_config for storing pfit values (Daniel) add i9xx_pfit_enable function for use by 9xx and VLV (Daniel) v3: fixup conflicts and lvds_dither check Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: fix up botched conflict resolution from Jesse: - border = LVDS_BORDER_ENABLE was lost for CENTER scaling - comment about gen2/3 panel fitter scaling was lost - dev_priv->lvds_dither reintroduced.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-25drm/i915: hsw backlight registers need transcoder instead of pipeJani Nikula
v2: Make TRANSCODER_EDP handling more explicit. (Imre) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-25drm/i915: protect backlight registers and data with a spinlockJani Nikula
Backlight data and registers are fiddled through LVDS/eDP modeset enable/disable hooks, backlight sysfs files, asle interrupts, and register save/restore. Protect the backlight related registers and driver private fields using a spinlock. The locking in register save/restore covers a little more than is strictly necessary, including non-modeset case, for simplicity. v2: Cover register access, save/restore, i915_read_blc_pwm_ctl() and code paths leading there. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-25drm/i915: keep max backlight internal to intel_panel.cJani Nikula
In preparation of adding locking to backlight, make max backlight value (the modulation frequency the PWM duty cycle value must not exceed) internal to intel_panel.c. Have intel_panel_set_backlight() accept a caller defined range for level, and scale input to max backlight value internally. Clean up intel_panel_get_max_backlight() and usage internally. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-18drm/i915: ensure single initialization and cleanup of backlight deviceJani Nikula
Backlight cleanup in the eDP connector destroy callback caused the backlight device to be removed on some systems that first initialized LVDS and then attempted to initialize eDP. Prevent multiple backlight initializations, and ensure backlight cleanup is only done once by moving it to modeset cleanup. A small wrinkle is the introduced asymmetry in backlight setup/cleanup. This could be solved by adding refcounting, but it seems overkill considering that there should only ever be one backlight device. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55701 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Peter Verthez <peter.verthez@skynet.be> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-03Merge tag 'v3.9-rc5' into drm-intel-next-queuedDaniel Vetter
Backmerge Linux 3.9-rc5 since I want to merge a few dp clock cleanups for -next, but they will conflict all over the place with commit 9d1a455b0ca1c2c956b4d9ab212864a8695270f1 Author: Takashi Iwai <tiwai@suse.de> Date: Mon Mar 18 11:25:36 2013 +0100 drm/i915: Use the fixed pixel clock for eDP in intel_dp_set_m_n() from -fixes. Conflicts: drivers/gpu/drm/i915/intel_dp.c: Simply adjacent lines changed. drivers/gpu/drm/i915/intel_panel.c: A field rename in -next conflicts with a bugfix in -fixes. Take the version from -fixes and apply the rename. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-04-02drm/i915: group backlight related stuff into a structJani Nikula
No functional changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-27drm/i915: return actual brightness to .get_brightness callbackJani Nikula
The backlight device .get_brightness callback is supposed to return the actual brightness by querying the hardware, not the cached value. See Documentation/ABI/stable/sysfs-class-backlight. The callback is there to support the actual_brightness sysfs file. With the backlight_level and backlight device brightness now in sync, one can reliably get the cached value through the brightness sysfs file. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-27drm/i915: keep backlight_level and backlight device brightness in syncJani Nikula
A single point of truth would be better than two, but achieving that would require more abstractions for CONFIG_BACKLIGHT_CLASS_DEVICE=n with not a whole lot of real benefits. Take the short route and just keep the backlight levels in sync. In particular, update backlight device brightness on opregion brightness changes. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-24Revert "drm/i915: write backlight harder"Daniel Vetter
This reverts commit cf0a6584aa6d382f802f2c3cacac23ccbccde0cd. Turns out that cargo-culting breaks systems. Note that we can't revert further, since commit 770c12312ad617172b1a65b911d3e6564fc5aca8 Author: Takashi Iwai <tiwai@suse.de> Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid fixed a regression in 3.6-rc kernels for which we've never figured out the exact root cause. But some further inspection of the backlight code reveals that it's seriously lacking locking. And especially the asle backlight update is know to get fired (through some smm magic) when writing specific backlight control registers. So the possibility of suffering from races is rather real. Until those races are fixed I don't think it makes sense to try further hacks. Which sucks a bit, but sometimes that's how it is :( References: http://www.mail-archive.com/intel-gfx@lists.freedesktop.org/msg18788.html Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Tested-by: Takashi Iwai <tiwai@suse.de> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: stable@vger.kernel.org (the reverted commit was cc: stable, too) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-03-23drm/i915: Move num_pipes to intel infoBen Widawsky
Requested by Daniel. v2: Fix incorrect num_pipe settings. (Chris) Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-02-15drm/i915: write backlight harderDaniel Vetter
770c12312ad617172b1a65b911d3e6564fc5aca8 is the first bad commit commit 770c12312ad617172b1a65b911d3e6564fc5aca8 Author: Takashi Iwai <tiwai@suse.de> Date: Sat Aug 11 08:56:42 2012 +0200 drm/i915: Fix blank panel at reopening lid changed the register write sequence for restoring the backlight, which helped prevent non-working backlights on some machines. Turns out that the original sequence was the right thing to do for a different set of machines. Worse, setting the backlight level _after_ enabling it seems to reset it somehow. So we need to make that one conditional upon the backlight having been reset to zero, and add the old one back. Cargo-culting at it's best, but it seems to work. Cc: stable@vger.kernel.org Cc: Takashi Iwai <tiwai@suse.de> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47941 Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-12-04drm/i915: do not access BLC_PWM_CTL2 on pre-gen4 hardwareJani Nikula
The BLC_PWM_CTL2 register does not exist before gen4. While at it, do a slight drive by cleanup of the code. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-21drm/i915: resurrect panel lid handlingDaniel Vetter
But disabled by default. This essentially reverts commit bcd5023c961a44c7149936553b6929b2b233dd27 Author: Dave Airlie <airlied@redhat.com> Date: Mon Mar 14 14:17:55 2011 +1000 drm/i915: disable opregion lid detection for now but leaves the autodetect mode disabled. There's also the explicit lid status option added in commit fca874092597ef946b8f07031d8c31c58b212144 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Feb 17 13:44:48 2011 +0000 drm/i915: Add a module parameter to ignore lid status Which overloaded the meaning for the panel_ignore_lid parameter even more. To fix up this mess, give the non-negative numbers 0,1 the original meaning back and use negative numbers to force a given state. So now we have 1 - disable autodetect, return unknown 0 - enable autodetect -1 - force to disconnected/lid closed -2 - force to connected/lid open v2: My C programmer license has been revoked ... v3: Beautify the code a bit, as suggested by Chris Wilson. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=27622 Tested-by: Andreas Sturmlechner <andreas.sturmlechner@gmail.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-11-20Merge branch 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel ↵Dave Airlie
into drm-next Daniel writes: Highlights of this -next round: - ivb fdi B/C fixes - hsw sprite/plane offset fixes from Damien - unified dp/hdmi encoder for hsw, finally external dp support on hsw (Paulo) - kill-agp and some other prep work in the gtt code from Ben - some fb handling fixes from Ville - massive pile of patches to align hsw VGA with the spec and make it actually work (Paulo) - pile of workarounds from Jesse, mostly for vlv, but also some other related platforms - start of a dev_priv reorg, that thing grew out of bounds and chaotic - small bits&pieces all over the place, down to better error handling for load-detect on gen2 (Chris, Jani, Mika, Zhenyu, ...) On top of the previous pile (just copypasta): - tons of hsw dp prep patches form Paulo - round scheduled work items and timers to nearest second (Chris) - some hw workarounds (Jesse&Damien) - vlv dp support and related fixups (Vijay et al.) - basic haswell dp support, not yet wired up for external ports (Paulo) - edp support (Paulo) - tons of refactorings to prepare for the above (Paulo) - panel rework, unifiying code between lvds and edp panels (Jani) - panel fitter scaling modes (Jani + Yuly Novikov) - panel power improvements, should now work without the BIOS setting it up - extracting some dp helpers from radeon/i915 and move them to drm_dp_helper.c - randome pile of workarounds (Damien, Ben, ...) - some cleanups for the register restore code for suspend/resume - secure batchbuffer support, should enable tear-free blits on gen6+ Chris) - random smaller fixlets and cleanups. * 'for-airlied' of git://people.freedesktop.org/~danvet/drm-intel: (231 commits) drm/i915: Restore physical HWS_PGA after resume drm/i915: Report amount of usable graphics memory in MiB drm/i915/i2c: Track users of GMBUS force-bit drm/i915: Allocate the proper size for contexts. drm/i915: Update load-detect failure paths for modeset-rework drm/i915: Clear unused fields of mode for framebuffer creation drm/i915: Always calculate 8xx WM values based on a 32-bpp framebuffer drm/i915: Fix sparse warnings in from AGP kill code drm/i915: Missed lock change with rps lock drm/i915: Move the remaining gtt code drm/i915: flush system agent TLBs on SNB drm/i915: Kill off now unused gen6+ AGP code drm/i915: Calculate correct stolen size for GEN7+ drm/i915: Stop using AGP layer for GEN6+ drm/i915: drop the double-OP_STOREDW usage in blt_ring_flush drm/i915: don't rewrite the GTT on resume v4 drm/i915: protect RPS/RC6 related accesses (including PCU) with a new mutex drm/i915: put ring frequency and turbo setup into a work queue v5 drm/i915: don't block resume on fb console resume v2 drm/i915: extract l3_parity substruct from dev_priv ...
2012-11-11drm/i915: move the suspend/resume register file out of dev_privDaniel Vetter
dev_priv has grown way too big, and grouping memebers into substructs and moving them out of line helps re-gain some overview. Unfortunatley I couldn't just call the substruct save and drop the prefix, since that will make most member names clash with registers #defines. Changes in i915_drv.h done by hand, everything else changed with s/\<save\([A-Z]*\)/regfile.save\1/ in vim. Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-26drm/i915: be less verbose about inability to provide vendor backlightJani Nikula
commit 28dcc2d60cb570d9f549c329b2f51400553412a1 Author: Jani Nikula <jani.nikula@intel.com> Date: Mon Sep 3 16:25:12 2012 +0300 drm/i915: do not expose a dysfunctional backlight interface to userspace prevents backlight interface creation if the BIOS has not set the backlight PWM CTL registers that contain the max PWM value. It's apparently normal on those machines, so demote the message about it to debug level. Reported-by: Orion Poplawski <orion@cora.nwra.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=56330 Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915: Move the fixed mode to intel_panelJani Nikula
Pave the way for sharing some logic between eDP and LVDS. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915: Create generic intel_panel for LVDS and eDPJani Nikula
Create a generic struct intel_panel for sharing a data structure and code between eDP and LVDS panels. Add the new struct to intel_connector so that later on we can have generic EDID and mode reading functions with EDID caching that transparently fallback to fixed mode when EDID is not available. Add intel_panel as a dummy first, and move data (such as the mentioned fixed mode) to it in later patches. Based on earlier work by Chris Wilson <chris@chris-wilson.co.uk> CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [danvet: Fixup tiny conflict in intel_dp_destroy.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-10-22drm/i915: Backlight setup requires connector so pass it as parameterJani Nikula
Get rid of saved int_lvds_connector and int_edp_connector in drm_i915_private. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-09-03drm/i915: do not expose a dysfunctional backlight interface to userspaceJani Nikula
Previously intel_panel_setup_backlight() would create a sysfs backlight interface with max brightness of 1 if it was unable to figure out the max backlight brightness. This rendered the backlight interface useless. Do not create a dysfunctional backlight interface to begin with. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Tested-by: David Woodhouse <David.Woodhouse@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-11drm/i915: Fix blank panel at reopening lidTakashi Iwai
When you reopen the lid on a laptop with PCH, the panel suddenly goes blank sometimes. It seems because BLC_PWM_CPU_CTL register is cleared to zero when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 registers are enabled. This patch fixes the problem by moving the call of the function setting BLC_PWM_CPU_CTL after enabling other two registers. Reported-and-tested-by: Hugh Dickins <hughd@google.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-06drm/i915: Make intel_panel_get_backlight static.Stéphane Marchesin
This function isn't used outside of intel_panel.c, so make it static. Signed-off-by: Stéphane Marchesin <marcheu@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-07-20drm/i915: don't forget the PCH backlight registersPaulo Zanoni
When we enable/disable the CPU backlight registers we can't forget to enable/disable the PCH backlight registers. Since we're using the CPU registers we should also unset the override bit. Fixes a regression on the following commit: drm/i915: properly enable the blc controller on the right pipe The commit just deleted the code that sets the PCH registers, so it was relying on the values set by the BIOS. I told my BIOS to boot on the DVI monitor instead of the LVDS panel, so I noticed the bug. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-12drm/i915: properly enable the blc controller on the right pipeDaniel Vetter
On gen4+ we have a bitfield to specify from which pipe the backlight controller should take it's clock. For PCH split platforms we've already set these up, but only at initialization time. And without taking into account the 3rd pipe added with ivb. For gen4, we've completely ignored these. Although we do restrict lvds to the 2nd pipe, so this is only a problem on machines where we boot up with the lvds on the first pipe. So restructure the code to enable the backlight on the right pipe at modeset time. v2: For odd reasons panel_enable_backlight gets called twice in a modeset, so we can't WARN_ON in there if the backlight controller is switched on already. v3: backlight enable can also be called through dpms on, so the check in there is legit. Update the comment to reflect that. Tested-By: Kamal Mostafa <kamal@canonical.com> Bugzilla: https://bugs.launchpad.net/bugs/954661 Cc: Carsten Emde <C.Emde@osadl.org> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-06-04drm/i915: don't chnage the original mode in dp_mode_fixupDaniel Vetter
We should only frob adjusted_mode. This is in preparation of a massive patch by Laurent Pinchart to make the mode argument const. After the previous two prep patches the only thing left is to clean up things a bit. I've opted to pass in an adjust_mode param to dp_adjust_dithering because that way we can be sure to avoid duplicating this logic between mode_valid and mode_fixup - which was the cause behind a dp link bw calculation bug in the past. Also mark the mode argument of pch_panel_fitting const. v2: Split up the mode->clock => adjusted_mode->clock change, as suggested by Chris Wilson. Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-22drm/backlight: initialize struct backlight_properties properlyCorentin Chary
The power field was never correctly initialized. [airlied: just took the two drm specific bits] Signed-off-by: Corentin Chary <corentin.chary@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-07Merge tag 'v3.4-rc6' into drm-intel-nextDaniel Vetter
Conflicts: drivers/gpu/drm/i915/intel_display.c Ok, this is a fun story of git totally messing things up. There /shouldn't/ be any conflict in here, because the fixes in -rc6 do only touch functions that have not been changed in -next. The offending commits in drm-next are 14415745b2..1fa611065 which simply move a few functions from intel_display.c to intel_pm.c. The problem seems to be that git diff gets completely confused: $ git diff 14415745b2..1fa611065 is a nice mess in intel_display.c, and the diff leaks into totally unrelated functions, whereas $git diff --minimal 14415745b2..1fa611065 is exactly what we want. Unfortunately there seems to be no way to teach similar smarts to the merge diff and conflict generation code, because with the minimal diff there really shouldn't be any conflicts. For added hilarity, every time something in that area changes the + and - lines in the diff move around like crazy, again resulting in new conflicts. So I fear this mess will stay with us for a little longer (and might result in another backmerge down the road). Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-04-16drm/i915: don't clobber the special upscaling lvds timingsDaniel Vetter
This regression has been introduced in commit ca9bfa7eed20ea34e862804e62aae10eb159edbb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sat Jan 28 14:49:20 2012 +0100 drm/i915: fixup interlaced vertical timings confusion, part 1 Unfortunately that commit failed to take into account that the lvds code does some special adjustements to the crtc timings for upscaling an centering. Fix this by explicitly computing crtc timings in the lvds mode fixup function and setting a special flag in mode->private_flags if the crtc timings have been adjusted. v2: Add a comment to explain the new mode driver private flag, suggested by Eugeni Dodonov. v3: Kill the confusing and now redundant set_crtcinfo call in intel_fixed_panel_mode, noticed by Chris Wilson. Reported-and-Tested-by: Hans de Bruin <jmdebruin@xmsnet.nl> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43071 Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-03-18i915: Add and use pr_fmt and pr_<level>Joe Perches
Use a more current logging style. Ensure that appropriate logging messages are prefixed with "i915: ". Convert printks to pr_<level>. Align arguments. Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-03-18drm/i915: panel: invert brightness via quirkCarsten Emde
A machine may need to invert the panel backlight brightness value. This patch adds the infrastructure for a quirk to do so. Signed-off-by: Carsten Emde <C.Emde@osadl.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-03-18drm/i915: panel: invert brightness via parameterCarsten Emde
Following the documentation of the Legacy Backlight Brightness (LBB) Register in the configuration space of some Intel PCI graphics adapters, setting the LBB register with the value 0x0 causes the backlight to be turned off, and 0xFF causes the backlight to be set to 100% intensity (http://download.intel.com/embedded/processors/Whitepaper/324567.pdf). The Acer Aspire 5734Z, however, turns the backlight off at 0xFF and sets it to maximum intensity at 0. In consequence, the screen of this systems becomes dark at an early boot stage which makes it unusable. The same inversion applies to the BLC_PWM_CTL I915 register. This problem was introduced in kernel version 2.6.38 when the PCI device of this system was first supported by the i915 KMS module. This patch adds a parameter to the i915 module to enable inversion of the brightness variable (i915.invert_brightness). Signed-off-by: Carsten Emde <C.Emde@osadl.org> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-02-10drm/i915: fixup interlaced vertical timings confusion, part 1Daniel Vetter
We have a pretty decent confusion about vertical timings of interlaced modes. Peter Ross has written a patch that makes interlace modes work on a lot more platforms/output combinations by doubling the vertical timings. The issue with that patch is that core drm _does_ support specifying whether we want these vertical timings in fields or frames, we just haven't managed to consistently use this facility. The relavant function is drm_mode_set_crtcinfo, which fills in the crtc timing information. The first thing to note is that the drm core keeps interlaced modes in frames, but displays modelines in fields. So when the crtc modeset helper copies over the mode into adjusted_mode it will already contain vertical timings in half-frames. The result is that the fixup code in intel_crtc_mode_fixup doesn't actually do anything (in most cases at least). Now gen3+ natively supports interlaced modes and wants the vertical timings in frames. Which is what sdvo already fixes up, at least under some conditions. There are a few other place that demand vertical timings in fields but never actually deal with interlaced modes, so use frame timings for consistency, too. These are: - lvds panel, - dvo encoders - dvo is the only way gen2 could support interlaced mode, but currently we don't support any encoders that do. - tv out - despite that the tv dac sends out an interlaced signal it expects a progressive mode pipe configuration. All these encoders enforce progressive modes by resetting interlace_allowed. Hence we always want crtc vertical timings in frames. Enforce this in our crtc mode_fixup function and rip out any redudant timing computations from the encoders' mode_fixup function. v2-4: Adjust the vertical timings a bit. v5: Split out the 'subtract-one for interlaced' fixes. v6: Clarify issues around tv-out and gen2. Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: Christopher Egert <cme3000@gmail.com> Tested-by: Alfonso Fiore <alfonso.fiore@gmail.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-01-17drivers: i915: Fix BLC PWM register setupSimon Que
There is an error in i915_read_blc_pwm_ctl, where the register values are not being copied correctly. BLC_PWM_CTL and BLC_PWM_CTL2 are getting mixed up. This patch fixes that so that saveBLC_PWM_CTL2 and not saveBLC_PWM_CTL is copied to the BLC_PWM_CTL2 register. Signed-off-by: Simon Que <sque@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2011-11-23drm/i915: Treat pre-gen4 backlight duty cycle value consistentlyKeith Packard
For i945 and earlier chips, the backlight frequency value had the low bit (of 16) fixed to zero. The Pineview code path handled this by just exposing the backlight range as 15 bits while other chips had the backlight range limited to 0 .. 0xfffe. This patch makes everyone take the pineview code path, providing 15 bits of backlight duty cycle range which seems more than sufficient to me. Daniel Mack reported that writing 1 to bit 0 of the duty cycle register was causing problems on his Samsung X20 notebook, even when the duty cycle value was less than the maximum backlight value. (He tried a value of 29749 with max_brightness of 29750). This patch never writes a '1' to that bit. Signed-off-by: Keith Packard <keithp@keithp.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Reported-and-tested-by: Daniel Mack <zonque@gmail.com> Cc: stable@kernel.org
2011-11-17drm/i915: Fix inconsistent backlight level during disabledTakashi Iwai
When the brightness property is inquired while the backlight is disabled, the driver returns a wrong value (zero) because it probes the value after the backlight was turned off. This caused a black screen even after the backlight is enabled again. It should return the internal backlight_level instead, so that it won't be influenced by the backlight-enable state. BugLink: https://bugs.freedesktop.org/show_bug.cgi?id=41926 BugLink: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/872652 Tested-by: Kamal Mostafa <kamal@canonical.com> Cc: Alex Davis <alex14641@yahoo.com> Cc: <stable@kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Keith Packard <keithp@keithp.com>