1. 09 6月, 2016 1 次提交
  2. 04 6月, 2016 1 次提交
  3. 30 5月, 2016 1 次提交
  4. 25 5月, 2016 1 次提交
  5. 23 5月, 2016 1 次提交
    • V
      drm: Add helper for DP++ adaptors · b3daa5ef
      Ville Syrjälä 提交于
      Add a helper which aids in the identification of DP dual mode
      (aka. DP++) adaptors. There are several types of adaptors
      specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
      
      Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
      may go as high as 300MHz and they provide a register informing the
      source device what the actual limit is. Supposedly also type 1 adaptors
      may optionally implement this register. This TMDS clock limit is the
      main reason why we need to identify these adaptors.
      
      Type 1 adaptors provide access to their internal registers and the sink
      DDC bus through I2C. Type 2 adaptors provide this access both via I2C
      and I2C-over-AUX. A type 2 source device may choose to implement either
      of these methods. If a source device implements the I2C-over-AUX
      method, then the driver will obviously need specific support for such
      adaptors since the port is driven like an HDMI port, but DDC
      communication happes over the AUX channel.
      
      This helper should be enough to identify the adaptor type (some
      type 1 DVI adaptors may be a slight exception) and the maximum TMDS
      clock limit. Another feature that may be available is control over
      the TMDS output buffers on the adaptor, possibly allowing for some
      power saving when the TMDS link is down.
      
      Other user controllable features that may be available in the adaptors
      are downstream i2c bus speed control when using i2c-over-aux, and
      some control over the CEC pin. I chose not to provide any helper
      functions for those since I have no use for them in i915 at this time.
      The rest of the registers in the adaptor are mostly just information,
      eg. IEEE OUI, hardware and firmware revision, etc.
      
      v2: Pass adaptor type to helper functions to ease driver implementation
          Fix a bunch of typoes (Paulo)
          Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know
          the type (Paulo)
          Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
          Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
          ease future LSPCON enabling
          Remove the unused DP_DUAL_MODE_LAST_RESERVED define
      v3: Fix kernel doc function argument descriptions (Jani)
          s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
          Add kernel doc for enum drm_dp_dual_mode_type
          Actually build the docs
          Fix more typoes
      v4: Adjust code indentation of type2 adaptor detection (Shashank)
          Add debug messages for failurs cases (Shashank)
      v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo)
      
      Cc: stable@vger.kernel.org
      Cc: Tore Anderson <tore@fud.no>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4)
      Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
      (cherry picked from commit ede53344)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      b3daa5ef
  6. 12 5月, 2016 1 次提交
  7. 09 5月, 2016 1 次提交
    • V
      drm: Add helper for DP++ adaptors · ede53344
      Ville Syrjälä 提交于
      Add a helper which aids in the identification of DP dual mode
      (aka. DP++) adaptors. There are several types of adaptors
      specified: type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
      
      Type 1 adaptors have a max TMDS clock limit of 165MHz, type 2 adaptors
      may go as high as 300MHz and they provide a register informing the
      source device what the actual limit is. Supposedly also type 1 adaptors
      may optionally implement this register. This TMDS clock limit is the
      main reason why we need to identify these adaptors.
      
      Type 1 adaptors provide access to their internal registers and the sink
      DDC bus through I2C. Type 2 adaptors provide this access both via I2C
      and I2C-over-AUX. A type 2 source device may choose to implement either
      of these methods. If a source device implements the I2C-over-AUX
      method, then the driver will obviously need specific support for such
      adaptors since the port is driven like an HDMI port, but DDC
      communication happes over the AUX channel.
      
      This helper should be enough to identify the adaptor type (some
      type 1 DVI adaptors may be a slight exception) and the maximum TMDS
      clock limit. Another feature that may be available is control over
      the TMDS output buffers on the adaptor, possibly allowing for some
      power saving when the TMDS link is down.
      
      Other user controllable features that may be available in the adaptors
      are downstream i2c bus speed control when using i2c-over-aux, and
      some control over the CEC pin. I chose not to provide any helper
      functions for those since I have no use for them in i915 at this time.
      The rest of the registers in the adaptor are mostly just information,
      eg. IEEE OUI, hardware and firmware revision, etc.
      
      v2: Pass adaptor type to helper functions to ease driver implementation
          Fix a bunch of typoes (Paulo)
          Add DRM_DP_DUAL_MODE_UNKNOWN for the case where we don't (yet) know
          the type (Paulo)
          Reject 0x00 and 0xff DP_DUAL_MODE_MAX_TMDS_CLOCK values (Paulo)
          Adjust drm_dp_dual_mode_detect() type2 vs. type1 detection to
          ease future LSPCON enabling
          Remove the unused DP_DUAL_MODE_LAST_RESERVED define
      v3: Fix kernel doc function argument descriptions (Jani)
          s/NONE/UNKNOWN/ in drm_dp_dual_mode_detect() docs
          Add kernel doc for enum drm_dp_dual_mode_type
          Actually build the docs
          Fix more typoes
      v4: Adjust code indentation of type2 adaptor detection (Shashank)
          Add debug messages for failurs cases (Shashank)
      v5: EXPORT_SYMBOL(drm_dp_dual_mode_read) (Paulo)
      
      Cc: stable@vger.kernel.org
      Cc: Tore Anderson <tore@fud.no>
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Shashank Sharma <shashank.sharma@intel.com>
      Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> (v4)
      Link: http://patchwork.freedesktop.org/patch/msgid/1462542412-25533-1-git-send-email-ville.syrjala@linux.intel.com
      ede53344
  8. 06 5月, 2016 1 次提交
  9. 03 5月, 2016 1 次提交
  10. 22 3月, 2016 1 次提交
  11. 17 3月, 2016 1 次提交
  12. 08 3月, 2016 1 次提交
  13. 09 2月, 2016 2 次提交
  14. 25 1月, 2016 1 次提交
  15. 11 1月, 2016 1 次提交
    • L
      apple-gmux: Add initial documentation · 3d7b75fd
      Lukas Wunner 提交于
      Document what I've learned so far about the gmux so that we can
      collaboratively reverse-engineer its remaining unknown bits
      without everyone having to start from scratch.
      
      The DOC sections are bound together in the gpu.tmpl DocBook
      under a new vga_switcheroo "Handlers" chapter. Eventually
      this should be amended with documentation about the four other
      handlers that exist so far (nouveau v1 DSM, nouveau Optimus DSM,
      radeon ATPX, amdgpu ATPX).
      
      Requires kernel-doc with asciidoc support.
      
      The EFI variable was reverse-engineered by Bruno Bierbaumer
      <bruno@bierbaumer.net> and Andreas Heider <andreas@meetr.de>.
      
      Some of the remaining open questions:
      
      * How are vblank intervals synchronized on retinas to achieve seamless
        switching? Is the DP mux capable of this? It's not mentioned in the
        data sheets. Or is it done at the OS level, i.e. do we have to
        synchronize vblank intervals between DRM drivers? There's a signal
        coming from the panel connector and going into gmux, could this be
        the vblank signal as received by the panel to properly time the
        switch?
      
      * On retinas there's an I2C bus between gmux and the connector of the
        right I/O board, apparently leading to the Parade PS8401A HDMI
        repeater. What is this for, is it controlled via gmux registers?
        Data sheet:
        http://www.paradetech.com/products/jitter-cleaning-repeaters/ps8401/
      
      * On retinas there's an I2C bus between gmux and the LED driver.
        Pre-retinas connected the LED driver to SMBUS. Are there additional
        gmux registers on retinas to control it?
      
      * The MacPro6,1 2013 also has a gmux, the same Renesas R4F2113 as the
        retina MacBook Pro. The Mac Pro doesn't have a built-in display,
        so what is its purpose? Power control of the dual FirePro GPUs?
        Switching of the external DP/Thunderbolt ports? The iFixit teardown
        clearly shows one TI HD3SS212 DisplayPort mux on the logic board next
        to one of the three Thunderbolt controllers. However six muxes would
        be necessary to switch all six ports between GPUs. The mux is probably
        necessary for one of the display configurations allowed by Apple,
        but which one?
        https://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778
        https://d3nevzfk7ii3be.cloudfront.net/igi/fELBTnt31QhnDsqq.huge
        https://support.apple.com/en-us/HT202801
      
      * Registers we haven't decoded yet:
        0x700 32 Bit configmap?
        0x708 32 Bit power sequence?
        0x712  8 Bit status of clock from panel on retinas?
        0x713  8 Bit dito?
        0x724 16 Bit backlight, raw value?
        0x760 32 Bit backlight
        0x764 32 Bit backlight
        0x768  8 Bit backlight
        0x76a 16 Bit backlight
        0x76c 16 Bit backlight
        0x76e 16 Bit backlight
        0x77f        edp/dp/hdmi probe? retina only.
      
      * Addition by Bruno Prémont <bonbons@linux-vserver.org>:
        "Missing is also precise knowledge as to what the gmux depends on.
        From behavioral reports, it is somehow sensitive to VGA IO/MEM
        routing (it apparently needs the routing to go to integrated GPU,
        not discrete GPU).
        When the routing is inappropriate backlight control IO just reads back
        as 0xFF (and eventually gmux IO in general does so)."
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Acked-by: NDarren Hart <dvhart@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/da309e436fbeac886477d80376457b7d83ea4b2d.1452431795.git.lukas@wunner.deSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      3d7b75fd
  16. 05 1月, 2016 1 次提交
  17. 04 1月, 2016 1 次提交
  18. 22 12月, 2015 1 次提交
  19. 15 12月, 2015 2 次提交
  20. 10 12月, 2015 1 次提交
  21. 09 12月, 2015 1 次提交
  22. 08 12月, 2015 5 次提交
  23. 24 11月, 2015 2 次提交
  24. 16 10月, 2015 4 次提交
  25. 07 10月, 2015 1 次提交
  26. 30 9月, 2015 2 次提交
    • D
      drm/drm_ioctl.c: kerneldoc · 0aaf20cf
      Daniel Vetter 提交于
      As usual pull it into the drm docbook template, too. And again as
      usual I've decided to only document stuff exported to drivers, so all
      the old leftover markup from the shared drm repo days lost the magic
      ** signature.
      Reviewed-by: NDavid Herrmann <dh.herrmann@gmail.com>
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      0aaf20cf
    • D
      drm/doc: Update docs about device instance setup · 6e3f797c
      Daniel Vetter 提交于
      ->load is deprecated, bus functions are deprecated and everyone
      should use drm_dev_alloc&register.
      
      So update the .tmpl (and pull a bunch of the overview docs into the
      sourcecode to increase chances that it'll stay in sync in the future)
      and add notes to functions which are deprecated. I didn't bother to
      clean up and document the unload sequence similarly since that one is
      still a bit a mess: drm_dev_unregister does way too much,
      drm_unplug_dev does what _unregister should be doing but then has the
      complication of promising something it doesn't actually do (it doesn't
      unplug existing open fds for instance, only prevents new ones).
      
      Motivated since I don't want to hunt every new driver for usage of
      drm_platform_init any more ;-)
      
      v2: Reword the deprecation note for ->load a bit, using Laurent's
      suggestion as an example (but making the wording a bit stronger even).
      Fix spelling in commit message.
      
      v3: More spelling fixes from Laurent.
      
      Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Acked-by: David Herrmann <dh.herrmann@gmail.com> (v2)
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      6e3f797c
  27. 25 9月, 2015 1 次提交
  28. 25 8月, 2015 1 次提交
  29. 15 8月, 2015 1 次提交
    • A
      drm/i915: Integrate GuC-based command submission · d1675198
      Alex Dai 提交于
      GuC-based submission is mostly the same as execlist mode, up to
      intel_logical_ring_advance_and_submit(), where the context being
      dispatched would be added to the execlist queue; at this point
      we submit the context to the GuC backend instead.
      
      There are, however, a few other changes also required, notably:
      1.  Contexts must be pinned at GGTT addresses accessible by the GuC
          i.e. NOT in the range [0..WOPCM_SIZE), so we have to add the
          PIN_OFFSET_BIAS flag to the relevant GGTT-pinning calls.
      
      2.  The GuC's TLB must be invalidated after a context is pinned at
          a new GGTT address.
      
      3.  GuC firmware uses the one page before Ring Context as shared data.
          Therefore, whenever driver wants to get base address of LRC, we
          will offset one page for it. LRC_PPHWSP_PN is defined as the page
          number of LRCA.
      
      4.  In the work queue used to pass requests to the GuC, the GuC
          firmware requires the ring-tail-offset to be represented as an
          11-bit value, expressed in QWords. Therefore, the ringbuffer
          size must be reduced to the representable range (4 pages).
      
      v2:
          Defer adding #defines until needed [Chris Wilson]
          Rationalise type declarations [Chris Wilson]
      
      v4:
          Squashed kerneldoc patch into here [Daniel Vetter]
      
      v5:
          Update request->tail in code common to both GuC and execlist modes.
          Add a private version of lr_context_update(), as sharing the
              execlist version leads to race conditions when the CPU and
              the GuC both update TAIL in the context image.
          Conversion of error-captured HWS page to string must account
              for offset from start of object to actual HWS (LRC_PPHWSP_PN).
      
      Issue: VIZ-4884
      Signed-off-by: NAlex Dai <yu.dai@intel.com>
      Signed-off-by: NDave Gordon <david.s.gordon@intel.com>
      Reviewed-by: NTom O'Rourke <Tom.O'Rourke@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      d1675198