An error occurred fetching the project authors.
  1. 30 Mar, 2017 2 commits
  2. 14 Mar, 2017 1 commit
  3. 08 Mar, 2017 1 commit
  4. 16 Feb, 2017 1 commit
  5. 15 Feb, 2017 1 commit
  6. 17 Nov, 2016 2 commits
  7. 14 Sep, 2016 2 commits
  8. 14 Jul, 2016 2 commits
  9. 07 Jul, 2016 1 commit
  10. 05 Jul, 2016 1 commit
  11. 29 Jun, 2016 3 commits
  12. 23 May, 2016 2 commits
  13. 09 May, 2016 1 commit
    • Tvrtko Ursulin's avatar
      drm/i915: Small display interrupt handlers tidy · 91d14251
      Tvrtko Ursulin authored
      I have noticed some of our interrupt handlers use both dev and
      dev_priv while they could get away with only dev_priv in the
      huge majority of cases.
      
      Tidying that up had a cascading effect on changing functions
      prototypes, so relatively big churn factor, but I think it is
      for the better.
      
      For example even where changes cascade out of i915_irq.c, for
      functions prefixed with intel_, genX_ or <plat>_, it makes more
      sense to take dev_priv directly anyway.
      
      This allows us to eliminate local variables and intermixed usage
      of dev and dev_priv where only one is good enough.
      
      End result is shrinkage of both source and the resulting binary.
      
      i915.ko:
      
       - .text         000b0899
       + .text         000b0619
      
      Or if we look at the Gen8 display irq chain:
      
       -00000000000006ad t gen8_irq_handler
       +0000000000000663 t gen8_irq_handler
         -0000000000000028 T intel_opregion_asle_intr
         +0000000000000024 T intel_opregion_asle_intr
         -000000000000008c t ilk_hpd_irq_handler
         +000000000000007f t ilk_hpd_irq_handler
         -0000000000000116 T intel_check_page_flip
         +0000000000000112 T intel_check_page_flip
         -000000000000011a T intel_prepare_page_flip
         +0000000000000119 T intel_prepare_page_flip
         -0000000000000014 T intel_finish_page_flip_plane
         +0000000000000013 T intel_finish_page_flip_plane
         -0000000000000053 t hsw_pipe_crc_irq_handler
         +000000000000004c t hsw_pipe_crc_irq_handler
         -000000000000022e t cpt_irq_handler
         +0000000000000213 t cpt_irq_handler
      
      So small shrinkage but it is all fast paths so doesn't harm.
      
      Situation is similar in other interrupt handlers as well.
      
      v2: Tidy intel_queue_rps_boost_for_request as well. (Chris Wilson)
      Signed-off-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      91d14251
  14. 19 Apr, 2016 1 commit
    • Joonas Lahtinen's avatar
      drm/i915: Clean up PCI config register handling · e10fa551
      Joonas Lahtinen authored
      Do not use magic numbers, do not prefix stuff with "PCI_", do not
      declare registers in implementation files. Also move the PCI
      registers under correct comment in i915_reg.h.
      
      v2:
      - Consistently use BSM (not BDSM or other variants from PRM) (Chris)
      - Also include register address to help identify the register (Chris)
      v3:
      - Refer to register value as *_val instead of *_reg (Chris)
      v4:
      - Make style checker happy
      
      Cc: Jani Nikula <jani.nikula@intel.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      e10fa551
  15. 13 Apr, 2016 1 commit
  16. 12 Apr, 2016 1 commit
    • Ville Syrjälä's avatar
      drm/i915: Get panel_type from OpRegion panel details · a0562819
      Ville Syrjälä authored
      We've had problems on several occasions with using the panel type
      from the VBT block 40. Usually it seems to be 2, which often
      doesn't give us the correct timings for the panel. After some
      more digging I found a way to get a panel type via the OpRegion
      SWSCI GBDA "Get Panel Details" method. Let's try to use it.
      
      The spec has this to say about the output:
      "Bits [15:8] - Panel Type
       Bits contain the panel type user setting from CMOS
       00h = Not Valid, use default Panel Type & Timings from VBT
       01h - 0Fh = Panel Number"
      
      Another version of the spec lists the valid range as 1-16, which makes
      more sense since VBT supports 16 panels. Based on actual results
      from Rob's G45, 1-16 is what we need to accept.
      
      The other bits in the output don't look relevant for the problem at
      hand.
      
      The input is specified as:
      "Bits [31:4] - Reserved
       Reserved (must be zero)
       Bits [3:0] - Panel Number
       These bits contain the sequential index of Panel, starting at 0 and
       counting upwards from the first integrated Internal Flat-Panel Display
       Encoder present, and then from the first external Display Encoder
       (e.g., S/DVO-B then S/DVO-C) which supports Internal Flat-Panels.
       0h - 0Fh = Panel number"
      
      For now I've just hardcoded the input panel number as 0. That would seem
      like a decent choise for LVDS. Not so sure about eDP when port != A.
      
      v2: Accept values 1-16
          Filter out bogus results in opregion code (Jani)
          Add debug logging for all the different branches (Jani)
      
      Cc: Jani Nikula <jani.nikula@linux.intel.com>
      Cc: Rob Kramer <rob@solution-space.com>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825Signed-off-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/1460359431-11003-1-git-send-email-ville.syrjala@linux.intel.comReviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Tested-by: default avatarRob Kramer <rob@solution-space.com>
      a0562819
  17. 17 Dec, 2015 1 commit
  18. 16 Dec, 2015 7 commits
  19. 11 Dec, 2015 1 commit
  20. 31 Oct, 2015 1 commit
  21. 13 Oct, 2015 1 commit
  22. 02 Oct, 2015 1 commit
    • Shashank Sharma's avatar
      drm/i915/bxt: DSI encoder support in CRTC modeset · 7d4aefd0
      Shashank Sharma authored
      SKL and BXT qualifies the HAS_DDI() check, and hence haswell
      modeset functions are re-used for modeset sequence. But DDI
      interface doesn't include support for DSI.
      This patch adds:
      1. cases for DSI encoder, in those modeset functions and allows
         a CRTC modeset
      2. Adds call to pre_pll enabled from CRTC modeset function. Nothing
         needs to be done as such in CRTC for DSI encoder, as PLL, clock
         and and transcoder programming will be taken care in encoder's
         pre_enable and pre_pll_enable function.
      
      v2: Fixed Jani's review comments. Added INVALID_PORT for non DDI
          encoder like DSI for platforms having HAS_DDI as true.
      
      v3: Rebased on latest drm-nightly branch. Added a WARN_ON for invalid
          encoder.
      
      v4: WARN_ON for invalid encoder is refactored as per Jani's suggestion.
          Fixed the sequence for pre_pll_enable.
      
      v5: Protected DDI code paths in case of DSI encoder calls.
      Signed-off-by: default avatarShashank Sharma <shashank.sharma@intel.com>
      Signed-off-by: default avatarUma Shankar <uma.shankar@intel.com>
      Reviewed-by: default avatarJani Nikula <jani.nikula@intel.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      7d4aefd0
  23. 06 Jul, 2015 5 commits