Message ID | 20240119111132.1290455-1-tudor.ambarus@linaro.org |
---|---|
Headers | show |
Series | GS101 Oriole: CMU_PERIC0 support and USI updates | expand |
On 19/01/2024 12:11, Tudor Ambarus wrote: > CMU_PERIC0 is the clock management unit used for the peric0 block which > is used for USI and I3C. Add support for all cmu_peric0 clocks but > CLK_GOUT_PERIC0_IP (not enough info in the datasheet). > > Few clocks are marked as critical because when either of them is > disabled, the system hangs even if their clock parents are enabled. > > Reviewed-by: Peter Griffin <peter.griffin@linaro.org> > Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> > Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> > --- > drivers/clk/samsung/clk-gs101.c | 583 ++++++++++++++++++++++++++++++++ > 1 file changed, 583 insertions(+) > This does not apply. Please rebase on my samsung for-next or next linux-next and resend. Best regards, Krzysztof
On Fri, 19 Jan 2024 11:11:25 +0000, Tudor Ambarus wrote: > Add dt-schema documentation for the Connectivity Peripheral 0 (PERIC0) > clock management unit. > > Applied, thanks! [1/8] dt-bindings: clock: google,gs101-clock: add PERIC0 clock management unit https://git.kernel.org/krzk/linux/c/b393a6c5e65652a19733978c3711c7c05c497594 Best regards,
On 1/22/24 11:13, Krzysztof Kozlowski wrote: > On 19/01/2024 12:11, Tudor Ambarus wrote: >> CMU_PERIC0 is the clock management unit used for the peric0 block which >> is used for USI and I3C. Add support for all cmu_peric0 clocks but >> CLK_GOUT_PERIC0_IP (not enough info in the datasheet). >> >> Few clocks are marked as critical because when either of them is >> disabled, the system hangs even if their clock parents are enabled. >> >> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> >> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> >> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org> >> --- >> drivers/clk/samsung/clk-gs101.c | 583 ++++++++++++++++++++++++++++++++ >> 1 file changed, 583 insertions(+) >> > > This does not apply. Please rebase on my samsung for-next or next > linux-next and resend. > Oh, yes. I rebased, did a boot test and then sent v5 at: https://lore.kernel.org/linux-arm-kernel/20240122114113.2582612-1-tudor.ambarus@linaro.org/T/#u Thanks! ta
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 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: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