Re: How the registration of rpmsg devices should be done?

From: Tzu-Jung Lee
Date: Wed Jul 04 2012 - 06:57:10 EST


On Wed, Jul 4, 2012 at 4:36 PM, Ohad Ben-Cohen <ohad@xxxxxxxxxx> wrote:
> Hi,
>
> On Wed, Jul 4, 2012 at 11:26 AM, Tzu-Jung Lee <roylee17@xxxxxxxxx> wrote:
>> I working on the IPC functionality on our SoC and is looking into the
>> rpmsg & remoteproc framework of inux v3.4.
>
> Great! Which SoC are you working on ?
>> Since rpmsg_create_channel() is static and internal to rpmsg module,
>> I'm wondering how the registration of rpmsg device should be done?
>
> From Documentation/rpmsg.txt:
>
> "4. Allocations of rpmsg channels:
>
> At this point we only support dynamic allocations of rpmsg channels.
>
> This is possible only with remote processors that have the VIRTIO_RPMSG_F_NS
> virtio device feature set. This feature bit means that the remote
> processor supports dynamic name service announcement messages.
>
> When this feature is enabled, creation of rpmsg devices (i.e. channels)
> is completely dynamic: the remote processor announces the existence of a
> remote rpmsg service by sending a name service message (which contains
> the name and rpmsg addr of the remote service, see struct rpmsg_ns_msg).
>
> This message is then handled by the rpmsg bus, which in turn dynamically
> creates and registers an rpmsg channel (which represents the remote service).
> If/when a relevant rpmsg driver is registered, it will be immediately probed
> by the bus, and can then start sending messages to the remote service.
>
> The plan is also to add static creation of rpmsg channels via the virtio
> config space, but it's not implemented yet."

Got it. Thanks for your prompt guide.

I'll go with the static route for now as OMAP branch does, and get
back later when the "remote end" (maybe a simulated one) getting a
good shape.

Thanks,
Roy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/