Skip to content
  1. Jun 03, 2016
  3. May 28, 2016
  5. May 27, 2016
  7. May 26, 2016
  9. May 24, 2016
  11. May 23, 2016
    • Ville Syrjälä's avatar
      drm: Add helper for DP++ adaptors · b3daa5ef
      Ville Syrjälä authored 
      

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: default avatarVille 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: default avatarJani Nikula <jani.nikula@intel.com>
      b3daa5ef
  13. May 21, 2016
  15. May 20, 2016
  17. May 19, 2016
    • Marek Vasut's avatar
      devicetree: Add Creative Technology vendor id · f2c27767
      Marek Vasut authored 
      

Add vendor ID for Creative technology.

Signed-off-by: default avatarMarek Vasut <marek.vasut@gmail.com>
Cc: Antony Pavlov <antonynpavlov@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: default avatarRob Herring <robh@kernel.org>
      f2c27767
    • Christian Lamparter's avatar
      gpio: dt-bindings: add ibm,ppc4xx-gpio binding · 9a0d4404
      Christian Lamparter authored 
      

This patch adds binding information for IBM/AMCC/APM GPIO
Controllers of the PowerPC 4XX series and compatible SoCs.

The "PowerPC 405EP Embedded Processor Data Sheet" has the
following to say about the GPIO controllers: "

 - Controller functions and GPIO registers are programmed
   and accessed via memory-mapped OPB bus master accesses

 - All GPIOs are pin-shared with other functions. DCRs control
   whether a particular pin that has GPIO capabilities acts
   as a GPIO or is used for another purpose.

 - Each GPIO outputs is separately programmable to emulate
   an open-drain driver (i.e. drives to zero, threestated if
   output bit is 1)

"
The ppc4xx_gpio.c driver is part of the platform/sysdev drivers
in arch/powerpc/sysdev.

Signed-off-by: default avatarChristian Lamparter <chunkeey@googlemail.com>
Signed-off-by: default avatarRob Herring <robh@kernel.org>
      9a0d4404
  19. May 18, 2016
    • Vishal Verma's avatar
      dax: for truncate/hole-punch, do zeroing through the driver if possible · 4b0228fa
      Vishal Verma authored 
      

In the truncate or hole-punch path in dax, we clear out sub-page ranges.
If these sub-page ranges are sector aligned and sized, we can do the
zeroing through the driver instead so that error-clearing is handled
automatically.

For sub-sector ranges, we still have to rely on clear_pmem and have the
possibility of tripping over errors.

Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Jan Kara <jack@suse.cz>
Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
Reviewed-by: default avatarJan Kara <jack@suse.cz>
Signed-off-by: default avatarVishal Verma <vishal.l.verma@intel.com>
      4b0228fa
  21. May 17, 2016