Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 16 4月, 2016 2 次提交
  3. 07 4月, 2016 6 次提交
  5. 27 3月, 2016 3 次提交
  7. 13 3月, 2016 1 次提交
  9. 09 2月, 2016 1 次提交
  11. 25 1月, 2016 3 次提交
  13. 13 12月, 2015 1 次提交
  15. 12 12月, 2015 1 次提交
  17. 28 11月, 2015 1 次提交
  19. 20 11月, 2015 1 次提交
  21. 19 11月, 2015 2 次提交
  23. 26 10月, 2015 1 次提交
  25. 13 10月, 2015 1 次提交
  27. 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
  29. 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
  31. 17 7月, 2015 1 次提交
  33. 06 7月, 2015 2 次提交
  35. 15 5月, 2015 1 次提交
  37. 28 4月, 2015 1 次提交
  39. 27 4月, 2015 1 次提交
  41. 15 3月, 2015 1 次提交
  43. 23 2月, 2015 1 次提交
  45. 30 1月, 2015 1 次提交
  47. 28 1月, 2015 1 次提交
  49. 26 1月, 2015 1 次提交
  51. 23 1月, 2015 1 次提交