Hello Shenwei,
On 10/6/25 16:33, Shenwei Wang wrote:
Hi Arnaud,
-----Original Message-----
From: Arnaud POULIQUEN <[email protected]>
Sent: Monday, October 6, 2025 4:53 AM
To: Shenwei Wang <[email protected]>; Bjorn Andersson
<[email protected]>; Mathieu Poirier <[email protected]>; Rob
Herring <[email protected]>; Krzysztof Kozlowski <[email protected]>; Conor
Dooley <[email protected]>; Shawn Guo <[email protected]>; Sascha
Hauer <[email protected]>; Linus Walleij <[email protected]>;
Bartosz Golaszewski <[email protected]>
Cc: Pengutronix Kernel Team <[email protected]>; Fabio Estevam
<[email protected]>; Peng Fan <[email protected]>; linux-
[email protected]; [email protected]; [email protected];
[email protected]; [email protected]; dl-linux-imx
<[email protected]>; [email protected]
Subject: [EXT] Re: [PATCH v2 3/4] gpio: imx-rpmsg: add imx-rpmsg GPIO driver
Then, the RPMsg device should be probed either by the remote
processor using the name service announcement mechanism or if not
possible by your remoteproc driver.
The idea is to probe the GPIO driver successfully only after the remote
processor is online and has sent the name service announcement.
Until then, the GPIO driver will remain in a deferred state, ensuring that all
consumers of the associated GPIOs are also deferred.
The implementation you provided below does not guarantee that the
related consumers will be properly deferred. This is the most important
behavior for a GPIO/I2C controllers.
As long as you keep the GPIO/I2C device as a child of the remote processor node,
you should not have deferred probe issues.
The|of_platform_populate()|function ensures
that the I2C/GPIO devices are probed when the remote processor is started.
Calling|devm_gpiochip_add_data|in the RPMsg driver probe should also
prevent such issues.
Here, deferred probing is not an issue -it's an intentional feature. We need to
ensure that all consumers of the GPIO/I2C controllers remain
in the deferred state until the remote processor is fully online.
For instance, consider a regulator node that references a GPIO line from the
RPMSG GPIO controller. The regulator will stay in the deferred state
until the remote processor comes online and its services are announced and
received.
I think there is a misunderstanding. My intention was just to mention
that in my proposal, the deferred mechanism should also work as
expected. This is the case for the rpmsg_i2c I mentioned as an example.
Anyway the main point here is to break the dependency between your
remoteproc driver and the rpmsg GPIO driver. In your remoteproc
driver, you should just call of_platform_populate, and let's the
compatible mechanism find the associated independent driver defined
in the rpmsg_gpio.c
From my perspective the sequence should be
1) the remoteproc driver starts the remote processor
2) the remoteproc driver parses the child node with of_platform_populate
3) the rpmsg_gpio platform driver is probed by the of_platform_populate
- parse the DT node and store configuration in data structure
- register an rpmsg_gpio driver
4) the rpmsg gpio driver is probed (by the rpmsg bus).
- register the GPIO and irq chips
Until step 4, the users should be automatically deferred
That said, regarding your implementation, the fact that you have created
a single rpmsg endpoint for several rpmsg services complexify this
approach , creating a dependency not only between rpmsg and remoteproc
but also among rpmsg devices. Having a single rpmsg endpoint associated
with a single rpmsg service would simplify things.
Of course, I am just sharing my opinion and expectations here. For the
next steps, I will let the maintainers, Mathieu and Bjorn, provide their
advice and guidance.
Thanks,
Arnaud
Thanks,
Shenwei
Regards,
Arnaud
Thanks,
Shenwei
To better understand my proposal you can have a look to [1]and [2].
Here is another example for an rpmsg_i2c( ST downstream implementation):
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
