| Message ID | 20240119111132.1290455-8-tudor.ambarus@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | GS101 Oriole: CMU_PERIC0 support and USI updates | expand |
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
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,
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";