1. 11 4月, 2014 1 次提交
  2. 06 3月, 2014 1 次提交
  3. 28 1月, 2014 1 次提交
    • J
      drm/i915: move module parameters into a struct, in a new file · d330a953
      Jani Nikula 提交于
      With 20+ module parameters, I think referring to them via a struct
      improves clarity over just having a bunch of globals. While at it, move
      the parameter initialization and definitions into a new file
      i915_params.c to reduce clutter in i915_drv.c.
      
      Apart from the ill-named i915_enable_rc6, i915_enable_fbc and
      i915_enable_ppgtt parameters, for which we lose the "i915_" prefix
      internally, the module parameters now look the same both on the kernel
      command line and in code. For example, "i915.modeset".
      
      The downsides of the change are losing static on a couple of variables
      and not having the initialization and module_param_named() right next to
      each other. On the other hand, all module parameters are now defined in
      one place at i915_params.c. Plus you can do this to find all module
      parameter references:
      
      $ git grep "i915\." -- drivers/gpu/drm/i915
      
      v2:
      - move the definitions into a new file
      - s/i915_params/i915/
      - make i915_try_reset i915.reset, for consistency
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d330a953
  4. 16 12月, 2013 1 次提交
  5. 12 12月, 2013 1 次提交
  6. 15 11月, 2013 1 次提交
  7. 05 11月, 2013 1 次提交
  8. 01 10月, 2013 6 次提交
    • D
      drm/i915: Rip out SUPPORTS_EDP · 6fca55b1
      Daniel Vetter 提交于
      It only controls the setting of the vbt.edp_support variable, which in
      turn only controls one debug output plus can also force-disable the
      lvds output.
      
      Since the value only restricted this logic to mobile ilk there's the
      slight risk that this will break lvds on desktop ilk or on snb/ivb
      platforms. But with the vbt it's better when we know what's going on
      here, so let's rip it out and see what happens.
      
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6fca55b1
    • P
      drm/i915: don't init DP or HDMI when not supported by DDI port · 311a2094
      Paulo Zanoni 提交于
      There's no reason to init a DP connector if the encoder just supports
      HDMI: we'll just waste hundreds and hundreds of cycles trying to do DP
      AUX transactions to detect if there's something there. Same goes for a
      DP connector that doesn't support HDMI, but I'm not sure these
      actually exist.
      
      v2: - Use bit fields
          - Remove useless identation level
          - Replace DRM_ERROR with DRM_DEBUG_KMS
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      311a2094
    • P
      drm/i915: add some assertions about VBT DDI port types · 554d6af5
      Paulo Zanoni 提交于
      Our code makes a lot of assumptions regarding what each DDI port
      actually supports, and the VBT should tell us what is really happening
      in the hardware. So parse the information provided by the VBT and
      check if any of our assumptions is wrong.
      
      Our driver also has a history of not really trusting the VBT, so a
      WARN here could mean that:
       a) our coding assumptions are wrong
       b) the VBT is wrong
       c) we're incorrectly parsing the VBT
       d) the checks are wrong
      
      But I really hope we won't ever trigger any of those WARNs.
      
      v2: Don't check the redundant "Capabilities" field from byte 24 since
          it doesn't seem to be used.
      v3: Rebase
      v4: Replace WARN with DRM_DEBUG_KMS
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v2)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      554d6af5
    • P
      drm/i915: check the DDC and AUX bits of the VBT on DDI machines · 6bf19e7c
      Paulo Zanoni 提交于
      Our code currently assumes that port X will use the DP AUX channel X
      and the DDC pin X. The VBT should tell us how things are mapped, so
      add some WARNs in case we discover our assumptions are wrong (or in
      case the VBT is just wrong, which is also perfectly possible).
      
      Why would someone wire port B to AUX C and DDC D?
      
      v2: Rebase
      v3: Convert WARNs to DRM_DEBUG_KMS
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> (v1)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6bf19e7c
    • P
      drm/i915: use the HDMI DDI buffer translations from VBT · 6acab15a
      Paulo Zanoni 提交于
      We currently use the recommended values from BSpec, but the VBT
      specifies the correct value to use for the hardware we have, so use
      it. We also fall back to the recommended value in case we can't find
      the VBT.
      
      In addition, this code also provides some infrastructure to parse more
      information about the DDI ports. There's a lot more information we
      could extract and use in the future.
      
      v2: - Move some code to init_vbt_defaults.
      v3: - Rebase
          - Clarify the "DVO Port" matching code
      v4: - Use I915_MAX_PORTS
          - Change the HAS_DDI checks
          - Replace DRM_ERROR with DRM_DEBUG_KMS
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6acab15a
    • P
      drm/i915: VBT's child_device_config changes over time · 768f69c9
      Paulo Zanoni 提交于
      We currently treat the child_device_config as a simple struct, but
      this is not correct: new BDB versions change the meaning of some
      offsets, so the struct needs to be adjusted for each version.
      
      Since there are too many changes (today we're in version 170!), making
      a big versioned union would be too complicated, so child_device_config
      is now a union of 3 things: (i) a "raw" byte array that's safe to use
      anywhere; (ii)  an "old" structure that's the one we've been using and
      should be safe to keep in the SDVO and TV code; and (iii) a "common"
      structure that should contain only fields that are common for all the
      known VBT versions.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      768f69c9
  9. 04 9月, 2013 1 次提交
  10. 11 5月, 2013 1 次提交
  11. 18 4月, 2013 1 次提交
  12. 09 4月, 2013 1 次提交
    • B
      drm/i915: Don't touch South Display when PCH_NOP · ab5c608b
      Ben Widawsky 提交于
      Interrupts, clock gating, LVDS, and GMBUS are all within the, "this will
      be bad for CPU" range when we have PCH_NOP.
      
      There is a bit of a hack in init clock gating. We want to do most of the
      clock gating, but the part we skip will hang the system. It could
      probably be abstracted a bit better, but I don't feel it's too
      unsightly.
      
      v2: Use inverse HAS_PCH_NOP check (Jani)
      
      v3: Actually do what I claimed in v2 (spotted by Daniel)
      Merge Ivybridge IRQ handler PCH check to decrease whitespace (Daniel)
      Move LVDS bail into this patch (Ben)
      
      v4: logical rebase conflict resolution with SDEIIR (Ben)
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      
      Brush up patch a bit and resolve conflicts:
      - Adjust PCH_NOP checks due to Egbert's hpd handling rework.
      - Addd a PCH_NOP check in the irq uninstall code.
      - Resolve conflicts with Paulo's SDE irq handling race fix.
      
      v5: Drop the added hunks in the ilk irq handler again, they're bogus.
      OOps.
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ab5c608b
  13. 23 11月, 2012 1 次提交
    • J
      drm/i915: do not default to 18 bpp for eDP if missing from VBT · 9a30a61f
      Jani Nikula 提交于
      commit 500a8cc4
      Author: Zhenyu Wang <zhenyuw@linux.intel.com>
      Date:   Wed Jan 13 11:19:52 2010 +0800
      
          drm/i915: parse eDP panel color depth from VBT block
      
      originally introduced parsing bpp for eDP from VBT, with a default of 18
      bpp if the eDP BIOS data block is not present. Turns out that default seems
      to break the Macbook Pro with retina display, as noted in
      
      commit 4344b813
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Fri Aug 10 11:10:20 2012 +0200
      
          drm/i915: ignore eDP bpc settings from vbt
      
      Since we can't ignore bpc settings from VBT completely after all, get rid
      of the default. Do not clamp eDP to 18 bpp by default if the eDP BDB is
      missing from VBT.
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Tested-by: NHenrik Rydberg <rydberg@euromail.se>
      [danvet: paste in the updated commit message from irc.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      9a30a61f
  14. 22 11月, 2012 1 次提交
  15. 03 10月, 2012 2 次提交
  16. 27 6月, 2012 1 次提交
  17. 01 4月, 2012 1 次提交
  18. 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
  19. 23 3月, 2012 1 次提交
  20. 02 3月, 2012 1 次提交
  21. 27 2月, 2012 1 次提交
  22. 18 1月, 2012 1 次提交
  23. 21 10月, 2011 1 次提交
  24. 28 9月, 2011 2 次提交
  25. 27 9月, 2011 1 次提交
  26. 20 9月, 2011 1 次提交
  27. 14 7月, 2011 1 次提交
    • C
      drm/i915/bios: Avoid temporary allocation whilst searching for downclock · 99834ea4
      Chris Wilson 提交于
      Alan Cox reported a missing check on the kmalloc return value for the
      allocation of a temporary mode used for searching for the LVDS downlock
      frequency. This allocation is roughly 200 bytes, a little too large to
      friviously place on the stack. However, we can simply use the few bytes
      we need stored within the original DVO timing data, skip the translation
      and do the compare directly between the timing data rather than on a
      mode, thus avoiding the need for any temporary allocations.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
      Cc: Keith Packard <keithp@keithp.com>
      Signed-off-by: NKeith Packard <keithp@keithp.com>
      99834ea4
  28. 28 4月, 2011 1 次提交
  29. 22 2月, 2011 1 次提交
  30. 01 2月, 2011 1 次提交
  31. 19 1月, 2011 2 次提交
  32. 14 1月, 2011 1 次提交