On Mi, 2025-02-19 at 21:20 +0200, Daniel Baluta wrote: > On i.MX8MP we introduced support for using a reset controller > to control DSP operation. > > This patch adds reset property which is required for i.MX8MP. > > Signed-off-by: Daniel Baluta <daniel.baluta@xxxxxxx> > --- > .../devicetree/bindings/dsp/fsl,dsp.yaml | 19 ++++++++++++++++++- > 1 file changed, 18 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml > index ab93ffd3d2e5..923e7f079f1b 100644 > --- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml > +++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml > @@ -82,6 +82,13 @@ properties: > description: > Phandle to syscon block which provide access for processor enablement > > + resets: > + description: > + A pair consisting of phandle to audio-blk-control and an index referencing > + the DSP Run/Stall bit in audiomix registers. > + See include/dt-bindings/reset/imx8mp-reset-audiomix.h for each index meaning. > + maxItems: 1 This is going to be confusing when there is an actual (undocumented?) DSP core reset that is not described in the device tree bindings, see patch 8. To me this looks like a bit of a gray zone, as I don't know how the hardware actually works, but if you wouldn't call the Run/Stall bit a reset, it probably shouldn't be described as such in the device tree bindings. I'm not sure. Should both core and runstall reset be described in the device tree? Or only the core reset, or neither? Either way we should try not to lie about the hardware here. regards Philipp
