summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/radeon/radeon_connectors.c
Commit message (Collapse)AuthorAgeFilesLines
* drm/radeon: Poll for both connect/disconnect on analog connectorsLyude2016-07-071-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | DRM_CONNECTOR_POLL_CONNECT only enables polling for connections, not disconnections. Because of this, we end up losing hotplug polling for analog connectors once they get connected. Easy way to reproduce: - Grab a machine with a radeon GPU and a VGA port - Plug a monitor into the VGA port, wait for it to update the connector from disconnected to connected - Disconnect the monitor on VGA, a hotplug event is never sent for the removal of the connector. Originally, only using DRM_CONNECTOR_POLL_CONNECT might have been a good idea since doing VGA polling can sometimes result in having to mess with the DAC voltages to figure out whether or not there's actually something there since VGA doesn't have HPD. Doing this would have the potential of showing visible artifacts on the screen every time we ran a poll while a VGA display was connected. Luckily, radeon_vga_detect() only resorts to this sort of polling if the poll is forced, and DRM's polling helper doesn't force it's polls. Additionally, this removes some assignments to connector->polled that weren't actually doing anything. Cc: stable@vger.kernel.org Signed-off-by: Lyude <cpaul@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: fix initial connector audio valueAlex Deucher2016-04-141-1/+6
| | | | | | | | | This got lost somewhere along the way. This fixes audio not working until set_property was called. Noticed-by: Hyungwon Hwang <hyungwon.hwang7@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: Switch DDC when reading the EDIDLukas Wunner2016-02-091-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pre-retina MacBook Pro uses an LVDS panel and a gmux controller to switch the panel between its two GPUs. The panel mode in VBIOS is notoriously bogus on these machines. Use drm_get_edid_switcheroo() in lieu of drm_get_edid() on LVDS if the vga_switcheroo handler is capable of temporarily switching the panel's DDC lines to the discrete GPU. This allows us to retrieve the EDID if the panel is currently muxed to the integrated GPU. This only enables EDID probing on the pre-retina MBP (2008 - 2013). The retina MBP (2012 - present) uses eDP and gmux is not capable of switching AUX separately from the main link on these models. This will be addressed in later patches. List of pre-retina MBPs with dual GPUs, one of them AMD: [MBP 8,2 2011 intel SNB + amd turks pre-retina 15"] [MBP 8,3 2011 intel SNB + amd turks pre-retina 17"] v3: Commit newly added due to introduction of drm_get_edid_switcheroo() wrapper which drivers need to opt-in to. v5: Rebase on "vga_switcheroo: Add handler flags infrastructure", i.e. call drm_get_edid_switcheroo() only if the handler indicates that DDC is switchable. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=61115 Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/dae71655e8c484fbef492d3389c157975f9622c9.1452525860.git.lukas@wunner.de
* drm/radeon: Retry DDC probing on DVI on failure if we got an HPD interruptLyude2015-12-041-1/+20
| | | | | | | | | | | | | | | | | | | | | HPD signals on DVI ports can be fired off before the pins required for DDC probing actually make contact, due to the pins for HPD making contact first. This results in a HPD signal being asserted but DDC probing failing, resulting in hotplugging occasionally failing. This is somewhat rare on most cards (depending on what angle you plug the DVI connector in), but on some cards it happens constantly. The Radeon R5 on the machine used for testing this patch for instance, runs into this issue just about every time I try to hotplug a DVI monitor and as a result hotplugging almost never works. Rescheduling the hotplug work for a second when we run into an HPD signal with a failing DDC probe usually gives enough time for the rest of the connector's pins to make contact, and fixes this issue. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Lyude <cpaul@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* DRM - radeon: Don't link train DisplayPort on HPD until we get the dpcdStephen Chandler Paul2015-08-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most of the time this isn't an issue since hotplugging an adaptor will trigger a crtc mode change which in turn, causes the driver to probe every DisplayPort for a dpcd. However, in cases where hotplugging doesn't cause a mode change (specifically when one unplugs a monitor from a DisplayPort connector, then plugs that same monitor back in seconds later on the same port without any other monitors connected), we never probe for the dpcd before starting the initial link training. What happens from there looks like this: - GPU has only one monitor connected. It's connected via DisplayPort, and does not go through an adaptor of any sort. - User unplugs DisplayPort connector from GPU. - Change in HPD is detected by the driver, we probe every DisplayPort for a possible connection. - Probe the port the user originally had the monitor connected on for it's dpcd. This fails, and we clear the first (and only the first) byte of the dpcd to indicate we no longer have a dpcd for this port. - User plugs the previously disconnected monitor back into the same DisplayPort. - radeon_connector_hotplug() is called before everyone else, and tries to handle the link training. Since only the first byte of the dpcd is zeroed, the driver is able to complete link training but does so against the wrong dpcd, causing it to initialize the link with the wrong settings. - Display stays blank (usually), dpcd is probed after the initial link training, and the driver prints no obvious messages to the log. In theory, since only one byte of the dpcd is chopped off (specifically, the byte that contains the revision information for DisplayPort), it's not entirely impossible that this bug may not show on certain monitors. For instance, the only reason this bug was visible on my ASUS PB238 monitor was due to the fact that this monitor using the enhanced framing symbol sequence, the flag for which is ignored if the radeon driver thinks that the DisplayPort version is below 1.1. Signed-off-by: Stephen Chandler Paul <cpaul@redhat.com> Reviewed-by: Jerome Glisse <jglisse@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* drm/radeon: rework audio detect (v4)Alex Deucher2015-07-291-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | 1. Always assign audio function pointers even if the display does not support audio. We need to properly disable the audio stream when when using a non-audio capable monitor. Fixes purple line on some hdmi monitors. 2. Check if a pin is in use by another encoder before disabling it. v2: make sure we've fetched the edid before checking audio and look up the encoder before calling audio_detect since connector->encoder may not be assigned yet. Separate pin and afmt. They are allocated at different times and have no dependency on eachother. v3: fix connector fetching in encoder functions v4: fix missed dig->pin check in dce6_afmt_write_latency_fields bugs: https://bugzilla.kernel.org/show_bug.cgi?id=93701 https://bugzilla.redhat.com/show_bug.cgi?id=1236337 https://bugs.freedesktop.org/show_bug.cgi?id=91041 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* Revert "drm/radeon: only mark audio as connected if the monitor supports it ↵Alex Deucher2015-05-271-6/+2
| | | | | | | | | | | | | | (v3)" This breaks too many things. bugs: https://bugzilla.kernel.org/show_bug.cgi?id=99041 https://bugs.freedesktop.org/show_bug.cgi?id=90681 This reverts commit 0f55db36d49d45b80eff0c0a2a498766016f458b. Cc: stable@vger.kernel.org
* drm/radeon: only mark audio as connected if the monitor supports it (v3)Alex Deucher2015-04-271-2/+6
| | | | | | | | | | | Otherwise the driver may try and send audio which may confuse the monitor. v2: set pin to NULL if no audio v3: avoid crash with analog encoders Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* drm/radeon: constify more struct drm_*_helper funcs pointersJani Nikula2015-04-131-2/+2
| | | | | | | | | Some non-const pointers were added since the last constification, fix them. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/radeon: constify all struct drm_*_helper funcs pointersJani Nikula2015-04-071-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | They are not to be modified. Generated using the semantic patch: @@ @@ ( const struct drm_crtc_helper_funcs * | - struct drm_crtc_helper_funcs * + const struct drm_crtc_helper_funcs * ) @@ @@ ( const struct drm_encoder_helper_funcs * | - struct drm_encoder_helper_funcs * + const struct drm_encoder_helper_funcs * ) @@ @@ ( const struct drm_connector_helper_funcs * | - struct drm_connector_helper_funcs * + const struct drm_connector_helper_funcs * ) @@ @@ ( const struct drm_plane_helper_funcs * | - struct drm_plane_helper_funcs * + const struct drm_plane_helper_funcs * ) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* drm/radeon: add DisplayPort MST support (v2)Dave Airlie2015-03-191-3/+61
| | | | | | | | | | | | | | | | This adds initial DP 1.2 MST support to radeon, on CAYMAN and up in theory. This is off by default. v2: agd5f: - add UNIPHY3 offsets - move atom cmd table code into atombios_encoders.c - whitespace cleanup - replace some magic numbers with proper defines Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: implement output csc property for DCE5+Alex Deucher2015-03-191-0/+52
| | | | | | | | | | Implement the property for DCE5+ asics. Older asics require a slightly more complex process. bug: https://bugs.freedesktop.org/show_bug.cgi?id=83226 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* radeon/audio: defined initial audio interface that gets initialized via ↵Slava Grigorev2015-01-221-0/+8
| | | | | | | | detect() call Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Slava Grigorev <slava.grigorev@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: report disconnected for LVDS/eDP with PX if ddc failsAlex Deucher2014-11-261-1/+18
| | | | | | | | | | | | If ddc fails, presumably the i2c mux (and hopefully the signal mux) are switched to the other GPU so don't fetch the edid from the vbios so that the connector reports disconnected. bug: https://bugzilla.opensuse.org/show_bug.cgi?id=904417 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* drm/radeon: Prevent hdmi deep color if max_tmds_clock is undefined.Mario Kleiner2014-08-051-1/+10
| | | | | | | | | | | HDMI spec requires a valid max_tmds_clock from edid for hdmi deep color modes. If a sink violates this, disable deep color. Also add a hint to user about the deep_color module parameter if deep color is disabled due to that. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: make radeon_connector_encoder_is_hbr2 staticAlex Deucher2014-08-051-1/+1
| | | | | | It's only used in radeon_connectors.c. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: use a fetch function to get the edidAlex Deucher2014-08-051-6/+21
| | | | | | | | | | | | | | | We keep a cached version of the edid in radeon_connector which we use for determining connectedness and when to enable certain features like hdmi audio, etc. When the user uses the firmware interface to override the driver with some other edid the driver's copy is never updated. The fetch function will check if there is a user supplied edid and update the driver's copy if there is. bug: https://bugs.freedesktop.org/show_bug.cgi?id=80691 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: restructure edid fetchingAlex Deucher2014-08-051-52/+110
| | | | | | | | Split radeon_ddc_get_modes() and move it into radeon_connectors.c since that is the only place that uses it. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: consolidate vga and dvi get_modes functions (v2)Alex Deucher2014-08-051-13/+1
| | | | | | | | They are identical. v2: rebase Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: enable display scaling on all connectors (v2)Alex Deucher2014-08-051-16/+90
| | | | | | | | | | | | | | | | | | | | This enables the display scaler on all connectors for r5xx and newer asics. Previously we only enabled the scaler for fixed mode displays (eDP or LVDS) since they have to use the scaler to support non-native modes. Most other displays are multi-sync or have a built in scaler to support non-native modes. The default scaling mode for non-fixed displays is none which will use the scaler in the monitor. Note that we do not populate any fake modes like we do for fixed displays so it will only use the modes in the edid. For other modes, you'll need to populate them manually. bug: https://bugs.freedesktop.org/show_bug.cgi?id=80868 v2: properly handle scaling with no modes defined Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: use helpersRob Clark2014-07-181-48/+18
| | | | | Signed-off-by: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* Merge tag 'topic/core-stuff-2014-06-30' of ↵Dave Airlie2014-07-081-3/+3
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://anongit.freedesktop.org/drm-intel into drm-next misc core patches picked up by Daniel and Jani. * tag 'topic/core-stuff-2014-06-30' of git://anongit.freedesktop.org/drm-intel: drm/fb-helper: Remove unnecessary list empty check in drm_fb_helper_debug_enter() drm/fb-helper: Redundant info->fix.type_aux setting in drm_fb_helper_fill_fix() drm/debugfs: add an "edid_override" file per connector drm/debugfs: add a "force" file per connector drm: add register and unregister functions for connectors drm: fix uninitialized acquire_ctx fields (v2) drm: Driver-specific ioctls range from 0x40 to 0x9f drm: Don't export internal module variables
| * drm: add register and unregister functions for connectorsThomas Wood2014-06-191-3/+3
| | | | | | | | | | | | | | | | | | | | 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/radeon: add a module parameter to control deep color supportAlex Deucher2014-07-011-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Some monitors seem to have problems with deep color enabled, even though they claim to support it. I'm not sure if the monitor need a quirk or if the driver is doing something the monitor doesn't like. At this point lets just disable deep color by default like we did for hdmi audio and work through the bugs so we can eventually enable it by default. bug: https://bugs.freedesktop.org/show_bug.cgi?id=80531 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | drm/radeon: improve dvi_mode_validAlex Deucher2014-06-181-9/+7
| | | | | | | | | | | | | | Make sure we have an HDMI monitor before validating modes with clocks >165 Mhz on single link connections. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | drm/radeon: update mode_valid testing for DPAlex Deucher2014-06-181-4/+15
|/ | | | | | | When we have a passive adapter validate the clocks against the HMDI/DVI limits. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: hdmi deep color modes must obey clock limit of sink.Mario Kleiner2014-06-091-0/+31
| | | | | | | | | | | | Make sure that a hdmi deep color mode can't exceed the max tmds clock limit of a hdmi sink if such a limit is defined by edid. If requested deep color bpc would exceed the limit given the mode to be set, try to degrade gracefully to lower supported deep color bpc or to standard 8 bpc if needed. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm: Split connection_mutex out of mode_config.mutex (v3)Daniel Vetter2014-06-041-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* drm/radeon: replace drm_get_connector_name() with direct name field useJani Nikula2014-06-041-10/+15
| | | | | | | | | | | | | | | | | | Generated using semantic patch: @@ expression E; @@ - drm_get_connector_name(E) + E->name [airlied: regenerated] Acked-by: Alex Deucher <alexander.deucher@amd.com> 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/radeon: Limit hdmi deep color bit depth to 12 bpc.Mario Kleiner2014-06-021-0/+25
| | | | | | | | | | | | | | | DCE-4/5/6 can't support more than 12 bpc deep color over hdmi, so clamp to 12 bpc when a hdmi deep color capable display is connected. This even makes sense on DCE-8+, which could do up to 16 bpc, as driving with more than 12 bpc would only waste video bandwidth as long as we don't support framebuffers with more than 12 bpc depth. On pre-DCE4 we clamp hdmi bit depth to 8 bpc, as those asics don't support hdmi deep color. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: fix typo in radeon_connector_is_dp12_capable()Alex Deucher2014-06-021-1/+1
| | | | | | | | | We were checking the ext clock rather than the display clock. Noticed by ArtForz on IRC. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* drm/radeon/dp: switch to the common i2c over aux codeAlex Deucher2014-04-081-37/+7
| | | | | | | Provides a nice cleanup in radeon. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Christian König <christian.koenig@amd.com>
* drm: Replace crtc fb with primary plane fb (v3)Matt Roper2014-04-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Now that CRTC's have a primary plane, there's no need to track the framebuffer in the CRTC. Replace all references to the CRTC fb with the primary plane's fb. This patch was generated by the Coccinelle semantic patching tool using the following rules: @@ struct drm_crtc C; @@ - (C).fb + C.primary->fb @@ struct drm_crtc *C; @@ - (C)->fb + C->primary->fb v3: Generate patch via coccinelle. Actual removal of crtc->fb has been moved to a subsequent patch. v2: Fixup several lingering crtc->fb instances that were missed in the first patch iteration. [Rob Clark] Signed-off-by: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Rob Clark <robdclark@gmail.com>
* drm/radeon: use the new drm helpers for dp auxAlex Deucher2014-03-251-3/+14
| | | | | | | | | | Switch to the new dp helpers. The main difference is that the DP helpers don't allow an adjustable delay in the aux transaction, but I don't know that this is necessary. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Christian König <christian.koenig@amd.com>
* drm/radeon: move com/atombios scratch reg functions to radeon_mode.hAlex Deucher2014-01-071-9/+0
| | | | | | | | | fixes warnings with -Wmissing-prototypes Based on initial patches from Rashika Kheria. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Rashika Kheria <rashika.kheria@gmail.com>
* drm/radeon: fix mismerge of drm-next with 3.12Alex Deucher2013-11-081-12/+4
| | | | | | Audio is enabled by default now. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* Merge tag 'drm-intel-fixes-2013-11-07' of ↵Dave Airlie2013-11-081-12/+25
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-next Bit a bit -fixes pull request in the merge window than usual dua to two feauture-y things: - Display CRCs are now enabled on all platforms, including the odd DP case on gm45/vlv. Since this is a testing-only feature it should ever hurt, but I figured it'll help with regression-testing -fixes. So I left it in and didn't postpone it to 3.14. - Display power well refactoring from Imre. Would have caused major pain conflict with the bdw stage 1 patches if I'd postpone this to -next. It's only an relatively small interface rework, so shouldn't cause pain. It's also been in my tree since almost 3 weeks already. That accounts for about two thirds of the pull, otherwise just bugfixes: - vlv backlight fix from Jesse/Jani - vlv vblank timestamp fix from Jesse - improved edp detection through vbt from Ville (fixes a vlv issue) - eDP vdd fix from Paulo - fixes for dvo lvds on i830M - a few smaller things all over Note: This contains a backmerge of v3.12. Since the -internal branch always applied on top of -nightly I need that unified base to merge bdw patches. So you'll get a conflict with radeon connector props when pulling this (and nouveau/master will also conflict a bit when Ben doesn't rebase). The backmerge itself only had conflicts in drm/i915. There's also a tiny conflict between Jani's backlight fix and your sysfs lifetime fix in drm-next. * tag 'drm-intel-fixes-2013-11-07' of git://people.freedesktop.org/~danvet/drm-intel: (940 commits) drm/i915/vlv: use per-pipe backlight controls v2 drm/i915: make backlight functions take a connector drm/i915: move opregion asle request handling to a work queue drm/i915/vlv: use PIPE_START_VBLANK interrupts on VLV drm/i915: Make intel_dp_is_edp() less specific drm/i915: Give names to the VBT child device type bits drm/i915/vlv: enable HDA display audio for Valleyview2 drm/i915/dvo: call ->mode_set callback only when the port is running drm/i915: avoid unclaimed registers when capturing the error state drm/i915: Enable DP port CRC for the "auto" source on g4x/vlv drm/i915: scramble reset support for DP port CRC on vlv drm/i915: scramble reset support for DP port CRC on g4x drm/i916: add "auto" pipe CRC source ... Conflicts: MAINTAINERS drivers/gpu/drm/i915/intel_panel.c drivers/gpu/drm/nouveau/core/subdev/mc/base.c drivers/gpu/drm/radeon/atombios_encoders.c drivers/gpu/drm/radeon/radeon_connectors.c
| * drm/radeon: rework audio optionAlex Deucher2013-10-181-12/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In 3.12 I changed audio to be enabled by default, but you still had to turn it on via xrandr. This was confusing to users so change it to minic the previous behavior: - audio option is set to -1 (auto) by default which is the current 3.12 behavior (audio is enabled but requires xrandr to turn it on). - if audio = 1, the audio is enabled without needing to mess with xrandr (previous behavior) - audio = 0 disables audio It retains the new feature of allowing the user to enable audio on the fly with xrandr, but turns audio on automatically if radeon.audio=1 is set which is what most users expect. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com>
* | drm/radeon: enable hdmi audio by defaultAlex Deucher2013-11-011-4/+4
| | | | | | | | | | | | | | Seems to be stable enough for the majority of users. It can be disabled on the fly via connector attributes. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | drm/radeon: add runtime PM support (v2)Dave Airlie2013-11-011-8/+55
| | | | | | | | | | | | | | | | | | | | | | This hooks radeon up to the runtime PM system to enable dynamic power management for secondary GPUs in switchable and powerxpress laptops. v2: agd5f: clean up, add module parameter Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | drm/radeon: add a connector property for ditherAlex Deucher2013-11-011-0/+33
|/ | | | | | | | Allows you to enable dither in the display hardware when the monitor supports lower a lower bpc than the current framebuffer format. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: fix panel scaling with eDP and LVDS bridgesAlex Deucher2013-09-151-3/+31
| | | | | | | | | We were using the wrong set_properly callback so we always ended up with Full scaling even if something else (Center or Full aspect) was selected. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* drm/radeon: Fix hmdi typoDamien Lespiau2013-09-151-1/+1
| | | | | | | | | I keep making that one, so checked if I was the only one. Apparently not. Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: add a connector property for audioAlex Deucher2013-09-111-0/+33
| | | | | | | | | | This provides a connector property to enable/disable hdmi audio on the fly. The default is disabled, but you can select auto (let the driver detect an audio capable monitor and enable it) or enabled (force audio enabled). This also enables audio by default so you no longer need a module parameter to enable audio. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* drm/radeon: Properly handle DDC probe for DP bridgesNiels Ole Salscheider2013-01-031-4/+6
| | | | | | | | | | | | | DDC information can be accessed using AUX CH Fixes failure to probe monitors on some systems with DP bridge chips. agd5f: minor fixes Signed-off-by: Niels Ole Salscheider <niels_ole@salscheider-online.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* drm/radeon: drm_connector_property -> drm_object_propertyRob Clark2012-11-301-31/+31
| | | | Signed-off-by: Rob Clark <rob@ti.com>
* DRM/Radeon: On DVI-I use Load Detection when EDID is bogus.Egbert Eich2012-11-011-7/+21
| | | | | | | | | | | | | | The Radeon driver uses the analog/digital flag to determine if the DAC or the TMDS encoder should be enabled on a DVI-I connector. If the EDID is bogus this flag is no longer reliable. This fix adds a fallback to DAC load detection to determine if anything is connected to the DAC. If not and a (bogus) EDID is found it assumes a digital display is connected. This works around problems with some crappy IPMI devices using Radeon ES1000. Signed-off-by: Egbert Eich <eich@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds2012-10-031-29/+14
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull drm merge (part 1) from Dave Airlie: "So first of all my tree and uapi stuff has a conflict mess, its my fault as the nouveau stuff didn't hit -next as were trying to rebase regressions out of it before we merged. Highlights: - SH mobile modesetting driver and associated helpers - some DRM core documentation - i915 modesetting rework, haswell hdmi, haswell and vlv fixes, write combined pte writing, ilk rc6 support, - nouveau: major driver rework into a hw core driver, makes features like SLI a lot saner to implement, - psb: add eDP/DP support for Cedarview - radeon: 2 layer page tables, async VM pte updates, better PLL selection for > 2 screens, better ACPI interactions The rest is general grab bag of fixes. So why part 1? well I have the exynos pull req which came in a bit late but was waiting for me to do something they shouldn't have and it looks fairly safe, and David Howells has some more header cleanups he'd like me to pull, that seem like a good idea, but I'd like to get this merge out of the way so -next dosen't get blocked." Tons of conflicts mostly due to silly include line changes, but mostly mindless. A few other small semantic conflicts too, noted from Dave's pre-merged branch. * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (447 commits) drm/nv98/crypt: fix fuc build with latest envyas drm/nouveau/devinit: fixup various issues with subdev ctor/init ordering drm/nv41/vm: fix and enable use of "real" pciegart drm/nv44/vm: fix and enable use of "real" pciegart drm/nv04/dmaobj: fixup vm target handling in preparation for nv4x pcie drm/nouveau: store supported dma mask in vmmgr drm/nvc0/ibus: initial implementation of subdev drm/nouveau/therm: add support for fan-control modes drm/nouveau/hwmon: rename pwm0* to pmw1* to follow hwmon's rules drm/nouveau/therm: calculate the pwm divisor on nv50+ drm/nouveau/fan: rewrite the fan tachometer driver to get more precision, faster drm/nouveau/therm: move thermal-related functions to the therm subdev drm/nouveau/bios: parse the pwm divisor from the perf table drm/nouveau/therm: use the EXTDEV table to detect i2c monitoring devices drm/nouveau/therm: rework thermal table parsing drm/nouveau/gpio: expose the PWM/TOGGLE parameter found in the gpio vbios table drm/nouveau: fix pm initialization order drm/nouveau/bios: check that fixed tvdac gpio data is valid before using it drm/nouveau: log channel debug/error messages from client object rather than drm client drm/nouveau: have drm debugging macros build on top of core macros ...
| * drm/radeon: Mark all possible functions / structs as staticLauri Kasanen2012-09-201-14/+14
| | | | | | | | | | | | | | | | | | Let's allow GCC to optimize better. This exposed some five unused functions, but this patch doesn't remove them. Signed-off-by: Lauri Kasanen <cand@gmx.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
| * drm/radeon: add backlight control for atom devices (v2)Alex Deucher2012-09-201-15/+0
| | | | | | | | | | | | | | | | | | On systems that use the build in GPU backlight controller, we can use atom tables to change the brightness level. v2: use firmware flags Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
OpenPOWER on IntegriCloud