1. 05 7月, 2014 2 次提交
  2. 13 6月, 2014 2 次提交
  3. 12 6月, 2014 3 次提交
  4. 11 6月, 2014 5 次提交
  5. 10 6月, 2014 4 次提交
  6. 09 6月, 2014 1 次提交
  7. 07 6月, 2014 12 次提交
  8. 06 6月, 2014 6 次提交
    • L
      amd-xgbe: AMD 10GbE device bindings documentation · 7c123b6a
      Lendacky, Thomas 提交于
      This patch provides the documentation of the device bindings
      for the AMD 10GbE platform driver.
      Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7c123b6a
    • V
      cpufreq: add support for intermediate (stable) frequencies · 1c03a2d0
      Viresh Kumar 提交于
      Douglas Anderson, recently pointed out an interesting problem due to which
      udelay() was expiring earlier than it should.
      
      While transitioning between frequencies few platforms may temporarily switch to
      a stable frequency, waiting for the main PLL to stabilize.
      
      For example: When we transition between very low frequencies on exynos, like
      between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz.
      No CPUFREQ notification is sent for that. That means there's a period of time
      when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz
      and 300MHz. And so udelay behaves badly.
      
      To get this fixed in a generic way, introduce another set of callbacks
      get_intermediate() and target_intermediate(), only for drivers with
      target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.
      
      get_intermediate() should return a stable intermediate frequency platform wants
      to switch to, and target_intermediate() should set CPU to that frequency,
      before jumping to the frequency corresponding to 'index'. Core will take care of
      sending notifications and driver doesn't have to handle them in
      target_intermediate() or target_index().
      
      NOTE: ->target_index() should restore to policy->restore_freq in case of
      failures as core would send notifications for that.
      Tested-by: NStephen Warren <swarren@nvidia.com>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: NDoug Anderson <dianders@chromium.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1c03a2d0
    • T
      drm: Document how to register devices without struct drm_bus · b528ae71
      Thierry Reding 提交于
      With the recent addition of the drm_set_unique() function, devices can
      now be registered without requiring a drm_bus. Add a brief description
      to the DRM docbook to show how that can be achieved.
      Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      b528ae71
    • T
      drm: Add device registration documentation · c6a1af8a
      Thierry Reding 提交于
      Describe how devices are registered using the drm_*_init() functions.
      Adding this to docbook requires a largish set of changes to the comments
      in drm_{pci,usb,platform}.c since they are doxygen-style rather than
      proper kernel-doc and therefore mess with the docbook generation.
      
      While at it, mark usage of drm_put_dev() as discouraged in favour of
      calling drm_dev_unregister() and drm_dev_unref() directly.
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      c6a1af8a
    • 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
  9. 05 6月, 2014 5 次提交