On 18.07.2023 20:07, Dmitry Baryshkov wrote: > On 18/07/2023 15:19, Konrad Dybcio wrote: >> v3 -> v4: >> - Fix up indentation in the bindings patch >> - Add an example glink-edge subnode to remoteproc-rpm (its bindings >> require that..) >> >> Link to v3: https://lore.kernel.org/r/20230328-topic-msgram_mpm-v3-0-2c72f27b4706@xxxxxxxxxx >> >> v2 -> v3: >> - Fix the example >> - Pick up tags >> - remove the outdated example from the cover letter, check bindings >> should you want to see one >> >> The bindings for the wrapper node used in the yaml example are merged >> in qcom/for-next >> >> Link to v2: https://lore.kernel.org/r/20230328-topic-msgram_mpm-v2-0-e24a48e57f0d@xxxxxxxxxx >> >> v1 -> v2: >> - deprecate 'reg', make qcom,rpm-msg-ram required [1/2] >> - Use devm_ioremap() [2/2] >> >> Link to v1: https://lore.kernel.org/r/20230328-topic-msgram_mpm-v1-0-1b788a5f5a33@xxxxxxxxxx >> >> Depends on resolution of https://github.com/devicetree-org/dt-schema/issues/104 >> >> The MPM (and some other things, irrelevant to this patchset) resides >> (as far as the ARM cores are concerned, anyway) in a MMIO-mapped region >> that's a portion of the RPM (low-power management core)'s RAM, known >> as the RPM Message RAM. Representing this relation in the Device Tree >> creates some challenges, as one would either have to treat a memory >> region as a bus, map nodes in a way such that their reg-s would be >> overlapping, or supply the nodes with a slice of that region. >> >> This series implements the third option, by adding a qcom,rpm-msg-ram >> property, which has been used for some drivers poking into this region >> before. Bindings ABI compatibility is preserved through keeping the >> "normal" (a.k.a read the reg property and map that region) way of >> passing the register space. > > This almost bleeds to have some uniformity with qcom,rpm-stats (and with the boot stats). All these drivers provides us with the insight into the RPM memory. RPM master stats - yes, it should be moved under this node. The other stats - I don't yet know. Konrad
