1. 24 8月, 2016 1 次提交
    • T
      drm/tegra: dsi: Enhance runtime power management · 87904c3e
      Thierry Reding 提交于
      The MIPI DSI output on Tegra SoCs requires some external logic to
      calibrate the MIPI pads before a video signal can be transmitted. This
      MIPI calibration logic requires to be powered on while the MIPI pads are
      being used, which is currently done as part of the DSI driver's probe
      implementation.
      
      This is suboptimal because it will leave the MIPI calibration logic
      powered up even if the DSI output is never used.
      
      On Tegra114 and earlier this behaviour also causes the driver to hang
      while trying to power up the MIPI calibration logic because the power
      partition that contains the MIPI calibration logic will be powered on
      by the display controller at output pipeline configuration time. Thus
      the power up sequence for the MIPI calibration logic happens before
      it's power partition is guaranteed to be enabled.
      
      Fix this by splitting up the API into a request/free pair of functions
      that manage the runtime dependency between the DSI and the calibration
      modules (no registers are accessed) and a set of enable, calibrate and
      disable functions that program the MIPI calibration logic at points in
      time where the power partition is really enabled.
      
      While at it, make sure that the runtime power management also works in
      ganged mode, which is currently also broken.
      Reported-by: NJonathan Hunter <jonathanh@nvidia.com>
      Tested-by: NJonathan Hunter <jonathanh@nvidia.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      87904c3e
  2. 23 6月, 2016 11 次提交
  3. 28 5月, 2016 1 次提交
    • A
      remove lots of IS_ERR_VALUE abuses · 287980e4
      Arnd Bergmann 提交于
      Most users of IS_ERR_VALUE() in the kernel are wrong, as they
      pass an 'int' into a function that takes an 'unsigned long'
      argument. This happens to work because the type is sign-extended
      on 64-bit architectures before it gets converted into an
      unsigned type.
      
      However, anything that passes an 'unsigned short' or 'unsigned int'
      argument into IS_ERR_VALUE() is guaranteed to be broken, as are
      8-bit integers and types that are wider than 'unsigned long'.
      
      Andrzej Hajda has already fixed a lot of the worst abusers that
      were causing actual bugs, but it would be nice to prevent any
      users that are not passing 'unsigned long' arguments.
      
      This patch changes all users of IS_ERR_VALUE() that I could find
      on 32-bit ARM randconfig builds and x86 allmodconfig. For the
      moment, this doesn't change the definition of IS_ERR_VALUE()
      because there are probably still architecture specific users
      elsewhere.
      
      Almost all the warnings I got are for files that are better off
      using 'if (err)' or 'if (err < 0)'.
      The only legitimate user I could find that we get a warning for
      is the (32-bit only) freescale fman driver, so I did not remove
      the IS_ERR_VALUE() there but changed the type to 'unsigned long'.
      For 9pfs, I just worked around one user whose calling conventions
      are so obscure that I did not dare change the behavior.
      
      I was using this definition for testing:
      
       #define IS_ERR_VALUE(x) ((unsigned long*)NULL == (typeof (x)*)NULL && \
             unlikely((unsigned long long)(x) >= (unsigned long long)(typeof(x))-MAX_ERRNO))
      
      which ends up making all 16-bit or wider types work correctly with
      the most plausible interpretation of what IS_ERR_VALUE() was supposed
      to return according to its users, but also causes a compile-time
      warning for any users that do not pass an 'unsigned long' argument.
      
      I suggested this approach earlier this year, but back then we ended
      up deciding to just fix the users that are obviously broken. After
      the initial warning that caused me to get involved in the discussion
      (fs/gfs2/dir.c) showed up again in the mainline kernel, Linus
      asked me to send the whole thing again.
      
      [ Updated the 9p parts as per Al Viro  - Linus ]
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Cc: Andrzej Hajda <a.hajda@samsung.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: https://lkml.org/lkml/2016/1/7/363
      Link: https://lkml.org/lkml/2016/5/27/486
      Acked-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> # For nvmem part
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      287980e4
  4. 16 3月, 2016 2 次提交
  5. 09 3月, 2016 1 次提交
    • L
      dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc() · f6e45661
      Luis R. Rodriguez 提交于
      Rename dma_*_writecombine() to dma_*_wc(), so that the naming
      is coherent across the various write-combining APIs. Keep the
      old names for compatibility for a while, these can be removed
      at a later time. A guard is left to enable backporting of the
      rename, and later remove of the old mapping defines seemlessly.
      
      Build tested successfully with allmodconfig.
      
      The following Coccinelle SmPL patch was used for this simple
      transformation:
      
      @ rename_dma_alloc_writecombine @
      expression dev, size, dma_addr, gfp;
      @@
      
      -dma_alloc_writecombine(dev, size, dma_addr, gfp)
      +dma_alloc_wc(dev, size, dma_addr, gfp)
      
      @ rename_dma_free_writecombine @
      expression dev, size, cpu_addr, dma_addr;
      @@
      
      -dma_free_writecombine(dev, size, cpu_addr, dma_addr)
      +dma_free_wc(dev, size, cpu_addr, dma_addr)
      
      @ rename_dma_mmap_writecombine @
      expression dev, vma, cpu_addr, dma_addr, size;
      @@
      
      -dma_mmap_writecombine(dev, vma, cpu_addr, dma_addr, size)
      +dma_mmap_wc(dev, vma, cpu_addr, dma_addr, size)
      
      We also keep the old names as compatibility helpers, and
      guard against their definition to make backporting easier.
      
      Generated-by: Coccinelle SmPL
      Suggested-by: NIngo Molnar <mingo@kernel.org>
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: airlied@linux.ie
      Cc: akpm@linux-foundation.org
      Cc: benh@kernel.crashing.org
      Cc: bhelgaas@google.com
      Cc: bp@suse.de
      Cc: dan.j.williams@intel.com
      Cc: daniel.vetter@ffwll.ch
      Cc: dhowells@redhat.com
      Cc: julia.lawall@lip6.fr
      Cc: konrad.wilk@oracle.com
      Cc: linux-fbdev@vger.kernel.org
      Cc: linux-pci@vger.kernel.org
      Cc: luto@amacapital.net
      Cc: mst@redhat.com
      Cc: tomi.valkeinen@ti.com
      Cc: toshi.kani@hp.com
      Cc: vinod.koul@intel.com
      Cc: xen-devel@lists.xensource.com
      Link: http://lkml.kernel.org/r/1453516462-4844-1-git-send-email-mcgrof@do-not-panic.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      f6e45661
  6. 04 3月, 2016 2 次提交
  7. 14 12月, 2015 3 次提交
  8. 02 10月, 2015 1 次提交
  9. 13 8月, 2015 7 次提交
  10. 03 4月, 2015 1 次提交
  11. 27 1月, 2015 1 次提交
    • T
      gpu: host1x: Provide a proper struct bus_type · f4c5cf88
      Thierry Reding 提交于
      Previously the struct bus_type exported by the host1x infrastructure was
      only a very basic skeleton. Turn that implementation into a more full-
      fledged bus to support proper probe ordering and power management.
      
      Note that the bus infrastructure needs to be available before any of the
      drivers can be registered. This is automatically ensured if all drivers
      are built as loadable modules (via symbol dependencies). If all drivers
      are built-in there are no such guarantees and the link order determines
      the initcall ordering. Adjust drivers/gpu/Makefile to make sure that the
      host1x bus infrastructure is initialized prior to any of its users (only
      drm/tegra currently).
      
      v2: Fix building host1x and tegra-drm as modules
      Reported-by: NDave Airlie <airlied@gmail.com>
      Reviewed-by: NSean Paul <seanpaul@chromium.org>
      Reviewed-by: NMark Zhang <markz@nvidia.com>
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      f4c5cf88
  12. 23 1月, 2015 3 次提交
  13. 13 11月, 2014 6 次提交
反馈
建议
客服 返回
顶部