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. 02 6月, 2014 3 次提交
  3. 13 5月, 2014 1 次提交
  4. 10 5月, 2014 1 次提交
  5. 04 5月, 2014 1 次提交
  6. 29 4月, 2014 2 次提交
    • T
      ARM: common: edma: Fix xbar mapping · cf7eb979
      Thomas Gleixner 提交于
      This is another great example of trainwreck engineering:
      
      commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support)
      added support for using EDMA on peripherals which have no direct EDMA
      event mapping.
      
      The code compiles and does not explode in your face, but that's it.
      
      1) Reading an u16 array from an u32 device tree array simply does not
         work. Even if the function is named "edma_of_read_u32_to_s16_array".
      
         It merily calls of_property_read_u16_array. So the resulting 16bit
         array will have every other entry = 0.
      
      2) The DT entry for the xbar registers related to xbar has length 0x10
         instead of the real length: 0xfd0 - 0xf90 = 0x40.
      
         Not a real problem as it does not cross a page boundary, but
         wrong nevertheless.
      
      3) But none of this matters as the mapping never happens:
      
         After reading nonsense edma_of_read_u32_to_s16_array() invalidates
         the first array entry pair, so nobody can ever notice the
         braindamage by immediate explosion.
      
      Seems the QA criteria for this code was solely not to explode when
      someone adds edma-xbar-event-map entries to the DT. Goal achieved,
      congratulations!
      
      Not really helpful if someone wants to use edma on a device which
      requires a xbar mapping.
      
      Fix the issues by:
      
      - annotating the device tree entry with "/bits/ 16" as documented in
        the of_property_read_u16_array kernel doc
      
      - make the size of the xbar register mapping correct
      
      - invalidating the end of the array and not the start
      
      This convoluted mess wants to be completely rewritten as there is no
      point to keep the xbar_chan array memory and the iomapping of the xbar
      regs around forever. Marking the xbar mapped channels as used should
      be done right there.
      
      But that's a different issue and this patch is small enough to make it
      work and allows a simple backport for stable.
      
      Cc: stable@vger.kernel.org # v3.12+
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NSekhar Nori <nsekhar@ti.com>
      cf7eb979
    • L
      clocksource: arch_arm_timer: Fix age-old arch timer C3STOP detection issue · 82a56194
      Lorenzo Pieralisi 提交于
      ARM arch timers are tightly coupled with the CPU logic and lose context
      on platform implementing HW power management when cores are powered
      down at run-time. Marking the arch timers as C3STOP regardless of power
      management capabilities causes issues on platforms with no power management,
      since in that case the arch timers cannot possibly enter states where the
      timer loses context at runtime and therefore can always be used as a high
      resolution clockevent device.
      
      In order to fix the C3STOP issue in a way compliant with how real HW
      works, this patch adds a boolean property to the arch timer bindings
      to define if the arch timer is managed by an always-on power domain.
      
      This power domain is present on all ARM platforms to date, and manages
      HW that must not be turned off, whatever the state of other HW
      components (eg power controller). On platforms with no power management
      capabilities, it is the only power domain present, which encompasses
      and manages power supply for all HW components in the system.
      
      If the timer is powered by the always-on power domain, the always-on
      property must be present in the bindings which means that the timer cannot
      be shutdown at runtime, so it is not a C3STOP clockevent device.
      If the timer binding does not contain the always-on property, the timer is
      assumed to be power-gateable, hence it must be defined as a C3STOP
      clockevent device.
      
      Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
      Cc: Magnus Damm <damm@opensource.se>
      Cc: Marc Carino <marc.ceeeee@gmail.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Acked-by: NMarc Zyngier <marc.zyngier@arm.com>
      Acked-by: NRob Herring <robh@kernel.org>
      Signed-off-by: NLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: NDaniel Lezcano <daniel.lezcano@linaro.org>
      82a56194
  7. 28 4月, 2014 1 次提交
  8. 23 4月, 2014 1 次提交
  9. 19 4月, 2014 1 次提交
  10. 18 4月, 2014 1 次提交
  11. 17 4月, 2014 2 次提交
  12. 15 4月, 2014 8 次提交
  13. 14 4月, 2014 1 次提交
  14. 08 4月, 2014 1 次提交
  15. 07 4月, 2014 1 次提交
  16. 06 4月, 2014 1 次提交
  17. 04 4月, 2014 9 次提交
  18. 03 4月, 2014 1 次提交
  19. 02 4月, 2014 1 次提交
  20. 31 3月, 2014 1 次提交