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, v5.15.35, v5.15.34, v5.15.33 |
|
#
5d6f5267 |
| 04-Apr-2022 |
Arnd Bergmann <arnd@arndb.de> |
ARM: rework endianess selection
Choosing big-endian vs little-endian kernels in Kconfig has not worked correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long time ago.
The problems is
ARM: rework endianess selection
Choosing big-endian vs little-endian kernels in Kconfig has not worked correctly since the introduction of CONFIG_ARCH_MULTIPLATFORM a long time ago.
The problems is that CONFIG_BIG_ENDIAN depends on ARCH_SUPPORTS_BIG_ENDIAN, which can set by any one platform in the config, but would actually have to be supported by all of them.
This was mostly ok for ARMv6/ARMv7 builds, since these are BE8 and tend to just work aside from problems in nonportable device drivers. For ARMv4/v5 machines, CONFIG_BIG_ENDIAN and CONFIG_ARCH_MULTIPLATFORM were never set together, so this was disabled on all those machines except for IXP4xx.
As IXP4xx can now become part of ARCH_MULTIPLATFORM, it seems better to formalize this logic: all ARMv4/v5 platforms get an explicit dependency on being either big-endian (ixp4xx) or little-endian (the rest). We may want to fix ixp4xx in the future to support both, but it does not work in LE mode at the moment.
For the ARMv6/v7 platforms, there are two ways this could be handled
a) allow both modes only for platforms selecting 'ARCH_SUPPORTS_BIG_ENDIAN' today, but only LE mode for the others, given that these were added intentionally at some point.
b) allow both modes everwhere, given that it was already possible to build that way by e.g. selecting ARCH_VIRT, and that the list is not an accurate reflection of which platforms may or may not work.
Out of these, I picked b) because it seemed slighly more logical to me.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: 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, 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, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, 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 |
|
#
52835d59 |
| 04-Apr-2017 |
Dave Gerlach <d-gerlach@ti.com> |
soc: ti: Add ti_sci_pm_domains driver
Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider to allow each device to attach and associate it's ti-sci-id so that it can be contro
soc: ti: Add ti_sci_pm_domains driver
Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider to allow each device to attach and associate it's ti-sci-id so that it can be controlled through the TI SCI protocol.
This driver implements a simple genpd where each device node has a phandle to the power domain node and also must provide an index which represents the ID to be passed with TI SCI representing the device using a single phandle cell. The driver manually parses the phandle to get the cell value. Through this interface the genpd dev_ops start and stop hooks will use TI SCI to turn on and off each device as determined by pm_runtime usage.
Reviewed-by: Kevin Hilman <khilman@baylibre.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
show more ...
|
Revision tags: 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 |
|
#
a2735c30 |
| 19-Jan-2017 |
Suman Anna <s-anna@ti.com> |
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
The Keystone 2 family of SoCs will use various Reset Controller drivers for managing the resets of remote processor devices like DSPs on the SoC, so s
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER
The Keystone 2 family of SoCs will use various Reset Controller drivers for managing the resets of remote processor devices like DSPs on the SoC, so select the ARCH_HAS_RESET_CONTROLLER option by default to enable the Reset framework.
Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
show more ...
|
Revision tags: v4.9, openbmc-4.4-20161121-1, v4.4.33, 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 |
|
#
e13688fe |
| 14-Sep-2016 |
Kishon Vijay Abraham I <kishon@ti.com> |
ARM: select PCI_DOMAINS config from ARCH_MULTIPLATFORM
PCI_DOMAINS config should be selected for any SoCs having more than a single PCIe controller. Without PCI_DOMAINS config, only one PCIe control
ARM: select PCI_DOMAINS config from ARCH_MULTIPLATFORM
PCI_DOMAINS config should be selected for any SoCs having more than a single PCIe controller. Without PCI_DOMAINS config, only one PCIe controller gets registered.
Select PCI_DOMAINS in ARCH_MULTIPLATFORM if PCI is selected, since it doesn't harm even if a platform has a single PCIe port. Also remove PCI_DOMAINS being selected from other platform specific configs.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
6016b23b |
| 14-Sep-2016 |
Kishon Vijay Abraham I <kishon@ti.com> |
ARM: stop *MIGHT_HAVE_PCI* config from being selected redundantly
*MIGHT_HAVE_PCI* config is already selected in ARCH_MULTIPLATFORM. Don't select it redundantly in all ARCH_MULTIPLATFORM based machi
ARM: stop *MIGHT_HAVE_PCI* config from being selected redundantly
*MIGHT_HAVE_PCI* config is already selected in ARCH_MULTIPLATFORM. Don't select it redundantly in all ARCH_MULTIPLATFORM based machines.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com> Acked-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: 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 |
|
#
c12547a0 |
| 03-Jun-2016 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
clocksource/drivers/keystone: Add the COMPILE_TEST option
Change the Kconfig option logic to fullfil with the current approach.
A new Kconfig option is added, CONFIG_KEYSTONE_TIMER and is selected
clocksource/drivers/keystone: Add the COMPILE_TEST option
Change the Kconfig option logic to fullfil with the current approach.
A new Kconfig option is added, CONFIG_KEYSTONE_TIMER and is selected by the platform. Then the clocksource's Kconfig is changed to make this option selectable by the user if the COMPILE_TEST option is set. Otherwise, it is up to the platform's Kconfig to select the timer.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
show more ...
|
#
229a4bc8 |
| 14-Jun-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
ARM: keystone: remove redundant depends on ARM_PATCH_PHYS_VIRT
KeyStone is Multi-platform. ARM_PATCH_PHYS_VIRT is already select'ed by ARCH_MULTIPLATFORM.
Signed-off-by: Masahiro Yamada <yamada.ma
ARM: keystone: remove redundant depends on ARM_PATCH_PHYS_VIRT
KeyStone is Multi-platform. ARM_PATCH_PHYS_VIRT is already select'ed by ARCH_MULTIPLATFORM.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
show more ...
|
#
2689d180 |
| 08-Jun-2016 |
Lokesh Vutla <lokeshvutla@ti.com> |
ARM: keystone: Enable PINCTRL config
Some Keystone 2 devices utilize pinmuxing which requires PINCTRL to be enabled. Therefore, enable PINCTRL for all Keystone 2 devices.
Signed-off-by: Lokesh Vutl
ARM: keystone: Enable PINCTRL config
Some Keystone 2 devices utilize pinmuxing which requires PINCTRL to be enabled. Therefore, enable PINCTRL for all Keystone 2 devices.
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Franklin S Cooper Jr <fcooper@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
show more ...
|
Revision tags: 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, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3 |
|
#
443fcf63 |
| 29-Oct-2014 |
Murali Karicheri <m-karicheri2@ti.com> |
ARM: keystone: add pcie related options
Now that Keystone PCI controller is merged, add pcie related options by default for keystone architecture so that driver can be enabled in the build.
Signed-
ARM: keystone: add pcie related options
Now that Keystone PCI controller is merged, add pcie related options by default for keystone architecture so that driver can be enabled in the build.
Signed-off-by: Murali Karicheri <m-karicheri2@ti.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
show more ...
|
Revision tags: v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6 |
|
#
13ee8955 |
| 12-May-2014 |
Arnd Bergmann <arnd@arndb.de> |
ARM: keystone requires ARM_PATCH_PHYS_VIRT
The dynamic relocation that the keystone platform performs only works if we can pick the phys offset at boot time. It's possible that there is another solu
ARM: keystone requires ARM_PATCH_PHYS_VIRT
The dynamic relocation that the keystone platform performs only works if we can pick the phys offset at boot time. It's possible that there is another solution for this, but this is the easiest workaround. Kernels with ARM_PATCH_PHYS_VIRT are not portable across platforms, and I see no reason why anyone would run a kernel without ARM_PATCH_PHYS_VIRT on keystone.
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
Revision tags: v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3, v3.14-rc2, v3.14-rc1 |
|
#
90bc8ac7 |
| 31-Jan-2014 |
Rob Herring <robh@kernel.org> |
ARM: select HAVE_SMP for V7 multi-platform
All V7 platforms can run SMP kernels, so make CONFIG_SMP visible for V7 multi-platform builds.
Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Step
ARM: select HAVE_SMP for V7 multi-platform
All V7 platforms can run SMP kernels, so make CONFIG_SMP visible for V7 multi-platform builds.
Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Stephen Warren <swarren@nvidia.com> Acked-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
Revision tags: v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1 |
|
#
ddb902cc |
| 22-Nov-2013 |
Rob Herring <robh@kernel.org> |
ARM: centralize common multi-platform kconfig options
Multi-platform requires various kconfig options to be selected, so platforms don't need to select them individually.
Signed-off-by: Rob Herring
ARM: centralize common multi-platform kconfig options
Multi-platform requires various kconfig options to be selected, so platforms don't need to select them individually.
Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Cc: Russell King <linux@arm.linux.org.uk> Acked-by: Stephen Warren <swarren@nvidia.com> Tested-by: Stephen Warren <swarren@wwwdotorg.org> Acked-by: Arnd Bergmann <arnd@arndb.de>
show more ...
|
#
e324f7c9 |
| 09-Jan-2014 |
Grygorii Strashko <grygorii.strashko@ti.com> |
ARM: keystone: config: fix build warning when CONFIG_DMADEVICES is not set
Drop automatic selection of TI_EDMA from Keystone Kconfig file, as it produces build warning in case if CONFIG_DMADEVICES i
ARM: keystone: config: fix build warning when CONFIG_DMADEVICES is not set
Drop automatic selection of TI_EDMA from Keystone Kconfig file, as it produces build warning in case if CONFIG_DMADEVICES is not set:
warning: (ARCH_KEYSTONE) selects TI_EDMA which has unmet direct dependencies (DMADEVICES && (ARCH_DAVINCI || ARCH_OMAP || ARCH_KEYSTONE))
Instead enable TI EDMA support from defconfig.
Reported-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com> Signed-off-by: Olof Johansson <olof@lixom.net>
show more ...
|
#
df595a9d |
| 23-Nov-2013 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
ARM: keystone: enable DMA zone for LPAE
Keystone II peripheral devices support 32-bit DMA and hence can access only first 2GB of the memory address space. So set the platform dma_zone_size to handle
ARM: keystone: enable DMA zone for LPAE
Keystone II peripheral devices support 32-bit DMA and hence can access only first 2GB of the memory address space. So set the platform dma_zone_size to handle that case.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
#
89b3feef |
| 23-Nov-2013 |
Taras Kondratiuk <taras.kondratiuk@linaro.org> |
ARM: keystone: enable big endian support
Keystone code is big endian compatible, so mark it as one that supports big endian.
Note this patch just allows to select Big endian build for ARCH_KEYSTONE
ARM: keystone: enable big endian support
Keystone code is big endian compatible, so mark it as one that supports big endian.
Note this patch just allows to select Big endian build for ARCH_KEYSTONE, but it does not enable BE by default.
Signed-off-by: Taras Kondratiuk <taras.kondratiuk@linaro.org> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
Revision tags: v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4 |
|
#
700e2629 |
| 30-Sep-2013 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
ARM: keystone: Select TI_EDMA to be able to enable SPI driver
Select the TI EDMA to be able to enable SPI driver on Keystone SOCs. Keystone SOCs share the EDMA IP with other TI SOCs.
Note that EDMA
ARM: keystone: Select TI_EDMA to be able to enable SPI driver
Select the TI EDMA to be able to enable SPI driver on Keystone SOCs. Keystone SOCs share the EDMA IP with other TI SOCs.
Note that EDMA support hasn't been added and tested yet for Keystone SOC data(device tree), but building it, is harmless since driver like SPI already takes care of supporting non-dma mode in the absence of such data.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
Revision tags: v3.12-rc3, v3.12-rc2, v3.12-rc1, v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1 |
|
#
4a19aad2 |
| 14-Jul-2013 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
ARM: keystone: Enable clock drivers
Enable common clock drivers on Keystone 2 based SOCs.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
|
#
7da080de |
| 14-Jul-2013 |
Paul Bolle <pebolle@tiscali.nl> |
ARM: keystone: drop useless HAVE_SCHED_CLOCK
The Kconfig symbol HAVE_SCHED_CLOCK got removed in v3.4, with commit 6905a65879b5 ("ARM: Make the sched_clock framework mandatory"). But a select stateme
ARM: keystone: drop useless HAVE_SCHED_CLOCK
The Kconfig symbol HAVE_SCHED_CLOCK got removed in v3.4, with commit 6905a65879b5 ("ARM: Make the sched_clock framework mandatory"). But a select statement for it popped up again through commit 828989ad87af ("ARM: keystone: Add minimal TI Keystone platform support"). Drop that statement, as it is useless.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl> [santosh.shilimkar@ti.com: Minor edit in the subject] Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
Revision tags: v3.10, v3.10-rc7 |
|
#
ec711d6e |
| 21-Jun-2013 |
Arnd Bergmann <arnd@arndb.de> |
ARM: keystone: select ARM_ERRATA_798181 only for SMP
Selecting this symbol causes a build warning without SMP:
warning: (ARCH_KEYSTONE) selects ARM_ERRATA_798181 which has unmet direct dependencies
ARM: keystone: select ARM_ERRATA_798181 only for SMP
Selecting this symbol causes a build warning without SMP:
warning: (ARCH_KEYSTONE) selects ARM_ERRATA_798181 which has unmet direct dependencies (CPU_V7 && SMP)
Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
Revision tags: v3.10-rc6 |
|
#
f07cb6a0 |
| 10-Jun-2013 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
ARM: keystone: Enable SMP support on Keystone machines
Add basic SMP support for Keystone machines. This does not include support for CPU hotplug for now.
Cc: Arnd Bergmann <arnd@arndb.de> Cc: arm@
ARM: keystone: Enable SMP support on Keystone machines
Add basic SMP support for Keystone machines. This does not include support for CPU hotplug for now.
Cc: Arnd Bergmann <arnd@arndb.de> Cc: arm@kernel.org
Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
#
828989ad |
| 10-Jun-2013 |
Santosh Shilimkar <santosh.shilimkar@ti.com> |
ARM: keystone: Add minimal TI Keystone platform support
Texas Instruments Keystone family of multi-core devices are based on ARM Cortex A15. Patch adds basic definitions for a new Keystone sub-archi
ARM: keystone: Add minimal TI Keystone platform support
Texas Instruments Keystone family of multi-core devices are based on ARM Cortex A15. Patch adds basic definitions for a new Keystone sub-architecture in ARM.
The TCI66xxK2H Communications Infrastructure Keystone SoCs are member of the C66x family based on TI's new KeyStone 2 multi-core SoC Architecture designed specifically for high performance wireless and networking infrastructure applications. The SOCs contains many subsystems like Cortex A15 ARM CorePacs, C66XX DSP CorePacs, MSMC memory controller, Tera Net bus, IP Network, Navigator, Hyperlink, 1G/10G Ethernet, Radio layers and queue based communication systems.
Cc: Arnd Bergmann <arnd@arndb.de> Cc: arm@kernel.org
Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
show more ...
|
Revision tags: 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, 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, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, 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 |
|
#
52835d59 |
| 04-Apr-2017 |
Dave Gerlach <d-gerlach@ti.com> |
soc: ti: Add ti_sci_pm_domains driver Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider to allow each device to attach and associate it's ti-sci-id so that
soc: ti: Add ti_sci_pm_domains driver Introduce a ti_sci_pm_domains driver to act as a generic pm domain provider to allow each device to attach and associate it's ti-sci-id so that it can be controlled through the TI SCI protocol. This driver implements a simple genpd where each device node has a phandle to the power domain node and also must provide an index which represents the ID to be passed with TI SCI representing the device using a single phandle cell. The driver manually parses the phandle to get the cell value. Through this interface the genpd dev_ops start and stop hooks will use TI SCI to turn on and off each device as determined by pm_runtime usage. Reviewed-by: Kevin Hilman <khilman@baylibre.com> Acked-by: Santosh Shilimkar <ssantosh@kernel.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Keerthy <j-keerthy@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Dave Gerlach <d-gerlach@ti.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
show more ...
|
Revision tags: 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 |
|
#
a2735c30 |
| 19-Jan-2017 |
Suman Anna <s-anna@ti.com> |
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER The Keystone 2 family of SoCs will use various Reset Controller drivers for managing the resets of remote processor devices like DSPs
ARM: Keystone: Enable ARCH_HAS_RESET_CONTROLLER The Keystone 2 family of SoCs will use various Reset Controller drivers for managing the resets of remote processor devices like DSPs on the SoC, so select the ARCH_HAS_RESET_CONTROLLER option by default to enable the Reset framework. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Nishanth Menon <nm@ti.com> Signed-off-by: Santosh Shilimkar <ssantosh@kernel.org>
show more ...
|