• Daniel Vetter's avatar
    drm/i915: use the gmbus irq for waits · 28c70f16
    Daniel Vetter authored
    We need two special things to properly wire this up:
    - Add another argument to gmbus_wait_hw_status to pass in the
      correct interrupt bit in gmbus4.
    - Since we can only get an irq for one of the two events we want,
      hand-roll the wait_event_timeout code so that we wake up every
      jiffie and can check for NAKs. This way we also subsume gmbus
      support for platforms without interrupts (or where those are not
      yet enabled).
    
    The important bit really is to only enable one gmbus interrupt source
    at the same time - with that piece of lore figured out, this seems to
    work flawlessly.
    
    Ben Widawsky rightfully complained the lack of measurements for the
    claimed benefits (especially since the first version was actually
    broken and fell back to bit-banging). Previously reading the 256 byte
    hdmi EDID takes about 72 ms here. With this patch it's down to 33 ms.
    Given that transfering the 256 bytes over i2c at wire speed takes
    20.5ms alone, the reduction in additional overhead is rather nice.
    
    v2: Chris Wilson wondered whether GMBUS4 might contain some set bits
    when booting up an hence result in some spurious interrupts. Since we
    clear GMBUS4 after every wait and we do gmbus transfer really early in
    the setup sequence to detect displays the window is small, but still
    be paranoid and clear it properly.
    
    v3: Clarify the comment that gmbus irq generation can only support one
    kind of event, why it bothers us and how we work around that limit.
    
    Cc: Daniel Kurtz <djkurtz@chromium.org>
    Reviewed-by: default avatarImre Deak <imre.deak@intel.com>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
    28c70f16
intel_i2c.c 14.9 KB