• D
    drm/i915/intel_i2c: assign HDMI port D to pin pair 6 · e4fd17af
    Daniel Kurtz 提交于
    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: NDaniel Kurtz <djkurtz@chromium.org>
    Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
    Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
    e4fd17af
intel_i2c.c 11.4 KB