1. 21 6月, 2014 1 次提交
  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 6 次提交
    • S
      drm/panel: add support for EDT ET057090DHU panel · 26ab0065
      Stefan Agner 提交于
      This panel is sold by Toradex for Colibri T20/T30 and Apalis T30
      evaluation kits.
      Signed-off-by: NStefan Agner <stefan@agner.ch>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      26ab0065
    • P
      drm/panel: Add support for EDT ETM0700G0DH6 and ET070080DH6 panels · fff5de45
      Philipp Zabel 提交于
      The EDT ETM0700G0DH6 and ET070080DH6 are 7" 800x480 panels,
      which can be supported by the simple panel driver.
      Signed-off-by: NPhilipp Zabel <p.zabel@pengutronix.de>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      fff5de45
    • D
      locking/mutexes: Documentation update/rewrite · 9161f540
      Davidlohr Bueso 提交于
      Our mutexes have gone a long ways since the original
      implementation back in 2005/2006. However, the mutex-design.txt
      document is still stuck in the past, to the point where most of
      the information there is practically useless and, more
      important, simply incorrect. This patch pretty much rewrites it
      to resemble what we have nowadays.
      
      Since regular semaphores are almost much extinct in the kernel
      (most users now rely on mutexes or rwsems), it no longer makes
      sense to have such a close comparison, which was copied from
      most of the cover letter when Ingo introduced the generic mutex
      subsystem.
      
      Note that ww_mutexes are intentionally left out, leaving things
      as generic as possible.
      Signed-off-by: NDavidlohr Bueso <davidlohr@hp.com>
      Cc: tim.c.chen@linux.intel.com
      Cc: paulmck@linux.vnet.ibm.com
      Cc: waiman.long@hp.com
      Cc: jason.low2@hp.com
      Cc: aswin@hp.com
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1401338203.2618.11.camel@buesod1.americas.hpqcorp.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      9161f540
    • M
      powerpc: Add cpu family documentation · 91a6151b
      Michael Ellerman 提交于
      This patch adds some documentation on the different cpu families
      supported by arch/powerpc.
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      91a6151b
    • 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
    • P
      init/main.c: add initcall_blacklist kernel parameter · 7b0b73d7
      Prarit Bhargava 提交于
      When a module is built into the kernel the module_init() function
      becomes an initcall.  Sometimes debugging through dynamic debug can
      help, however, debugging built in kernel modules is typically done by
      changing the .config, recompiling, and booting the new kernel in an
      effort to determine exactly which module caused a problem.
      
      This patchset can be useful stand-alone or combined with initcall_debug.
      There are cases where some initcalls can hang the machine before the
      console can be flushed, which can make initcall_debug output inaccurate.
      Having the ability to skip initcalls can help further debugging of these
      scenarios.
      
      Usage: initcall_blacklist=<list of comma separated initcalls>
      
      ex) added "initcall_blacklist=sgi_uv_sysfs_init" as a kernel parameter and
      the log contains:
      
      	blacklisting initcall sgi_uv_sysfs_init
      	...
      	...
      	initcall sgi_uv_sysfs_init blacklisted
      
      ex) added "initcall_blacklist=foo_bar,sgi_uv_sysfs_init" as a kernel parameter
      and the log contains:
      
      	blacklisting initcall foo_bar
      	blacklisting initcall sgi_uv_sysfs_init
      	...
      	...
      	initcall sgi_uv_sysfs_init blacklisted
      
      [akpm@linux-foundation.org: tweak printk text]
      Signed-off-by: NPrarit Bhargava <prarit@redhat.com>
      Cc: Richard Weinberger <richard.weinberger@gmail.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: Rob Landley <rob@landley.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7b0b73d7