An error occurred fetching the project authors.
- 08 Aug, 2014 3 commits
-
-
Damien Lespiau authored
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>
-
Ville Syrjälä authored
CHV display PHY registes have two swing margin/deemph settings. Make it clear which ones we're using. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Ville Syrjälä authored
CHV was forgotten the intel_{dp,hdmi}_prepare() were introduced (or the chv patches were still in flight?). Call these when enabling the ports. Things tend to work much better when we actually write something to the port registers :) Signed-off-by:
-
- 23 Jul, 2014 3 commits
-
-
Sonika Jindal authored
v2: Adding IS_G4X instead of gen < 5 as suggested by Daniel Signed-off-by:
Sonika Jindal <sonika.jindal@intel.com> Signed-off-by:
-
Sonika Jindal authored
Signed-off-by:
-
Vandana Kannan authored
Create and attach the drm property to set aspect ratio. If there is no user specified value, then PAR_NONE/Automatic option is set by default. User can select aspect ratio 4:3 or 16:9. The aspect ratio selected by user would come into effect with a mode set. v2: Modified switch case to include aspect ratio enum changes v3: Modified the patch according the change in the earlier patch to return errno in case property creation fails. With this change, property will be attached only if creation is successful Signed-off-by:
Vandana Kannan <vandana.kannan@intel.com> Cc: Thierry Reding <thierry.reding@gmail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
-
- 19 Jun, 2014 1 commit
-
-
Thomas Wood authored
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:
-
- 11 Jun, 2014 2 commits
-
-
Ville Syrjälä authored
Try to force the PHY clock buffer enables to make the clock routing work. v2: Fix the pipe B case to actually enable CH0 clock buffers Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by:
-
Ville Syrjälä authored
These should make it possible to feed port C from pipe A or port B from pipe B. Didn't quite seem to work though. Signed-off-by:
-
- 04 Jun, 2014 1 commit
-
-
Jani Nikula authored
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:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
Dave Airlie <airlied@redhat.com>
-
- 20 May, 2014 9 commits
-
-
Ville Syrjälä authored
The spec only tells us to set individual bits here and there. So we use RMW for most things. Do the same for the swing calc init. Eventually we should optimize things to just blast the final value in with group access whenever possible. But to do that someone needs to take a good look at what's the reset value for each registers, and possibly if the BIOS manages to frob with some of them. For now use RMW access always. Signed-off-by:
-
Ville Syrjälä authored
Like PCS, TX group reads return 0xffffffff. So we need to target each lane separately if we want to use RMW cycles to update the registers. Signed-off-by:
-
Ville Syrjälä authored
All PCS groups access reads return 0xffffffff, so we can't use group access for RMW cycles. Instead target each spline separately. Signed-off-by:
-
Ville Syrjälä authored
The bits we've been setting so far only progagate the reset singal to the data lanes. To actaully force the reset signal we need to set another override bit. v2: Fix mispalced ';' (Mika) Reviewed-by:
-
Ville Syrjälä authored
Seems like we shouldn't leave the data lane resert deasserted when the port if disabled. So propagate the reset the data lanes in the encoder .post_disable() hook. Signed-off-by:
-
Ville Syrjälä authored
We need to pick the correct data lanes based on the port not the pipe, so move the data lane deassert into the encoder .pre_enable() hook from the chv_enable_pll(). Signed-off-by:
-
Ville Syrjälä authored
Fix the encoder .get_config hooks to report the correct active pipe for CHV. Signed-off-by:
Antti Koskipää <antti.koskipaa@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
On CHV the GMBUS port for port D is different from other gmch platforms which have port D. Fix it up. Signed-off-by:
-
Ville Syrjälä authored
On CHV pipe C can driver only port D, and pipes A and B can drivbe only ports B and C. Configure the crtc_mask appropriately to reflect that. v2: Moar braces (Jani) Signed-off-by:
-
- 16 May, 2014 5 commits
-
-
Daniel Vetter authored
Similar to dp the only thing we do is call intel_write_eld and prepare a bit of state for the enable hooks. The only difference is that we write that to the hardware instead of keeping track of it somewhere in software. Still we can just move all this to the very first enable hook. Reviewed-by:
Naresh Kumar Kachhi <naresh.kumar.kachhi@intel.com> Signed-off-by:
-
Daniel Vetter authored
Those functions are only used on vlv platforms, so no need to check. Especially if we're not too consistent about it. Reviewed-by:
-
Daniel Vetter authored
Including state readout and cross-checking. This allows us to get rid of crtc->eld_vld on hsw+. It also means that fastboot will be unhappy if the BIOS hasn't set up the audio routing like we want it too. Wrt fastboot and external screens I see a few options: - Don't. - Try to fix up eld, infoframes and audio settings after the fact. But that means some pretty extensive reworking of our code which currently does all this while the pipe/port is still off. I won't bother with converting SDVO over to this because the audio support for SDVO is very lacking: - We don't update the eld. - We don't update the audio state on the sdvo encoder. - We don't check whether the platform can even feed audio to the sdvo encoder. I've converted hdmi, dp & ddi all in one go since ddi needs both hdmi and dp converted and so doing it step-by-step would have required a few intermediate hacks. Reviewed-by:
-
Daniel Vetter authored
Also add state readout and cross-check support. The only invasive change is wiring up the new flag to the ->set_infoframes callbacks. Reviewed-by:
-
Daniel Vetter authored
For compliance we really should be sending NULL infoframes always when we detect a hdmi capable monitor. Also remove the now redudant setting for the has_audio case and enforce that audio is only possible with a hdmi sink. Reviewed-by:
-
- 12 May, 2014 2 commits
-
-
Chon Ming Lee authored
With additional of pipe C, current 1 bit registers for pipe select for HDMI and DP are no longer able to gather for 3 pipes. As a result, new bits location in the same registers are added. For HDMI, VLV uses bit 30, CHV uses bit 24-25. For DP, VLV uses bit 30, CHV uses bit 16-17. Reviewed-by:
Chon Ming Lee <chon.ming.lee@intel.com> Reviewed-by:
Imre Deak <imre.deak@intel.com> Signed-off-by:
-
Chon Ming Lee authored
Added programming phy layer for CHV based on "Application note for 1273 CHV Display phy". v2: Rebase the code and do some cleanup. v3: Rework based on Ville review. -Fix the macro where the ch info need to swap, and add parens to ? operator. -Fix wrong bit define for DPIO_PCS_SWING_CALC_0 and DPIO_PCS_SWING_CALC_1 and rename for meaningful. -Add some comments for CHV specific DPIO registers. -Change the dp margin registery value to decimal to align with the doc. -Fix the not clearing some value in vlv_dpio_read before write again. -Create new hdmi/dp encoder function for chv instead of share with valleyview. v4: Rebase the code after rename the DPIO registers define and upstream change. Based on Ville review. -For unique transition scale selection, after Ville point out, look like the doc might wrong for the bit 26. Use bit 27 for ch0 and ch1. -Break up some dpio write value into two/three steps for readability. -Remove unrelated change. -Add some shift define for some registers instead just give the hex value. -Fix a bug where write to wrong VLV_TX_DW3. v5: Based on Ville review. - Move tx lane latency optimal setting from chv_dp_pre_pll_enable to chv_pre_enable_dp, and chv_hdmi_pre_pll_enable to chv_hdmi_pre_enable respectively. - Fix typo in one margin_reg_value for DP_TRAIN_VOLTAGE_SWING_400. - Clear DPIO_TX_UNIQ_TRANS_SCALE_EN for DP and HDMI. - Mask the old deemph and swing bits for hdmi. v6: Remove stub for pre_pll_enable for dp and hdmi. Signed-off-by:
-
- 22 Apr, 2014 1 commit
-
-
Ville Syrjälä authored
In commit commit 6375b768 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Mar 3 11:33:36 2014 +0200 drm/i915: Reject >165MHz modes w/ DVI monitors the driver started to filter out display modes which exceed the single-link DVI 165Mz dotclock limits when the monitor doesn't report itself as being HDMI compliant. The intent was to filter out all EDID derived modes that require dual-link DVI to operate since we don't support dual-link. However the patch went a bit too far and also causes the driver to reject such modes even when specified by the user. Normally we don't check the sink limitations when setting a mode from the user. This allows the user to specify any mode whether the sink reports to support it or not. This can be useful since often the sinks support more modes than they report in the EDID. So relax the checks a bit, and apply the single-link DVI dotclock limit only when filtering the mode list, and ignore the limit when setting a user specified mode. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=72961Tested-by:
Nicholas Vinson <nvinson@comcast.net> Cc: stable@vger.kernel.org [3.14] Reviewed-by:
Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
-
- 09 Apr, 2014 4 commits
-
-
Jesse Barnes authored
Needs to happen after clock is running or it doesn't behave correctly. v2: fix subject (Ville) make it clearer that this occurs in pre_enable (Paulo) misc bikesheds (Paulo) Signed-off-by:Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Jesse Barnes authored
Allows sending of the null packets for conformance. Signed-off-by:
-
Jesse Barnes authored
We also do a disable later when we write a specific infoframe, but here we do it to prevent sending a stale one before updating the infoframes. Signed-off-by:
-
Jesse Barnes authored
In case we end up bouncing these around between ports. Signed-off-by:
-
- 10 Mar, 2014 4 commits
-
-
Ville Syrjälä authored
BSpec is a bit unclear whether HDMI+HDMI cloning should work on g4x. Tests on real hardware say that it does. Since g4x can't send infoframes to more than one HDMI port anyway, we don't lose anything by allow it. For PCH platforms BSpec explicitly forbids HDMI+HDMI cloning. Whether HDMI+HDMI cloning might also work on VLV is a bit unclear, but since we'd at least lose the capability of sending infoframes to more than one cloned HDMI port, it doesn't seem like a good idea to allow it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73850Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Ville Syrjälä authored
HDMI+VGA cloning should be supported on all platforms. The only real obstacle is the 1.5x clock adjustment for 12bpc HDMI, but that is now taken care of, so we can allow HDMI+VGA cloning. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73850Signed-off-by:
-
Ville Syrjälä authored
When cloning HDMI with other output types, we can't use 12bpc since the clocks for the other encoder types would be off. So have intel_hdmi_compute_config() check if there are other encoders besides HDMI being fed from the same pipe, and if so, pick 8bpc insted if 12bpc. Signed-off-by:
-
Ville Syrjälä authored
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:
-
- 07 Mar, 2014 2 commits
-
-
Imre Deak authored
Since the encoder is tied to its port, we need to make sure the power domain for that port is on before reading out the encoder HW state. Note that this also covers also all connector get_hw_state handlers, since all those just call the corresponding encoder get_hw_state handler, which checks - after this change - for all power domains the connector needs. v2: - no change v3: - push down the power domain checks into the specific encoder get_hw_state handlers (Daniel) Signed-off-by:
-
Imre Deak authored
The connector detect and get_mode handlers need to access the port specific HW blocks to read the EDID etc. Get/put the port power domains around these handlers. v2: - get port power domain for HDMI too (Ville) - get port power domain for the DP,HDMI audio detect handlers (Jesse) - Leave the intel_runtime_pm_get/put in the DP detect function in place. Instead of just removing them, these should be moved to the appropriate power_well enable/disable handlers. We can do this after Paulo's 'Merge PC8 with runtime PM, v2' patchset. v3: - rebased on latest -nightly Signed-off-by:
-
- 03 Mar, 2014 1 commit
-
-
Ville Syrjälä authored
Single-link DVI max dotclock is 165MHz. Filter out modes with higher dotclock when the monitor doesn't support HDMI. Modes higher than 165 MHz were allowed in commit 7d148ef5 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Jul 22 18:02:39 2013 +0200 drm/i915: fix hdmi portclock limits Also don't attempt to use 12bpc mode with DVI monitors. Cc: Adam Nielsen <a.nielsen@shikadi.net> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75345 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=70331Tested-by:
Ralf Jung <post+kernel@ralfj.de> Cc: stable@vger.kernel.org Signed-off-by:
-
- 14 Feb, 2014 1 commit
-
-
Imre Deak authored
Since commit d9255d57 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:
-
- 13 Feb, 2014 1 commit
-
-
Ville Syrjälä authored
We have a couple of switch cases to compute the port value for the VIDEO_DIP_CTL register. Replace them with a simple macro. We do lose a few BUG() calls, but many people may consider that an improvement. Signed-off-by:
-
