diff mbox series

[v4,7/8] arm64: dts: exynos: gs101: define USI8 with I2C configuration

Message ID 20240119111132.1290455-8-tudor.ambarus@linaro.org
State New
Headers show
Series GS101 Oriole: CMU_PERIC0 support and USI updates | expand

Commit Message

Tudor Ambarus Jan. 19, 2024, 11:11 a.m. UTC
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(+)

Comments

Krzysztof Kozlowski Jan. 22, 2024, 11:15 a.m. UTC | #1
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 Jan. 23, 2024, 7:52 a.m. UTC | #2
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.

Best regards,
Krzysztof
Tudor Ambarus Jan. 23, 2024, 8:34 a.m. UTC | #3
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
Krzysztof Kozlowski Jan. 23, 2024, 8:39 a.m. UTC | #4
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
Tudor Ambarus Jan. 23, 2024, 8:44 a.m. UTC | #5
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.
Tudor Ambarus Jan. 23, 2024, 8:57 a.m. UTC | #6
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
Krzysztof Kozlowski Jan. 23, 2024, 8:59 a.m. UTC | #7
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
Tudor Ambarus Jan. 23, 2024, 9:09 a.m. UTC | #8
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
Krzysztof Kozlowski Jan. 23, 2024, 9:54 a.m. UTC | #9
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,
diff mbox series

Patch

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";