[PATCH v7 2/7] dt-bindings: memory-controllers: Add STM32 Octo Memory Manager controller

[Rob Herring]

On Wed, Apr 02, 2025 at 10:45:08AM +0200, Krzysztof Kozlowski wrote:
> On 02/04/2025 00:20, Rob Herring wrote:
> >> +      clocks = <&rcc CK_BUS_OSPIIOM>,
> >> +               <&scmi_clk CK_SCMI_OSPI1>,
> >> +               <&scmi_clk CK_SCMI_OSPI2>;
> >> +      clock-names = "omm", "ospi1", "ospi2";
> >> +      resets = <&rcc OSPIIOM_R>,
> >> +               <&scmi_reset RST_SCMI_OSPI1>,
> >> +               <&scmi_reset RST_SCMI_OSPI2>;
> >> +      reset-names = "omm", "ospi1", "ospi2";
> >> +      access-controllers = <&rifsc 111>;
> >> +      power-domains = <&CLUSTER_PD>;
> >> +      #address-cells = <2>;
> >> +      #size-cells = <1>;
> >> +      st,syscfg-amcr = <&syscfg 0x2c00 0x7>;
> >> +      st,omm-req2ack-ns = <0>;
> >> +      st,omm-mux = <0>;
> >> +      st,omm-cssel-ovr = <0>;
> >> +
> >> +      spi at 0 {
> >> +        compatible = "st,stm32mp25-ospi";
> >> +        reg = <0 0 0x400>;
> >> +        memory-region = <&mm_ospi1>;
> >> +        interrupts = <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>;
> >> +        dmas = <&hpdma 2 0x62 0x00003121 0x0>,
> >> +               <&hpdma 2 0x42 0x00003112 0x0>;
> >> +        dma-names = "tx", "rx";
> >> +        clocks = <&scmi_clk CK_SCMI_OSPI1>;
> >> +        resets = <&scmi_reset RST_SCMI_OSPI1>, <&scmi_reset RST_SCMI_OSPI1DLL>;
> > 
> > Looks like you are duplicating properties in the parent and child nodes. 
> > Maybe that accurately models the h/w, but if it is just so the drivers 
> > can get the resources from "the driver's node", you can always just look 
> > in the child nodes for the resources (as probably you want to drop the 
> > per instance resources from the parent).
> 
> 
> The current solution was actually my suggestion because if a parent
> device has to toggle child's reset, it means it actually is the consumer
> of that reset one way or another. IOW, it is one of its resources.
> 
> This also might matter for some of the implementations because we might
> need to setup device links or do some probe-ordering (in the future)
> between parent and the reset provider.
> 
> Without reset resource in the parent, I could imagine probe order:
> 1. parent (pokes into the child for reset)
> 2. reset and clock providers
> 3. child
> which would defer between 1 and 2.
> 
> With parent having the resource it would be re-ordered into:
> 1. reset and clock providers
> 2. parent
> 3. child

Okay, fair enough.

Rob