USI8 I2C is used to communicate with an eeprom found on the battery
connector. Define USI8 in I2C configuration.
USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
selection of the protocol is intentionally left for the board dts file.
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
arch/arm64/boot/dts/exynos/google/gs101.dtsi | 29 ++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/google/gs101.dtsi b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
index 6aa25cc4676e..f14a24628d04 100644
--- a/arch/arm64/boot/dts/exynos/google/gs101.dtsi
+++ b/arch/arm64/boot/dts/exynos/google/gs101.dtsi
@@ -352,6 +352,35 @@ pinctrl_peric0: pinctrl@10840000 {
interrupts = <GIC_SPI 625 IRQ_TYPE_LEVEL_HIGH 0>;
};
+ usi8: usi@109700c0 {
+ compatible = "google,gs101-usi",
+ "samsung,exynos850-usi";
+ reg = <0x109700c0 0x20>;
+ ranges;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ clocks = <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>,
+ <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>;
+ clock-names = "pclk", "ipclk";
+ samsung,sysreg = <&sysreg_peric0 0x101c>;
+ status = "disabled";
+
+ hsi2c_8: i2c@10970000 {
+ compatible = "google,gs101-hsi2c",
+ "samsung,exynosautov9-hsi2c";
+ reg = <0x10970000 0xc0>;
+ interrupts = <GIC_SPI 642 IRQ_TYPE_LEVEL_HIGH 0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&hsi2c8_bus>;
+ clocks = <&cmu_peric0 CLK_GOUT_PERIC0_PERIC0_TOP0_IPCLK_7>,
+ <&cmu_peric0 CLK_GOUT_PERIC0_CLK_PERIC0_USI8_USI_CLK>;
+ clock-names = "hsi2c", "hsi2c_pclk";
+ status = "disabled";
+ };
+ };
+
usi_uart: usi@10a000c0 {
compatible = "google,gs101-usi",
"samsung,exynos850-usi";
--
2.43.0.429.g432eaa2c6b-googOn 19/01/2024 12:11, Tudor Ambarus wrote: > USI8 I2C is used to communicate with an eeprom found on the battery > connector. Define USI8 in I2C configuration. > > USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8 > doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the > selection of the protocol is intentionally left for the board dts file. ... and dropped, because this patch does not build: https://krzk.eu/#/builders/29/builds/3869 and I missed weird dependency mentioned in cover letter: "This patch set shall be queued after the cmu_misc clock name fixes from:" Sorry, this cannot work like that. DTS for new features cannot build depend on driver changes. Best regards, Krzysztof
On 1/23/24 07:52, Krzysztof Kozlowski wrote: > On 19/01/2024 12:11, Tudor Ambarus wrote: >> USI8 I2C is used to communicate with an eeprom found on the battery >> connector. Define USI8 in I2C configuration. >> >> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8 >> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the >> selection of the protocol is intentionally left for the board dts file. > > ... and dropped, because this patch does not build: > https://krzk.eu/#/builders/29/builds/3869 > and I missed weird dependency mentioned in cover letter: > > "This patch set shall be queued after the cmu_misc clock name fixes from:" > > Sorry, this cannot work like that. DTS for new features cannot build > depend on driver changes. No worries. What shall I do so that you re-consider the dropped patches? I'm not yet familiar with your release management, but I guess that if you submit your "fixes-clk" branch for integration into v6.8-rc2, and then merge v6.8-rc2 into your "next/dt64", you'll then be able to queue the dropped patches as well. Thanks, ta
On 23/01/2024 09:34, Tudor Ambarus wrote: > > > On 1/23/24 07:52, Krzysztof Kozlowski wrote: >> On 19/01/2024 12:11, Tudor Ambarus wrote: >>> USI8 I2C is used to communicate with an eeprom found on the battery >>> connector. Define USI8 in I2C configuration. >>> >>> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8 >>> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the >>> selection of the protocol is intentionally left for the board dts file. >> >> ... and dropped, because this patch does not build: >> https://krzk.eu/#/builders/29/builds/3869 >> and I missed weird dependency mentioned in cover letter: >> >> "This patch set shall be queued after the cmu_misc clock name fixes from:" >> >> Sorry, this cannot work like that. DTS for new features cannot build >> depend on driver changes. > > No worries. What shall I do so that you re-consider the dropped patches? > I'm not yet familiar with your release management, but I guess that if > you submit your "fixes-clk" branch for integration into v6.8-rc2, and > then merge v6.8-rc2 into your "next/dt64", you'll then be able to queue > the dropped patches as well. It is nothing specific to my release management but years old rule: DTS branch cannot contain driver commits. It is nothing new, discussed on mailing lists for various SoC architectures many times. However I don't fully understand why that dependency - except patch hunk context - exists. You shouldn't have such dependency. Best regards, Krzysztof
On 1/23/24 08:39, Krzysztof Kozlowski wrote: > On 23/01/2024 09:34, Tudor Ambarus wrote: >> >> >> On 1/23/24 07:52, Krzysztof Kozlowski wrote: >>> On 19/01/2024 12:11, Tudor Ambarus wrote: >>>> USI8 I2C is used to communicate with an eeprom found on the battery >>>> connector. Define USI8 in I2C configuration. >>>> >>>> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8 >>>> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the >>>> selection of the protocol is intentionally left for the board dts file. >>> >>> ... and dropped, because this patch does not build: >>> https://krzk.eu/#/builders/29/builds/3869 >>> and I missed weird dependency mentioned in cover letter: >>> >>> "This patch set shall be queued after the cmu_misc clock name fixes from:" >>> >>> Sorry, this cannot work like that. DTS for new features cannot build >>> depend on driver changes. >> >> No worries. What shall I do so that you re-consider the dropped patches? >> I'm not yet familiar with your release management, but I guess that if >> you submit your "fixes-clk" branch for integration into v6.8-rc2, and >> then merge v6.8-rc2 into your "next/dt64", you'll then be able to queue >> the dropped patches as well. > > It is nothing specific to my release management but years old rule: DTS > branch cannot contain driver commits. It is nothing new, discussed on > mailing lists for various SoC architectures many times. Okay, thanks for the explanation. > > However I don't fully understand why that dependency - except patch hunk > context - exists. You shouldn't have such dependency. > Let me try offline, I'll get back to you.
On 1/23/24 08:44, Tudor Ambarus wrote: >> However I don't fully understand why that dependency - except patch hunk >> context - exists. You shouldn't have such dependency. >> > Let me try offline, I'll get back to you. The dropped patches depend on the dt-bindings patch that you queued through the "next/drivers" branch: b393a6c5e656 dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit We need the peric0 bindings that are referenced in device tree, that's why the next/dt64 branch failed to build. Please let me know if there's something on my side that I have to do (now or in the future). Thanks, ta
On 23/01/2024 09:57, Tudor Ambarus wrote: > > > On 1/23/24 08:44, Tudor Ambarus wrote: >>> However I don't fully understand why that dependency - except patch hunk >>> context - exists. You shouldn't have such dependency. >>> >> Let me try offline, I'll get back to you. > > The dropped patches depend on the dt-bindings patch that you queued > through the "next/drivers" branch: > > b393a6c5e656 dt-bindings: clock: google,gs101-clock: add PERIC0 clock > management unit > > We need the peric0 bindings that are referenced in device tree, that's > why the next/dt64 branch failed to build. > > Please let me know if there's something on my side that I have to do > (now or in the future). It is useful to mention this in cover letter, so I will know how to apply the patches. I understand therefore the dependency mention in the cover letter is not accurate, so I can ignore that aspect. Best regards, Krzysztof
On 1/23/24 08:59, Krzysztof Kozlowski wrote: > On 23/01/2024 09:57, Tudor Ambarus wrote: >> >> >> On 1/23/24 08:44, Tudor Ambarus wrote: >>>> However I don't fully understand why that dependency - except patch hunk >>>> context - exists. You shouldn't have such dependency. >>>> >>> Let me try offline, I'll get back to you. >> >> The dropped patches depend on the dt-bindings patch that you queued >> through the "next/drivers" branch: >> >> b393a6c5e656 dt-bindings: clock: google,gs101-clock: add PERIC0 clock >> management unit >> >> We need the peric0 bindings that are referenced in device tree, that's >> why the next/dt64 branch failed to build. >> >> Please let me know if there's something on my side that I have to do >> (now or in the future). > > It is useful to mention this in cover letter, so I will know how to > apply the patches. I understand therefore the dependency mention in the Thanks for the patience, I learn along the way. > cover letter is not accurate, so I can ignore that aspect. > Yes, that's right. The dependency on name fixes is just as a patch hunk context, no functional or build dependencies. I now know the process, and I'll be more verbose next time. Cheers, ta
On Fri, 19 Jan 2024 11:11:31 +0000, Tudor Ambarus wrote:
> USI8 I2C is used to communicate with an eeprom found on the battery
> connector. Define USI8 in I2C configuration.
>
> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
> selection of the protocol is intentionally left for the board dts file.
>
> [...]
Applied, thanks!
[7/8] arm64: dts: exynos: gs101: define USI8 with I2C configuration
https://git.kernel.org/krzk/linux/c/f3635d5ff6105e6e0450b2e7f7bb0055f0fea305
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
On Fri, 19 Jan 2024 11:11:31 +0000, Tudor Ambarus wrote:
> USI8 I2C is used to communicate with an eeprom found on the battery
> connector. Define USI8 in I2C configuration.
>
> USI8 CONFIG register comes with a 0x0 reset value, meaning that USI8
> doesn't have a default protocol (I2C, SPI, UART) at reset. Thus the
> selection of the protocol is intentionally left for the board dts file.
>
> [...]
Applied, thanks!
[7/8] arm64: dts: exynos: gs101: define USI8 with I2C configuration
https://git.kernel.org/krzk/linux/c/9ca7055a35a7b2b373ead6f3a67ee8b5e0e6e468
Best regards,
--
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
© 2016 - 2025 Red Hat, Inc.