1. 06 9月, 2012 4 次提交
  2. 26 7月, 2012 1 次提交
    • D
      drm/i915: simplify possible_clones computation · 66a9278e
      Daniel Vetter 提交于
      Intel hw only has one MUX for encoders, so outputs are either not
      cloneable or all in the same group of cloneable outputs. This neatly
      simplifies the code and allows us to ditch some ugly if cascades in
      the dp and hdmi init code (well, we need these if cascades for other
      stuff still, but that can be taken care of in follow-up patches).
      
      Note that this changes two things:
      - dvo can now be cloned with sdvo, but dvo is gen2 whereas sdvo is
        gen3+, so no problem. Note that the old code had a bug and didn't
        allow cloning crt with dvo (but only the other way round).
      - sdvo-lvds can now be cloned with sdvo-non-tv. Spec says this won't
        work, but the only reason I've found is that you can't use the
        panel-fitter (used for lvds upscaling) with anything else. But we
        don't use the panel fitter for sdvo-lvds. Imo this part of Bspec is
        a) rather confusing b) mostly as a guideline to implementors (i.e.
        explicitly stating what is already implicit from the spec, without
        always going into the details of why). So I think we can ignore this
        - worst case we'll get a bug report from a user with with sdvo-lvds
        and sdvo-tmds and have to add that special case back in.
      
      Because sdvo lvds is a bit special explain in comments why sdvo LVDS
      outputs can be cloned, but native LVDS and eDP can't be cloned - we
      use the panel fitter for the later, but not for sdvo.
      
      Note that this also uncoditionally initializes the panel_vdd work used
      by eDP. Trying to be clever doesn't buy us anything (but strange bugs)
      and this way we can kill the is_edp check.
      
      v2: Incorporate review from Paulo
      - Add in a missing space.
      - Pimp comment message to address his concerns.
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      66a9278e
  3. 25 7月, 2012 1 次提交
    • D
      drm/i915/lvds: ditch ->prepare special case · 520c41cf
      Daniel Vetter 提交于
      LVDS is the first output where dpms on/off and prepare/commit don't
      perfectly match. Now the idea behind this special case seems to be
      that for simple resolution changes on the LVDS we don't need to stop
      the pipe, because (at least on newer chips) we can adjust the panel
      fitter on the fly.
      
      There are a few problems with the current code though:
      - We still stop and restart the pipe unconditionally, because the crtc
        helper code isn't flexible enough.
      - We show some ugly flickering, especially when changing crtcs (this
        the crtc helper would actually take into account, but we don't
        implement the encoder->get_crtc callback required to make this work
        properly).
      
      So it doesn't even work as advertised. I agree that it would be nice
      to do resolution changes on LVDS (and also eDP) whithout blacking the
      screen where the panel fitter allows to do that. But imo we should
      implement this as a special case a few layers up in the mode set code,
      akin to how we already detect simple framebuffer changes (and only
      update the required registers with ->mode_set_base).
      
      Until this is all in place, make our lives easier and just rip it out.
      
      Also note that this seems to fix actual bugs with enabling the lvds
      output, see:
      
      http://lists.freedesktop.org/archives/intel-gfx/2012-July/018614.html
      
      Cc: Takashi Iwai <tiwai@suse.de>
      Cc: Giacomo Comes <comes@naic.edu>
      Acked-by: NChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: NTakashi Iwai <tiwai@suse.de>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      520c41cf
  4. 20 7月, 2012 1 次提交
  5. 05 7月, 2012 1 次提交
  6. 22 6月, 2012 1 次提交
  7. 13 6月, 2012 3 次提交
    • D
      drm/i915: allow pipe A for lvds on gen4 · 0b9f43a0
      Daniel Vetter 提交于
      Given the havoc the missing backlight pipe select code might have
      caused, let's try to re-enabled pipe A support for lvds on gen4 hw.
      Just to see what all blows up ...
      
      Note though that
      
      commit 4add75c4
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Sat Dec 4 17:49:46 2010 +0000
      
          drm/i915: Allow LVDS to be on pipe A for Ironlake+
      
      claims that this caused tons of spurious wakeups somehow.
      
      More details can be found in the old revert:
      
      commit 12e8ba25
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Sep 7 23:39:28 2010 +0100
      
          Revert "drm/i915: Allow LVDS on pipe A on gen4+"
      
          Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=16307Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0b9f43a0
    • D
      drm/i915: properly enable the blc controller on the right pipe · 24ded204
      Daniel Vetter 提交于
      On gen4+ we have a bitfield to specify from which pipe the backlight
      controller should take it's clock. For PCH split platforms we've
      already set these up, but only at initialization time. And without
      taking into account the 3rd pipe added with ivb.
      
      For gen4, we've completely ignored these. Although we do restrict lvds
      to the 2nd pipe, so this is only a problem on machines where we boot
      up with the lvds on the first pipe.
      
      So restructure the code to enable the backlight on the right pipe at
      modeset time.
      
      v2: For odd reasons panel_enable_backlight gets called twice in a
      modeset, so we can't WARN_ON in there if the backlight controller is
      switched on already.
      
      v3: backlight enable can also be called through dpms on, so the check
      in there is legit. Update the comment to reflect that.
      Tested-By: NKamal Mostafa <kamal@canonical.com>
      Bugzilla: https://bugs.launchpad.net/bugs/954661
      Cc: Carsten Emde <C.Emde@osadl.org>
      Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      24ded204
    • D
      drm/i915: clear up backlight #define confusion on gen4+ · 7cf41601
      Daniel Vetter 提交于
      - Regroup definitions for BLC_PWM_CTL so that they're all together and
        and ordered according to the bitfields.
      
      - Add all missing definitions for BLC_PWM_CTL2.
      
      - Use the BLM_ (for backlight modulation) prefix consistently.
      
      - Note that combination mode (i.e. also taking the legacy backlight
        control value from pci config space into account) is gen4 only.
      
      - Move the new registers for PCH-split machines up, they're an almost
        match for the gen4 defitions.  Prefix the special PCH-only bits with
        BLM_PCH_. Also add the pipe C select bit for ivb.
      
      - Rip out the second pair of PCH polarity definitions - they're only
        valid on early (pre-production) ilk silicon.
      
      - Adapt the existing code to use the new definitions. This has the
        nice benefit of killing a magic (1 << 30) left behind be Jesse
        Barnes.
      
      No functional changes in this patch.
      Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      7cf41601
  8. 24 5月, 2012 1 次提交
  9. 03 5月, 2012 1 次提交
  10. 16 4月, 2012 1 次提交
  11. 10 4月, 2012 1 次提交
  12. 03 4月, 2012 1 次提交
  13. 28 3月, 2012 1 次提交
    • D
      drm/i915/intel_i2c: refactor using intel_gmbus_get_adapter · 3bd7d909
      Daniel Kurtz 提交于
      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: NDaniel Kurtz <djkurtz@chromium.org>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3bd7d909
  14. 27 2月, 2012 1 次提交
  15. 15 2月, 2012 1 次提交
  16. 09 2月, 2012 1 次提交
  17. 13 1月, 2012 1 次提交
  18. 17 12月, 2011 1 次提交
  19. 21 10月, 2011 1 次提交
  20. 16 8月, 2011 1 次提交
  21. 09 8月, 2011 2 次提交
  22. 30 7月, 2011 1 次提交
  23. 05 6月, 2011 1 次提交
  24. 10 5月, 2011 1 次提交
  25. 06 4月, 2011 1 次提交
  26. 25 3月, 2011 1 次提交
  27. 16 2月, 2011 1 次提交
  28. 08 2月, 2011 1 次提交
  29. 06 2月, 2011 1 次提交
  30. 19 1月, 2011 2 次提交
  31. 15 1月, 2011 1 次提交
  32. 12 1月, 2011 2 次提交