Re: [PATCH] rpmsg: Solve circular dependencies involving RPMSG_VIRTIO

From: Bjorn Andersson
Date: Tue Jun 27 2017 - 17:47:33 EST


On Tue 27 Jun 12:08 PDT 2017, Suman Anna wrote:

> Hi Bjorn,
>
> Thanks for the patch.
>
> On 06/27/2017 01:43 AM, Bjorn Andersson wrote:
> > While it's very common to use RPMSG for communicating with firmware
> > running on these remoteprocs there is no functional dependency on RPMSG.
>
> This is not entirely accurate though. RPMSG is the IPC transport on
> these remoteprocs, you seem to suggest that there are alternatives for
> these remoteprocs. Without RPMSG, you can boot, but you will not be able
> to talk to the remoteprocs, so I would call it a functional dependency.
>

IMHO this functional dependency is not from the remoteproc driver but
your system (and firmware) design. It should be possible to write
firmware that exposes any other type of virtio device.

> > As such RPMSG should be selected by the system integrator and not
> > automatically by the remoteproc drivers.
> >
> > This does solve problems reported with circular Kconfig dependencies for
> > Davinci and Keystone remoteproc drivers.
>
> The Keystone one issue shows up on linux-next (and not on 4.12-rcX) due
> to the differing options on RESET_CONTROLLER on VIDEO_QCOM_VENUS
> (through QCOM_SCOM).

That's probably why I didn't see this when build testing before pushing
this.

> This can also be resolved by changing the depends on RESET_CONTROLLER
> to a select RESET_CONTROLLER or dropping the line.
>

Except that this would violate the general rule of "don't use 'select'
for user-selectable options".

> The davinci one is tricky though, as I did change it from using a select
> to a depends on dependency, and obviously ppc64_defconfig is something
> that I would not check.
>

While I hate the process of figuring out and enable all the dependencies
to be able to enable a particular config, this change does reduce the
risk of running into more of these cyclic dependencies.

> This patch definitely resolves both issues, but it is not obvious that
> someone would also have to enable RPMSG_VIRTIO to have these remoteprocs
> useful when looking at either of the menuconfig help.
>

This is a common issue we have with config options and while I hate to
add another item to the list of things that you can miss in your system
configuration I would prefer that my Kconfig is maintainable.

This also means that most remoteproc drivers should "depends on MAILBOX"
and not select either the framework or the specific drivers. But let's
try to ignore that until after the merge window.

Regards,
Bjorn

> regards
> Suman
>
> >
> > Signed-off-by: Bjorn Andersson <bjorn.andersson@xxxxxxxxxx>
> > ---
> > drivers/media/platform/Kconfig | 2 +-
> > drivers/remoteproc/Kconfig | 4 ----
> > drivers/rpmsg/Kconfig | 20 +++++++++-----------
> > 3 files changed, 10 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
> > index 1313cd533436..cb2f31cd0088 100644
> > --- a/drivers/media/platform/Kconfig
> > +++ b/drivers/media/platform/Kconfig
> > @@ -382,10 +382,10 @@ config VIDEO_STI_DELTA_DRIVER
> > tristate
> > depends on VIDEO_STI_DELTA
> > depends on VIDEO_STI_DELTA_MJPEG
> > + depends on RPMSG
> > default VIDEO_STI_DELTA_MJPEG
> > select VIDEOBUF2_DMA_CONTIG
> > select V4L2_MEM2MEM_DEV
> > - select RPMSG
> >
> > endif # VIDEO_STI_DELTA
> >
> > diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> > index b950e6cd4ba2..3b16f422d30c 100644
> > --- a/drivers/remoteproc/Kconfig
> > +++ b/drivers/remoteproc/Kconfig
> > @@ -21,7 +21,6 @@ config OMAP_REMOTEPROC
> > depends on REMOTEPROC
> > select MAILBOX
> > select OMAP2PLUS_MBOX
> > - select RPMSG_VIRTIO
> > help
> > Say y here to support OMAP's remote processors (dual M3
> > and DSP on OMAP4) via the remote processor framework.
> > @@ -53,7 +52,6 @@ config DA8XX_REMOTEPROC
> > depends on ARCH_DAVINCI_DA8XX
> > depends on REMOTEPROC
> > depends on DMA_CMA
> > - select RPMSG_VIRTIO
> > help
> > Say y here to support DA8xx/OMAP-L13x remote processors via the
> > remote processor framework.
> > @@ -76,7 +74,6 @@ config KEYSTONE_REMOTEPROC
> > depends on ARCH_KEYSTONE
> > depends on RESET_CONTROLLER
> > depends on REMOTEPROC
> > - select RPMSG_VIRTIO
> > help
> > Say Y here here to support Keystone remote processors (DSP)
> > via the remote processor framework.
> > @@ -133,7 +130,6 @@ config ST_REMOTEPROC
> > depends on REMOTEPROC
> > select MAILBOX
> > select STI_MBOX
> > - select RPMSG_VIRTIO
> > help
> > Say y here to support ST's adjunct processors via the remote
> > processor framework.
> > diff --git a/drivers/rpmsg/Kconfig b/drivers/rpmsg/Kconfig
> > index 2a5d2b446de2..46f3f2431d68 100644
> > --- a/drivers/rpmsg/Kconfig
> > +++ b/drivers/rpmsg/Kconfig
> > @@ -1,8 +1,5 @@
> > -menu "Rpmsg drivers"
> > -
> > -# RPMSG always gets selected by whoever wants it
> > -config RPMSG
> > - tristate
> > +menuconfig RPMSG
> > + tristate "Rpmsg drivers"
> >
> > config RPMSG_CHAR
> > tristate "RPMSG device interface"
> > @@ -15,7 +12,7 @@ config RPMSG_CHAR
> >
> > config RPMSG_QCOM_GLINK_RPM
> > tristate "Qualcomm RPM Glink driver"
> > - select RPMSG
> > + depends on RPMSG
> > depends on HAS_IOMEM
> > depends on MAILBOX
> > help
> > @@ -26,16 +23,17 @@ config RPMSG_QCOM_GLINK_RPM
> > config RPMSG_QCOM_SMD
> > tristate "Qualcomm Shared Memory Driver (SMD)"
> > depends on QCOM_SMEM
> > - select RPMSG
> > + depends on RPMSG
> > help
> > Say y here to enable support for the Qualcomm Shared Memory Driver
> > providing communication channels to remote processors in Qualcomm
> > platforms.
> >
> > config RPMSG_VIRTIO
> > - tristate
> > - select RPMSG
> > + tristate "Virtio remote processor messaging driver (RPMSG)"
> > + depends on RPMSG
> > select VIRTIO
> > select VIRTUALIZATION
> > -
> > -endmenu
> > + help
> > + Say y here to enable support for the Virtio remote processor
> > + messaging protocol (RPMSG).
> >
>