Re: [PATCH v2 2/8] dt-bindings: dsp: fsl,dsp: Add resets property

[Frank Li <Frank.li@nxp.com>]

On Thu, Feb 20, 2025 at 04:45:42PM +0100, Philipp Zabel wrote:
> 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@nxp.com>
> > ---
> >  .../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.

According to some hardware common sense for cpu core. Generally release
RESET Pin to let core runnings. Difference system use difference signal
name. Spec/RM generally copy from hardware sign name. The functionaltiy
is work as core reset.  Release 'reset' let core go. The module is abstract
layer for the function.

>
> 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.

Not lie about hardware. Try match hardware behavior to existed abstract
module. Hardware is back box, which we often only observe it from outside.
But I can assume hardware implement like

	swtich(state) {
		...
		state = new state;
		...
		case RUNSTALL:
		state = state;
	}

Of course, hardware may use simple gate a input clock to run/stall a core.

Frank

>
> regards
> Philipp