[PATCH] remoteproc: imx_rproc: replace devm_clk_get() with devm_clk_get_optional()

[Hiago De Franco]

Hi Mathieu,

On Wed, Apr 23, 2025 at 11:14:17AM -0600, Mathieu Poirier wrote:
> Good morning,
> 
> On Wed, Apr 23, 2025 at 12:51:31PM -0300, Hiago De Franco wrote:
> > From: Hiago De Franco <hiago.franco at toradex.com>
> > 
> > The "clocks" device tree property is not mandatory, and if not provided
> > Linux will shut down the remote processor power domain during boot if it
> > is not present, even if it is running (e.g. it was started by U-Boot's
> > bootaux command).
> 
> If a clock is not present imx_rproc_probe() will fail, the clock will remain
> unused and Linux will switch it off.  I think that is description of what is
> happening.
> 
> > 
> > Use the optional devm_clk_get instead.
> > 
> > Signed-off-by: Hiago De Franco <hiago.franco at toradex.com>
> > ---
> >  drivers/remoteproc/imx_rproc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> > index 74299af1d7f1..45b5b23980ec 100644
> > --- a/drivers/remoteproc/imx_rproc.c
> > +++ b/drivers/remoteproc/imx_rproc.c
> > @@ -1033,7 +1033,7 @@ static int imx_rproc_clk_enable(struct imx_rproc *priv)
> >  	if (dcfg->method == IMX_RPROC_NONE)
> >  		return 0;
> >  
> > -	priv->clk = devm_clk_get(dev, NULL);
> > +	priv->clk = devm_clk_get_optional(dev, NULL);
> 
> If my understanding of the problem is correct (see above), I think the real fix
> for this is to make the "clocks" property mandatory in the bindings.

Thanks for the information, from my understanding this was coming from
the power domain, I had a small discussion about this with Peng [1],
where I was able to bisect the issue into a scu-pd commit. But I see
your point for this commit, I can update the commit description.

About the change itself, I was not able to find a defined clock to use
into the device tree node for the i.MX8QXP/DX, maybe I am missing
something? I saw some downstream device trees from NXP using a dummy
clock, which I tested and it works, however this would not be the
correct solution.

[1] https://lore.kernel.org/lkml/20250404141713.ac2ntcsjsf7epdfa@hiago-nb/

Cheers,
Hiago.

> 
> Daniel and Iuliana, I'd like to have your opinions on this.
> 
> Thanks,
> Mathieu
> 
> >  	if (IS_ERR(priv->clk)) {
> >  		dev_err(dev, "Failed to get clock\n");
> >  		return PTR_ERR(priv->clk);
> > -- 
> > 2.39.5
> >