summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_opregion.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915/opregion: handle VBT sizes bigger than 6 KBJani Nikula2015-12-171-3/+24
| | | | | | | | | | | | | | The RVDA and RVDS (raw VBT data address and size) fields of the ASLE mailbox may specify an alternate location for VBT instead of mailbox #4. Use the alternate location if available and valid, falling back to mailbox #4 otherwise. v2: Update debug logging (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178280-28020-1-git-send-email-jani.nikula@intel.com
* drm/i915: prefer for_each_intel_* macros for iterationJani Nikula2015-12-161-3/+3
| | | | | | | | | Use the for_each_intel_* macros for iterating intel_encoder, intel_connector, and intel_crtc. No functional changes. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450262896-5325-1-git-send-email-jani.nikula@intel.com
* drm/i915/debugfs: add a separate debugfs file for VBTJani Nikula2015-12-161-0/+1
| | | | | | | | | | | | | In the future the VBT might not be in mailbox #4 of the ACPI OpRegion, thus unavailable in i915_opregion, so add a separate file for the VBT. v2: Drop the locking as unneeded (Chris) v3: Rebase Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178232-27780-1-git-send-email-jani.nikula@intel.com
* drm/i915/opregion: make VBT pointer a constJani Nikula2015-12-161-1/+1
| | | | | | | | Because we can. It's not to be touched so tell the compiler too. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/4b1872b121fb34a193cff9a5cb4e7c858d4a55aa.1450089383.git.jani.nikula@intel.com
* drm/i915/opregion: make VBT size limit more strictJani Nikula2015-12-161-1/+1
| | | | | | | | The VBT in OpRegion should fit in mailbox #4. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/4bdb3f5820e3dbd1cdfa7b65cadfce4f80b880f0.1450089383.git.jani.nikula@intel.com
* drm/i915: refactor VBT validationJani Nikula2015-12-161-2/+9
| | | | | | | | | | | | | | Make the validation function a boolean operating on a buffer of given size, removing the extra pointer dances. Move the OpRegion based VBT validation to intel_opregion_setup(), only initializing opregion->vbt if it's valid. v2: move logging about valid VBT to opregion setup too (Ville) Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450178175-27420-1-git-send-email-jani.nikula@intel.com
* drm/i915: move "no VBT in opregion" quirk to intel_opregion_setup()Jani Nikula2015-12-161-2/+23
| | | | | | | | | | Check the quirk in intel_opregion_setup(), and don't initialize opregion->vbt at all if the quirk says it's not present, hiding the quirk from the rest of the driver. Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/7cdc86eb441f8b7075142445a800b07ecf8c76cb.1450089383.git.jani.nikula@intel.com
* drm/i915: Add Intel opregion mailbox 5 structureDeepak M2015-12-161-0/+13
| | | | | | | | | | | | | | | | | | | Mailbox 5 is BIOS to Driver Notification mailbox is intended to support BIOS to Driver event notification or data storage for BIOS to Driver data synchronization purpose. Mailbox 5 is the extension of mailbox 3. v4 by Jani: - don't add asle_ext to dev_priv as it's unused - use u8 for bddc and rsvd fields in asle ext struct - add BUILD_BUG_ON the asle ext struct size - debug logging for asle ext present Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Deepak M <m.deepak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/c2d4009659fca32280d9859ec34a62f45b86d895.1450089383.git.jani.nikula@intel.com
* drm/i915: add VBT address and size fields to ASLE mailbox structDeepak M2015-12-111-1/+3
| | | | | | | | | | | | | To be used on systems where the VBT does not fit into the normal VBT mailbox. v3: rebase Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Deepak M <m.deepak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1448923632-16760-3-git-send-email-m.deepak@intel.com [Jani: updated commit message] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* drm/i915: Don't complain about lack of ACPI video biosDaniel Vetter2015-10-311-1/+1
| | | | | | | | | | Another CI fail we have for no reason. Totally unjustified since nothing fails at all. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445590806-23886-1-git-send-email-daniel.vetter@ffwll.ch Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* i915: switch from acpi_os_ioremap to memremapWilliams, Dan J2015-10-131-42/+41
| | | | | | | | | | | | | | i915 expects the OpRegion to be cached (i.e. not __iomem), so explicitly map it with memremap rather than the implied cache setting of acpi_os_ioremap(). Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/bxt: DSI encoder support in CRTC modesetShashank Sharma2015-10-021-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | SKL and BXT qualifies the HAS_DDI() check, and hence haswell modeset functions are re-used for modeset sequence. But DDI interface doesn't include support for DSI. This patch adds: 1. cases for DSI encoder, in those modeset functions and allows a CRTC modeset 2. Adds call to pre_pll enabled from CRTC modeset function. Nothing needs to be done as such in CRTC for DSI encoder, as PLL, clock and and transcoder programming will be taken care in encoder's pre_enable and pre_pll_enable function. v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI encoder like DSI for platforms having HAS_DDI as true. v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid encoder. v4: WARN_ON for invalid encoder is refactored as per Jani's suggestion. Fixed the sequence for pre_pll_enable. v5: Protected DDI code paths in case of DSI encoder calls. Signed-off-by: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Uma Shankar <uma.shankar@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'drm-intel-fixes-2015-07-15' into drm-intel-next-queuedDaniel Vetter2015-07-151-11/+1
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Backmerge fixes since it's getting out of hand again with the massive split due to atomic between -next and 4.2-rc. All the bugfixes in 4.2-rc are addressed already (by converting more towards atomic instead of minimal duct-tape) so just always pick the version in next for the conflicts in modeset code. All the other conflicts are just adjacent lines changed. Conflicts: drivers/gpu/drm/i915/i915_drv.h drivers/gpu/drm/i915/i915_gem_gtt.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_drv.h drivers/gpu/drm/i915/intel_ringbuffer.h Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
| * drm: i915: Port to new backlight interface selection APIHans de Goede2015-06-191-11/+1
| | | | | | | | | | | | | | | | | | | | This results in a nice cleanup, as we can replace the complicated logic from should_ignore_backlight_request() with a simple check for the type being native. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | drm/i915/opregion: start using extended didlJani Nikula2015-07-061-7/+21
| | | | | | | | | | | | | | | | | | Adding support for did2, or the extended support display devices ID list, increases the total to 15. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/opregion: abstract didl and did2 getter and setterJani Nikula2015-07-061-11/+39
| | | | | | | | | | | | | | | | Make it easier to handle the extended didl. No functional changes. 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>
* | drm/i915/opregion: prefer DRM logging functions over pr_warn and dev_dbgJani Nikula2015-07-061-7/+3
| | | | | | | | | | | | | | | | Conform to same style as the rest of the driver. 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>
* | drm/i915/opregion: add new opregion stuffJani Nikula2015-07-061-3/+12
| | | | | | | | | | | | | | | | | | | | Inluding extended didl and cpdl fields Present since opregion version 3.0. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915/opregion: use BUILD_BUG_ON to verify mailbox struct sizesJani Nikula2015-07-061-0/+5
|/ | | | | | 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>
* drm/i915: Remove DRIVER_MODESET checks from modeset codeDaniel Vetter2015-02-271-4/+2
| | | | | | | | Mostly just checks in i915-private modeset ioctls. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* ACPI / i915: Update the condition to ignore firmware backlight change requestAaron Lu2014-09-301-5/+11
| | | | | | | | | | | | | | | | | | | | | | Some of the Thinkpads' firmware will issue a backlight change request through i915 operation region unconditionally on AC plug/unplug, the backlight level used is arbitrary and thus should be ignored. This is handled by commit 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change). Then there is a Dell laptop whose vendor backlight interface also makes use of operation region to change backlight level and with the above commit, that interface no long works. The condition used to ignore the backlight change request from firmware is thus changed to: if the vendor backlight interface is not in use and the ACPI backlight interface is broken, we ignore the requests; oterwise, we keep processing them. Fixes: 0b9f7d93ca61 (ACPI / i915: ignore firmware requests for backlight change) Link: https://lkml.org/lkml/2014/9/23/854 Reported-and-tested-by: Pali Rohár <pali.rohar@gmail.com> Cc: 3.16+ <stable@vger.kernel.org> # 3.16+ Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'v3.16' into drm-nextDave Airlie2014-08-051-0/+9
|\ | | | | | | | | | | | | | | | | | | Linux 3.16 backmerge requested by i915, nouveau and radeon authors Conflicts: drivers/gpu/drm/i915/i915_gem_render_state.c drivers/gpu/drm/i915/intel_drv.h
| * ACPI / i915: ignore firmware requests for backlight changeAaron Lu2014-07-071-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some Thinkpad laptops' firmware will initiate a backlight level change request through operation region on the events of AC plug/unplug, but since we are not using firmware's interface to do the backlight setting on these affected laptops, we do not want the firmware to use some arbitrary value from its ASL variable to set the backlight level on AC plug/unplug either. Link: https://bugzilla.kernel.org/show_bug.cgi?id=76491 Link: https://bugzilla.kernel.org/show_bug.cgi?id=77091 Reported-and-tested-by: Igor Gnatenko <i.gnatenko.brain@gmail.com> Reported-and-tested-by: Anton Gubarkov <anton.gubarkov@gmail.com> Signed-off-by: Aaron Lu <aaron.lu@intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | Merge remote-tracking branch 'airlied/drm-next' into drm-intel-nextDaniel Vetter2014-07-291-0/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull in drm-next with Dave's DP MST support so that I can merge some conflicting patches which also touch the driver load sequencing around interrupt handling. Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: add DP 1.2 MST support (v0.7)Dave Airlie2014-07-221-0/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds DP 1.2 MST support on Haswell systems. Notes: a) this reworks irq handling for DP MST ports, so that we can avoid the mode config locking in the current hpd handlers, as we need to process up/down msgs at a better time. Changes since v0.1: use PORT_PCH_HOTPLUG to detect short vs long pulses add a workqueue to deal with digital events as they can get blocked on the main workqueue beyong mode_config mutex fix a bunch of modeset checker warnings acks irqs in the driver cleanup the MST encoders Changes since v0.2: check irq status again in work handler move around bring up and tear down to fix DPMS on/off use path properties. Changes since v0.3: updates for mst apis more state checker fixes irq handling improvements fbcon handling support improved reference counting of link - fixes redocking. Changes since v0.4: handle gpu reset hpd reinit without oopsing check link status on HPD irqs fix suspend/resume Changes since v0.5: use proper functions to get max link/lane counts fix another checker backtrace - due to connectors disappearing. set output type in more places fro, unknown->displayport don't talk to devices if no HPD asserted check mst on short irqs only check link status properly rebase onto prepping irq changes. drop unsued force_act Changes since v0.6: cleanup unused struct entry. [airlied: fix some sparse warnings]. Reviewed-by: Todd Previte <tprevite@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | drm/i915: respect the VBT minimum backlight brightnessJani Nikula2014-07-231-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Historically we've exposed the full backlight PWM duty cycle range to the userspace, in the name of "mechanism, not policy". However, it turns out there are both panels and board designs where there is a minimum duty cycle that is required for proper operation. The minimum duty cycle is available in the VBT. The backlight class sysfs interface does not make any promises to the userspace about the physical meaning of the range 0..max_brightness. Specifically there is no guarantee that 0 means off; indeed for acpi_backlight 0 usually is not off, but the minimum acceptable value. Respect the minimum backlight, and expose the range acceptable to the hardware as 0..max_brightness to the userspace via the backlight class device; 0 means the minimum acceptable enabled value. To switch off the backlight, the user must disable the encoder. As a side effect, make the backlight class device max brightness and physical PWM modulation frequency (i.e. max duty cycle) independent. This allows a follow-up patch to virtualize the max value exposed to the userspace. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: s/BUG_ON/WARN_ON/] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: convert crtc and connection_mutex to ww_mutex (v5)Rob Clark2014-06-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | For atomic, it will be quite necessary to not need to care so much about locking order. And 'state' gives us a convenient place to stash a ww_ctx for any sort of update that needs to grab multiple crtc locks. Because we will want to eventually make locking even more fine grained (giving locks to planes, connectors, etc), split out drm_modeset_lock and drm_modeset_acquire_ctx to track acquired locks. Atomic will use this to keep track of which locks have been acquired in a transaction. v1: original v2: remove a few things not needed until atomic, for now v3: update for v3 of connection_mutex patch.. v4: squash in docbook v5: doc tweaks/fixes Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: Split connection_mutex out of mode_config.mutex (v3)Daniel Vetter2014-06-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After the split-out of crtc locks from the big mode_config.mutex there's still two major areas it protects: - Various connector probe states, like connector->status, EDID properties, probed mode lists and similar information. - The links from connector->encoder and encoder->crtc and other modeset-relevant connector state (e.g. properties which control the panel fitter). The later is used by modeset operations. But they don't really care about the former since it's allowed to e.g. enable a disconnected VGA output or with a mode not in the probed list. Thus far this hasn't been a problem, but for the atomic modeset conversion Rob Clark needs to convert all modeset relevant locks into w/w locks. This is required because the order of acquisition is determined by how userspace supplies the atomic modeset data. This has run into troubles in the detect path since the i915 load detect code needs _both_ protections offered by the mode_config.mutex: It updates probe state and it needs to change the modeset configuration to enable the temporary load detect pipe. The big deal here is that for the probe/detect users of this lock a plain mutex fits best, but for atomic modesets we really want a w/w mutex. To fix this lets split out a new connection_mutex lock for the modeset relevant parts. For simplicity I've decided to only add one additional lock for all connector/encoder links and modeset configuration states. We have piles of different modeset objects in addition to those (like bridges or panels), so adding per-object locks would be much more effort. Also, we're guaranteed (at least for now) to do a full modeset if we need to acquire this lock. Which means that fine-grained locking is fairly irrelevant compared to the amount of time the full modeset will take. I've done a full audit, and there's just a few things that justify special focus: - Locking in drm_sysfs.c is almost completely absent. We should sprinkle mode_config.connection_mutex over this file a bit, but since it already lacks mode_config.mutex this patch wont make the situation any worse. This is material for a follow-up patch. - omap has a omap_framebuffer_flush function which walks the connector->encoder->crtc links and is called from many contexts. Some look like they don't acquire mode_config.mutex, so this is already racy. Again fixing this is material for a separate patch. - The radeon hot_plug function to retrain DP links looks at connector->dpms. Currently this happens without any locking, so is already racy. I think radeon_hotplug_work_func should gain mutex_lock/unlock calls for the mode_config.connection_mutex. - Same applies to i915's intel_dp_hot_plug. But again, this is already racy. - i915 load_detect code needs to acquire this lock. Which means the w/w dance due to Rob's work will be nicely contained to _just_ this function. I've added fixme comments everywhere where it looks suspicious but in the sysfs code. After a quick irc discussion with Dave Airlie it sounds like the lack of locking in there is due to sysfs cleanup fun at module unload. v1: original (only compile tested) v2: missing mutex_init(), etc (from Rob Clark) v3: i915 needs more care in the conversion: - Protect the edp pp logic with the connection_mutex. - Use connection_mutex in the backlight code due to get_pipe_from_connector. - Use drm_modeset_lock_all in suspend/resume paths. - Update lock checks in the overlay code. Cc: Alex Deucher <alexdeucher@gmail.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Rob Clark <robdclark@gmail.com>
* Merge tag 'drm-intel-fixes-2014-02-06' of ↵Dave Airlie2014-02-111-3/+6
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | ssh://git.freedesktop.org/git/drm-intel into drm-next Just minor stuff really, on vlv dp fix and two patches to tune down some opregion sanity check. Plus MAINTAINERS update for the new git repo, which is the only reason I've really bothered with this pull request. * tag 'drm-intel-fixes-2014-02-06' of ssh://git.freedesktop.org/git/drm-intel: drm/i915: demote opregion excessive timeout WARN_ONCE to DRM_INFO_ONCE drm: add DRM_INFO_ONCE() to print a one-time DRM_INFO() message MAINTAINERS: Update drm/i915 git repo drm/i915: vlv: fix DP PHY lockup due to invalid PP sequencer setup
| * drm/i915: demote opregion excessive timeout WARN_ONCE to DRM_INFO_ONCEJani Nikula2014-02-041-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The WARN_ONCE is a bit too verbose, make it a DRM_INFO_ONCE. While at it, add a #define for MAX_DSLP and make the message a bit more informative. v2: use DRM_INFO_ONCE, add MAX_DSLP, pimp the message. Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> 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>
* | Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2014-01-291-35/+12
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm updates from Dave Airlie: "Been a bit busy, first week of kids school, and waiting on other trees to go in before I could send this, so its a bit later than I'd normally like. Highlights: - core: timestamp fixes, lots of misc cleanups - new drivers: bochs virtual vga - vmwgfx: major overhaul for their nextgen virt gpu. - i915: runtime D3 on HSW, watermark fixes, power well work, fbc fixes, bdw is no longer prelim. - nouveau: gk110/208 acceleration, more pm groundwork, old overlay support - radeon: dpm rework and clockgating for CIK, pci config reset, big endian fixes - tegra: panel support and DSI support, build as module, prime. - armada, omap, gma500, rcar, exynos, mgag200, cirrus, ast: fixes - msm: hdmi support for mdp5" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (595 commits) drm/nouveau: resume display if any later suspend bits fail drm/nouveau: fix lock unbalance in nouveau_crtc_page_flip drm/nouveau: implement hooks for needed for drm vblank timestamping support drm/nouveau/disp: add a method to fetch info needed by drm vblank timestamping drm/nv50: fill in crtc mode struct members from crtc_mode_fixup drm/radeon/dce8: workaround for atom BlankCrtc table drm/radeon/DCE4+: clear bios scratch dpms bit (v2) drm/radeon: set si_notify_smc_display_change properly drm/radeon: fix DAC interrupt handling on DCE5+ drm/radeon: clean up active vram sizing drm/radeon: skip async dma init on r6xx drm/radeon/runpm: don't runtime suspend non-PX cards drm/radeon: add ring to fence trace functions drm/radeon: add missing trace point drm/radeon: fix VMID use tracking drm: ast,cirrus,mgag200: use drm_can_sleep drm/gma500: Lock struct_mutex around cursor updates drm/i915: Fix the offset issue for the stolen GEM objects DRM: armada: fix missing DRM_KMS_FB_HELPER select drm/i915: Decouple GPU error reporting from ring initialisation ...
| * drm/i915: Eliminate lots of WARNs when there's no backlight presentVille Syrjälä2014-01-221-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | My 855gm doesn't register the intel backlight but it still ends up calling the backlight code to enable/disable the backlight via the LVDS code. This leads to some WARNs due to backlight.max being 0. Let's have intel_panel_enable_backlight() and intel_panel_disable_backlight() check whether there's a backlight present or not. Also move the backlight.present check from asle_set_backlight() into intel_panel_set_backlight() for some extra symmetry. 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>
| * Merge tag 'v3.13-rc3' into drm-intel-next-queuedDaniel Vetter2013-12-091-1/+1
| |\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 3.13-rc3 I need a backmerge for two reasons: - For merging the ppgtt patches from Ben I need to pull in the bdw support. - We now have duplicated calls to intel_uncore_forcewake_reset in the setup code to due 2 different patches merged into -next and 3.13. The conflict is silen so I need the merge to be able to apply Deepak's fixup patch. Conflicts: drivers/gpu/drm/i915/intel_display.c Trivial conflict, it doesn't even show up in the merge diff. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: use __packed instead of __attribute__((packed))Jani Nikula2013-12-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Checkpatch tells me WARNING: __packed is preferred over __attribute__((packed)) so switch over to __packed across the driver before adding new packed structs. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | Merge branch 'bdw-fixes' into backlight-reworkDaniel Vetter2013-11-151-0/+2
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge the bdw changes into the backlight rework branch so that we can adapt the new code for bdw, too. This is a bit a mess, but doing this another way would have delayed the merging of the backlight refactoring. Mea culpa. As discussed with Jani on irc only do bdw-specific callbacks for the set/get methods and bake in the only other special-case into the pch enable function. Conflicts: drivers/gpu/drm/i915/intel_panel.c v2: Don't enable the PWM too early for bdw (Jani). v3: Create new bdw_ functions for setup and enable - the rules change sufficiently imo with the switch from controlling the pwm from the cpu to controlling it completel from the pch to warrant this. v4: Rip out unused pipe variable in bdw_enable_backlight (0-day builder). Tested-by: Ben Widawsky <ben@bwidawsk.net> (on bdw) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: make asle notifications update backlight on all connectorsJani Nikula2013-11-131-30/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ALthough usually there's only one connector that supports backlight, this also finds the correct connector. Before, we only updated the connector on pipe A, which might not be the one with backlight. (This only made a difference on BYT.) 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>
* | | | ACPI / i915: Fix incorrect <acpi/acpi.h> inclusions via <linux/acpi_io.h>Lv Zheng2013-12-071-1/+0
| |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid build problems and breaking dependencies between ACPI header files, <acpi/acpi.h> should not be included directly by code outside of the ACPI core subsystem. However, that is possible if <linux/acpi_io.h> is included, because that file contains a direct inclusion of <acpi/acpi.h>. For this reason, remove the direct <acpi/acpi.h> inclusion from <linux/acpi_io.h>, move that file from include/linux/ to include/acpi/ and make <linux/acpi.h> include it for CONFIG_ACPI set along with the other ACPI header files. Accordingly, Remove the inclusions of <linux/acpi_io.h> from everywhere. Of course, that causes the contents of the new <acpi/acpi_io.h> file to be available for CONFIG_ACPI set only, so intel_opregion.o that depends on it should also depend on CONFIG_ACPI (and it really should not be compiled for CONFIG_ACPI unset anyway). References: https://01.org/linuxgraphics/sites/default/files/documentation/acpi_igd_opregion_spec.pdf Cc: Matthew Garrett <mjg59@srcf.ucam.org> Signed-off-by: Lv Zheng <lv.zheng@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> [rjw: Subject and changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | | Merge tag 'pm+acpi-2-3.13-rc1' of ↵Linus Torvalds2013-11-201-1/+1
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm Pull more ACPI and power management updates from Rafael Wysocki: - ACPI-based device hotplug fixes for issues introduced recently and a fix for an older error code path bug in the ACPI PCI host bridge driver - Fix for recently broken OMAP cpufreq build from Viresh Kumar - Fix for a recent hibernation regression related to s2disk - Fix for a locking-related regression in the ACPI EC driver from Puneet Kumar - System suspend error code path fix related to runtime PM and runtime PM documentation update from Ulf Hansson - cpufreq's conservative governor fix from Xiaoguang Chen - New processor IDs for intel_idle and turbostat and removal of an obsolete Kconfig option from Len Brown - New device IDs for the ACPI LPSS (Low-Power Subsystem) driver and ACPI-based PCI hotplug (ACPIPHP) cleanup from Mika Westerberg - Removal of several ACPI video DMI blacklist entries that are not necessary any more from Aaron Lu - Rework of the ACPI companion representation in struct device and code cleanup related to that change from Rafael J Wysocki, Lan Tianyu and Jarkko Nikula - Fixes for assigning names to ACPI-enumerated I2C and SPI devices from Jarkko Nikula * tag 'pm+acpi-2-3.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (24 commits) PCI / hotplug / ACPI: Drop unused acpiphp_debug declaration ACPI / scan: Set flags.match_driver in acpi_bus_scan_fixed() ACPI / PCI root: Clear driver_data before failing enumeration ACPI / hotplug: Fix PCI host bridge hot removal ACPI / hotplug: Fix acpi_bus_get_device() return value check cpufreq: governor: Remove fossil comment in the cpufreq_governor_dbs() ACPI / video: clean up DMI table for initial black screen problem ACPI / EC: Ensure lock is acquired before accessing ec struct members PM / Hibernate: Do not crash kernel in free_basic_memory_bitmaps() ACPI / AC: Remove struct acpi_device pointer from struct acpi_ac spi: Use stable dev_name for ACPI enumerated SPI slaves i2c: Use stable dev_name for ACPI enumerated I2C slaves ACPI: Provide acpi_dev_name accessor for struct acpi_device device name ACPI / bind: Use (put|get)_device() on ACPI device objects too ACPI: Eliminate the DEVICE_ACPI_HANDLE() macro ACPI / driver core: Store an ACPI device pointer in struct acpi_dev_node cpufreq: OMAP: Fix compilation error 'r & ret undeclared' PM / Runtime: Fix error path for prepare PM / Runtime: Update documentation around probe|remove|suspend cpufreq: conservative: set requested_freq to policy max when it is over policy max ...
| * | ACPI: Eliminate the DEVICE_ACPI_HANDLE() macroRafael J. Wysocki2013-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Since DEVICE_ACPI_HANDLE() is now literally identical to ACPI_HANDLE(), replace it with the latter everywhere and drop its definition from include/acpi.h. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | | drm/i915/opregion: fix build error on CONFIG_ACPI=nJani Nikula2013-11-081-0/+2
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix CONFIG_ACPI=n build fail CC drivers/gpu/drm/i915/intel_opregion.o drivers/gpu/drm/i915/intel_opregion.c: In function ‘intel_opregion_setup’: drivers/gpu/drm/i915/intel_opregion.c:879:2: error: ‘asle_work’ undeclared (first use in this function) drivers/gpu/drm/i915/intel_opregion.c:879:2: note: each undeclared identifier is reported only once for each function it appears in make[4]: *** [drivers/gpu/drm/i915/intel_opregion.o] Error 1 introduced in commit 91a60f20712179e56b7a6c3d332a5f6f9a54aa11 Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Oct 31 18:55:48 2013 +0200 drm/i915: move opregion asle request handling to a work queue Reported-by: Jim Davis <jim.epost@gmail.com> Reference: http://lkml.kernel.org/r/CA+r1ZhjcFpr5KKVX0pLCOP8cAyZoiYO=UyqYMJtNSV-Kt_p7xQ@mail.gmail.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: make backlight functions take a connectorJesse Barnes2013-11-061-2/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On VLV/BYT, backlight controls a per-pipe, so when adjusting the backlight we need to pass the correct info. So make the externally visible backlight functions take a connector argument, which can be used internally to figure out the pipe backlight to adjust. v2: make connector pipe lookup check for NULL crtc (Jani) fixup connector check in ASLE code (Jani) v3: make sure we take the mode config lock around lookups (Daniel) v4: fix double unlock in panel_get_brightness (Daniel) v5: push ASLE work into a work queue (Daniel) v6: separate ASLE work to a prep patch, rebase (Jani) Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: move opregion asle request handling to a work queueJani Nikula2013-11-061-2/+18
| | | | | | | | | | | | | | | | | | Doing this has been long overdue anyway, but now we really need it in preparation for per connector backlight handling. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: Add breadcrumbs for why the backlight is being setChris Wilson2013-10-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | 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: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: increase the SWSCI DSLP default timeout to 50msPaulo Zanoni2013-10-111-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge tag 'v3.12-rc2' into drm-intel-nextDaniel Vetter2013-09-241-1/+1
|\ \ | |/ | | | | | | | | | | | | | | | | | | | | | | | | | | 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: try not to lose backlight CBLV precisionJani Nikula2013-09-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ACPI has _BCM and _BQC methods to set and query the backlight brightness, respectively. The ACPI opregion has variables BCLP and CBLV to hold the requested and current backlight brightness, respectively. The BCLP variable has range 0..255 while the others have range 0..100. This means the _BCM method has to scale the brightness for BCLP, and the gfx driver has to scale the requested value back for CBLV. If the _BQC method uses the CBLV variable (apparently some implementations do, some don't) for current backlight level reporting, there's room for rounding errors. Use DIV_ROUND_UP for scaling back to CBLV to get back to the same values that were passed to _BCM, presuming the _BCM simply uses bclp = (in * 255) / 100 for scaling to BCLP. Reference: https://gist.github.com/aaronlu/6314920 Reported-by: Aaron Lu <aaron.lu@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Aaron Lu <aaron.lu@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: check for more ASLC interruptsPaulo Zanoni2013-09-171-32/+121
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: clear opregon->lid_state after we unmap itPaulo Zanoni2013-09-131-0/+1
| | | | | | | | | | | | | | | | | | We don't seem to be using the pointer after it's unmapped, so this patch doesn't fix any bug I can reproduce. 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: add opregion function to notify bios of adapter power stateJani Nikula2013-09-041-0/+27
| | | | | | | | | | | | | | | | Notifying the bios lets it enter power saving states. 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>
* | drm/i915: add opregion function to notify bios of encoder enable/disableJani Nikula2013-09-041-0/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bios interface seems messy, and it's hard to tell what the bios really wants. At first, only add support for DDI based machines (hsw+), and see how it turns out. The spec says to notify prior to power down and after power up. It is unclear whether it makes a difference. v2: - squash notification function and callers patches together (Daniel) - move callers to haswell_crtc_{enable,disable} (Daniel) - rename notification function (Chris) v3: - separate notification function and callers again, as it's not clear whether the display power state notification is the right thing to do after all v4: per Paulo's review: - drop LVDS - WARN on unsupported encoder types 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>
OpenPOWER on IntegriCloud