Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36 |
|
#
9be1a999 |
| 25-Apr-2022 |
Brian Norris <briannorris@chromium.org> |
soc: rockchip: Clean up Kconfig whitespace
There are spaces instead of tabs, and other inconsistent indentation.
Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <l
soc: rockchip: Clean up Kconfig whitespace
There are spaces instead of tabs, and other inconsistent indentation.
Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/20220426014545.628100-1-briannorris@chromium.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
show more ...
|
Revision tags: v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18 |
|
#
b9d6c47a |
| 28-Jan-2022 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
rockchip/soc/drivers: Add DTPM description for rk3399
The DTPM framework does support now the hierarchy description.
The platform specific code can call the hierarchy creation function with an arra
rockchip/soc/drivers: Add DTPM description for rk3399
The DTPM framework does support now the hierarchy description.
The platform specific code can call the hierarchy creation function with an array of struct dtpm_node pointing to their parent.
This patch provides a description of the big / Little CPUs and the GPU and tie them together under a virtual 'package' name. Only rk3399 is described now.
The description could be extended in the future with the memory controller with devfreq.
The description is always a module and it describes the soft dependencies. The userspace has to load the softdeps module in the right order.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by; Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20220128163537.212248-6-daniel.lezcano@linaro.org
show more ...
|
Revision tags: v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15 |
|
#
2a1c55d4 |
| 08-Feb-2021 |
Geert Uytterhoeven <geert+renesas@glider.be> |
soc: rockchip: ROCKCHIP_GRF should not default to y, unconditionally
Merely enabling CONFIG_COMPILE_TEST should not enable additional code. To fix this, restrict the automatic enabling of ROCKCHIP_G
soc: rockchip: ROCKCHIP_GRF should not default to y, unconditionally
Merely enabling CONFIG_COMPILE_TEST should not enable additional code. To fix this, restrict the automatic enabling of ROCKCHIP_GRF to ARCH_ROCKCHIP, and ask the user in case of compile-testing.
Fixes: 4c58063d4258f6be ("soc: rockchip: add driver handling grf setup") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210208143855.418374-1-geert+renesas@glider.be Signed-off-by: Heiko Stuebner <heiko@sntech.de>
show more ...
|
#
25fbfc31 |
| 08-Feb-2021 |
Geert Uytterhoeven <geert+renesas@glider.be> |
soc: rockchip: ROCKCHIP_GRF should not default to y, unconditionally
[ Upstream commit 2a1c55d4762dd34a8b0f2e36fb01b7b16b60735b ]
Merely enabling CONFIG_COMPILE_TEST should not enable additional co
soc: rockchip: ROCKCHIP_GRF should not default to y, unconditionally
[ Upstream commit 2a1c55d4762dd34a8b0f2e36fb01b7b16b60735b ]
Merely enabling CONFIG_COMPILE_TEST should not enable additional code. To fix this, restrict the automatic enabling of ROCKCHIP_GRF to ARCH_ROCKCHIP, and ask the user in case of compile-testing.
Fixes: 4c58063d4258f6be ("soc: rockchip: add driver handling grf setup") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210208143855.418374-1-geert+renesas@glider.be Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14 |
|
#
e943c43b |
| 06-Oct-2020 |
Ulf Hansson <ulf.hansson@linaro.org> |
PM: AVS: rockchip-io: Move the driver to the rockchip specific drivers
The avs drivers are all SoC specific drivers that doesn't share any code. Instead they are located in a directory, mostly to ke
PM: AVS: rockchip-io: Move the driver to the rockchip specific drivers
The avs drivers are all SoC specific drivers that doesn't share any code. Instead they are located in a directory, mostly to keep similar functionality together. From a maintenance point of view, it makes better sense to collect SoC specific drivers like these, into the SoC specific directories.
Therefore, let's move the rockchip-io driver to the rockchip directory.
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4 |
|
#
ec8f24b7 |
| 19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Add SPDX license identifier - Makefile/Kconfig
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project
treewide: Add SPDX license identifier - Makefile/Kconfig
Add SPDX license identifiers to all Make/Kconfig files which:
- Have no license information of any form
These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is:
GPL-2.0-only
Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33 |
|
#
4c58063d |
| 16-Nov-2016 |
Heiko Stuebner <heiko@sntech.de> |
soc: rockchip: add driver handling grf setup
The General Register Files are an area of registers containing a lot of single-bit settings for numerous components as well full components like usbphy c
soc: rockchip: add driver handling grf setup
The General Register Files are an area of registers containing a lot of single-bit settings for numerous components as well full components like usbphy control. Therefore all used components are accessed via the syscon provided by the grf nodes or from the sub-devices created through the simple-mfd created from the grf node.
Some settings are not used by anything but will need to be set up according to expectations on the kernel side.
Best example is the force_jtag setting, which defaults to on and results in the soc switching the pin-outputs between jtag and sdmmc automatically depending on the card-detect status. This conflicts heavily with how the dw_mmc driver expects to do its work and also with the clock-controller, which has most likely deactivated the jtag clock due to it being unused.
So far the handling of this setting was living in the mach-rockchip code for the arm32-based rk3288 but that of course doesn't work for arm64 socs and would also look ugly for further arm32 socs.
Also always disabling this setting is quite specific to linux and its subsystems, other operating systems might prefer other settings, so that the bootloader cannot really set a sane default for all.
So introduce a top-level driver for the grf that handles these settings that need to be a certain way but nobody cares about.
Other needed settings might surface in the future and can then be added here, but only as a last option. Ideally general GRF settings should be handled in the driver needing them.
Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Douglas Anderson <dianders@chromium.org>
show more ...
|
Revision tags: v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1 |
|
#
0cc59891 |
| 09-Oct-2015 |
Thierry Reding <treding@nvidia.com> |
soc: rockchip: Restrict to ARCH_ROCKCHIP
By definition this directory contains drivers that are specific to the Rockchip architecture. All Kconfig options should therefore depend on ARCH_ROCKCHIP to
soc: rockchip: Restrict to ARCH_ROCKCHIP
By definition this directory contains drivers that are specific to the Rockchip architecture. All Kconfig options should therefore depend on ARCH_ROCKCHIP to avoid exposing these symbols on other architectures. For example, this options currently shows up as new when doing an incremental build on PowerPC.
Signed-off-by: Thierry Reding <treding@nvidia.com>
[add COMPILE_TEST alternative condition] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
show more ...
|
Revision tags: v4.3-rc1 |
|
#
7c696693 |
| 08-Sep-2015 |
Caesar Wang <wxt@rock-chips.com> |
soc: rockchip: power-domain: Add power domain driver
This driver is found on RK3288 SoCs.
In order to meet high performance and low power requirements, a power management unit is designed or saving
soc: rockchip: power-domain: Add power domain driver
This driver is found on RK3288 SoCs.
In order to meet high performance and low power requirements, a power management unit is designed or saving power when RK3288 in low power mode. The RK3288 PMU is dedicated for managing the power of the whole chip.
PMU can work in the Low Power Mode by setting bit[0] of PMU_PWRMODE_CON register. After setting the register, PMU would enter the Low Power mode. In the low power mode, pmu will auto power on/off the specified power domain, send idle req to specified power domain, shut down/up pll and so on. All of above are configurable by setting corresponding registers.
Signed-off-by: Caesar Wang <wxt@rock-chips.com> Reviewed-by: Kevin Hilman <khilman@linaro.org>
[replace dsb() with dsb(sy) for arm64 buildability; sy is the default, so no functional change; adapt to per-user clocks in genpd] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
show more ...
|
#
25fbfc31 |
| 08-Feb-2021 |
Geert Uytterhoeven <geert+renesas@glider.be> |
soc: rockchip: ROCKCHIP_GRF should not default to y, unconditionally [ Upstream commit 2a1c55d4762dd34a8b0f2e36fb01b7b16b60735b ] Merely enabling CONFIG_COMPILE_TEST should not enab
soc: rockchip: ROCKCHIP_GRF should not default to y, unconditionally [ Upstream commit 2a1c55d4762dd34a8b0f2e36fb01b7b16b60735b ] Merely enabling CONFIG_COMPILE_TEST should not enable additional code. To fix this, restrict the automatic enabling of ROCKCHIP_GRF to ARCH_ROCKCHIP, and ask the user in case of compile-testing. Fixes: 4c58063d4258f6be ("soc: rockchip: add driver handling grf setup") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20210208143855.418374-1-geert+renesas@glider.be Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14 |
|
#
e943c43b |
| 06-Oct-2020 |
Ulf Hansson <ulf.hansson@linaro.org> |
PM: AVS: rockchip-io: Move the driver to the rockchip specific drivers The avs drivers are all SoC specific drivers that doesn't share any code. Instead they are located in a directory,
PM: AVS: rockchip-io: Move the driver to the rockchip specific drivers The avs drivers are all SoC specific drivers that doesn't share any code. Instead they are located in a directory, mostly to keep similar functionality together. From a maintenance point of view, it makes better sense to collect SoC specific drivers like these, into the SoC specific directories. Therefore, let's move the rockchip-io driver to the rockchip directory. Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4 |
|
#
ec8f24b7 |
| 19-May-2019 |
Thomas Gleixner <tglx@linutronix.de> |
treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These file
treewide: Add SPDX license identifier - Makefile/Kconfig Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33 |
|
#
4c58063d |
| 16-Nov-2016 |
Heiko Stuebner <heiko@sntech.de> |
soc: rockchip: add driver handling grf setup The General Register Files are an area of registers containing a lot of single-bit settings for numerous components as well full components
soc: rockchip: add driver handling grf setup The General Register Files are an area of registers containing a lot of single-bit settings for numerous components as well full components like usbphy control. Therefore all used components are accessed via the syscon provided by the grf nodes or from the sub-devices created through the simple-mfd created from the grf node. Some settings are not used by anything but will need to be set up according to expectations on the kernel side. Best example is the force_jtag setting, which defaults to on and results in the soc switching the pin-outputs between jtag and sdmmc automatically depending on the card-detect status. This conflicts heavily with how the dw_mmc driver expects to do its work and also with the clock-controller, which has most likely deactivated the jtag clock due to it being unused. So far the handling of this setting was living in the mach-rockchip code for the arm32-based rk3288 but that of course doesn't work for arm64 socs and would also look ugly for further arm32 socs. Also always disabling this setting is quite specific to linux and its subsystems, other operating systems might prefer other settings, so that the bootloader cannot really set a sane default for all. So introduce a top-level driver for the grf that handles these settings that need to be a certain way but nobody cares about. Other needed settings might surface in the future and can then be added here, but only as a last option. Ideally general GRF settings should be handled in the driver needing them. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Reviewed-by: Douglas Anderson <dianders@chromium.org>
show more ...
|
Revision tags: v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1 |
|
#
0cc59891 |
| 09-Oct-2015 |
Thierry Reding <treding@nvidia.com> |
soc: rockchip: Restrict to ARCH_ROCKCHIP By definition this directory contains drivers that are specific to the Rockchip architecture. All Kconfig options should therefore depend on
soc: rockchip: Restrict to ARCH_ROCKCHIP By definition this directory contains drivers that are specific to the Rockchip architecture. All Kconfig options should therefore depend on ARCH_ROCKCHIP to avoid exposing these symbols on other architectures. For example, this options currently shows up as new when doing an incremental build on PowerPC. Signed-off-by: Thierry Reding <treding@nvidia.com> [add COMPILE_TEST alternative condition] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
show more ...
|
Revision tags: v4.3-rc1 |
|
#
7c696693 |
| 08-Sep-2015 |
Caesar Wang <wxt@rock-chips.com> |
soc: rockchip: power-domain: Add power domain driver This driver is found on RK3288 SoCs. In order to meet high performance and low power requirements, a power management unit i
soc: rockchip: power-domain: Add power domain driver This driver is found on RK3288 SoCs. In order to meet high performance and low power requirements, a power management unit is designed or saving power when RK3288 in low power mode. The RK3288 PMU is dedicated for managing the power of the whole chip. PMU can work in the Low Power Mode by setting bit[0] of PMU_PWRMODE_CON register. After setting the register, PMU would enter the Low Power mode. In the low power mode, pmu will auto power on/off the specified power domain, send idle req to specified power domain, shut down/up pll and so on. All of above are configurable by setting corresponding registers. Signed-off-by: Caesar Wang <wxt@rock-chips.com> Reviewed-by: Kevin Hilman <khilman@linaro.org> [replace dsb() with dsb(sy) for arm64 buildability; sy is the default, so no functional change; adapt to per-user clocks in genpd] Signed-off-by: Heiko Stuebner <heiko@sntech.de>
show more ...
|