On Tue, Dec 9, 2025 at 5:27 PM Rob Herring <[email protected]> wrote: > > On Tue, Dec 09, 2025 at 04:04:25PM +0200, Daniel Baluta wrote: > > After commit 67a7bc7f0358 ("remoteproc: Use of reserved_mem_region_* > > functions for "memory-region"") following commands with > > imx-dsp-rproc started to fail: > > > > $ echo zephyr.elf > /sys/class/remoteproc/remoteproc0/firmware > > $ echo start > /sys/class/remoteproc/remoteproc0/state > > $ echo stop > /sys/class/remoteproc/remoteproc0/state > > $ echo start > /sys/class/remoteproc/remoteproc0/state #! This fails > > -sh: echo: write error: Device or resource busy > > So unlike Marek's case, the first time works. Can you confirm your > region is fixed address?
Yes, all regions are fixed addresses. > > + cpu_addr = devm_ioremap_wc(dev, res.start, > > resource_size(&res)); > > Best case this is reusing the same mapping and we just have unnecessary > ioremap and iounmap calls and devm entries. Worst case, we get a new > virtual mapping every time. IIRC, arm32 will reuse existing mapping, but > arm64 does not. But that's 10+ years ago I looked into it. > > Seems like devres is not the right lifetime. This should be just > ioremap_wc() instead. Yes, looks like for arm64 (imx8mp-evk) will not reuse existing mapping but creates a new one. Best course of action would be as Iulia suggested to move the operation at probe instead of prepare.
