1. 03 12月, 2014 2 次提交
  2. 01 10月, 2014 1 次提交
  3. 08 8月, 2014 2 次提交
  4. 07 8月, 2014 2 次提交
  5. 09 7月, 2014 1 次提交
  6. 19 6月, 2014 1 次提交
  7. 14 6月, 2014 1 次提交
  8. 11 6月, 2014 1 次提交
  9. 05 6月, 2014 3 次提交
    • I
      drm/i915: dsi: fix pipe-off timeout due to port vs. pipe disable ordering · c315faf8
      Imre Deak 提交于
      If we disable first the port (by disabling DPI) and only then the
      display pipe the pipe-off flag will never be set, possibly leading to a
      hanged pipe state at the next modeset-enable.
      
      Note that according to the VLV2 display cluster HAS, we should disable
      the port before the pipe. This doesn't seem to match reality based on
      the above and it's also asymmetric with the enabling sequence, where we
      first enable the port and then the pipe.
      
      v2:
      - send the panel shutdown command before stopping the pipe, since this
        is the recommended sequence (Shobhit)
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NShobhit Kumar <shobhit.kumar@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      c315faf8
    • S
      drm/i915: Detect if MIPI panel based on VBT and initialize only if present · 3e6bd011
      Shobhit Kumar 提交于
      It seems by default the VBT has MIPI configuration block as well. The
      Generic driver will assume always MIPI if MIPI configuration block is found.
      This is causing probelm when actually there is eDP. Fix this by looking
      into general definition block which will have device configurations. From here
      we can figure out what is the LFP type and initialize MIPI only if MIPI
      is found.
      
      v2: Addressed review comments by Damien
          - Moved PORT definitions to intel_bios.h and renamed as DVO_PORT_MIPIA
          - renamed is_mipi to has_mipi and moved definition as suggested
          - Check has_mipi inside parse_mipi and intel_dsi_init insted of outside
      
      v3: Make has_mipi as a bitfield as suggested
      Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      [danvet: fold in conditions to pack everything neatly below 80 chars.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3e6bd011
    • S
      drm/i915: Add support for Generic MIPI panel driver · 2ab8b458
      Shobhit Kumar 提交于
      This driver makes use of the generic panel information from the VBT.
      Panel information is classified into two - panel configuration and panel
      power sequence which is unique to each panel. The generic driver uses the
      panel configuration and sequence parsed from VBT block #52 and #53
      
      v2: Address review comments by Jani
          - Move all of the things in driver c file from header
          - Make all functions static
          - Make use of video/mipi_display.c instead of redefining
          - Null checks during sequence execution
      
      v3: Address review comments by Damien
          - Rename the panel driver file as intel_dsi_panel_vbt.c
          - Fix style changes as suggested
          - Correct comments for lp->hs and hs->lp count calculations
          - General updating comments to have more clarity
          - using max() instead of ternary operator
          - Fix names (ui_num, ui_den) while using UI in calculations
          - compute max of lp_to_hs switch and hs_to_lp switch while computing
            hs_lp_switch_count
      Signed-off-by: NShobhit Kumar <shobhit.kumar@intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      2ab8b458
  10. 19 5月, 2014 1 次提交
  11. 16 5月, 2014 4 次提交
  12. 10 4月, 2014 7 次提交
  13. 11 3月, 2014 1 次提交
    • V
      drm/i915: Make encoder cloning more flexible · bc079e8b
      Ville Syrjälä 提交于
      Currently we allow encoders to indicate whether they can be part of a
      cloned set with just one flag. That's not flexible enough to describe
      the actual hardware capabilities. Instead make it a bitmask of encoder
      types with which the current encoder can be cloned.
      
      For now we set the bitmask to allow DVO+DVO and DVO+VGA, which should
      match what the old boolean flag allowed. We will add some more cloning
      options in the future.
      
      Note that this patch also removes the encoder.possible_clones setting
      from encoder setup code - we compute this dynamically.
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: NRodrigo Vivi <rodrigo.vivi@gmail.com>
      [danvet: Add Ville's explanation why removing the encoder
      possible_clones is save.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      bc079e8b
  14. 08 3月, 2014 2 次提交
  15. 14 2月, 2014 1 次提交
    • I
      drm/i915: add unregister callback to connector · 4932e2c3
      Imre Deak 提交于
      Since
      
      commit d9255d57
      Author: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Date:   Thu Sep 26 20:05:59 2013 -0300
      
      it became clear that we need to separate the unload sequence into two
      parts:
      
      1. remove all interfaces through which new operations on some object
         (crtc, encoder, connector) can be started and make sure all pending
         operations are completed
      2. do the actual tear down of the internal representation of the above
         objects
      
      The above commit achieved this separation for connectors by splitting
      out the sysfs removal part from the connector's destroy callback and
      doing this removal before calling drm_mode_config_cleanup() which does
      the actual tear-down of all the drm objects.
      
      Since we'll have to customize the interface removal part for different
      types of connectors in the upcoming patches, add a new unregister
      callback and move the interface removal part to it.
      
      No functional change.
      Signed-off-by: NImre Deak <imre.deak@intel.com>
      Reviewed-by: NAntti Koskipää <antti.koskipaa@linux.intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      4932e2c3
  16. 13 2月, 2014 1 次提交
  17. 12 12月, 2013 5 次提交
  18. 28 11月, 2013 1 次提交
  19. 17 10月, 2013 1 次提交
  20. 01 10月, 2013 1 次提交
    • P
      drm/i915: destroy connector sysfs files earlier · d9255d57
      Paulo Zanoni 提交于
      For some reason, every single time I try to run module_reload
      something tries to read the connector sysfs files. This happens
      after we destroy the encoders and before we destroy the connectors, so
      when the sysfs read triggers the connector detect() function,
      intel_conector->encoder points to memory that was already freed.
      
      The bad backtrace is just:
          [<ffffffff8163ca9a>] dump_stack+0x54/0x74
          [<ffffffffa00c2c8e>] intel_dp_detect+0x1e/0x4b0 [i915]
          [<ffffffffa001913d>] status_show+0x3d/0x80 [drm]
          [<ffffffff813d5340>] dev_attr_show+0x20/0x60
          [<ffffffff81221f50>] ? sysfs_read_file+0x80/0x1b0
          [<ffffffff81221f79>] sysfs_read_file+0xa9/0x1b0
          [<ffffffff811aaf1e>] vfs_read+0x9e/0x170
          [<ffffffff811aba4c>] SyS_read+0x4c/0xa0
          [<ffffffff8164e392>] system_call_fastpath+0x16/0x1b
      
      But if you add tons of memory checking debug options to your Kernel
      you'll also see:
       - general protection fault: 0000
       - BUG kmalloc-4096 (Tainted: G      D W   ): Poison overwritten
       - INFO: Allocated in intel_ddi_init+0x65/0x270 [i915]
       - INFO: Freed in intel_dp_encoder_destroy+0x69/0xb0 [i915]
      Among a bunch of other error messages.
      
      So this commit just destroys the sysfs files before both the encoder
      and connectors are freed.
      Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d9255d57
  21. 04 9月, 2013 1 次提交