This bus has three USB-related devices attached to it:
0x25: Maxim 77759 Type-C port controller
0x35: Maxim 20339EWB Surge protection IC
0x36: Maxim 77759 Fuel gauge
0x57: NXP PCA9468 Battery charger
0x66: Maxim 77759 PMIC
0x69: Maxim 77759 Charger
where the Maxim 77759 has multiple i2c slave addresses.
These don't have (upstream) Linux drivers yet, but nevertheless we can
enable the bus so as to allow working on them (and to make i2cdetect /
i2cdump / etc. work).
Signed-off-by: André Draszik <andre.draszik@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20240201161258.1013664-8-andre.draszik@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
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: Jaewon Kim <jaewon02.kim@samsung.com>
Link: https://lore.kernel.org/r/20231208074527.50840-2-jaewon02.kim@samsung.com
[krzysztof: Re-order nodes to match coding style: UFS reset pins,
gpg/gpp in peric0 and peric1, all nodes in the soc@0;
drop fallback compatibles from wakeup-interrupt-controller]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
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: Alim Akhtar <alim.akhtar@samsung.com>
Link: https://lore.kernel.org/r/20231108104343.24192-18-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
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: Alim Akhtar <alim.akhtar@samsung.com>
Link: https://lore.kernel.org/r/20231108104343.24192-17-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
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: Alim Akhtar <alim.akhtar@samsung.com>
Link: https://lore.kernel.org/r/20231108104343.24192-16-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
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: Alim Akhtar <alim.akhtar@samsung.com>
Link: https://lore.kernel.org/r/20231108104343.24192-15-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
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: Alim Akhtar <alim.akhtar@samsung.com>
Link: https://lore.kernel.org/r/20231108104343.24192-14-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reserve a 2 MiB memory region to record kmsg dumps, console, ftrace and
userspace messages. The implemented memory split allows capturing and
reading corresponding ring buffers:
* dmesg: 6 dumps, 128 KiB each
* console: 128 KiB
* ftrace: 128 KiB for each of 8 CPUs (1 MiB total)
* userspace messages: 128 KiB
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20231008033633.21304-1-semen.protsenko@linaro.org
[krzysztof: move the node to alphabetically sorted position]
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The E850-96 board has a micro-USB socket and two USB 2.0 host sockets.
The USB role (host or peripheral) is selected automatically depending on
micro-USB cable attachment state:
- micro-USB cable is attached: USB device role
- micro-USB cable is detached: USB host role
USB can't act simultaneously as a device and a host, because Exynos850
SoC has only one USB controller and there are no external USB
controllers on the E850-96 board. So the USB switch chip (specifically
TS3USB221A) connects SoC USB lines either to micro-USB connector or to
USB hub chip (LAN9514), w.r.t. micro-USB cable attachment state.
When USB works in the host role, Ethernet capability becomes available
too, as the LAN9514 chip (providing USB hub) also enables Ethernet PHY
and Ethernet MAC.
Dynamic role switching is done in gpio-usb-b-connector, using current
micro-USB VBUS line level as a trigger:
- VBUS=high: SoC USB lines are wired to micro-USB socket
- VBUS=low: SoC USB lines are wired to USB hub chip
In order to make USB host functional when the board was booted with
micro-USB cable disconnected, role-switch-default-mode = "host" is used.
One can use E850-96 board schematics [1] to figure out how exactly all
related USB hardware connections and lines reflect into corresponding
device tree definitions.
As PMIC regulators are not implemented yet, we rely on USB LDOs being
already enabled in the bootloader. A dummy regulator is provided to
"usbdrd" vdd nodes for now.
[1] https://www.96boards.org/documentation/consumer/e850-96b/hardware-docs/
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20230825215445.28309-3-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Add USB controller and USB PHY controller nodes for Exynos850 SoC.
The USB controller has next features:
- Dual Role Device (DRD) controller
- DWC3 compatible
- Supports USB 2.0 host and USB 2.0 device interfaces
- Supports full-speed (12 Mbps) and high-speed (480 Mbps) modes with
USB device 2.0 interface
- Supports on-chip USB PHY transceiver
- Supports up to 16 bi-directional endpoints (that includes control
endpoint 0)
- Complies with xHCI 1.00 specification
Only USB 2.0 is supported in Exynos850, so only UTMI+ PHY interface is
specified in "phys" property (index 0) and PIPE3 is omitted (index 1).
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Link: https://lore.kernel.org/r/20230825215445.28309-2-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Previously, the mshc0 alias has been necessary so that
MMC_CAP_1_8V_DDR | MMC_CAP_8_BIT_DATA are set for mshc_0/mmc_0.
However, these capabilities should be described in the device tree so
that we do not have to rely on the alias.
The property mmc-ddr-1_8v replaces MMC_CAP_1_8V_DDR, while bus_width =
<8>, which is already set for all the mshc0/mmc0 nodes, replaces
MMC_CAP_8_BIT_DATA.
Also drop other mshc aliases as they are not needed.
Signed-off-by: Henrik Grimler <henrik@grimler.se>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20230315212814.15908-2-henrik@grimler.se
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Neither simple-bus bindings nor dtc W=1 accept device nodes in soc@ node
which do not have unit address. Therefore usethe address space
of child device (actual DWC3 Controller) as the wrapper's address to
fix:
exynos5433-tm2e.dtb: soc@0: usbdrd: {'compatible': ['samsung,exynos5433-dwusb3'], ...
should not be valid under {'type': 'object'}
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Link: https://lore.kernel.org/r/20230127212713.267014-3-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
The soc node is supposed to have only device nodes with MMIO addresses,
as reported by dtc W=1:
exynos5433-bus.dtsi:10.20-16.4:
Warning (simple_bus_reg): /soc@0/bus0: missing or empty reg/ranges property
and dtbs_check:
exynos5433-tm2.dtb: soc@0: bus1:
{'compatible': ['samsung,exynos-bus'], 'clocks': [[21, 220]], 'clock-names': ['bus'], 'operating-points-v2': [[165]], 'status': ['okay'], 'devfreq': [[166]]} should not be valid under {'type': 'object'}
Move the bus nodes and their OPP tables out of SoC to fix this.
Link: https://lore.kernel.org/r/20230125094513.155063-8-krzysztof.kozlowski@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
