1. 06 6月, 2014 2 次提交
    • T
      drm/tegra: dsi - Implement VDD supply support · 3b077afb
      Thierry Reding 提交于
      The DSI controllers are powered by a (typically 1.2V) regulator. Usually
      this is always on, so there was no need to support enabling or disabling
      it thus far. But in order not to consume any power when DSI is inactive,
      give the driver a chance to enable or disable the supply as needed.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      3b077afb
    • T
      drm/tegra: hdmi - Add connector supply support · fb50a116
      Thierry Reding 提交于
      Revert commit 18ebc0f4 "drm/tegra: hdmi: Enable VDD earlier for
      hotplug/DDC" and instead add a new supply for the +5V pin on the HDMI
      connector.
      
      The vdd-supply property refers to the regulator that supplies the
      AVDD_HDMI input on Tegra, rather than the +5V HDMI connector pin. This
      was never a problem before, because all boards had that pin hooked up to
      a regulator that was always on. Starting with Dalmore and continuing
      with Venice2, the +5V pin is controllable via a GPIO. For reasons
      unknown, the GPIO ended up as the controlling GPIO of the AVDD_HDMI
      supply in the Dalmore and Venice2 DTS files. But that's not correct.
      Instead, a separate supply must be introduced so that the +5V pin can be
      controlled separately from the supplies that feed the HDMI block within
      Tegra.
      
      A new hdmi-supply property is introduced that takes the place of the
      vdd-supply and vdd-supply is only enabled when HDMI is enabled rather
      than all the time.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      fb50a116
  2. 05 6月, 2014 1 次提交
    • R
      drm: convert crtc and connection_mutex to ww_mutex (v5) · 51fd371b
      Rob Clark 提交于
      For atomic, it will be quite necessary to not need to care so much
      about locking order.  And 'state' gives us a convenient place to stash a
      ww_ctx for any sort of update that needs to grab multiple crtc locks.
      
      Because we will want to eventually make locking even more fine grained
      (giving locks to planes, connectors, etc), split out drm_modeset_lock
      and drm_modeset_acquire_ctx to track acquired locks.
      
      Atomic will use this to keep track of which locks have been acquired
      in a transaction.
      
      v1: original
      v2: remove a few things not needed until atomic, for now
      v3: update for v3 of connection_mutex patch..
      v4: squash in docbook
      v5: doc tweaks/fixes
      Signed-off-by: NRob Clark <robdclark@gmail.com>
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      51fd371b
  3. 02 6月, 2014 3 次提交
  4. 27 5月, 2014 1 次提交
    • S
      Documentation: drm: describing drm properties exposed by various drivers · 6c6a3996
      Sagar Kamble 提交于
      Started documenting drm properties for drm drivers. This patch provides
      information about properties in drm, i915, psb and cdv/gma-500. Information
      about other properties can be added on top of these.
      
      v2: Added description of drm properties in armada, exynos, i2c/ch7006, noveau,
      omap, qxl, radeon, rcar-du
      
      v3: Removed "Property Object" column since it is implementation related. Property
      type column refined.[Ville's review comments]
      
      v4: Removed whitespace warnings and minor nits. [Randy's review comments]
      
      v5: Restructured output for ENUM properties
      
      v6: Review comments on formatting the table. [Laurent's review comments]
      
      v7: Minor restructuring. [Laurent's review comments]
      
      Cc: Rob Landley <rob@landley.net>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: NLaurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
      Cc: David Herrmann <dh.herrmann@gmail.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
      Cc: Sagar Kamble <sagar.a.kamble@intel.com>
      Cc: "Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com>
      Cc: linux-doc@vger.kernel.org
      Cc: dri-devel@lists.freedesktop.org
      Signed-off-by: NSagar Kamble <sagar.a.kamble@intel.com>
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      6c6a3996
  5. 26 5月, 2014 2 次提交
  6. 22 5月, 2014 2 次提交
  7. 21 5月, 2014 2 次提交
  8. 05 5月, 2014 1 次提交
  9. 23 4月, 2014 2 次提交
  10. 22 4月, 2014 1 次提交
    • A
      drm: make mode_valid callback optional · f9b0e251
      Andrzej Hajda 提交于
      Many drm connectors do not need mode validation.
      The patch makes this callback optional and removes dumb implementations.
      
      v2: Rebase:
      - imx move to a shared (but still dummy) ->mode_valid implementation.
      - probe helpers have been extracted to drm_probe_helper.c
      
      Signed-off-by: Andrzej Hajda <a.hajda@samsung.com> (v1)
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      f9b0e251
  11. 19 4月, 2014 1 次提交
    • T
      Documentation/vm/numa_memory_policy.txt: fix wrong document in numa_memory_policy.txt · 8f28ed92
      Tang Chen 提交于
      In document numa_memory_policy.txt, the following examples for flag
      MPOL_F_RELATIVE_NODES are incorrect.
      
      	For example, consider a task that is attached to a cpuset with
      	mems 2-5 that sets an Interleave policy over the same set with
      	MPOL_F_RELATIVE_NODES.  If the cpuset's mems change to 3-7, the
      	interleave now occurs over nodes 3,5-6.  If the cpuset's mems
      	then change to 0,2-3,5, then the interleave occurs over nodes
      	0,3,5.
      
      According to the comment of the patch adding flag MPOL_F_RELATIVE_NODES,
      the nodemasks the user specifies should be considered relative to the
      current task's mems_allowed.
      
       (https://lkml.org/lkml/2008/2/29/428)
      
      And according to numa_memory_policy.txt, if the user's nodemask includes
      nodes that are outside the range of the new set of allowed nodes, then
      the remap wraps around to the beginning of the nodemask and, if not
      already set, sets the node in the mempolicy nodemask.
      
      So in the example, if the user specifies 2-5, for a task whose
      mems_allowed is 3-7, the nodemasks should be remapped the third, fourth,
      fifth, sixth node in mems_allowed.  like the following:
      
      	mems_allowed:       3  4  5  6  7
      
      	relative index:     0  1  2  3  4
      	                    5
      
      So the nodemasks should be remapped to 3,5-7, but not 3,5-6.
      
      And for a task whose mems_allowed is 0,2-3,5, the nodemasks should be
      remapped to 0,2-3,5, but not 0,3,5.
      
      	mems_allowed:       0  2  3  5
      
              relative index:     0  1  2  3
                                  4  5
      Signed-off-by: NTang Chen <tangchen@cn.fujitsu.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Acked-by: NDavid Rientjes <rientjes@google.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8f28ed92
  12. 18 4月, 2014 2 次提交
  13. 17 4月, 2014 8 次提交
  14. 15 4月, 2014 8 次提交
  15. 14 4月, 2014 1 次提交
  16. 10 4月, 2014 1 次提交
  17. 08 4月, 2014 2 次提交