- 13 Dec, 2023 4 commits
-
-
Peter Griffin authored
Add initial board support for the Pixel 6 phone code named Oriole. This has been tested with a minimal busybox initramfs and boots to a shell. Tested-by:
Will McVicker <willmcvicker@google.com> Reviewed-by:
Sam Protsenko <semen.protsenko@linaro.org> Signed-off-by:
Peter Griffin <peter.griffin@linaro.org> Reviewed-by:
Alim Akhtar <alim.akhtar@samsung.com> Link: https://lore.kernel.org/r/20231211162331.435900-16-peter.griffin@linaro.orgSigned-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
-
Peter Griffin authored
Google gs101 SoC is a ARMv8 mobile SoC found in the Pixel 6 (oriole), Pixel 6a (bluejay) and Pixel 6 pro (raven) mobile phones. It features: * 4xA55 Little cluster * 2xA76 Mid cluster * 2xX1 Big cluster This commit adds the basic device tree for gs101 (SoC). Further platform support will be added over time. Reviewed-by:
-
Peter Griffin authored
This introduces bindings and dt-schema for the Google Tensor SoCs. Currently just gs101 and pixel 6 are supported. Reviewed-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20231211162331.435900-3-peter.griffin@linaro.orgSigned-off-by:
-
Aakarsh Jain authored
Add MFC DT node and reserve memory node for MFC usage. Cc: <linux-fsd@tesla.com> Signed-off-by:
Smitha T Murthy <smithatmurthy@gmail.com> Signed-off-by:
Aakarsh Jain <aakarsh.jain@samsung.com> Link: https://lore.kernel.org/r/20231206063045.97234-12-aakarsh.jain@samsung.comSigned-off-by:
-
- 11 Dec, 2023 4 commits
-
-
Krzysztof Kozlowski authored
-
Jaewon Kim authored
ExynosAutov920 SADK is ExynosAutov920 SoC based SADK(Samsung Automotive Development Kit) board. It has 16GB(8GB + 8GB) LPDDR5 RAM and 256GB (128GB + 128GB) UFS. This is minimal support board device-tree. * Serial console * GPIO Key * PWM FAN Signed-off-by:
Jaewon Kim <jaewon02.kim@samsung.com> Link: https://lore.kernel.org/r/20231208074527.50840-3-jaewon02.kim@samsung.comSigned-off-by:
-
Jaewon Kim authored
Samsung ExynosAutov920 is ARMv8-based automotive-oriented SoC. It has AE(Automotive Enhanced) IPs for safety. * Cortex-A78AE 10-cores * GIC-600AE This is minimal support for ExynosAutov920 SoC. * Enumerate all pinctrl nodes * Enable Chip-Id * Serial0 for console * PWM Since the clock driver is not yet implemented, it is supported as fixed-clock. Signed-off-by:
-
Krzysztof Kozlowski authored
No need to create a new enum every time we bring-up new SoC. Reviewed-by:
-
- 10 Dec, 2023 3 commits
-
-
Peter Griffin authored
GS101 has three different SYSREG controllers, add dedicated compatibles for them to the documentation. Reviewed-by:
-
Peter Griffin authored
Provide dt-schema documentation for Google gs101 SoC clock controller. Currently this adds support for cmu_top, cmu_misc and cmu_apm. Reviewed-by:
-
Peter Griffin authored
Add gs101-pmu compatible to the bindings documentation. Reviewed-by:
-
- 07 Dec, 2023 7 commits
-
-
Krzysztof Kozlowski authored
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. This will also help reviews of new code using existing DTS as template. No functional impact on Linux drivers behavior. Acked-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20231205092229.19135-7-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
-
Krzysztof Kozlowski authored
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by:
-
Krzysztof Kozlowski authored
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by:
-
Krzysztof Kozlowski authored
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by:
-
Krzysztof Kozlowski authored
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by:
-
Krzysztof Kozlowski authored
Tesla FSD is a derivative of Samsung Exynos SoC, thus just like the others it reuses several devices from older designs. Historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add Tesla FSD compatible specific to be used with an existing fallback. Acked-by:
-
- 24 Nov, 2023 2 commits
-
-
Krzysztof Kozlowski authored
ExynosAutov9 pin controller capable of wake-ups is still compatible with Exynos7, however it does not mux interrupts. Add Exynos7 compatible fallback to annotate that compatibility and match the bindings. Link: https://lore.kernel.org/r/20231122200407.423264-3-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
Exynos850 pin controller capable of wake-ups is still compatible with Exynos7, however it does not mux interrupts. Add Exynos7 compatible fallback to annotate that compatibility and match the bindings. Link: https://lore.kernel.org/r/20231122200407.423264-2-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
- 15 Nov, 2023 20 commits
-
-
Krzysztof Kozlowski authored
-
Jaewon Kim authored
Add "samsung,exynosautov920-chipid" compatible string to binding document. Signed-off-by:
-
Jaewon Kim authored
Add binding for the ExynosAutov920 SADK(Samsung Automotive Development Kit) board. Signed-off-by:
-
Jaewon Kim authored
Add samsung,exynosautov920-pwm compatible string to binding document. Signed-off-by:
-
Jaewon Kim authored
Add samsung,exynosautov9-uart dedicated compatible for representing uart of ExynosAutov920 SoC. Signed-off-by:
-
Jaewon Kim authored
Add samsung,exynosautov920-usi dedicated compatible for representing USI of ExynosAutoV920 SoC. Signed-off-by:
-
Jaewon Kim authored
Add samsung,exynosautov920-pmu compatible for representing pmu of ExynosAutov920 SoC. Signed-off-by:
-
Jaewon Kim authored
Add compatible for ExynosAutov920 sysreg controllers. Signed-off-by:
-
Jaewon Kim authored
ExynosAutov9 SADK board has 3 keys to test external GPIO interrupt. To support this, add 3 gpio-key(Wakeup, Volume Down, Volume Up) node. Signed-off-by:
-
Krzysztof Kozlowski authored
ExynosAutov9 reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to ExynosAutov9 in front of all old-SoC-like compatibles. This will also help reviews of new code using existing DTS as template. No functional impact on Linux drivers behavior. Reviewed-by:
-
Krzysztof Kozlowski authored
Exynos850 reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to Exynos850 in front of all old-SoC-like compatibles. This will also help reviews of new code using existing DTS as template. No functional impact on Linux drivers behavior. Reviewed-by:
-
Krzysztof Kozlowski authored
Exynos7885 reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to Exynos7885 in front of all old-SoC-like compatibles. This will also help reviews of new code using existing DTS as template. No functional impact on Linux drivers behavior. Reviewed-by:
-
Krzysztof Kozlowski authored
Exynos7 reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to Exynos7 in front of all old-SoC-like compatibles. This will also help reviews of new code using existing DTS as template. No functional impact on Linux drivers behavior. Reviewed-by:
-
Krzysztof Kozlowski authored
Exynos5433 reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to Exynos5433 in front of all old-SoC-like compatibles. This will also help reviews of new code using existing DTS as template. No functional impact on Linux drivers behavior. Reviewed-by:
-
Krzysztof Kozlowski authored
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by:
-
Krzysztof Kozlowski authored
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by:
Lee Jones <lee@kernel.org> Acked-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20231108104343.24192-12-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Krzysztof Kozlowski authored
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by:
-
Krzysztof Kozlowski authored
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by:
-
Krzysztof Kozlowski authored
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Reviewed-by:
-
Krzysztof Kozlowski authored
Samsung Exynos SoC reuses several devices from older designs, thus historically we kept the old (block's) compatible only. This works fine and there is no bug here, however guidelines expressed in Documentation/devicetree/bindings/writing-bindings.rst state that: 1. Compatibles should be specific. 2. We should add new compatibles in case of bugs or features. Add compatibles specific to each SoC in front of all old-SoC-like compatibles. Re-shuffle also the entries in compatibles, so the one-compatible-enum is the first. Reviewed-by:
-
