- 25 May, 2012 1 commit
-
-
Chris Wilson authored
Paulo pointed out that gen4 re-used the SDVO registers for HDMI (the separate HDMI registers where introduced with the first PCH) and so g4x_hdmi_connected() never selected the right bit and always returned disconnected. Regression in commit 8ec22b21 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Fri May 11 18:01:34 2012 +0100 drm/i915/hdmi: Query the live connector status bit for G4x Cc: Paulo Zanoni <przanoni@gmail.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Tested-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
- 21 May, 2012 1 commit
-
-
Chris Wilson authored
Similar to g4x_dp_detect() we should probe the PORT_HOTPLUG_STATUS as to whether the connector is active prior to attempting to retrieve the EDID. Signed-off-by:
-
- 20 May, 2012 2 commits
-
-
Paulo Zanoni authored
Both the control and data registers are completely different now. Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
-
Paulo Zanoni authored
- Changed the coding style of auxiliary infoframe functions to make them smaller - Fixed the column alignment of some function definitions - Remove definition of "struct drm_crtc" in some places as they're used only to retrieve "struct intel_crtc" Signed-off-by:
-
- 19 May, 2012 5 commits
-
-
Eugeni Dodonov authored
On Haswell, we need to properly train the DDI buffers prior to enabling HDMI, and enable the required clocks with correct dividers for the desired frequency. Also, we cannot simple reuse HDMI routines from previous generations of GPU, as most of HDMI-specific stuff is being done via the DDI port programming instead of HDMI-specific registers. This commit take advantage of the WR PLL clock table which is in a separate (previous) commit to select the right divisors for each mode. Signed-off-by:
-
Eugeni Dodonov authored
Move intel_hdmi data structure and support functions to a shared location, to allow their usage from intel_ddi module. Reviewed-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Eugeni Dodonov authored
Those are driven by DDIs on Haswell architecture, so we need to keep track of which DDI is being used on each output. Reviewed-by:
-
Eugeni Dodonov authored
This will throw a BUG() message when an unknown sdvox register is given to intel_hdmi_init. When this happens, things could going to be pretty much broken afterwards, so we better detect this as soon as possible. Signed-off-by:
-
Eugeni Dodonov authored
Haswell has different DIP control registers and offsets which we need to use for infoframes, which this patch adds. Note that this does not adds full DIP frames support, but only the basic functionality necessary for HDMI to work in early enablement. v2: replace infoframe handling with a debug message, proper support will be added via a patch from Paulo Zanoni later. Signed-off-by:
Paulo Zanoni <przanoni@gmail.com> Signed-off-by:
-
- 08 May, 2012 12 commits
-
-
Daniel Vetter authored
These two functions are actually hw-specific and only valid for gm45 thru gen7. HSW completely changes how this works, so label them accordingly. v2: s/gm45/g4x/ like for the previous patch. Acked-by:
-
Daniel Vetter authored
Generally we call stuff with i9xx_ when it's valid for gen3+. But gen3 and early gen4 only support hdmi with sdvo cards, and writing infoframes works completely different there. v2: Use g4x instead of gm45 - it applies to the desktop variant, too. v3: Properly align the paramters of g4x_write_infoframe again, noticed by Paulo Zanoni. Acked-by:
-
Daniel Vetter authored
Simplifies things because for all the infoframes we care about, we always send them on each vblank. Also, this gets rid of one of the hw specific functions mislabelled with the intel_ prefix - hsw will completely change how this works! Acked-by:
-
Paulo Zanoni authored
Just like Gen 4, IBX has a "Port Select" field on the DIP register, but the ports are different. Signed-off-by:
-
Paulo Zanoni authored
IBX does not need the workaround used in cpt_write_infoframe that requires the AVI frame to be enabled while being updated. Signed-off-by:
-
Paulo Zanoni authored
The registers are on the PCH, so use the PCH name instead of the CPU name. Also, the way this function is implemented is really only for CPT and PPT. For now, both functions have the same implementations: the next patch will fix ibx_write_infoframe. Signed-off-by:
-
Paulo Zanoni authored
Better safe than sorry. Currently we never change the frequency and use the same for every infoframe type, so the only way to reproduce a bug would be with the BIOS doing something. Signed-off-by:
-
Paulo Zanoni authored
That's what the VIDEO_DIP_CTL documentation says we need to do. Except when it's the AVI InfoFrame and we're ironlake_write_infoframe. Signed-off-by:
-
Paulo Zanoni authored
This will allow us to disable an infoframe without changing its frequency. Signed-off-by:
-
Paulo Zanoni authored
Should prevent bugs when changing the port. Signed-off-by:
-
Paulo Zanoni authored
Make sure we're doing the right thing, just like we do on gen5+. Signed-off-by:
-
Paulo Zanoni authored
Don't use intermediate variables, change the value of 'val' as we go through the function. The new style looks more similar to the rest of our code. IMHO, it's also easier to read and change. Signed-off-by:
-
- 03 May, 2012 2 commits
-
-
Paulo Zanoni authored
While testing with the intel_infoframes tool on gen4, I see that when video DIP is disabled, what we write to the DATA memory is not exactly what we read back later. This regression has been introduce in commit 64a8fc01 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Sep 22 11:16:00 2011 +0530 drm/i915: fix ILK+ infoframe support That commit was setting VIDEO_DIP_CTL to 0 when initializing, which caused the problem. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43947 Cc: stable@kernel.org Tested-by:
Yang Guang <guang.a.yang@intel.com> Signed-off-by:
-
Paulo Zanoni authored
They require an AVI InfoFrame with a proper Pixel Repetition field. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Signed-off-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
-
- 28 Mar, 2012 2 commits
-
-
Shobhit Kumar authored
HDMI register offsets are different in Valleyview. Add support for the same. v2: drop superfluous comments in HDMI init (Daniel) Signed-off-by:
Beeresh G <beeresh.g@intel.com> Signed-off-by:
Shobhit Kumar <shobhit.kumar@intel.com> Reviewed-by:
Vijay Purushothaman <vijay.a.purushothaman@intel.com> Reviewed-by:
Jesse Barnes <jesse.barnes@intel.com> Signed-off-by:
-
Daniel Kurtz authored
Instead of letting other modules directly access the ->gmbus array, introduce intel_gmbus_get_adapter() for looking up an i2c_adapter for a given gmbus port identifier. This will enable later refactoring of the gmbus port list. Note: Before requesting an adapter for a given gmbus port number, the driver must first check its validity using i2c_intel_gmbus_is_port_valid(). If this check fails, a call to intel_gmbus_get_adapter() will WARN_ON and return NULL. This is relevant for parts of the driver that read a port from VBIOS, which might be improperly initialized and contain an invalid port. In these cases, the driver must fall back to using a safer default port. Signed-off-by:
Daniel Kurtz <djkurtz@chromium.org> Signed-off-by:
-
- 14 Feb, 2012 1 commit
-
-
Wu Fengguang authored
When HDMI-DVI converter is used, it's not only necessary to turn off audio, but also to disable HDMI_MODE_SELECT and video infoframe. Since the DVI mode is mainly tied to audio functionality from end user POV, add a new "force-dvi" audio mode: xrandr --output HDMI1 --set audio force-dvi Note that most users won't need to set this and happily rely on the EDID based DVI auto detection. Reported-by:
Andrea Arcangeli <aarcange@redhat.com> Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
-
- 10 Feb, 2012 1 commit
-
-
Peter Ross authored
Signed-off-by:
Peter Ross <pross@xvid.org> Reviewed-by:
Christopher Egert <cme3000@gmail.com> Tested-by:
Alfonso Fiore <alfonso.fiore@gmail.com> Signed-off-by:
-
- 19 Dec, 2011 1 commit
-
-
Wu Fengguang authored
On HDMI monitor hot remove, clear SDVO_AUDIO_ENABLE accordingly, so that the audio driver will receive hot plug events and take action to refresh its device state and ELD contents. The cleared SDVO_AUDIO_ENABLE bit needs to be restored to prevent losing HDMI audio after DPMS on. CC: Wang Zhenyu <zhenyu.z.wang@intel.com> Signed-off-by:
Keith Packard <keithp@keithp.com>
-
- 21 Oct, 2011 1 commit
-
-
Jesse Barnes authored
Misc fixes based on tests with an infoframe analyzer: - checksum *does* include header bytes - DIP enable & AVI infoframe are tied together in hw, so disable both and make sure AVI frames are enabled first - use every vsync flag for SPD frames to avoid reserved value in frequency field when enabling both AVI & SPD Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40281 . Signed-off-by:
-
- 20 Oct, 2011 2 commits
-
-
Jesse Barnes authored
Required for 3 pipe functionality. Signed-off-by:
-
Jesse Barnes authored
Well almost anyway. IVB has 3 planes, pipes, transcoders, and FDI interfaces, but only 2 pipe PLLs. So two of the pipes must use the same pipe timings (e.g. 2 DP plus one other, or two HDMI with the same mode and one other, etc.). Signed-off-by:
-
- 21 Sep, 2011 1 commit
-
-
Wu Fengguang authored
Add ELD support for Intel Eaglelake, IbexPeak/Ironlake, SandyBridge/CougarPoint and IvyBridge/PantherPoint chips. ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio capabilities of the plugged monitor. It's built and passed to audio driver in 2 steps: (1) at get_modes time, parse EDID and save ELD to drm_connector.eld[] (2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP. Test scheme: plug in the HDMI/DP monitor, and run cat /proc/asound/card0/eld* to check if the monitor name, HDMI/DP type, etc. show up correctly. Minor imperfection: the GEN5_AUD_CNTL_ST/DIP_Port_Select field always reads 0 (reserved). Without knowing the port number, I worked it around by setting the ELD_valid bit for ALL the three ports. It's tested to not be a problem, because the audio driver will find invalid ELD data and hence rightfully abort, even when it sees the ELD_valid indicator. Thanks to Zhenyu and Pierre-Louis for a lot of valuable help and testing. CC: Zhao Yakui <yakui.zhao@intel.com> CC: Wang Zhenyu <zhenyu.z.wang@intel.com> CC: Jeremy Bush <contractfrombelow@gmail.com> CC: Christopher White <c.white@pulseforce.com> CC: Pierre-Louis Bossart <pierre-louis.bossart@intel.com> CC: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by:
-
- 03 Aug, 2011 2 commits
-
-
Jesse Barnes authored
Set an SPD infoframe if the sink supports it. Signed-off-by:
-
Jesse Barnes authored
This makes it easier to add support for other infoframes (e.g. SPD, vendor specific). Signed-off-by:
-
- 29 Jul, 2011 1 commit
-
-
Jesse Barnes authored
On Ironlake and above, we have per-transcoder DIP registers, so use them for sending DIPs like AVI infoframes on ILK and above. Signed-off-by:
-
- 07 Jul, 2011 2 commits
-
-
Jesse Barnes authored
The Intel HDMI encoder can support 8bpc or 12bpc. Set the appropriate value based on the pipe bpp when configuring the output. Signed-off-by:
-
Jesse Barnes authored
These bits are reserved on ILK+ (ILK+ provides this feature in the transcoder and pipe configuration instead, which we already set). Signed-off-by:
-
- 04 Jun, 2011 2 commits
-
-
Chris Wilson authored
Make the audio property creation routine common and share the single property between the connectors. Signed-off-by:
-
Nicolas Kaiser authored
Signed-off-by:
Nicolas Kaiser <nikai@nikai.net> Reviewed-by:
-
- 22 Feb, 2011 1 commit
-
-
Chris Wilson authored
In order to prevent "crushed blacks" on TVs, the range of the RGB output may be limited to 16-235. This used to be available through Xorg under the "Broadcast RGB" option, so reintroduce support for KMS. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34543 Signed-off-by:
-
