- 09 Apr, 2012 15 commits
-
-
Eugeni Dodonov authored
Different registers are identified by their target id and offset. To simplify their programming, they are called as <RegisterName><TargetId>. For example, SSCCTL register accessed through SBI at target id 6 and offset 0c is called SBI_SSCCTL6. Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
Eugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch>
-
Eugeni Dodonov authored
Multiple clocks can drive different outputs. v2: use the port enums to access individual ports v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Signed-off-by:
-
Eugeni Dodonov authored
This PLL control can drive DDI ports at desired frequencies for DisplayPort and FDI connections. Reviewed-by:
-
Eugeni Dodonov authored
Pixel clock gating control for Lynx point. Reviewed-by:
-
Eugeni Dodonov authored
Those are responsible for the Sideband Interface programming. v2: rename SBI bits to better reflect their meaning Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Eugeni Dodonov authored
Those registers are used to train DDI buffer translations for each link type. v2: access each port registers through the DDI_BUF_TRANS macro Signed-off-by:
-
Eugeni Dodonov authored
There is one instance of those registers for each DDI port. v2: access registers via the DDI_BUF_CTL() macro Reviewed-by:
-
Eugeni Dodonov authored
There is one set of those registers for each port. Signed-off-by:
-
Eugeni Dodonov authored
This is one set of those registers for each pipe. v2: use port enum to access individual registers Signed-off-by:
-
Eugeni Dodonov authored
There is one set of such registers for each pipe (A/B/C/EDP). v2: update to use DDI PORTS enum v1 Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
Eugeni Dodonov authored
There are 5 DDI ports on Haswell. Port A is always enabled, and is the one connected to eDP, and Port E is the one that can be connected to the PCH using FDI protocol. Ports B, C, D and E can be used for digital outputs. Signed-off-by:
-
Eugeni Dodonov authored
This defines the registers used by different power wells. Reviewed-by:
-
Eugeni Dodonov authored
Reviewed-by:
-
Eugeni Dodonov authored
This adds product definitions for desktop, mobile and server boards. v2: split into a separate patch, add .has_pch_split feature. Signed-off-by:
-
Eugeni Dodonov authored
The macro is becoming too complex and with VLV upon us it can lead to confusion. So transforming this into a feature check instead. Signed-off-by:
-
- 28 Mar, 2012 23 commits
-
-
Jesse Barnes authored
Haven't seen this yet, but it doesn't hurt. Signed-off-by:
Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by:
-
Jesse Barnes authored
ValleyView has a new interrupt architecture; best to put it in a new set of functions. Also make sure the ring mask functions handle ValleyView. FIXME: fix flipping; need to enable interrupts and call prepare/finish Signed-off-by:
-
Jesse Barnes authored
Signed-off-by:
-
Jesse Barnes authored
ValleyView handles force wake differently than previous chipsets, so add a couple of new functions for it. But leave it disabled by default until we test it (need a chip with the Punit enabled first). Signed-off-by:
-
Jesse Barnes authored
... and bind it right to the PCI id. Note that there are still a few things to fix here: - we need to move the tlb flush to a better place in drm/i915. - we need to check snoop support on vlv and implement it. Signed-off-by:
-
Jesse Barnes authored
We need to flush the Gunit TLB when we update GTT PTEs on VLV, but the register for doing so is above the range we normally map. Map the whole register space to make sure we can get it. v2: only map the larger space on gen7+ (Daniel) Signed-off-by:
-
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:
-
Gajanan Bhat authored
This patch adds support for programming drain latency registers of Pondicherry memory arbiter of Valleyview. v2: clarify function names (Daniel) fix summary typo (Daniel) v3: add parens (Ben) make drain function return bool (Ben) Acked-by:Ben Widawsky <ben@bwidawsk.net> Signed-off-by:
Gajanan Bhat <gajanan.bhat@intel.com> Reviewed-by:
-
Jesse Barnes authored
Set required clock gating and chicken bits on VLV. v2: set PIXEL_SUBSPAN_COLLECT_OPT_DISABLE too (Ben) move function below ivb version to pretend to be consistent (Ben) Reviewed-by: -
Jesse Barnes authored
ValleyView puts some display related registers like the PLL controls and dividers behind the DPIO bus. Add simple indirect register access routines to get to those registers. v2: move new wait_for macro to intel_drv.h (Ben) fix DPIO_PKT double write (Ben) add debugfs file Reviewed-by: -
Jesse Barnes authored
Add register definitions for the new VLV PLL bits. v2: remove unused bits & regs (Ben) Acked-by:
-
Jesse Barnes authored
Add support for ValleyView watermark handling. v2: remove unused reg & bit definitions (Ben) Acked-by:
-
Jesse Barnes authored
For use by the rest of the ValleyView code. v2: fix desktop variant to not set is_mobile (Ben) Acked-by:
-
Daniel Vetter authored
Makes it more readable and maintainable. ValleyView will add its own PLL update function in a later patch. v2: split LVDS bits out of this patch (Daniel) v3: fix dropped DP dithering hunk (Daniel) Acked-by:
-
Daniel Vetter authored
Just to make things clearer and reduce the size of this monstrosity. v2: make sure 8xx PLL update function calls update_lvds too (Daniel) Signed-off-by:
-
Chris Wilson authored
Fixes a regression from 9e984bc1 (drm/i915: Don't do MTRR setup if PAT is enabled) where we left the MTRR as 0 and so tried to free a MTRR we did not own during unload. Reported-and-tested-by:
Adam Jackson <ajax@redhat.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniel Kurtz authored
This memory is always allocated, and it is always a fixed size, so just allocate it along with the rest of the driver state. Signed-off-by:
Daniel Kurtz <djkurtz@chromium.org> Reviewed-by:
-
Daniel Kurtz authored
There is no GMBUS "disabled" port 0, nor "reserved" port 7. For the other 6 ports there is a fixed 1:1 mapping between pin pairs and gmbus ports, which means every real gmbus port has a gpio pin. Given these realizations, clean up gmbus initialization. Tested on Sandybridge (gen 6, PCH == CougarPoint) hardware. 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 authored
Instead of rolling our own custom quirk_xfer function, use the bit_algo pre_xfer and post_xfer functions to setup and teardown bit-banged i2c transactions. Signed-off-by:
-
Daniel Kurtz authored
According to i915 documentation [1], "Port D" (DP/HDMI Port D) is actually gmbus pin pair 6 (gmbus0.2:0 == 110b GPIOF), not 7 (111b). Pin pair 7 is a reserved pair. [1] Documentation for [DevSNB+] and [DevIBX], as found on http://intellinuxgraphics.org: [DevSNB+]: http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf Section 2.2.2 lists the 6 gmbus ports (gpio pin pairs): [ 5: HDMI/DPD, 4: HDMIB, 3: HDMI/DPC, 2: LVDS, 1: SSC, 0: VGA ] 2.2.2.1 lists the GPIO registers to control these 6 ports. 2.2.3.1 lists the mapping between 5 of these gmbus ports and the 3 Pin_Pair_Select bits (of the GMBUS0 register). This table is missing HDMIB (port 101). [DevIBX]: http://intellinuxgraphics.org/IHD_OS_Vol3_Part3r2.pdf Section 2.2.2 lists the same 6 gmbus ports plus two 'reserved' gpio ports. 2.2.2.1 lists 8 GPIO registers... however, it says the size of the block is 6x32, which implies that those 2 reserved GPIO registers (GPIO_6 & GPIO_7) don't actually exist (or are irrelevant). 2.2.3.1 lists the mapping between the 6 named gmbus ports and the 3 Pin_Pair_Select bits (of the GMBUS0 register). This table has HDMIB. Note: the "reserved" and "disabled" pairs do not actually map to a physical pair of pins, nor GPIO regs and shouldn't be initialized or used. Fixing this is left for a later patch. This bug had not been noticed earlier for two reasons: 1) Until recently, "gmbus" mode was disabled - all transfers actually used "bit-bang" mode on GPIO port 5 (the "HDMI/DPD CTLDATA/CLK" pair), at register 0x5024 (defined as GPIOF i915_reg.h). Since this is the correct pair of pins for HDMI1, transfers succeed. 2) Even if gmbus mode is re-enabled, the first attempted transaction will fail because it tries to use the wrong ("Reserved") pin pair. However, the driver immediately falls back again to the bit-bang method, which correctly uses GPIOF, so again, transfers succeed. However, if gmbus mode is re-enabled and the GPIO fall-back mode is disabled, then reading an attached monitor's EDID fail. Signed-off-by:
-
Daniel Kurtz authored
Signed-off-by:
-
Daniel Kurtz authored
Split out gmbus_xfer_read/write() helper functions. Signed-off-by:
-
- 27 Mar, 2012 2 commits
-
-
Daniel Vetter authored
Beside helping the compiler untangle this maze they double-up as documentation for which parts of the code aren't performance-critical but just around to keep old (but already dead-slow) userspace from breaking. Reviewed-by:
-
Daniel Vetter authored
The issue is that with inline clflushing the clflushing isn't properly swizzled. Fix this by - always clflushing entire 128 byte chunks and - unconditionally flush before writes when swizzling a given page. We could be clever and check whether we pwrite a partial 128 byte chunk instead of a partial cacheline, but I've figured that's not worth it. Now the usual approach is to fold this into the original patch series, but I've opted against this because - this fixes a corner case only very old userspace relies on and - I'd like to not invalidate all the testing the pwrite rewrite has gotten. This fixes the regression notice by tests/gem_tiled_partial_prite_pread from i-g-t. Unfortunately it doesn't fix the issues with partial pwrites to tiled buffers on bit17 swizzling machines. But that is also broken without the pwrite patches, so likely a different issue (or a problem with the testcase). v2: Simplify the patch by dropping the overly clever partial write logic for swizzled pages. Reviewed-by:
-
