[PATCH 0/4] stm32mp: add minimal RCC support for STM32MP13

[Patrick DELAUNAY]

Hi,

On 5/11/22 18:44, Sean Anderson wrote:
> Hi Patrick,
>
> On 5/10/22 3:51 AM, Patrick Delaunay wrote:
>>
>> Add a minimal support for STM32MP13 RCC, the reset and clock controller
>> - update of the RCC MISC driver to bind the correct clock and reset 
>> driver
>> - reset driver, same than STM32MP15x = drivers/reset/stm32-reset.c
>> - clock driver, add a empty driver for STM32MP13x =
>>    drivers/clk/stm32/clk-stm32mp13.c
>> - Add RCC node in SOC device tree with u-boot,dm-pre-reloc property
>>
>> This serie is only a preliminary step for STM32MP13 clock and reset 
>> support
>> in U-Boot, based on Linux kernel binding introduced by [1] and it 
>> prepares
>> the next device tree alignment with Linux kernel.
>>
>> The functional STMP13 clock driver based on CCF and on SCMI clocks
>> provided by OP-TEE and the clock and reset references in SOC device tree
>> will be pushed when the associated patches in [1] will be accepted.
>>
>> [1] Introduction of STM32MP13 RCC driver (Reset Clock Controller)
>> https://lore.kernel.org/linux-arm-kernel/20220316131000.9874-1-gabriel.fernandez@foss.st.com/
>
> I'm not really sure what the purpose of this series is. Can you
> elaborate a bit on why we need a dummy clock driver? Why don't
> you just add the binding to the device tree without the associated
> driver?


After this serie, the RCC reset part is functional on STM32MP13 (probe 
and ops)

even if the associated binding is not present in device tree.

tested with:

------------------------- arch/arm/dts/stm32mp131.dtsi 
-------------------------
index fcb0af09b5..d9c6185bcf 100644
@@ -197,6 +197,7 @@
              interrupt-names = "cmd_irq";
              clocks = <&clk_pll4_p>;
              clock-names = "apb_pclk";
+            resets = <&rcc 14224>;
              cap-sd-highspeed;
              cap-mmc-highspeed;
              max-frequency = <130000000>;


A dummy STM32MP13 clock driver is requested to allow RCC MISC and RCC RESET

binding and probe without issue.


This reset support was requested by SDMCC driver and SD-Card boot, 
before the patch:

http://patchwork.ozlabs.org/project/uboot/patch/20220506160540.13.I39b69e8dc7b43b8e265e77388fb53f7c1fa2a007@changeid/


As we solve the SDMCC dependency issue (reset become optionnal), so this 
serie is no more mandatory.


This serie is a just a cleanup / preliminary step, but I can drop this 
dummy RCC driver if it is disturbing.


>
> --Sean


Patrick