1. 09 10月, 2015 3 次提交
    • C
      ARM: dts: rockchip: add the support power-domain node on RK3288 SoCs · b63af764
      Caesar Wang 提交于
      We can add more domains node in the future.
      This patch add the needed clocks into power-controller.
      As the discuess about all the device clocks being listed in
      the power-domains itself.
      
      There are several reasons as follows:
      
      Firstly, the clocks need be turned off to save power when
      the system enter the suspend state. So we need to enumerate
      the clocks in the dts. In order to power domain can turn on and off.
      
      Secondly, the reset-circuit should reset be synchronous on RK3288,
      then sync revoked. So we need to enable clocks of all devices.
      In other words, we have to enable the clocks before you operate them
      if all the device clocks are included in someone domians.
      
      Thirdly, as the chip designs for PM hardhare. we need turn on the noc
      clocks, if we are operating the "pd_vio" domain to enter the idle status.
      The device's clock be included in domains that needed turn on if do that.
      
      The clocks in the dts are needed to enable before you want to happy work.
      At the moment, This patch is very good work for PM hardware.
      
      Also, we can add these clocks in the future if we have some hidden clocks.
      Signed-off-by: NCaesar Wang <wxt@rock-chips.com>
      Reviewed-by: NMichael Turquette <mturquette@baylibre.com>
      Reviewed-by: NKevin Hilman <khilman@linaro.org>
      
      [add necessary power-domain properties to keep drm subsys working]
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      b63af764
    • D
      ARM: dts: rockchip: Add the hdmi-ddc pinctrl settings for rk3288 · e61ccb12
      Douglas Anderson 提交于
      The pins for i2c5 can either be configured as "I2C5" which means that
      they're controlled by the normal RK3288 I2C controller or as "EDP / HDMI
      I2C".  It's unclear why EDP is referenced here since apparently setting
      the mux to this position enables I2C communication using the dw_hdmi
      block with a patch like <https://patchwork.kernel.org/patch/7098101/>.
      
      There appear to be some reasons why using the builtin I2C controller in
      dw_hdmi is better than using the normal RK3288 I2C controller, so boards
      based on rk3288 might eventually want to use this pinmux if it's known
      to work.
      
      Once driver support in dw_hdmi lands, boards would use this by selecting
      this pinctrl for the HDMI block and then _not_ specifying a ddc-i2c-bus
      and _not_ setting the status to "okay" for i2c5 (which uses the same
      pins).
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      e61ccb12
    • A
      ARM: dts: rockchip: pull up cts lines on rk3288 · 8915f364
      Alexandru M Stan 提交于
      The flow control lines from a user accessible UART are optional,
      the user might not have anything connected to those pins.
      In order to prevent random interrupts happening and noise affecting
      the cts pin should be pulled up.
      
      Note that the default state for that pin on the rk3288 is pulled up,
      so this patch merely restores them.
      
      This is similar to what we're already doing with the RX pin,
      so it should be safe. At worst it might be a slightly higher power usage
      (through ~50 kohms) when the cts is low.
      Suggested-by: NNeil Hendin <nhendin@chromium.org>
      Signed-off-by: NAlexandru M Stan <amstan@chromium.org>
      Reviewed-by: NDouglas Anderson <dianders@chromium.org>
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      8915f364
  2. 08 8月, 2015 1 次提交
    • H
      ARM: dts: rockchip: reserve unusable memory region on rk3288 · b21bcfc9
      Heiko Stuebner 提交于
      The all current Rockchip SoCs supporting 4GB of ram have problems accessing
      the memory region 0xfe000000~0xff000000. This also seems to includes the
      rk3368 arm64 soc.
      
      All current code handling dma memory oddities I could find, seem to involve
      soc-specific code (zone-dma or so) while this issue is shared between arm32
      and arm64 socs from Rockchip, which would need to have this described in
      the soc devicetree on both socs.
      
      Limiting the dma-zone alone also does not solve the issue and as the
      dma-masks need to be a power-of-two in the kernel, the next lower dma-mask
      brings memory usable for dma down to 2GB.
      
      So as a stop-gap block off the affected region to prevent its use by
      devices with 4GB of memory, like some recent Chromebooks.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Reviewed-by: NDouglas Anderson <dianders@chromium.org>
      b21bcfc9
  3. 17 7月, 2015 1 次提交
  4. 06 7月, 2015 2 次提交
  5. 15 5月, 2015 1 次提交
  6. 28 4月, 2015 1 次提交
  7. 27 4月, 2015 1 次提交
  8. 15 3月, 2015 1 次提交
  9. 23 2月, 2015 1 次提交
  10. 30 1月, 2015 1 次提交
  11. 28 1月, 2015 1 次提交
  12. 26 1月, 2015 1 次提交
  13. 23 1月, 2015 2 次提交
  14. 01 1月, 2015 1 次提交
  15. 31 12月, 2014 1 次提交
  16. 21 12月, 2014 1 次提交
  17. 06 12月, 2014 1 次提交
  18. 05 12月, 2014 1 次提交
  19. 25 11月, 2014 1 次提交
  20. 22 11月, 2014 1 次提交
    • H
      ARM: dts: rockchip: temporarily disable smp on rk3288 · b77d4394
      Heiko Stuebner 提交于
      Stock firmware on rk3288 does not initizalize the CNTVOFF registers
      of the architected timer correctly. This introduces issues with the
      newly added SMP support for rk3288, resulting in rcu stalls due to
      differing timer values per core.
      
      There exist preliminary and tested patches for u-boot for this problem,
      but there are a minority of boards using other bootloaders like coreboot.
      
      There also is currently a second solution for miss-initialized architected
      timers in the works:
      - clocksource: arch_timer: Fix code to use physical timers when requested
      - clocksource: arch_timer: Allow the device tree to specify uninitialized timer registers
      
      Therefore disable smp on rk3288 again till these are finalized, also
      allowing coreboot-based boards to boot again.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      b77d4394
  21. 06 11月, 2014 1 次提交
  22. 02 11月, 2014 3 次提交
  23. 25 10月, 2014 1 次提交
  24. 20 10月, 2014 2 次提交
  25. 26 9月, 2014 1 次提交
  26. 09 9月, 2014 3 次提交
  27. 04 9月, 2014 1 次提交
  28. 03 9月, 2014 1 次提交
  29. 28 8月, 2014 2 次提交
  30. 17 8月, 2014 1 次提交