summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915/intel_lvds.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/i915: Get rid of dpms handling.Maarten Lankhorst2015-08-141-1/+1
| | | | | | | | | This is now done completely atomically. Keep connectors_active for now, but make it mirror crtc_state->active. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Convert resume to atomic.Maarten Lankhorst2015-07-141-1/+1
| | | | | | | | | | | | | | | Instead of all the ad-hoc updating, duplicate the old state first before reading out the hw state, then restore it. intel_display_resume is a new function that duplicates the sw state, then reads out the hw state, and commits the old state. intel_display_setup_hw_state now only reads out the atomic state. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90396 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by: Daniel Stone <daniels@collabora.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Disable LVDS port after the pipe on PCHVille Syrjälä2015-07-061-5/+31
| | | | | | | | | | | | | | | Follow the correct pipe vs port disable sequence for the PCH LVDS ports, ie. disable the port after the pipe. Other PCH port were already converted in the following commits: 1ea56e269e136544c0a76dc831c5edc27c47cb3c drm/i915: Disable CRT port after pipe on PCH platforms 3c65d1d1bb92ea959e8bce3eeae90fe5c3daa58a drm/i915: Disable SDVO port after the pipe on PCH platforms a4790cec3adf5eec91f397b1884706a71c70730f drm/i915: Disable HDMI port after the pipe on PCH platforms 08aff3fe26ae7a0d6f302ac2e1b7e2eb9933cd42 drm/i915: Move DP port disable to post_disable for pch platforms but LVDS was forgotten. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Nuke lvds downclock supportDaniel Vetter2015-06-241-17/+1
| | | | | | | | | | | | | | With the new DRRS code it kinda sticks out, and we never managed to get this to work well enough without causing issues. Time to wave goodbye. I've decided to keep the logic for programming the reduced clocks intact, but everything else is gone. If anyone ever wants to resurrect this we need to redo it all anyway on top of the frontbuffer tracking. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Ignore LVDS presence in VBT flag if the LVDS is enabled by BIOSChris Wilson2015-06-221-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | On older gen, pre-Ironlake, parts there is no hardwired pin to report the presence of an LVDS panel. Instead, we have to rely on the VBT to declare whether the machine has a panel or not. Though notoriously unreliable, so far we have erred on the side of false-positives and have required a list of machines which end up falsely reporting a panel as present. However, we now have reports of false-negatives, machines with an LVDS that are being ignored due to the VBT not declaring the panel. This patch ignores the VBT setting if the BIOS has already enabled the LVDS panel (and on Ironlake+ we also have the hardware presence pin). It fixes the Samsung NP680Z5E-X01FR in the bug report, but is likely to result in more false-positives, and since we rely on the BIOS to enable the panel, there are likely different circumstances where the BIOS will not enable that panel (and so we may see the same machine with and without a panel all on the whim of the BIOS). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90979 Reported-and-tested-by: lysxia@gmail.com Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Backmerge v4.1-rc4 into into drm-nextDave Airlie2015-05-201-2/+24
|\ | | | | | | | | | | | | | | | | | | We picked up a silent conflict in amdkfd with drm-fixes and drm-next, backmerge v4.1-rc5 and fix the conflicts Signed-off-by: Dave Airlie <airlied@redhat.com> Conflicts: drivers/gpu/drm/drm_irq.c
| * drm/i915: Add missing MacBook Pro models with dual channel LVDSLukas Wunner2015-05-051-1/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Single channel LVDS maxes out at 112 MHz. The 15" pre-retina models shipped with 1440x900 (106 MHz) by default or 1680x1050 (119 MHz) as a BTO option, both versions used dual channel LVDS even though the smaller one would have fit into a single channel. Notes: Bug report showing that the MacBookPro8,2 with 1440x900 uses dual channel LVDS (this lead to it being hardcoded in intel_lvds.c by Daniel Vetter with commit 618563e3945b9d0864154bab3c607865b557cecc): https://bugzilla.kernel.org/show_bug.cgi?id=42842 If i915.lvds_channel_mode=2 is missing even though the machine needs it, every other vertical line is white and consequently, only the left half of the screen is visible (verified by myself on a MacBookPro9,1). Forum posting concerning a MacBookPro6,2 with 1440x900, author is using i915.lvds_channel_mode=2 on the kernel command line, proving that the machine uses dual channels: https://bbs.archlinux.org/viewtopic.php?id=185770 Chi Mei N154C6-L04 with 1440x900 is a replacement panel for all MacBook Pro "A1286" models, and that model number encompasses the MacBookPro6,2 / 8,2 / 9,1. Page 17 of the panel's datasheet shows it's driven with dual channel LVDS: http://www.ebay.com/itm/-/400690878560 http://www.everymac.com/ultimate-mac-lookup/?search_keywords=A1286 http://www.taopanel.com/chimei/datasheet/N154C6-L04.pdf Those three 15" models, MacBookPro6,2 / 8,2 / 9,1, are the only ones with i915 graphics and dual channel LVDS, so that list should be complete. And the 8,2 is already in intel_lvds.c. Possible motivation to use dual channel LVDS even on the 1440x900 models: Reduce the number of different parts, i.e. use identical logic boards and display cabling on both versions and the only differing component is the panel. Signed-off-by: Lukas Wunner <lukas@wunner.de> Acked-by: Jani Nikula <jani.nikula@intel.com> Cc: stable@vger.kernel.org [Jani: included notes in the commit message for posterity] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Assume dual channel LVDS if pixel clock necessitates itLukas Wunner2015-05-051-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Single channel LVDS maxes out at 112 MHz, anything above must be dual channel. This avoids the need to specify i915.lvds_channel_mode=2 on all 17" MacBook Pro models with i915 graphics since they had 1920x1200 (193 MHz), plus those 15" pre-retina models which had a resolution of 1680x1050 (119 MHz) as a BTO option. Source for 112 MHz limit of single channel LVDS is section 2.3 of: https://01.org/linuxgraphics/sites/default/files/documentation/ivb_ihd_os_vol3_part4.pdf v2: Avoid hardcoding 17" models by assuming dual channel LVDS if the resolution necessitates it, suggested by Jani Nikula. v3: Fix typo, thanks Joonas Lahtinen. v4: Split commit in two, suggested by Ville Syrjälä. Signed-off-by: Lukas Wunner <lukas@wunner.de> Tested-by: Lukas Wunner <lukas@wunner.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org [Jani: included spec reference into the commit message] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
| * drm/i915: Allocate connector state together with the connectorsAnder Conselvan de Oliveira2015-04-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Connector states were being allocated in intel_setup_outputs() in loop over all connectors. That meant hot-added connectors would have a NULL state. Since the change to use a struct drm_atomic_state for the legacy modeset, connector states are necessary for the i915 driver to function properly, so that would lead to oopses. Broken by commit 944b0c76575753da5a332aab0a1d8c6df65a076b Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Date: Fri Mar 20 16:18:07 2015 +0200 drm/i915: Copy the staged connector config to the legacy atomic state v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reported-and-tested-by: Nicolas Kalkhof <nkalkhof@web.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Allocate connector state together with the connectorsAnder Conselvan de Oliveira2015-04-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Connector states were being allocated in intel_setup_outputs() in loop over all connectors. That meant hot-added connectors would have a NULL state. Since the change to use a struct drm_atomic_state for the legacy modeset, connector states are necessary for the i915 driver to function properly, so that would lead to oopses. v2: Fix test for intel_connector_init() success in lvds and sdvo (PRTS) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reported-and-tested-by: Nicolas Kalkhof <nkalkhof@web.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: base gmbus pin validity check on the gmbus pin map arrayJani Nikula2015-04-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | This will be helpful for adding future platforms. It is better to keep the information in the single point of truth (the table) instead of duplicating it into the validity function. While at it, add dev_priv parameter to the function, also to prepare for adding future platform support. 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: refer to pin instead of port in the intel_i2c.c interfacesJani Nikula2015-04-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | Rename intel_gmbus_is_port_valid to intel_gmbus_is_valid_pin, and rename port parameters to pin as well. This matches usage all around, as usually a pin is passed to the validity check function. No functional changes. 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: rename GMBUS_PORT_* macros as GMBUS_PIN_*Jani Nikula2015-04-011-1/+1
|/ | | | | | | | | The specs refer to pin pairs. Start moving towards using pin rather than port all around to avoid confusion. No functional changes. 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: Don't use encoder->new_crtc in intel_lvds_compute_config()Ander Conselvan de Oliveira2015-03-261-1/+1
| | | | | | | | Move towards atomic by using the legacy modeset's drm_atomic_state instead. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Implement connector state duplicationAnder Conselvan de Oliveira2015-03-261-0/+1
| | | | | | | | So that we can add connector states to the drm_atomic_state used in the legacy modeset. Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Use enabled value from crtc_state rather than crtc (v2)Matt Roper2015-02-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As vendors transition their drivers from legacy to atomic there's some duplication of data between drm_crtc and drm_crtc_state (since unconverted drivers likely won't have a state structure). i915 is partially converted and does have a crtc->state structure, but still uses direct crtc fields internally in many places, which causes the two sets of data to get out of sync. As of commit commit 31c946e85ce6b48ce0f25e3cdca8362e4fe8b300 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Feb 22 12:24:17 2015 +0100 drm: If available use atomic state in getcrtc ioctl This way drivers fully converted to atomic don't need to update these legacy state variables in their modeset code any more. Reviewed-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> the DRM core starts assuming that the presence of a ->state structure implies that it should make use of the values stored there which, on i915, leads to the core code using stale values for CRTC 'enabled' status. Let's switch over to using the state value of 'enable' internally rather than using the drm_crtc field. This ensures that our driver internals are working from the same data that the DRM core is, avoiding mismatches. This patch was generated with Coccinelle using the following semantic patch: <smpl> @@ struct drm_crtc C; struct drm_crtc *CP; @@ ( - C.enabled + C.state->enable | - CP->enabled + CP->state->enable ) // For assignments, we still update the legacy value as well as the state value // so add an extra assignment statement for that. @@ struct drm_crtc C; struct drm_crtc *CP; expression E; @@ ( C.state->enable = E; + C.enabled = E; | CP->state->enable = E; + CP->enabled = E; ) </smpl> The crtc->mode and crtc->hwmode fields should probably be transitioned over as well eventually, but we seem to do an okay job of keeping those up-to-date already so I want to minimize the changes that will clash with Ander's in-progress atomic work. v2: Don't remove the assignments to the legacy value when we assign to the state value. A second cocci stanza takes care of adding the legacy assignment back where appropriate. (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Add atomic_get_property entrypoint for connectors (v2)Matt Roper2015-01-271-0/+1
| | | | | | | | | | | | | | | | | | | | | Even though we only support atomic plane updates at the moment, we still need to add an .atomic_get_property() entrypoint for connectors before we allow the driver to flip on the DRIVER_ATOMIC bit. As soon as that bit gets set, the DRM core will start adding atomic connector properties (in addition to the plane properties we care about at the moment), so we need to be able to handle the new way the DRM core will interact with us. For simplicity, we just lookup driver-specific connector properties in the usual shadow array maintained by the core. Once we get real atomic modeset support for crtc's and planes, this code should be re-written to pull the data out of crtc/connector state structures. v2: Fix intel_dvo and intel_dsi that I missed on the first pass (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Setup dummy atomic state for connectors (v3)Matt Roper2015-01-271-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to enable/test plane updates via the atomic interface, but as soon as we flip DRIVER_ATOMIC on, the DRM core will take some atomic codepaths to lookup properties during drmModeGetConnector() and some of those codepaths unconditionally dereference connector->state (specifically when looking up the CRTC ID property in drm_atomic_connector_get_property()). Create a dummy connector state for each connector at init time to ensure the DRM core doesn't try to dereference a NULL connector->state. The actual connector properties will never be updated or contain useful information, but since we're doing this specifically for testing/debug of the plane operations (and only when a specific kernel module option is given), that shouldn't really matter. Once we start creating connector states, the DRM core will want to be able to clean them up for us. We also need to hook up the destruction entrypoint to the core's helper. v2: Squash in the patch to set the state destruction hook (Ander & Bob) v3: Only create dummy connector states when we're actually faking atomic support. (Ander) Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make intel_crtc->config a pointerAnder Conselvan de Oliveira2015-01-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To match the semantics of drm_crtc->state, which this will eventually become. The allocation of the memory for config will be fixed in a followup patch. By adding the extra _config field to intel_crtc it was possible to generate this entire patch with the cocci script below. @@ @@ struct intel_crtc { ... -struct intel_crtc_state config; +struct intel_crtc_state _config; +struct intel_crtc_state *config; ... } @@ struct intel_crtc *crtc; @@ -memset(&crtc->config, 0, sizeof(crtc->config)); +memset(crtc->config, 0, sizeof(*crtc->config)); @@ @@ __intel_set_mode(...) { <... -to_intel_crtc(crtc)->config = *pipe_config; +(*(to_intel_crtc(crtc)->config)) = *pipe_config; ...> } @@ @@ intel_crtc_init(...) { ... WARN_ON(drm_crtc_index(&intel_crtc->base) != intel_crtc->pipe); +intel_crtc->config = &intel_crtc->_config; return; ... } @@ struct intel_crtc *crtc; @@ -&crtc->config +crtc->config @@ struct intel_crtc *crtc; identifier member; @@ -crtc->config.member +crtc->config->member @@ expression E; @@ -&(to_intel_crtc(E)->config) +to_intel_crtc(E)->config @@ expression E; identifier member; @@ -to_intel_crtc(E)->config.member +to_intel_crtc(E)->config->member v2: Clarify manual changes by splitting them into another patch. (Matt) Improve cocci script to generate even more of the changes. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Embedded struct drm_crtc_state in intel_crtc_stateAnder Conselvan de Oliveira2015-01-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | And get rid of the duplicate mode structures. This patch was generated with the following semantic patch: @@ @@ struct intel_crtc_state { +struct drm_crtc_state base; + ... -struct drm_display_mode requested_mode; -struct drm_display_mode adjusted_mode; ... } @@ struct intel_crtc_state *state; @@ -state->adjusted_mode +state->base.adjusted_mode @@ struct intel_crtc_state *state; @@ -state->requested_mode +state->base.mode @@ struct intel_crtc_state state; @@ -state.adjusted_mode +state.base.adjusted_mode @@ struct intel_crtc_state state; @@ -state.requested_mode +state.base.mode @@ struct drm_crtc *crtc; @@ -to_intel_crtc(crtc)->config.adjusted_mode +to_intel_crtc(crtc)->config.base.adjusted_mode @@ identifier member; expression E; @@ -PIPE_CONF_CHECK_FLAGS(adjusted_mode.member, E); +PIPE_CONF_CHECK_FLAGS(base.adjusted_mode.member, E); @@ identifier member; @@ -PIPE_CONF_CHECK_I(adjusted_mode.member); +PIPE_CONF_CHECK_I(base.adjusted_mode.member); @@ identifier member; @@ -PIPE_CONF_CHECK_CLOCK_FUZZY(adjusted_mode.member); +PIPE_CONF_CHECK_CLOCK_FUZZY(base.adjusted_mode.member); v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Rename struct intel_crtc_config to intel_crtc_stateAnder Conselvan de Oliveira2015-01-271-2/+2
| | | | | | | | | | | | | | | | | | | | The objective is to make this structure usable with the atomic helpers, so let's start with the rename. Patch generated with coccinelle: @@ @@ -struct intel_crtc_config { +struct intel_crtc_state { ... } @@ @@ -struct intel_crtc_config +struct intel_crtc_state v2: Completely generate the patch with cocci. (Ander) Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.18' into drm-nextDave Airlie2014-12-081-11/+11
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Linux 3.18 Backmerge Linus tree into -next as we had conflicts in i915/radeon/nouveau, and everyone was solving them individually. * tag 'v3.18': (57 commits) Linux 3.18 watchdog: s3c2410_wdt: Fix the mask bit offset for Exynos7 uapi: fix to export linux/vm_sockets.h i2c: cadence: Set the hardware time-out register to maximum value i2c: davinci: generate STP always when NACK is received ahci: disable MSI on SAMSUNG 0xa800 SSD context_tracking: Restore previous state in schedule_user slab: fix nodeid bounds check for non-contiguous node IDs lib/genalloc.c: export devm_gen_pool_create() for modules mm: fix anon_vma_clone() error treatment mm: fix swapoff hang after page migration and fork fat: fix oops on corrupted vfat fs ipc/sem.c: fully initialize sem_array before making it visible drivers/input/evdev.c: don't kfree() a vmalloc address cxgb4: Fill in supported link mode for SFP modules xen-netfront: Remove BUGs on paged skb data which crosses a page boundary mm/vmpressure.c: fix race in vmpressure_work_fn() mm: frontswap: invalidate expired data on a dup-store failure mm: do not overwrite reserved pages counter at show_mem() drm/radeon: kernel panic in drm_calc_vbltimestamp_from_scanoutpos with 3.18.0-rc6 ... Conflicts: drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/nouveau/nouveau_drm.c drivers/gpu/drm/radeon/radeon_cs.c
| * drm/i915: Unlock panel even when LVDS is disabledDaniel Vetter2014-12-021-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we'll have backtraces in assert_panel_unlocked because the BIOS locks the register. In the reporter's case this regression was introduced in commit c31407a3672aaebb4acddf90944a114fa5c8af7b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Oct 18 21:07:01 2012 +0100 drm/i915: Add no-lvds quirk for Supermicro X7SPA-H Reported-by: Alexey Orishko <alexey.orishko@gmail.com> Cc: Alexey Orishko <alexey.orishko@gmail.com> Cc: stable@vger.kernel.org Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Francois Tigeot <ftigeot@wolfpond.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Tested-by: Alexey Orishko <alexey.orishko@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Pass the current pipe from eDP init to backlight setupVille Syrjälä2014-11-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On VLV/CHV both pipes A and B have their own backlight control registers. In order to correctly read out the current hardware state at init we need to know which pipe is driving the eDP port. Pass that information down from the eDP init code into the backlight code. To determine the correct pipe we first look at which pipe is currently configured in the port control register, if that look invalid we look at which pipe's PPS is currently controlling the port, and if that too looks invalid we just assume pipe A. 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>
* | drm/i915: Bikeshed rpm functions name a bit.Daniel Vetter2014-10-011-1/+1
|/ | | | | | | | | | | | | - fini goes with init, so call it intel_power_domains_fini. While at it shovel some of the fini code that leaked out of it back in. - give power_enabled functions the verb _is_ to make the meaning clearer. Also use a __ prefix instead of _unlocked to really discourage users. - rename runtime_pm_init/fini to enable/disable since that's what they do. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm: backmerge tag 'v3.17-rc5' into drm-nextDave Airlie2014-09-161-1/+1
|\ | | | | | | | | | | | | This is requested to get the fixes for intel and radeon into the same tree for future development work. i915_display.c: fix missing dev_priv conflict.
| * drm/i915: Remove bogus __init annotation from DMI callbacksMathias Krause2014-08-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The __init annotations for the DMI callback functions are wrong as this code can be called even after the module has been initialized, e.g. like this: # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove # modprobe i915 # echo 1 > /sys/bus/pci/rescan The first command will remove the PCI device from the kernel's device list so the second command won't see it right away. But as it registers a PCI driver it'll see it on the third command. If the system happens to match one of the DMI table entries we'll try to call a function in long released memory and generate an Oops, at best. Fix this by removing the bogus annotation. Modpost should have caught that one but it ignores section reference mismatches from the .rodata section. :/ Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT") Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...") Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...") Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Jarod Wilson <jarod@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> # Can modpost be fixed? Cc: stable@vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula@intel.com>
* | drm/i915: Introduce a for_each_intel_encoder() macroDamien Lespiau2014-08-081-2/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | Following the established idom, let's provide a macro to iterate through the encoders. spatch helps, once more, for the substitution: @@ iterator name list_for_each_entry; iterator name for_each_intel_encoder; struct intel_encoder * encoder; struct drm_device * dev; @@ -list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.head) { +for_each_intel_encoder(dev, encoder) { ... } I also modified a few call sites by hand where a pointer to mode_config was directly used (to avoid overflowing 80 chars). Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> [danvet: Wrap paramters correctly in the macro and remove spurious space checkpatch noticed.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* Merge tag 'v3.16' into drm-nextDave Airlie2014-08-051-0/+7
|\ | | | | | | | | | | | | | | | | | | 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
| * Revert "drm/i915: Don't set the 8to6 dither flag when not scaling"Daniel Vetter2014-07-141-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 773875bfb6737982903c42d1ee88cf60af80089c. It is very much needed and the lack of dithering has been reported by a large list of people with various gen2/3 hardware. Also, the original patch was complete non-sense since the WARNING backtraces in the references bugzilla are about gmch_pfit.lvds_border_bits mismatch, not at all about the dither bit. That one seems to work. Cc: Jiri Kosina <jkosina@suse.cz> Cc: Pavel Machek <pavel@ucw.cz> Cc: Hans de Bruin <jmdebruin@xmsnet.nl> Cc: stable@vger.kernel.org Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge tag 'drm-intel-next-2014-07-11' of ↵Dave Airlie2014-07-191-4/+14
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next - fbc improvements when stolen memory is tight (Ben) - cdclk handling improvements for vlv/chv (Ville) - proper fix for stuck primary planes on gmch platforms with cxsr (Imre&Ebgert Eich) - gen8 hw semaphore support (Ben) - more execlist prep work from Oscar Mateo - locking fixes for primary planes (Matt Roper) - code rework to support runtime pm for dpms on hsw/bdw (Paulo, Imre & me), but not yet enabled because some fixes from Paulo haven't made the cut - more gpu boost tuning from Chris - as usual piles of little things all over * tag 'drm-intel-next-2014-07-11' of git://anongit.freedesktop.org/drm-intel: (93 commits) drm/i915: Make the RPS interrupt generation mask handle the vlv wa drm/i915: Move RPS evaluation interval counters to i915->rps drm/i915: Don't cast a pointer to void* unnecessarily drm/i915: don't read LVDS regs at compute_config time drm/i915: check the power domains in intel_lvds_get_hw_state() drm/i915: check the power domains in ironlake_get_pipe_config() drm/i915: don't skip shared DPLL assertion on LPT drm/i915: Only touch WRPLL hw state in enable/disable hooks drm/i915: Switch to common shared dpll framework for WRPLLs drm/i915: ->enable hook for WRPLLs drm/i915: ->disable hook for WRPLLs drm/i915: State readout support for WRPLLs drm/i915: add POWER_DOMAIN_PLLS drm/i915: Document that the pll->mode_set hook is optional drm/i915: Basic shared dpll support for WRPLLs drm/i915: Precompute static ddi_pll_sel values in encoders drm/i915: BDW also has special-purpose DP DDI clocks drm/i915: State readout and cross-checking for ddi_pll_sel drm/i915: Move ddi_pll_sel into the pipe config drm/i915: Add a debugfs file for the shared dpll state ...
| * | drm/i915: don't read LVDS regs at compute_config timePaulo Zanoni2014-07-101-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We may reach this point while the machine is still runtime suspended, so we'll hit a WARN. The other encoders also don't touch registers at this point, so instead of waking the machine up, write some code to keep the register always at the same state, including after we runtime suspend/resume. Testcase: igt/pm_rpm Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80463 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | drm/i915: check the power domains in intel_lvds_get_hw_state()Paulo Zanoni2014-07-101-0/+5
| |/ | | | | | | | | | | | | | | | | | | | | Just like we do for the other encoders. This should fix some WARNs when running pm_rpm on SNB. Testcase: igt/pm_rpm Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80463 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm: add register and unregister functions for connectorsThomas Wood2014-06-191-1/+1
|/ | | | | | | | | | Introduce generic functions to register and unregister connectors. This provides a common place to add and remove associated user space interfaces. Signed-off-by: Thomas Wood <thomas.wood@intel.com> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: replace drm_get_connector_name() with direct name field useJani Nikula2014-06-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Generated using semantic patches: @@ expression E; @@ - drm_get_connector_name(&E) + E.name @@ expression E; @@ - drm_get_connector_name(E) + E->name v2: Turn drm_get_connector_name(&E) into E.name instead of &(E)->name. Acked-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/i915/lvds: Remove ->mode_set callbackDaniel Vetter2014-05-161-14/+0
| | | | | | | | | All the hard work was already done, only thing left to do is remove the empty callback. And a now rather misleading comment I've spotted while reading through code. Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Don't set the 8to6 dither flag when not scalingDaniel Vetter2014-04-131-7/+0
| | | | | | | | | | | | | | Apparently we really only need this when the pfit is enabled, at least I couldn't dicern any difference here. Furthermore the hacks we have to reconstruct this bit is a bit glaring, and probably only works because we can't move the lvds port to any other pipe than pipe B on gen2/3. So let's just rip this out. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77137 (the LVDS WARNING log, not the main "VGA can't be turned on" issue). Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add locking to fixed panel edid probingDaniel Vetter2014-03-281-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | With the recent addition of locking checks in commit 62ff94a5492175759546f8bc61383189d6b49122 Author: Daniel Vetter <daniel.vetter@ffwll.ch> AuthorDate: Thu Jan 23 22:18:47 2014 +0100 drm/crtc-helper: remove LOCKING from kerneldoc drm_add_edid_modes started to WARN about the mode_config.mutex not being held in the lvds and dp initialization code. Now since this is init code locking is fairly redudant if it wouldn't be for the drm core registering sysfs files a bit early. And the locking WARNINGs nicely enforce that indeed all access to the mode lists are properly protected. And a full audit shows that only i915 and gma500 touch the modes lists at init time. Hence I've opted to wrap up this entire mode detection sequence for fixed panels with the mode_config mutex for both lvds and edp outputs. Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make encoder cloning more flexibleVille Syrjälä2014-03-101-1/+1
| | | | | | | | | | | | | | | | | | | | Currently we allow encoders to indicate whether they can be part of a cloned set with just one flag. That's not flexible enough to describe the actual hardware capabilities. Instead make it a bitmask of encoder types with which the current encoder can be cloned. For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should match what the old boolean flag allowed. We will add some more cloning options in the future. Note that this patch also removes the encoder.possible_clones setting from encoder setup code - we compute this dynamically. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> [danvet: Add Ville's explanation why removing the encoder possible_clones is save.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: add unregister callback to connectorImre Deak2014-02-141-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit d9255d57147e1dbcebdf6670409c2fa0ac3609e6 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date:   Thu Sep 26 20:05:59 2013 -0300 it became clear that we need to separate the unload sequence into two parts: 1. remove all interfaces through which new operations on some object (crtc, encoder, connector) can be started and make sure all pending operations are completed 2. do the actual tear down of the internal representation of the above objects The above commit achieved this separation for connectors by splitting out the sysfs removal part from the connector's destroy callback and doing this removal before calling drm_mode_config_cleanup() which does the actual tear-down of all the drm objects. Since we'll have to customize the interface removal part for different types of connectors in the upcoming patches, add a new unregister callback and move the interface removal part to it. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/lvds: Remove dead code from failing caseDamien Lespiau2014-02-131-2/+0
| | | | | | | | | | | | Coverity points out that, if we end up in the 'failed' label, that's precisely because we couldn't retrieve a fixed mode (ie fixed_mode is NULL) and then "if (fixed_mode)" is always false. Remove that dead code. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Initialize downclock mode in panel initVandana Kannan2014-02-121-5/+5
| | | | | | | | | | | | | | | Instead of modifying intel_panel in lvds_init_connector/dsi_init/ edp_init_connector, making changes to move intel_panel->downclock_mode initialization to intel_panel_init() v2: Jani's review comments incorporated Removed downclock_mode local variable in dsi_init and edp_init_connector Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: move module parameters into a struct, in a new fileJani Nikula2014-01-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | With 20+ module parameters, I think referring to them via a struct improves clarity over just having a bunch of globals. While at it, move the parameter initialization and definitions into a new file i915_params.c to reduce clutter in i915_drv.c. Apart from the ill-named i915_enable_rc6, i915_enable_fbc and i915_enable_ppgtt parameters, for which we lose the "i915_" prefix internally, the module parameters now look the same both on the kernel command line and in code. For example, "i915.modeset". The downsides of the change are losing static on a couple of variables and not having the initialization and module_param_named() right next to each other. On the other hand, all module parameters are now defined in one place at i915_params.c. Plus you can do this to find all module parameter references: $ git grep "i915\." -- drivers/gpu/drm/i915 v2: - move the definitions into a new file - s/i915_params/i915/ - make i915_try_reset i915.reset, for consistency Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Make downclock deduction common for all panelsVandana Kannan2013-12-101-53/+16
| | | | | | | | | | | | If one mode of a internal panel has more than one refresh rate, then a reduced clock is found for the LFP (LVDS/eDP). This enables switching between low and high frequency dynamically. Moving downclock calculation to intel_panel so that it is common for LVDS and eDP. Signed-off-by: Vandana Kannan <vandana.kannan@intel.com> Signed-off-by: Pradeep Bhat <pradeep.bhat@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915/lvds: don't restore hw state in the lid notifier for pch platformsDaniel Vetter2013-12-021-3/+13
| | | | | | | | | | | | | | | | | | | | | | | It's a pain for two reasons: - The vga plane redisablign requires actual legacy vgao i/o to pull of. The hw engineers really botched this one here :( - There seem to be some BIOS out there which send out lid events when unplugging. Together with our broken DP code, which disables the port when the cable is lost, this results in an immediate modeset call, which can hang on the wait for outstanding flips. - Also we don't want to force a modeset on machines where it's not really needed, see the referenced bug. We might want to extend this in general to also all machines that support opregion, since there the BIOS supposedly should manage the gfx hardware more cooperatively. v2: Pimp commit message a bit. Cc: Roland Dreier <roland@kernel.org> References: https://bugs.freedesktop.org/show_bug.cgi?id=65486 Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: Return a drm_mode_status enum in the mode_valid vfuncsDamien Lespiau2013-11-281-2/+3
| | | | | | | | We had some mode_valid() vfuncs returning an int, others the enum. Let's use the latter everywhere. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/i915: make backlight functions take a connectorJesse Barnes2013-11-061-3/+6
| | | | | | | | | | | | | | | | | | 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>
* Merge tag 'v3.12' into drm-intel-nextDaniel Vetter2013-11-041-0/+16
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I want to merge in the new Broadwell support as a late hw enabling pull request. But since the internal branch was based upon our drm-intel-nightly integration branch I need to resolve all the oustanding conflicts in drm/i915 with a backmerge to make the 60+ patches apply properly. We'll propably have some fun because Linus will come up with a slightly different merge solution. Conflicts: drivers/gpu/drm/i915/i915_dma.c drivers/gpu/drm/i915/i915_drv.c drivers/gpu/drm/i915/intel_crt.c drivers/gpu/drm/i915/intel_ddi.c drivers/gpu/drm/i915/intel_display.c drivers/gpu/drm/i915/intel_dp.c drivers/gpu/drm/i915/intel_drv.h All rather simple adjacent lines changed or partial backports from -next to -fixes, with the exception of the thaw code in i915_dma.c. That one needed a bit of shuffling to restore the intent. Oh and the massive header file reordering in intel_drv.h is a bit trouble. But not much. v2: Also don't forget the fixup for the silent conflict that results in compile fail ... Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: No LVDS hardware on Intel D410PT and D425KTRob Pearce2013-10-281-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Intel D410PT(LW) and D425KT Mini-ITX desktop boards both show up as having LVDS but the hardware is not populated. This patch adds them to the list of such systems. Patch is against 3.11.4 v2: Patch revised to match the D425KT exactly as the D425KTW does have LVDS. According to Intel's documentation, the D410PTL and D410PLTW don't. Signed-off-by: Rob Pearce <rob@flitspace.org.uk> Cc: stable@vger.kernel.org [danvet: Pimp commit message to my liking and add cc: stable.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | drm/i915: destroy connector sysfs files earlierPaulo Zanoni2013-10-011-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some reason, every single time I try to run module_reload something tries to read the connector sysfs files. This happens after we destroy the encoders and before we destroy the connectors, so when the sysfs read triggers the connector detect() function, intel_conector->encoder points to memory that was already freed. The bad backtrace is just: [<ffffffff8163ca9a>] dump_stack+0x54/0x74 [<ffffffffa00c2c8e>] intel_dp_detect+0x1e/0x4b0 [i915] [<ffffffffa001913d>] status_show+0x3d/0x80 [drm] [<ffffffff813d5340>] dev_attr_show+0x20/0x60 [<ffffffff81221f50>] ? sysfs_read_file+0x80/0x1b0 [<ffffffff81221f79>] sysfs_read_file+0xa9/0x1b0 [<ffffffff811aaf1e>] vfs_read+0x9e/0x170 [<ffffffff811aba4c>] SyS_read+0x4c/0xa0 [<ffffffff8164e392>] system_call_fastpath+0x16/0x1b But if you add tons of memory checking debug options to your Kernel you'll also see: - general protection fault: 0000 - BUG kmalloc-4096 (Tainted: G D W ): Poison overwritten - INFO: Allocated in intel_ddi_init+0x65/0x270 [i915] - INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915] Among a bunch of other error messages. So this commit just destroys the sysfs files before both the encoder and connectors are freed. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
OpenPOWER on IntegriCloud